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
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.
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
REXX, JCL and Procs
Databases (Relational and Hierarchical)
Fixed Sequential Files and Variable Sequential Files
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.