Patterns are key for building software efficiently. They are the result of years of wisdom and have been traditionally used to conduct successful modernization of Legacy environments. Mainframe environments are not the exception. This article covers the use of two common Modernization Patterns for Mainframe Modernization.
Before discussing the patterns, let’s start categorizing Mainframe Modernization Approaches. We have found that it is simpler to categorize them as follows:
- Lift and Shift/Rehost/Migrate
- Code Conversion/Refactor
- Extend/Coexist
- Re-write/Re-Architect
- Other Approaches
The following illustration summarizes the characteristics of each of them.
As you can see, each presented approach has a flavor of temporary or permanent co-existence between the modern and old environments. That, however, neither tell us much on how to address the challenges inherent to dealing with the modernization nor how we can keep a future co-existence model to maintain our existing service level indicators.
But what is not evident?
Modernizing Mainframes cannot be compared to modernizing a server. Modernizing a mainframe means modernizing an ecosystem. A successful modernization strategy will include ways to deal with:
- Maintaining current Service Level Indicators and Objectives
- Managing legacy Data along with migrated data
- Dealing with Applications Inter-dependencies
- Define the Future of Scheduler and Jobs
- Define the Third-party tools replacement
- Conduct Hybrid Functional and non-functional testing
And of course, the Non-mainframe Dependencies who have been built over the years the mainframe have been supporting the business.
Design and Implementation Patterns
Good design encompasses factors such as consistency and coherence in component design and deployment, maintainability to simplify administration and development, and reusability to allow components and subsystems to be used in other applications and in other scenarios. Decisions made during the design and implementation phase have a huge impact on the quality and the total cost of ownership of cloud hosted applications and services.
At our Architecture Center, we have a list of tested patterns that describes the problem that they address, considerations for applying the pattern, and an example based on Microsoft Azure. They are available at https://learn.microsoft.com/en-us/azure/architecture/patterns/category/design-implementation. We call them the Design and Implementation Patterns.
Patterns for a Gradual Modernization of Mainframes
This article will cover two common patterns for Modernization available in our Design and Implementation Patterns: The Anti-corruption and Strangler Fig Patterns.
Anti-corruption Layer Pattern
The Anti-corruption Layer Pattern implements a façade or adapter layer between the Mainframe legacy system and Azure systems.
This pattern is used to ensure that an application's design is not limited by dependencies on outside subsystems. This pattern was first described by Eric Evans in Domain-Driven Design.
The goal is to isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach. The following diagram depicts the pattern.
When modernizing a mainframe environment, the Anti-corruption layer will be built using our Azure Logic Apps Workflows and our connectors for Mainframes and Midranges technologies. They will serve as a communications translator layer between the Mainframe and the newly created Azure systems.
The Strangler Fig Pattern
The Strangler Fig Pattern Incrementally migrates a legacy system by gradually replacing specific pieces of functionality with new applications and services.
As features from the legacy system are replaced, the new system eventually replaces all the old system's features, strangling the old system and allowing you to decommission it.
The goal is to incrementally replace specific pieces of functionality with new applications and services. Create a façade that intercepts requests going to the backend legacy system. The façade routes these requests either to the legacy application or the new services. Existing features can be migrated to the new system gradually, and consumers can continue using the same interface, unaware that any migration has taken place. The following diagram depicts the pattern.
As you can see, this process is gradual. Hence the importance to define a clear modernization Backlog for the existing Mainframe environment elements that includes a complete inventory of applications and their components, such as:
- COBOL and Copy/Includes
- Assembler
- BMS
- REXX, JCL and Procs
- Databases (Relational and Hierarchical)
- VSAM files
- GDG Bases
- Fixed Sequential Files and Variable Sequential Files
- PDS Members
- Interfaces
Considering this is a gradual modernization, you will need to focus the modernization efforts on isolating “Applications” or groupings of the elements on a Mainframe environment. To summarize, this means understanding the boundaries of the Modernization.
If your Mainframe looks like this:
You must determine the boundaries of the applications to be modernized (Sets of programs, data, jobs, etc. highlighted in colors). And this is the efforts need to be focused first. Unless you plan to conduct a Lift and Shift approach and avoid rewriting systems at all costs, this is required.
Both Patterns Together
- Azure Logic Apps will provide native connectors for IBM Mainframe and Midranges. Our connectors use our core Host Integration Server technologies to integrate with IBM CICS, IBM IMS, IBM MQ, IBM SI3270, IBM DB2 and IBM Host Files.
- Host Integration Server on Azure Virtual Machines continues providing SNA Gateway support for our customers using SNA APIs, Printing and APPC.
- SQL Server provides Data Replication solutions for our customers, modernizing their mainframes and midranges to Azure.
- Our partners also provide fantastic solutions to accomplish Data replication goals.
The following illustration depicts a downsized Mainframe interacting with the Anti-corruption Layer built using our Azure Logic Apps connectors for IBM Mainframes and midranges.
Remember that our Architecture Center also includes multiple Mainframe and midranges modernization topologies and solution patterns: https://learn.microsoft.com/en-us/azure/architecture/browse/?terms=mainframe.
Now, let’s pick an IBM CICS workload. How do I effectively interact with IBM CICS from Azure? Using our Azure Logic Apps connector for IBM CICS as depicted below (More information available at: Logic Apps Mission Critical Series: "We Speak: IBM CICS" - Microsoft Community Hub.
For other connectors and IBM Integration technologies, please visit:
|
Connector |
Link |
|
IBM MQ |
|
|
IBM Host Files |
|
|
IBM DB2 |
|
|
IBM IMS |
|
|
IBM SNA and AIS |
|
|
IBM i |
Integrating Azure Logic Apps Workflows with IBM i Applications |
|
IBM 3270 |
Integrating Azure Logic Apps Workflows with IBM 3270 Applications |
|
Microsoft DRDA Service |
And the following would be a Reference Architecture using our Azure Integration Services and extending workloads to Azure and keeping on-premises dependencies up and running.
Some final considerations:
- While Prioritization is business driven, execution should consider technical constraints.
- You will obtain the best results if you are able to set boundaries for Data, Jobs, Programs and external interfaces.
- If you are running IBM CICS, isolate specific IBM CICS transactions/programs along with its Data, Jobs, Dependencies (Mainframe and external). The same applies for IBM IMS systems.
- Plan for heavy Data replication and impact on SLAs. Consider Change Data Capture technologies.
- If you are using Messaging systems such as IBM MQ, consider leveraging it during the modernization.
- If you require SNA, we provide Host Integration Server to cover your Legacy SNA Integration needs.
The following video covers this topic: