Partners guide clients on mainframe modernization strategy

Mainframe modernization strategy takes varied paths

Lisa Dyer, a line-of-business executive at Chicago-based hybrid IT solution provider Ensono, has identified three types of modernization clients: organizations that aim to maintain mainframes, those that are looking to resituate mainframe workloads in the cloud and those determining what an ideal platform portfolio should look like. Dyer is responsible for Ensono's mainframe work.

The first customer type is intent on investing in the mainframe platform, Dyer said. Those organizations, she noted, believe the mainframe platform is well suited to their business needs -- workloads are mature and the processes they support seldom change.

Businesses may also retain mainframes if they house data required for long-term auditing purposes. Other devotees carry on with mainframe technology "just because it is history," she added. She likened that fondness for mainframes to purchasing a Maserati instead of hiring a Lyft.

The mainframes she encounters in the market tend to be the newer ones, such as IBM's z15. Clients with somewhat older models, such the IBM z13, might upgrade to a newer platform. "We don't see really old mainframes," she said.

As for the second customer type, Dyer said she encounters few customers who want to completely abandon mainframes. "It's a very limited use case," she said.

Far more prevalent are customers who take the middle road, developing customer-facing applications from scratch and linking those to mainframe-based business systems. "Mobile and web apps need to evolve much faster in response to much higher expectations [from users] regarding rich experience and expectations regarding the speed in which new features and capabilities come to them," she said. "Those systems of engagement need to connect to systems of record on the mainframe."

APIs, as interfaces between software functions, can provide the integration between new applications and mission-critical business functions on the mainframe. Ensono, for example, might enable the infrastructure capability for clients to create an API endpoint into an insurance policy application handled by CICS and DB2, which are major mainframe subsystems. A mobile app developed to let an insurance agent work on a claim in the field could use that API to pull up the customer's policy and make changes securely and fast, Dyer explained.

Other partners, however, said customers don't want to linger on their mainframes any longer than necessary. "In our experience, people intend to move out of the mainframe," said Suhas Hangal, a director in the cloud practice at Perficient, a digital consultancy based in St. Louis.

One compelling reason: a shrinking pool of mainframe knowledge. Retirements in the IT shop leave fewer staffers who understand mainframes. "The skill set is sunsetting," Hangal said.

A stepwise progression to cloud

But even customers eager to abandon their big iron for the cloud will seldom be able to do so in a single, relatively quick-turnaround project.

The amount of core business logic bound up in mainframes tends to rule out a one-year effort, Hangal said. In addition, other IT directives take resources away from mainframe initiatives, extending the timeline. One of Perficient's banking customers is migrating legacy mainframe systems to a virtualized, microservices environment, Hangal said. At the same time, that client rewrote its credit card and loan accounts management system and moved it to AWS and serverless computing. The mainframe project might have been completed in 18 months with a single-minded focus, but the simultaneous cloud journey will add extra time to the task, he said.

Fighting those headwinds, customers view mainframe modernization more realistically, opting for an incremental approach rather than a delimited event. "A couple of years ago, when people were talking about migrating from mainframes to the cloud, it was a very finite, single effort," Edenfield said. "Now, it does tend to go in a phased direction."

The initial phase is to determine the lay of the mainframe land, tracing the path of programs running on the big machines and uncovering dependencies. "The first step is, find everything," Edenfield said. "You need to understand what you have, where it is and [if] you missed anything."

Next, Advanced helps customers fine-tune their mainframe-based systems, which may be decades old. This analysis phase roots out redundancies and "dead code" that no longer serve any purpose, Edenfield said. The process can reduce customers' asset size by 30% to 70%, shrinking the amount of code they need to migrate, he added.

The actual cloud migration may take a couple of different forms. Rehosting, essentially a lift-and-shift exercise, places mainframe code in a virtual container without modification, Hangal said. Refactoring is another option, in which old code gets a fresh design. Here, legacy code written in Cobol or PL/1 is converted to modern languages such as Java or C#.

In keeping with the step-by-step approach, mainframe software assets may be broken down into individual workloads, rebuilt as microservices and migrated in chunks rather than all at one go. Mainframes still need to operate while the phased migration continues, but consultants can help clients reduce mainframe dependence during the interim. Deploying APIs and microservices to front end a mainframe is one approach. Using a cache is another method, Hangal said. "The cache, in particular, is helpful in storing data that does not change or does not frequently change, reducing the need to query the mainframe," he said.

Other and sometimes overlooked factors also come into play during a migration. For one, a modernization project should recognize the differences between the mainframe world and the cloud destination. Organizations built customized environments for their mainframes, catering to specific performance needs, Edenfield noted. Those customized components don't exist in a generic cloud setting. As a result, a workload that took three hours to run on a mainframe could take 30 hours to process in the cloud.

Edenfield called that an extreme case, but said it nevertheless makes an important point. Procedural languages like IBM's High Level Assembler, also referred to as HLASM or Assembler, are, in effect, closer to the machine than the more abstract, but more powerful, object-oriented languages such as Java. In some cases, tasks that can be quickly accomplished in Assembler require more overhead using an object-oriented language, which can result in performance issues, he noted.

Attention to workloads and properly architecting the cloud infrastructure help customers avoid such problems, Edenfield said.

Mainframe complexities should occupy IT services providers for the next several years, particularly in vertical markets such as financial services, state and national governments, and transportation. Consultants aim to offer services spanning the various upgrade and migration routes.

"The full spectrum is what we talk about when we talk about mainframe modernization," Ensono's Dyer said.