AWS Prescriptive Guidance - Mainframe modernization: Decoupling patterns for migrating application code

Page created by Brittany Wong
 
CONTINUE READING
AWS Prescriptive Guidance - Mainframe modernization: Decoupling patterns for migrating application code
AWS Prescriptive Guidance
Mainframe modernization: Decoupling
patterns for migrating application code
AWS Prescriptive Guidance Mainframe modernization:
                               Decoupling patterns for migrating application code

AWS Prescriptive Guidance: Mainframe modernization: Decoupling
patterns for migrating application code
Copyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not
Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or
discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may
or may not be affiliated with, connected to, or sponsored by Amazon.
AWS Prescriptive Guidance Mainframe modernization:
                                       Decoupling patterns for migrating application code

Table of Contents
  Introduction ...................................................................................................................................... 1
        Targeted business outcomes ........................................................................................................ 1
        Definitions ................................................................................................................................. 1
        Assumptions .............................................................................................................................. 2
        Code migration scenarios ............................................................................................................ 2
  Standalone applications ...................................................................................................................... 3
  Applications that share programs ......................................................................................................... 5
        Decouple by using a standalone API ............................................................................................. 6
              Migrating applications in the same wave ............................................................................... 6
              Migrating applications in different waves .............................................................................. 7
        Decouple by using a shared library ............................................................................................... 8
              Migrating applications in the same wave ............................................................................... 8
              Migrating applications in different waves .............................................................................. 8
        Decouple by using a message queue ............................................................................................ 9
              Migrating applications in different waves ............................................................................ 10
  Best practices .................................................................................................................................. 11
  Resources ........................................................................................................................................ 12
  AWS Prescriptive Guidance glossary .................................................................................................... 13
  Document history ............................................................................................................................. 20

                                                                        iii
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code
                                    Targeted business outcomes

Mainframe modernization:
Decoupling patterns for migrating
application code
    Krithika Palani Selvam and Kevin Yung, Senior Modernization Architects, AWS Professional Services

    April 2021

    Many enterprises are moving their mainframe workloads to the cloud to take advantage of factors
    such as cost reduction, increased agility, technical debt deduction, digital strategy support, mainframe
    legacy skills gap, and data analytics. Mainframe workloads are more challenging to migrate than x86-
    based workloads, because legacy mainframe applications are often developed and deployed in a tightly
    coupled manner. For example, a mainframe application might include programs that are used by a
    number of subsystems or are directly called by other applications. In these cases, changes made to the
    underlying programs also affect the associated subsystems and applications.

    For legacy applications, Amazon Web Services (AWS) recommends an incremental approach, where the
    migration is planned in waves, as a best practice. This approach helps reduce risk, because you select
    and prioritize applications that are closely related to be migrated together. However, this approach
    sometimes isn’t as straightforward for mainframe migrations as they are for x86-based migrations,
    especially because the mainframe application code can be temporal coupled (invoked synchronously) or
    deployment coupled (using linked modules). Migrating the coupled application code affects dependent
    applications and therefore carries some risks. To reduce such risks, you can decouple the mainframe
    application code without impacting dependent applications. This guide explains some of the commonly
    used patterns to decouple mainframe application code for migration.

    The guide is for IT and business executives, architects and business analysts, migration and technical
    leads, development teams, program and project managers, product owners, and operations and
    infrastructure managers who are planning to migrate and modernize their mainframe applications in the
    AWS Cloud.

Targeted business outcomes
    This guide addresses common challenges you might face when you migrate coupled programs from
    mainframes to AWS. It presents code decoupling patterns that AWS Professional Services consultants
    frequently encounter in their engagements with AWS customers. When you use these patterns, both
    your migrated and legacy applications can continue to function during the migration process.

Definitions
    In this guide:

    • A mainframe application refers to a set of related mainframe programs and subprograms that
      accomplish and facilitate a set of business processes. Mainframe applications can be batch processing
      systems or online transaction processing (OLTP) systems.

                                                  1
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code
                                            Assumptions

    • A mainframe component refers to a group of programs and subprograms that achieve specific
      functionality.
    • A mainframe program refers to a set of statements that implement business logic. Programs can be
      run independently.
    • A subprogram is usually written to handle a reusable operation or business logic that multiple
      applications require. A program calls its subprograms either statically or dynamically.
    • A business domain refers to a specific sphere that represents an autonomous unit of business that is
      modeled during analysis. For example, the business domain of software refers to the subject area to
      which the user applies that program.

Assumptions
    The examples and diagrams in this guide reflect the following assumptions:

    • The mainframe application that is being migrated might run a single program or multiple programs.
      For simplicity, the diagrams in this guide display two programs and a single subprogram for each
      application.
    • The mainframe programs and subprograms are written in COBOL, and the code is migrated to Java on
      AWS. However, you can use these decoupling patterns with your programming languages of choice.
    • The migration pattern is legacy automated refactoring, where code, data, and dependencies are
      automatically converted to a modern language, data store, and framework while guaranteeing
      functional equivalence with the same business functions. Refactoring involves using automated
      tools to convert the mainframe programming language (such as COBOL) into modern programming
      languages (such as Java or .NET).
    • Refactored applications are deployed on containers that are provisioned and managed by AWS
      Fargate. Fargate is a serverless compute engine for containers that works with both Amazon Elastic
      Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS). Fargate makes
      it easy for you to focus on building your applications because it removes the need to provision and
      manage servers.
    • Mainframe database tables and mainframe files are migrated with the application.

Code migration scenarios
    The two main types of legacy mainframe applications, from a code migration perspective, are:

    • Standalone applications (p. 3)
    • Applications that share programs with other applications (p. 5)

    The following sections describe the decoupling patterns for these two scenarios.

                                                  2
AWS Prescriptive Guidance Mainframe modernization:
                        Decoupling patterns for migrating application code

Standalone applications
   In the following diagram, applications A and B are standalone mainframe applications. Each application
   consists of programs and subprograms that it uses exclusively.

       Note
       For simplicity, all the diagrams in this guide illustrate programs that are shared by two
       applications, and subprograms that are called by two programs. In a complex mainframe
       application, a program might be called by many applications, and subprograms might be called
       by many programs.

                                                3
AWS Prescriptive Guidance Mainframe modernization:
                     Decoupling patterns for migrating application code

Because the applications are self-contained, you can group the COBOL programs and subprograms by
application for code refactoring, as shown in the following diagram.

After grouping, you can migrate applications A and B in the same wave or in different waves. In either
case, follow these steps:

1. For each application, package the refactored modern components and deploy them together into a
   runtime environment.
2. After migration, retire the on-premises mainframe applications and their components.

                                              4
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code

Applications that share programs
   The following diagram illustrates mainframe applications A and B that run a shared program called
   program AB.1. This case is also applicable when applications A and B include programs that call shared
   subprograms.

   Steps for analysis

                                                5
AWS Prescriptive Guidance Mainframe modernization:
                          Decoupling patterns for migrating application code
                                 Decouple by using a standalone API

    1. Perform an impact analysis of the shared program AB.1, so you can migrate applications A and
       B, and program AB.1 together. We recommend using the discovery tools listed in the Additional
       resources (p. 12) section to automate the analysis.
    2. Based on the impact analysis, identify the number of dependent applications that use shared
       programs such as program AB.1.
    3. (Recommended) Complete a business domain analysis to determine whether the shared program can
       be aggregated into a domain with applications and exposed as an API as one of the domain services.

    You can use one of the following approaches to decouple the applications in preparation for migration:

    • Use a standalone API (p. 6)
    • Use a shared library (p. 8)
    • Use a message queue (p. 9)

Approach 1: Decouple by using a standalone API
    When you use this approach, you instantiate a standalone API by converting the shared COBOL program
    AB.1 into a Java program. To minimize refactoring efforts, you can use automated refactoring tools
    provided by AWS Partners (see the Additional resources (p. 12) section) to generate network APIs for
    the program. Some tools can automatically generate a facade layer from the selected program by using
    an integrated development environment (IDE) such as Eclipse.

    We recommend this approach when the shared program can be instantiated as a standalone service. The
    remaining components of applications A and B are refactored into Java as a whole and migrated to the
    cloud. You can migrate the applications in the same wave or in different waves.

    Migrating applications in the same wave
    In the following diagram, applications A and B are grouped to be migrated in the same wave.

                                                 6
AWS Prescriptive Guidance Mainframe modernization:
                     Decoupling patterns for migrating application code
                         Migrating applications in different waves

If you’re decoupling your code by using a standalone API and migrating applications in the same wave,
follow these steps:

1. Refactor both applications with their respective programs and migrate them to the cloud.
2. Use the impact analysis report from the analysis phase to help developers and teams identify the
   refactored applications that call shared program AB.1. Replace the inner program call to shared
   program AB.1 with network API calls.
3. After the migration, retire the on-premises mainframe applications and their components.

Migrating applications in different waves
When applications are too big to be grouped into the same migration wave, you can migrate them in
multiple waves, as shown in the following diagram, and maintain service continuity during migration.
With this approach, you can modernize your applications in phases without bundling them together.
Migrating your applications in separate waves decouples them without requiring significant code
changes on the mainframe.

If you’re decoupling your code by using a standalone API and migrating applications in different waves,
follow these steps:

1. Migrate (refactor) application A with its associated programs to the cloud while application B
   continues to reside on premises.
2. In application A, replace the inner program call to shared program AB.1 with an API call.
3. Maintain a copy of program AB.1 on the mainframe so application B can continue to operate.
4. Freeze the feature development of program AB.1 on the mainframe. After this point, all feature
   development will take place in refactored program AB.1 in the cloud.
5. After application A is migrated successfully, retire the on-premises application and its components
   (excluding the shared program). Application B and its components (including the shared program)
   continue to reside on premises.
6. In the next set of migration waves, migrate application B and its components. You can call the
   migrated, refactored program AB.1 to reduce refactoring efforts for application B.

                                              7
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code
                                Decouple by using a shared library

Approach 2: Decouple by using a shared library
    In this approach, the shared program AB.1 is converted into a Java common library and is packaged with
    the applications for migration. We recommend this approach when the shared program is a supporting
    library instead of a standalone service.

    The remaining components of applications A and B are refactored into Java programs and migrated to
    the cloud. You can migrate the applications in the same wave or in different waves.

    Migrating applications in the same wave
    In the following diagram, applications A and B are grouped to be migrated in the same wave.

    If you’re decoupling your code by using a shared library and migrating applications in the same wave,
    follow these steps:

    1. Refactor applications A and B with their associated programs into Java and migrate them to the cloud.
    2. Maintain the source code of the applications in a fully managed source control service such as AWS
       CodeCommit. The teams that use the shared program can collaborate on code changes by using pull
       requests, branching, and merging, and can control the changes made to the shared program code.
    3. After the migration, retire the on-premises mainframe applications and their components.

    Migrating applications in different waves
    When applications are too big to be grouped into the same migration wave, you can migrate them in
    multiple waves, as shown in the following diagram, and maintain service continuity during migration.
    With this approach, you can modernize your applications in phases without bundling them together.
    Migrating your applications in separate waves decouples them without requiring significant code
    changes on the mainframe.

                                                  8
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code
                               Decouple by using a message queue

    If you’re decoupling your code by using a shared library and migrating applications in different waves,
    follow these steps:

    1. Migrate (refactor) application A with its associated programs to the cloud while application B
       continues to reside on premises.
    2. Maintain a copy of program AB.1 on the mainframe so that application B can continue to operate.
    3. Freeze the feature development of program AB.1 on the mainframe. At this point, all feature
       development will take place in refactored program AB.1 in the cloud.
    4. When developing new features for program AB.1, maintain backward compatibility to support
       application B’s migration in future waves.
    5. After application A is migrated successfully, retire the on-premises application and its components
       (excluding the shared program). Application B and its components (including the shared program)
       continue to reside on premises.
    6. In the next set of migration waves, migrate application B and its components. You can use the latest
       shared library of program AB.1 in the cloud to reduce the refactoring efforts for application B.

Approach 3: Decouple by using a message queue
    In this approach, the shared program AB.1 is converted into a Java program and migrated to the cloud as
    part of application A. A message queue is used as an interface between the refactored application in the
    cloud and the legacy application on premises. By using this approach, you can break up tightly coupled
    mainframe applications into producers and consumers, and make them more modular so they can
    function independently. The additional advantage is that you can migrate the applications in different
    waves.

    We recommend that you use this approach when:

    • Applications residing on the mainframe can communicate with the migrated applications in the cloud
      through a message queue.
    • Multiple copies of program AB.1 (for example, an on-premises copy and a cloud copy, as in the two
      previous approaches) can’t be maintained.

                                                  9
AWS Prescriptive Guidance Mainframe modernization:
                      Decoupling patterns for migrating application code
                          Migrating applications in different waves

• The queuing architecture pattern meets the business requirements for the applications that reside on
  the mainframe, because it involves re-architecting the existing applications.
• The applications that aren’t part of the first wave require a longer time (six months or more) to be
  migrated to the cloud.

Migrating applications in different waves
When applications are too big to be grouped into the same migration wave, you can migrate them in
multiple waves, as shown in the following diagram, and maintain service continuity during migration.
With this approach, you can modernize your applications in phases without bundling them together.

If you’re using this approach, follow these steps:

1. Migrate (refactor) application A with its associated programs to the cloud while application B
   continues to reside on premises.
2. Refactor application A (in the cloud) to communicate with application B (on premises) through a
   message queue.
3. Refactor application B on premises to replace the shared program AB.1 with a proxy program that
   sends messages to, and receives messages from, application A through the message queue.
4. After application A is migrated successfully, retire the on-premises application A and its components
   (including the shared program). Application B and its components continue to reside on premises.
5. In the next set of migration waves, migrate application B and its components. The loosely coupled
   queuing architecture continues to act as an interface between applications A and B on the cloud. This
   reduces the refactoring efforts for application B without impacting application A.

                                               10
AWS Prescriptive Guidance Mainframe modernization:
                        Decoupling patterns for migrating application code

Best practices
   During the mobilization and planning stages of migration, we recommend the following best practices:

   • Perform code analysis to produce a dependency map for the mainframe applications. We recommend
     that you automate code analysis by using discovery tools (see the Additional resources (p. 12)
     section) for this exercise.
   • Identify the list of programs and subprograms that are shared by applications by using the discovery
     tools. Group applications that share the same programs and subprograms together for the same
     migration wave, to reduce program calls between the on-premises environment and the cloud.
   • In the planning stage, run an impact analysis to identify applications that share programs and
     subprograms with the application that you’re planning to migrate. Select one of the decoupling
     patterns described in this guide for application migration.
   • When possible, perform mainframe migration incrementally to reduce complexity and risk. By
     doing incremental migration, migration teams can provide faster feedback regarding the migration
     progress, and businesses can use the feedback to optimize internal processes to accelerate the pace of
     migration.

                                                11
AWS Prescriptive Guidance Mainframe modernization:
                         Decoupling patterns for migrating application code

Resources
   Discovery tools

   • Blu Insights (Blu Age)
   • Probe (Heirloom Computing)
   • Enterprise Analyzer (Micro Focus)
   • ModPaaS (Modern Systems)
   • TSRI services

   Automated refactoring tools

   • Blu Age Velocity (Blu Age)
   • Heirloom (Heirloom Computing)
   • CTU (Modern Systems)
   • TSRI services

   Patterns and blogs

   • Mainframe modernization: DevOps on AWS with Micro Focus (AWS Prescriptive Guidance)
   • AWS blog posts about mainframes and legacy code

   AWS documentation

   • AWS Prescriptive Guidance
   • AWS documentation
   • AWS general reference
   • AWS glossary

                                                12
AWS Prescriptive Guidance Mainframe modernization:
                                    Decoupling patterns for migrating application code

AWS Prescriptive Guidance glossary

AI and ML terms (p. 13)     |   Migration terms (p. 14)   |   Modernization terms (p. 17)

AI and ML terms
 The following are commonly used terms in artificial intelligence (AI) and machine learning (ML)-related strategies,
guides, and patterns provided by AWS Prescriptive Guidance. To suggest entries, please use the Provide feedback
link at the end of the glossary.

binary classification                  A process that predicts a binary outcome (one of two possible classes). For
                                      example, your ML model might need to predict problems such as “Is this email
                                      spam or not spam?" or "Is this product a book or a car?"

classification                         A categorization process that helps generate predictions. ML models for
                                      classification problems predict a discrete value. Discrete values are always distinct
                                      from one another. For example, a model might need to evaluate whether or not
                                      there is a car in an image.

data preprocessing                    To transform raw data into a format that is easily parsed by your ML model.
                                      Preprocessing data can mean removing certain columns or rows and addressing
                                      missing, inconsistent, or duplicate values.

deep ensemble                         To combine multiple deep learning models for prediction. You can use deep
                                      ensembles to obtain a more accurate prediction or for estimating uncertainty in
                                      predictions.

deep learning                         An ML subfield that uses multiple layers of artificial neural networks to identify
                                      mapping between input data and target variables of interest.

exploratory data analysis             The process of analyzing a dataset to understand its main characteristics. You
(EDA)                                 collect or aggregate data and then perform initial investigations to find patterns,
                                      detect anomalies, and check assumptions. EDA is performed by calculating
                                      summary statistics and creating data visualizations.

features                              The input data that you use to make a prediction. For example, in a
                                      manufacturing context, features could be images that are periodically captured
                                      from the manufacturing line.

feature transformation                To optimize data for the ML process, including enriching data with additional
                                      sources, scaling values, or extracting multiple sets of information from a single
                                      data field. This enables the ML model to benefit from the data. For example, if
                                      you break down the “2021-05-27 00:15:37” date into “2021”, “May”, “Thu”, and
                                      “15”, you can help the learning algorithm learn nuanced patterns associated with
                                      different data components.

                                                              13
AWS Prescriptive Guidance Mainframe modernization:
                               Decoupling patterns for migrating application code

multiclass classification         A process that helps generate predictions for multiple classes (predicting one of
                                 more than two outcomes). For example, an ML model might ask "Is this product
                                 a book, car, or phone?" or "Which product category is most interesting to this
                                 customer?"

regression                       An ML technique that predicts a numeric value. For example, to solve the problem
                                 of "What price will this house sell for?" an ML model could use a linear regression
                                 model to predict a house's sale price based on known facts about the house (for
                                 example, the square footage).

training                         To provide data for your ML model to learn from. The training data must contain
                                 the correct answer. The learning algorithm finds patterns in the training data that
                                 map the input data attributes to the target (the answer that you want to predict).
                                 It outputs an ML model that captures these patterns. You can then use the ML
                                 model to make predictions on new data for which you don’t know the target.

target variable                  The value that you are trying to predict in supervised ML. This is also referred
                                 to as an outcome variable. For example, in a manufacturing setting the target
                                 variable could be a product defect.

tuning                           To change aspects of your training process to improve the ML model's accuracy.
                                 For example, you can train the ML model by generating a labeling set, adding
                                 labels, and then repeating these steps several times under different settings to
                                 optimize the model.

uncertainty                      A concept that refers to imprecise, incomplete, or unknown information that
                                 can undermine the reliability of predictive ML models. There are two types of
                                 uncertainty: Epistemic uncertainty is caused by limited, incomplete data, whereas
                                 aleatoric uncertainty is caused by the noise and randomness inherent in the data.
                                 For more information, see the Quantifying uncertainty in deep learning systems
                                 guide.

Migration terms
The following are commonly used terms in migration-related strategies, guides, and patterns provided by AWS
Prescriptive Guidance. To suggest entries, please use the Provide feedback link at the end of the glossary.

7 Rs                             Seven common migration strategies for moving applications to the cloud. These
                                 strategies build upon the 5 Rs that Gartner identified in 2011 and consist of the
                                 following:

                                 • Refactor/re-architect – Move an application and modify its architecture by
                                   taking full advantage of cloud-native features to improve agility, performance,
                                   and scalability. This typically involves porting the operating system and
                                   database. Example: Migrate your on-premises Oracle database to the Amazon
                                   Aurora PostgreSQL-Compatible Edition.
                                 • Replatform (lift and reshape) – Move an application to the cloud, and introduce
                                   some level of optimization to take advantage of cloud capabilities. Example:
                                   Migrate your on-premises Oracle database to Amazon Relational Database
                                   Service (Amazon RDS) for Oracle in the AWS Cloud.
                                 • Repurchase (drop and shop) – Switch to a different product, typically by moving
                                   from a traditional license to a SaaS model. Example: Migrate your customer
                                   relationship management (CRM) system to Salesforce.com.
                                 • Rehost (lift and shift) – Move an application to the cloud without making any
                                   changes to take advantage of cloud capabilities. Example: Migrate your on-
                                   premises Oracle database to Oracle on an EC2 instance in the AWS Cloud.

                                                        14
AWS Prescriptive Guidance Mainframe modernization:
                                Decoupling patterns for migrating application code

                                 • Relocate (hypervisor-level lift and shift) – Move infrastructure to the cloud
                                   without purchasing new hardware, rewriting applications, or modifying your
                                   existing operations. This migration scenario is specific to VMware Cloud
                                   on AWS, which supports virtual machine (VM) compatibility and workload
                                   portability between your on-premises environment and AWS. You can use the
                                   VMware Cloud Foundation technologies from your on-premises data centers
                                   when you migrate your infrastructure to VMware Cloud on AWS. Example:
                                   Relocate the hypervisor hosting your Oracle database to VMware Cloud on
                                   AWS.
                                 • Retain (revisit) – Keep applications in your source environment. These might
                                   include applications that require major refactoring, and you want to postpone
                                   that work until a later time, and legacy applications that you want to retain,
                                   because there’s no business justification for migrating them.
                                 • Retire – Decommission or remove applications that are no longer needed in
                                   your source environment.

application portfolio            A collection of detailed information about each application used by an
                                 organization, including the cost to build and maintain the application, and its
                                 business value. This information is key to the portfolio discovery and analysis
                                 process and helps identify and prioritize the applications to be migrated,
                                 modernized, and optimized.

artificial intelligence           The process of using machine learning techniques to solve operational problems,
operations (AIOps)               reduce operational incidents and human intervention, and increase service
                                 quality. For more information about how AIOps is used in the AWS migration
                                 strategy, see the operations integration guide.

AWS Cloud Adoption               A framework of guidelines and best practices from AWS to help organizations
Framework (AWS CAF)              develop an efficient and effective plan to move successfully to the cloud. AWS
                                 CAF organizes guidance into six focus areas called perspectives: business,
                                 people, governance, platform, security, and operations. The business, people,
                                 and governance perspectives focus on business skills and processes; the
                                 platform, security, and operations perspectives focus on technical skills and
                                 processes. For example, the people perspective targets stakeholders who handle
                                 human resources (HR), staffing functions, and people management. For this
                                 perspective, AWS CAF provides guidance for people development, training, and
                                 communications to help ready the organization for successful cloud adoption. For
                                 more information, see the AWS CAF website and the AWS CAF whitepaper.

AWS landing zone                 A landing zone is a well-architected, multi-account AWS environment that is
                                 scalable and secure. This is a starting point from which your organizations can
                                 quickly launch and deploy workloads and applications with confidence in their
                                 security and infrastructure environment. For more information about landing
                                 zones, see Setting up a secure and scalable multi-account AWS environment.

AWS Workload Qualification        A tool that evaluates database migration workloads, recommends migration
Framework (AWS WQF)              strategies, and provides work estimates. AWS WQF is included with AWS Schema
                                 Conversion Tool (AWS SCT). It analyzes database schemas and code objects,
                                 application code, dependencies, and performance characteristics, and provides
                                 assessment reports.

business continuity planning     A plan that addresses the potential impact of a disruptive event, such as a large-
(BCP)                            scale migration, on operations and enables a business to resume operations
                                 quickly.

Cloud Center of Excellence       A multi-disciplinary team that drives cloud adoption efforts across an
(CCoE)                           organization, including developing cloud best practices, mobilizing resources,
                                 establishing migration timelines, and leading the organization through large-

                                                        15
AWS Prescriptive Guidance Mainframe modernization:
                                 Decoupling patterns for migrating application code

                                  scale transformations. For more information, see the CCoE posts on the AWS
                                  Cloud Enterprise Strategy Blog.

cloud stages of adoption          The four phases that organizations typically go through when they migrate to the
                                  AWS Cloud:

                                  • Project – Running a few cloud-related projects for proof of concept and
                                    learning purposes
                                  • Foundation – Making foundational investments to scale your cloud adoption
                                    (e.g., creating a landing zone, defining a CCoE, establishing an operations
                                    model)
                                  • Migration – Migrating individual applications
                                  • Re-invention – Optimizing products and services, and innovating in the cloud

                                  These stages were defined by Stephen Orban in the blog post The Journey
                                  Toward Cloud-First & the Stages of Adoption on the AWS Cloud Enterprise
                                  Strategy blog. For information about how they relate to the AWS migration
                                  strategy, see the migration readiness guide.

configuration management           A database that contains information about a company’s hardware and software
database (CMDB)                   products, configurations, and inter-dependencies. You typically use data from a
                                  CMDB in the portfolio discovery and analysis stage of migration.

epic                              In agile methodologies, functional categories that help organize and prioritize
                                  your work. Epics provide a high-level description of requirements and
                                  implementation tasks. For example, AWS CAF security epics include identity and
                                  access management, detective controls, infrastructure security, data protection,
                                  and incident response. For more information about epics in the AWS migration
                                  strategy, see the program implementation guide.

heterogeneous database            Migrating your source database to a target database that uses a different
migration                         database engine (for example, Oracle to Amazon Aurora). Heterogeneous
                                  migration is typically part of a re-architecting effort, and converting the
                                  schema can be a complex task. AWS provides AWS SCT that helps with schema
                                  conversions.

homogeneous database              Migrating your source database to a target database that shares the same
migration                         database engine (for example, Microsoft SQL Server to Amazon RDS for SQL
                                  Server). Homogeneous migration is typically part of a rehosting or replatforming
                                  effort. You can use native database utilities to migrate the schema.

IT information library (ITIL)     A set of best practices for delivering IT services and aligning these services with
                                  business requirements. ITIL provides the foundation for ITSM.

IT service management (ITSM)      Activities associated with designing, implementing, managing, and supporting IT
                                  services for an organization. For information about integrating cloud operations
                                  with ITSM tools, see the operations integration guide.

Migration Acceleration            An AWS program that provides consulting support, training, and services to
Program (MAP)                     help organizations build a strong operational foundation for moving to the
                                  cloud, and to help offset the initial cost of migrations. MAP includes a migration
                                  methodology for executing legacy migrations in a methodical way and a set of
                                  tools to automate and accelerate common migration scenarios.

Migration Portfolio               An online tool that provides information for validating the business case for
Assessment (MPA)                  migrating to the AWS Cloud. MPA provides detailed portfolio assessment
                                  (server right-sizing, pricing, TCO comparisons, migration cost analysis) as well
                                  as migration planning (application data analysis and data collection, application
                                  grouping, migration prioritization, and wave planning). The MPA tool (requires

                                                         16
AWS Prescriptive Guidance Mainframe modernization:
                                 Decoupling patterns for migrating application code

                                  login) is available free of charge to all AWS consultants and APN Partner
                                  consultants.

Migration Readiness               The process of gaining insights about an organization’s cloud readiness status,
Assessment (MRA)                  identifying strengths and weaknesses, and building an action plan to close
                                  identified gaps, using the AWS CAF. For more information, see the migration
                                  readiness guide. MRA is the first phase of the AWS migration strategy.

migration at scale                The process of moving the majority of the application portfolio to the cloud in
                                  waves, with more applications moved at a faster rate in each wave. This phase
                                  uses the best practices and lessons learned from the earlier phases to implement
                                  a migration factory of teams, tools, and processes to streamline the migration of
                                  workloads through automation and agile delivery. This is the third phase of the
                                  AWS migration strategy.

migration factory                 Cross-functional teams that streamline the migration of workloads through
                                  automated, agile approaches. Migration factory teams typically include
                                  operations, business analysts and owners, migration engineers, developers,
                                  and DevOps professionals working in sprints. Between 20 and 50 percent of
                                  an enterprise application portfolio consists of repeated patterns that can be
                                  optimized by a factory approach. For more information, see the discussion of
                                  migration factories and the CloudEndure Migration Factory guide in this content
                                  set.

operational-level agreement       An agreement that clarifies what functional IT groups promise to deliver to each
(OLA)                             other, to support a service-level agreement (SLA).

operations integration (OI)       The process of modernizing operations in the cloud, which involves readiness
                                  planning, automation, and integration. For more information, see the operations
                                  integration guide.

organizational change             A framework for managing major, disruptive business transformations from a
management (OCM)                  people, culture, and leadership perspective. OCM helps organizations prepare for,
                                  and transition to, new systems and strategies by accelerating change adoption,
                                  addressing transitional issues, and driving cultural and organizational changes. In
                                  the AWS migration strategy, this framework is called people acceleration, because
                                  of the speed of change required in cloud adoption projects. For more information,
                                  see the OCM guide.

playbook                          A set of predefined steps that capture the work associated with migrations, such
                                  as delivering core operations functions in the cloud. A playbook can take the form
                                  of scripts, automated runbooks, or a summary of processes or steps required to
                                  operate your modernized environment.

responsible, accountable,         A matrix that defines and assigns roles and responsibilities in a project. For
consulted, informed (RACI)        example, you can create a RACI to define security control ownership or to identify
matrix                            roles and responsibilities for specific tasks in a migration project.

runbook                           A set of manual or automated procedures required to perform a specific task.
                                  These are typically built to streamline repetitive operations or procedures with
                                  high error rates.

service-level agreement (SLA)     An agreement that clarifies what an IT team promises to deliver to their
                                  customers, such as service uptime and performance.

Modernization terms
The following are commonly used terms in modernization-related strategies, guides, and patterns provided by AWS
Prescriptive Guidance. To suggest entries, please use the Provide feedback link at the end of the glossary.

                                                        17
AWS Prescriptive Guidance Mainframe modernization:
                              Decoupling patterns for migrating application code

business capability            What a business does to generate value (for example, sales, customer service,
                               or marketing). Microservices architectures and development decisions can be
                               driven by business capabilities. For more information, see the Organized around
                               business capabilities section of the Running containerized microservices on AWS
                               whitepaper.

microservice                   A small, independent service that communicates over well-defined APIs and is
                               typically owned by small, self-contained teams. For example, an insurance system
                               might include microservices that map to business capabilities, such as sales or
                               marketing, or subdomains, such as purchasing, claims, or analytics. The benefits
                               of microservices include agility, flexible scaling, easy deployment, reusable code,
                               and resilience. For more information, see Integrating microservices by using AWS
                               serverless services.

microservices architecture     An approach to building an application with independent components that run
                               each application process as a microservice. These microservices communicate
                               through a well-defined interface by using lightweight APIs. Each microservice
                               in this architecture can be updated, deployed, and scaled to meet demand for
                               specific functions of an application. For more information, see Implementing
                               microservices on AWS.

modernization                  Transforming an outdated (legacy or monolithic) application and its infrastructure
                               into an agile, elastic, and highly available system in the cloud to reduce costs,
                               gain efficiencies, and take advantage of innovations. For more information, see
                               Strategy for modernizing applications in the AWS Cloud.

modernization readiness        An evaluation that helps determine the modernization readiness of an
assessment                     organization’s applications; identifies benefits, risks, and dependencies; and
                               determines how well the organization can support the future state of those
                               applications. The outcome of the assessment is a blueprint of the target
                               architecture, a roadmap that details development phases and milestones for the
                               modernization process, and an action plan for addressing identified gaps. For
                               more information, see Evaluating modernization readiness for applications in the
                               AWS Cloud.

monolithic applications        Applications that run as a single service with tightly coupled processes. Monolithic
(monoliths)                    applications have several drawbacks. If one application feature experiences a
                               spike in demand, the entire architecture must be scaled. Adding or improving a
                               monolithic application’s features also becomes more complex when the code base
                               grows. To address these issues, you can use a microservices architecture. For more
                               information, see Decomposing monoliths into microservices.

polyglot persistence           Independently choosing a microservice’s data storage technology based on data
                               access patterns and other requirements. If your microservices have the same
                               data storage technology, they can encounter implementation challenges or
                               experience poor performance. Microservices are more easily implemented and
                               achieve better performance and scalability if they use the data store best adapted
                               to their requirements. For more information, see Enabling data persistence in
                               microservices.

split-and-seed model           A pattern for scaling and accelerating modernization projects. As new features
                               and product releases are defined, the core team splits up to create new product
                               teams. This helps scale your organization’s capabilities and services, improves
                               developer productivity, and supports rapid innovation. For more information, see
                               Phased approach to modernizing applications in the AWS Cloud.

two-pizza team                 A small DevOps team that you can feed with two pizzas. A two-pizza team size
                               ensures the best possible opportunity for collaboration in software development.

                                                      18
AWS Prescriptive Guidance Mainframe modernization:
 Decoupling patterns for migrating application code

  For more information, see the Two-pizza team section of the Introduction to
  DevOps on AWS whitepaper.

                        19
AWS Prescriptive Guidance Mainframe modernization:
                        Decoupling patterns for migrating application code

Document history
   The following table describes significant changes to this guide. If you want to be notified about future
   updates, you can subscribe to an RSS feed.

    update-history-change              update-history-description         update-history-date

    — (p. 20)                          Initial publication                April 23, 2021

                                                 20
You can also read