Mainframe Modernization, An Application-Centric Approach

In past blog articles I have focused on application modernization. This was always done in a way relatively independent of the underlying platform (operating system and often specialized middleware as well as hardware architecture) upon which the applications being modernized run today. As we build out a broader set of application modernization guidance based on experiences, a set of ideas, principles and refined techniques emerge that are specialized to or invented because of the underlying platform. This blog article will frame up the topic of mainframe modernization and be a setup for additional articles that dive more deeply into some of the topics introduced here.

To get started, there are two things to get out of the way immediately.

1. Technically, the mainframe hardware, operating systems, and supported middleware, namely the IBM Z and the ecosystem of things that run there are very modern and under continued evolution by IBM and related software providers. It is generally the applications and sometimes the operating models that leverage IBM Z which need modernizing.

2. An application-centric focus, as with application modernization in general, is the theme that we want to capture under this term mainframe modernization. The difference is that mainframe modernization has specific guidance and procedure related to the mainframe platform. While definitions of mainframe modernization are plentiful, we will use this application-centric definition for this blog and others to come.

With that preface, the rest of this blog entry will introduce and provide some thoughts that address:

A. Mainframe Modernization — Why Now?

B. Mainframe modernization and generic application modernization similarities and differences

C. Taxonomies and approaches that can help organize mainframe modernization activities.

D. A starter list of guidance and best practices

Mainframe Modernization — Why Now?

Moving away from the mainframe has been a topic of discussion and many failed predictions for most of my career. It would be naïve to say that this time around, the conditions are radically different. You can decide for yourself. A few things around timing are certainly noteworthy.

One can argue that the first few steps of digital transformation are often focused on user experience, proper channels along with safe and secure access from those digital channels. Much of this can be done without a lot of mainframe application modernization. Getting access to mainframe-based data and transactions via APIs will go a long way in the early days of digital transformation. However, companies going through a digital transformation are now reaching the point where the mainframe-based applications must be changed, often significantly.

This next step and perhaps the most important one is to truly become digital and have business processes that are built for and optimized to the digital experience. Things like a single view of the customer in the digital experience come to mind. Most of those existing applications on the mainframe must do more than expose APIs and democratize data in this phase of digital transformation. At the extreme, these applications need to be re-imagined while at a minimum some refactoring is required. This is intrusive, by definition, to the actual business logic and organization of business services.

With that in mind, where is the right place to do this reimagining and refactoring? The supporting story for why now often helps us with the answer.

1. Skills — It isn’t a stretch to say that skills at all levels are in short supply as it relates to the mainframe. Existing teams are aging. I regularly speak with some brilliant applications developers that are looking forward to retirement, like now. COBOL programmers are not coming out of academia in large numbers. Having language skills is just part of it, having knowledge of the aged applications and how they really work is an even more acute problem.

2. Investment — Large companies have for the most part reduced their level of investment in the applications that are on the mainframe. New capabilities are being built on the cloud which results in mainframe applications getting less attention and building up various amounts of technical debt.

3. Development velocity isn’t near that of what is going on in the cloud and in the modern world of microservices, Kubernetes, serverless and managed data services. Yes, modern DevOps is possible technically on the mainframe, but less pervasive. This is due in part to the existing operating models and years of muscle memory.

4. Economics — In addition to the technical reasons motivating mainframe modernization, there are a set of changes occurring around pricing of both software and hardware which are raising a bunch of red flags.

Why now? This confluence of these factors makes mainframe modernization not only water cooler talk, but also makes the focus list for CIOs and even CEOs.

Mainframe Modernization and Generic Application Modernization Similarities and Differences

While it is the case that mainframe modernization, by our definition described earlier, is a special case of application modernization, there are indeed more similarities than differences when we look at the next level of detail.

General application modernization advice and knowledge almost always applies. Things that need to be considered, tasks that need to be undertaken and the mindset in general is similar. The details, however, can vary a bit. Four things to consider are outlined in the figure below:

1. Shape and Size of Applications — What’s an application? Just as in the broader world, defining and counting applications on the mainframe is not a standardized conversation. Tools usually impart some reality about what to call an application. Realize that the application count might be influenced by the role the mainframe logic and data play. Mainframes can host entire applications, or they can host pieces of applications depending on the perspective taken. More and more, our experience shows that an outside in view that looks at the business transaction that a consumer or customer of the application is using will provide the right context. So while the tools impart some structure remember to think end-to-end when looking at SLAs and overall experience.

2. Application architectures are a good way to look at groups of applications. With mainframe applications or the mainframe portions of applications, the following are generally true:

a. More batch architectures than you find on other platforms and lots of built in support in the platform for making this work at high-volume.

b. A larger proportion of mainframe applications are going to be the backends, the systems of record, than in most other situations. The mainframe is the 3rd tier in a 3-tier architecture or the 2nd tier in older client-server architectures. This means access patterns or inbound requests are really important. Mainframe based applications do make calls out, but probably less so than distributed applications.

c. Less likely to see BFF (backend for front end), but probably see online application with green screen user interfaces. While many of these have been screen scraped or replaced, some of them are still out there. Mostly the remaining green screens are the long-tail applications which might be super important to a small but specialized set of users, leveraged only occasionally,

d. Application architectures on the mainframe are often built for scale, which can mean they are more loosely coupled. At the same time, being built for scale might mean that they depend on features like the coupling facility. There is more of a shared data mentality, so you’ll find that applications aren’t operating on copies of the data, they are operating on the actual system of record data at its source.

e. Finally, from a database perspective you will find a number of technologies and approaches including IMS, VSAM, IDMS and DB2. A lot of these architectures for data have many consumers, meaning that applications are not necessarily encapsulating their own data. This means applications often have a lot of dependencies on different tables and databases.

3. Armed with some appreciation for what makes up an application and what architectures might be encountered, application assessments are necessary to make solid technical and financial decisions about what and how to modernize. Assessments that are tool-based are the only viable ones in this day and age if you want my opinion. Sometimes the tools used, such as CAST Highlight, are the same as those used on the distributed platforms and this is a good thing. What might be different are the programming languages and middleware being used by the applications being scanned. Look for more COBOL, or PL/1. Look for CICS, IMS and VSAM. Don’t get me wrong, you can also find things like WebSphere, IBM MQ as well as lots of DB2 when scanning a mainframe application estate, but expect a lot of older languages and platform specific middleware as well.

4. Techniques to apply to an application for modernization presents a new set of conversations when the mainframe is involved. Let me enumerate a few things that we are seeing regularly.

a. Replatforming comes in the form of recompiling COBOL to run on x86 architectures. This is a viable option, providing a minimum change approach as far as the business logic goes. Various providers have tools and methods. Each has varying levels of support for languages and for various middleware which are inherently burned into the applications. Most of the time, it isn’t just COBOL, it is CICS COBOL or COBOL with other middleware involved.

b. Refactoring or a more aggressive Replatform, depending on how to want to state it, is also a much more common when it come to the mainframe applications. Here, the usual example is COBOL to Java. Again, there are several tools providers with varying degrees of support. Here, I will list a few points that are relevant to refactoring and come back to this in the future:

· These conversion tools and methods have matured a lot in the last couple of years. I am much more impressed and less skeptical here.

· That said, make sure your java programmers inspect the generated code before you buy. They must be able to maintain this without too much difficulty. Make sure you factor in the cost of having proper CI/CD pipelines as well, to support these converted applications.

· Ensure that you are carefully mapping the NFRs from the mainframe to that of the cloud. This is tricky to say the least, especially if the original COBOL application takes advantage of specific mainframe features such as the coupling facility in a sysplex, then you must clearly test and inspect the results, under normal and maximum load conditions.

· Think long and hard about the runtime execution environment in which these converted applications run. Some cloud providers are providing managed services to run converted applications. Maybe you should run these in Kubernetes, alongside the front ends and middle tiers that also may have been modernized in the direction of Kubernetes? Is this a well-trodden path?

c. Containerization as a direct technique is less common. There is less directly containerizable stuff on the mainframe at this point in time. Sure, if there is java, it can most certainly be containerized. But the path to containers often goes through replatforming for refactoring versus the more direct approaches which we are able to leverage on the distributed platform.

Taxonomies and Approaches for Mainframe Modernization Activities

In previous articles, we used an evolved version of the 7Rs to talk about what techniques to apply to applications and components of applications to effectively modernize them. The most common patterns leveraged in mainframe modernization cases, are shown in the following figure:

Each of the shaded boxes can be a subject of an entire blog. For now, at least we have the list here and will endeavor to build on it. It should also be noted that another common modernization action that affects the applications is DevOps Modernization. This is occurring in the context of applications that are staying on the mainframe and is all but mandatory for applications that are moving off the mainframe and going through one or the paths outlined in the figure.

Sometimes, the taxonomy above and how it is applied is influenced by a company’s overall platform strategy as it relates to the mainframe. At Kyndryl, we have been working with clients that have such strategies and with others to help them formulate this platform strategy. Typically, there are platform strategies to invest, maintain or move off the mainframe platform. These strategies are not exclusive, meaning you can choose to leverage more than one of them, which is why we recommend an application-centric and holistic approach to figuring all this out. This provides insights as to the level of investment in an application makes sense and which approaches are more appropriate.

Armed with the bigger picture and some of the organizing principles, the final section shared some best practices and experiences.

A Starter List of Guidance and Best Practices

We have accumulated a lot of knowledge in the past few years by engaging and working with large and small customers on application modernization. A similar story is unfolding around mainframe modernization. This final section enumerates a few things that might pique interest or resonate with your mainframe modernization initiative.

1. Remember the operating model — Often times, we get caught up in all the technical realities of mainframe modernization. If the same processes and procedures for development, provisioning, testing, and operations are brought forward to the new world, the investment in modernization will not pay off. Automation that has meetings and human interactions between every step won’t improve development velocity no matter how modern the source code is and how easy it is to iterate upon. Most of the application modernization techniques are trending towards more cloud native applications. Make sure your operating model is doing the same. Agile and product-centric companies (not just IT) come right into the middle of this operating model discussion. Check out what else is happening in your organization already. There are likely groups that are agile, are cloud native and have much of this figured out. Borrow their experiences.

2. Leverage zCloud — Sometimes, there are pieces that cannot easily move off, but they work. If you need to get out of your data center or off your current mainframe, but want to maintain portions of the mainframe estate, this option works very well technically and can makes a lot of sense from an ROI perspective.

3. Inspect all the moving parts on the mainframe — There are a lot of things happening on the mainframe — Our experience is that in addition to the applications themselves, there are other technical components on that mainframe that are essential to the way a business process is running. Things like scripts or JCL that glue together applications come to mind. What about printing? Remember that when the mainframe was the general-purpose compute, everything was done there. Stay application-centric but figure out what the rest of the story is and ensure that the need for all this glue and these utilities either goes away, gets converted to appropriate modern language source code or gets replaced by a cloud provider-based service.

4. Networking (the end-to-end path) — If mainframe applications are moving to the cloud, what is the networking path that an end consumer’s request might follow. We have seen cases where entry is at the mobile application (hosted in a public cloud) which then goes to an SOA layer (hosted in a private cloud) which then goes to a public cloud where the mainframe application has been replatformed to. How this gets resolved is a longer conversation? Should the middle-tier be modernized to the cloud also? (hint: probably).

5. Networking (latency and capacity) — If we use the same example from above, what is the change in latency? If an application on the SOA tier demanded low latency (aka. It’s conversation with the mainframe was chatty and synchronous) can that be maintained? Where is that cloud data center in relation to your data center? Even if the mainframe and the middle-tier go to the cloud, is there good latency and capacity plumbed into your cloud provider landing zone?

6. Security — This is a big topic. There is only room for a couple of examples here. How much encryption in motion and encryption at rest is happening in the current application architecture. When the application ends up on the public cloud, this now becomes necessary and again can affect performance and should take you right back to Network capacity. This is another reason why assessing the integrations that mainframe applications have, at the protocol level and at the volume level is really important to getting this right. In a different area of the security domain, we see it is important to understand the authorization schemes in place and how those are realized by the capabilities offered in public clouds. Getting there can usually be done, but not without some careful planning and mapping.

7. Find some simpler applications to start the move off journey with — On many mainframes there are super-complex custom-built applications, packaged applications, and the rest. I think of the rest as applications that were put onto the mainframe because it was the general-purpose compute platform. I wrote applications like this in the late 1980’s. They didn’t stress out the mainframe, but where else would one put a CRUD app in those days. Starting with an application in this latter category can be insightful, but perhaps not indicative of what it will take for the super-complex applications. Try them anyway. Moving them might help reduce consumption and will provide lessons learned to use when the big applications are tackled.

8. Testing and big bang versus incremental with Coexistence — When modernizing these mission critical applications, lots of testing, including side-by-side is necessary. Big bang means moving an entire set of applications at once. Incremental with Coexistence means moving applications one at a time or a few at a time. Both approaches are tricky, both are possible, and each has a set of heuristics to follow. Explore all the risks, both at a business and technical level. Think this through. Don’t be over influenced by the rate and pace at which the return on investment comes through. Choose the option that you can make happen. The return on investment will catch up either way if you can get the application modernized and stay there.

This section is one that can probably be refined and improved every day as we do this work with customers and as we encounter an improving and maturing ecosystem which is enabling mainframe modernization. Look for more of this kind of material in the future. At Kyndryl, our goal is to help you through all of this, no matter what your platform strategy is and no matter at what rate and pace that the journey will proceed.

Conclusion

Application Modernization continues to dominate a lot of conversions. It is increasingly being fueled by digital transformation activities. As individual organizations get further into their journeys on digital transformation, the application modernization work increasingly focuses on core business processes. Those processes, in many industries, are running in part or whole on mainframes. Like all applications being modernized, these core business processes require careful assessment. There are techniques leveraged when mainframes are involved that should be understood and leveraged when building an overall modernization, including the business case.

This article has outlined a framework and started on topics that can and should be further described and detailed.

Meanwhile, while the mainframe modernization topic heats up, the definition of what good looks like for modernized applications is also maturing. This is true for the constituent parts of an overall technical architecture and the operating model. We are going to be talking about application modernization for the foreseeable future including the specializations related to mainframe modernization. Stay tuned, because in my view, we are just now getting to the really good stuff and the really hard stuff, depending on your perspective. I’ll update this blog with pointers to other topics as we roll them out.