AWS prescriptive-guidance documentation change
Summary
Updated dependency descriptions for clarity, restructured content about infrastructure dependencies, added wave planning reference, and corrected migration strategy link.
Security assessment
Changes are editorial improvements to dependency categorization and migration strategy documentation. No security vulnerabilities, security features, or security-specific content is mentioned or added. The modifications focus on technical dependencies and migration processes without security implications.
Diff
diff --git a/prescriptive-guidance/latest/application-portfolio-assessment-guide/baseline-application-portfolio.md b/prescriptive-guidance/latest/application-portfolio-assessment-guide/baseline-application-portfolio.md index 1af3c8ee2..ff1919b91 100644 --- a//prescriptive-guidance/latest/application-portfolio-assessment-guide/baseline-application-portfolio.md +++ b//prescriptive-guidance/latest/application-portfolio-assessment-guide/baseline-application-portfolio.md @@ -17 +17 @@ Technical dependencies can be described in four categories: - * **Application-to-application** dependencies relate to the interaction between applications or application components with other applications or their components. An example of an application-to-application dependency is a payment-processing application and a stock-management application. These applications are independent, but they constantly interact using defined API operations. + * **Application-to-application** dependencies relate to the interaction between different applications or its components. An example of an application-to-application dependency is a payment-processing application and a stock-management application. These applications are independent, but they constantly interact using defined API operations or shared datasets. @@ -19 +19 @@ Technical dependencies can be described in four categories: - * **Application-to-infrastructure services** dependencies are technically application-to-application dependencies, given that the infrastructure service is itself an application. However, we recommend categorizing these separately. The main reason is that infrastructure services typically are shared by many applications, so they have a long trail of dependencies. They also typically follow a different migration strategy and pattern.For example, a load balancer can contain balancing pools for several applications. What matters is the dependency to the pool, which is likely to be migrated individually, alongside the dependent application, while the load balancer itself is retained or retired.In addition, individualizing application-to-infrastructure service dependencies helps to avoid false dependency groups. A false dependency group is when several business applications are grouped together, implying that have a common dependency to an infrastructure service must be migrated at the same time. For example, authentication services, such as Active Directory, are likely to be associated with large groups of applications. The key is to approach these applications individually and to address the dependency by enabling the service, such as AWS Directory Service for Microsoft Active Directory, in the cloud environment. + * **Application-to-infrastructure services** dependencies are technically application-to-application dependencies, given that the infrastructure service is itself an application. However, we recommend categorizing these separately. The main reason is that infrastructure services typically are shared by many applications, so they have a long trail of dependencies. They also typically follow a different migration strategy and pattern. @@ -20,0 +21 @@ Technical dependencies can be described in four categories: +For example, a load balancer can contain balancing pools for several applications. What matters is the dependency to the pool, which is likely to be migrated individually, alongside the dependent application, while the load balancer itself is retained or retired. @@ -21,0 +23 @@ Technical dependencies can be described in four categories: +In addition, individualizing application-to-infrastructure service dependencies helps to avoid false dependency groups. A false dependency group is when several business applications are grouped together, implying that having a common dependency to an infrastructure service forces them to be migrated at the same time. For example, authentication services, such as Active Directory, are likely to be associated with large groups of applications. The key is to filter infrastructure service dependencies out, and to enable these services in AWS. @@ -24 +26,5 @@ Technical dependencies can be described in four categories: -When you establish a baseline for the portfolio, we recommend that you confirm a migration strategy for each application component. The migration strategy will be one of the 6 Rs for migration (see the [Iterating the 6 Rs migration strategy](./iterating-6-rs-migration-strategy-selection.html) section). In the portfolio baseline, one of the 6 Rs should be associated with each application. A 6 R strategy should also be associated with each of the application's infrastructure components. + + +For more information about how to work with dependencies to create migration groups see the [Wave Planning](https://apg-library.amazonaws.com/content-viewer/author/252c3f6c-9941-4934-9262-6561a28cd5f7#wave-planning) section. + +When you establish a baseline for the portfolio, we recommend that you confirm a migration strategy for each application component. The migration strategy will be one of the 6 Rs for migration (see the [Iterating the 6 Rs migration strategy](./iterating-7-rs-migration-strategy-selection.html) section). In the portfolio baseline, one of the 6 Rs should be associated with each application. A 6 R strategy should also be associated with each of the application's infrastructure components.