Detailed application assessment - AWS Prescriptive Guidance
GeneralArchitectureOperationsPerformanceSoftware lifecycleMigrationResiliencySecurity and complianceDatabasesDependencies

Detailed application assessment

The goal of a detailed application assessment is the complete understanding of the targeted application and its associated infrastructure (compute, storage, and network). High-fidelity data is necessary to avoid pitfalls. For example, it is common for organizations to assume that they fully understand the application. This is natural, and it's true in many cases. However, to minimize risk to the business, it is important to validate institutional knowledge and static documentation by obtaining programmatic data as much as possible. This will take care of the heavy lifting of the discovery process. You can focus on the data elements that come from alternative sources, such as business-specific information, strategic roadmaps, and others.

The key is to avoid last-minute changes during and after migration. For example, when migrating, it's important to avoid changes based on unidentified dependencies that might require the inclusion of a server into an ongoing migration wave. Shortly after migration, it's important to avoid changes based on the associated platform requirements to allow traffic or deploy additional services. These kinds of unplanned changes increase the risk of security and operational issues. We highly recommend using programmatic discovery tooling to validate traffic patterns and dependencies when performing detailed application assessments.

At the beginning of the assessment, you must identify the application stakeholders. These are typically the following:

  • Business unit leads

  • Application owners

  • Architects

  • Operations and support

  • Cloud-enablement teams

  • Specific platform teams such as compute, storage, and networks

There are two approaches for detailed discovery. Top-down discovery starts with the application, or even with the user, and goes all the way down to the infrastructure. This is the recommended approach when the identification of the application is clear. Conversely, bottom-up discovery starts with the infrastructure and goes all the way up to the application or service and its users. This approach is useful when migration programs are driven by infrastructure teams and when application-to-infrastructure mapping is unclear. In general, you are likely to use a combination of both.

To dive deep into an application, existing architecture diagrams are good start. If these are not available, create one based on current knowledge. Do not underestimate the importance of this task, even for simple rehost or relocate migration strategies. Plotting architectural diagrams helps you to identify inefficiencies that can be quickly addressed with minor changes when in the cloud.

Depending on whether you are performing a top-down or bottom-up approach, the initial diagram will plot application components and services or infrastructure components such as servers and load balancers. After the main components and interfaces have been identified, validate them with programmatic data from discovery tools and application performance monitoring tools. The tools must support dependency analysis and provide communication information between components. Each component that makes up this application must be identified. Next, document dependencies to other applications and services, both internal and external.

In the absence of tooling to validate dependencies and mapping, a manual approach is required. For example, you can log into infrastructure components and run scripts to collect communication information such as open ports and established connections. Likewise, you can identify running processes and installed software. Don't underestimate the effort required for manual discovery. Programmatic tooling can capture and report most dependencies in a few days, except those that occur at greater intervals (typically a small percentage). Manual discovery can take weeks to collect and merge all data points, and it can still be prone to errors and missing data.

Proceed to obtain the information specified in the data requirements section for each prioritized application and the mapped infrastructure. Next, use the following questionnaire to guide you through the detailed assessment process. Meet with the identified stakeholders to discuss the answers to these questions.

General

  • What is the criticality level of this application? Is it revenue generating? Is it a business-strategic or supporting-business application? Is it a core infrastructure service shared by other systems?

  • Is there any ongoing transformation project for this application?

  • Is this an internally or externally facing application?

Architecture

  • What is the current architecture type (for example, SOA, microservices, monolith)? How many tiers does the architecture have? Is it tightly coupled or loosely coupled?

  • What are the components (for example, compute, databases, remote storage, load balancers, caching services)?

  • What are the APIs? Describe these, including API name, operations, URLs, ports, and protocols.

  • What is the maximum latency tolerated between components and between this and other applications or services?

Operations

  • In what locations does this application operate?

  • Who operates the application and infrastructure? Are these operated by internal or AWS Partner teams?

  • What happens if this application goes down? Who is affected? What is the impact?

  • Where are users or customers located? How do they access the application? What is the number of concurrent users?

  • When was the last technology refresh? Is a refresh scheduled in the future? If so, when?

  • What are the known risks and issues for this application? What is the history of outages and medium-severity and high severity incidents?

  • What is the usage cycle (in business hours)? What is the operating time zone?

  • What are the change freeze periods?

  • What solution is used to monitor this application?

Performance

  • What does the collected performance information show? Is usage spiky or constant and predictable? What is the time frame, interval, and date of the available performance data?

  • Are there scheduled batch jobs that are part of or interact with this application?

Software lifecycle

  • What is the current rate of change (weekly, monthly, quarterly, or yearly)?

  • What is the development lifecycle (for example, test, development, QA, UAT, pre-production, production)?

  • What are the deployment methods for application and infrastructure?

  • What is the deployment tooling?

  • Does this application or infrastructure use continuous integration (CI)/continuous delivery (CD)? What is the level of automation? What are the manual tasks?

  • What are the licensing requirements for the application and infrastructure?

  • What is the service level agreement (SLA)?

  • What are the current test mechanisms? What are the test stages?

Migration

  • What are the migration considerations?

At this point, note any considerations when migrating this application. For a more complete and accurate assessment, obtain answers to this question from the different stakeholders. Then contrast their knowledge and opinions.

Resiliency

  • What is the current backup method? What products are used for backup? What is the backup schedule? What is the backup retention policy?

  • What are the current recovery point objective (RPO) and recovery time objective (RTO)?

  • Does this application have a disaster recovery (DR) plan? If so, what is the DR solution?

  • When was the last DR test?

Security and compliance

  • What are the compliance and regulatory frameworks that apply to this application? What are the last and next audit dates?

  • Does this application host sensitive data? What is the data classification?

  • Is the data encrypted in transit or at rest, or both? What is the encryption mechanism?

  • Does this application use Secure Sockets Layer (SSL) certificates? What is the issuing authority?

  • What is the authentication method for users, components, and other applications and services?

Databases

  • What databases does this application use?

  • What is the typical number of concurrent connections to the database? What are the minimum number and maximum number of connections?

  • What is the connection method (for example, JDBC, ODBC)?

  • Are connection strings documented? If so, where?

  • What are the database schemas?

  • Does the database use custom data types?

Dependencies

  • What is the dependency between components? Note any dependencies that can't be resolved and that will require migrating the components together.

  • Are components split across locations? What is the connectivity between these locations (for example, WAN, VPN)?

  • What are the dependencies of this application to other applications or services?

  • What are the operational dependencies? For example, maintenance and release cycles such as patching windows.