# 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.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Steps for analysis**
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](resources.md) section to automate the analysis.
1. Based on the impact analysis, identify the number of dependent applications that use shared programs such as program AB.1.
1. (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](api.md)
+ [Use a shared library](library.md)
+ [Use a message queue](queue.md)
# 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](resources.md) 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.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
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.
1. 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.
1. 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.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
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.
1. In application A, replace the inner program call to shared program AB.1 with an API call.
1. Maintain a copy of program AB.1 on the mainframe so application B can continue to operate.
1. 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.
1. 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.
1. 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.
# 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.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
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.
1. Maintain the source code of the applications in a fully managed source control service. 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.
1. 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.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
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.
1. Maintain a copy of program AB.1 on the mainframe so that application B can continue to operate.
1. 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.
1. When developing new features for program AB.1, maintain backward compatibility to support application B’s migration in future waves.
1. 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.
1. 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.
+ 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.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
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.
1. Refactor application A (in the cloud) to communicate with application B (on premises) through a message queue.
1. 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.
1. 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.
1. 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.