top of page

Mainframe Modernization & Transformation Morphologies with Kyndryl and GCP

By: Dean Pratt

::: Current Trends :::

Let’s start this off with a fun fact. Did you know COBOL (Common Business Oriented Language) is now 63 years old? Founded on some of the FLOW-MATIC principles by the iconic Grace Hopper and developed by others like Jean Sammet, the US Department of Defense relied on it to unify data processing technologies in 1959. In most enterprise scale deployments utilizing mainframe technology, moving away from such a foundational programming language can be well, scary. Being involved in the tech industry, we know that any kind of IT outages directly equate to more dollars and revenue lost than ever really accounted for; especially considering the social impact on perception of that unfortunate company. Future business income and expansion lost is very hard to measure but easy to realize, and it hurts everyone.

Obviously, it’s not all negative though by any means. As the saying goes, “With great planning come great rewards.” — The Amazing Techman…or something like that lol. With rapidly evolving cloud offerings and AI driving automation, DevOps, analytics and efficiency innovation, many companies are setting a course for a new way to host their infrastructure and develop applications outside of the mainframe. To assist in that voyage, hosting current mainframe solutions with a major cloud provider like Google not only offers resilient availability, it provides notable reduced latency when interacting with other cloud applications and workflows.

All things considered, today’s CTO has much to gain by modernizing and transforming, but every company’s path will naturally look different. With the progressively increasing lack of COBOL technical resources, some will find it best to start the process of converting business apps immediately, and others not so much. There are plenty of stair-step approaches when choosing what apps to convert to a modern language, what COBOL apps to refactor into microservices behind APIs and what mainframe apps to host in the cloud yet leave as is until there is no other option. As CTOs are critically determining the nervous system of organizations today, when performing such a transplant, much care and caution should be involved in the planning and assessment phases. The quickly manifesting reality is that COBOL has a lifespan of 10–15 years, with estimates that 10% of its programmers are retiring every year. So is there really an excuse to remediate the sense of urgency in the name of “maintaining”? Is it absurd to hope the workforce changes don’t all come crashing down at once 10 years from now? Let’s take a look at some insights I’ve uncovered in my experience and other factors I personally see value in considering when setting a course for maturing mainframe ecosystems while maintaining future-state adaptability.

::: Pros & Cons :::

Though the journey of modernizing deployed infrastructure and nimbly evolving at the rate of progress in today’s world of technology is a daunting task, the benefits are numerous. Those who are resistant to change are at the very least destined for a hard time. When push comes to shove, the ROI and TCO benefits often diminish as there is more work and revamping that will need to be done. Monolithic COBOL environments have seen the writing on the wall for a while now…and it’s called “containerized microservices”. For clarity as you read on, the term “refactoring” means to reorganize the building blocks which preexist with slight modifications, “conversion” is defined as translating COBOL into a modern language.

Pros:

  • Agile application orchestration & growth path due to microservices architecture

  • Increased application functionality across entire ecosystem with API integrations allowing for new business outcomes & solutions

  • Cloud Native solution adjacency reduces latency and security risks while offering improved integration of Google Cloud offerings like industry leading security at scale, AI driven workloads/analytical pipelines & automated event based architectural solutions

  • Much more efficient consumption of purchased hardware due to a programmatic, multi-lithic application approach

  • Consumption pricing from Kyndryl/Google offers greater organizational OPEX flexibility for proactive initiatives

  • Kyndryl expertise in mainframe and managed cloud deployments reduces operational business risk and mitigates time to ROI for companies and clients globally

  • Cloud focused code transformation provides quicker evolutions in the future by utilizing managed services like Google’s Cloud Run service, eliminating the work needed for that foundational scripting

Cons:

  • Costs and time are involved in re-factoring and re-platforming apps

  • Often a 2–10 year process depending on the extent of infrastructure applications, transformation goals and the method of morphology employed

  • Scarcity of COBOL conversion tools and partners for implementation

  • Private cloud providers varying company lifespan & security resources/certifications

  • Introduces risk in multiple areas of the business that must be mitigated with planning and constant communication within the IT organization

::: Why Kyndryl & GCP? :::

Behind every sustainable IT solution is a talented team of growth oriented people who can look to the future and prepare a foundation for what’s potentially ahead. To that point, Kyndryl is a caring team of forward thinking, growth-focused professionals with some of the most knowledge and experience managing, migrating & modernizing mainframes in the world. At Kyndryl, there is a special focus put on innovation which is pivotal inside a company that manages so many expansive mainframe solutions. Partnering with a global-scale services integrator like Kyndryl offers mitigated risk, reliability and deep expertise into what success depends on when maturing your IT solution. They have experts waiting globally to discuss, plan and evaluate the best methods and architectural morphologies that are top of mind with you and your team. They also have experience with some of the largest enterprise deployments around and provide that same level of polished service and expertise to anyone they have the privilege of working and investing time with.

While there are many options out there for simply migrating existing mainframe/Power Systems to the cloud, many different providers, solutions and costs associated to choose from. Some differentiating points that stand out to me are security and reliability offered by a company like Google. Google Cloud is a leader in future-focused technology with over 850+ security engineers working constantly to protect its customers and the internet; as well as many needed and necessary compliance and security certifications. Google has defended against the two largest DDoS attacks publicly announced and are constantly offering cutting-edge automated ways to safeguard any solution. It is hard to find a partner with the same amount of experience working with mainframe and Power technologies. Everyday Kyndryl and Google Cloud teams work together to mature their creative and innovative initiatives, improving our customer’s pathways to success, manifesting their visions into a tangible reality. 👌

::: What’s Involved? :::

Before embarking on this massive undertaking, plan, plan, plan.

It can not be stated enough that the planning phase is going to make or break the success of your solution. Kyndryl brings experience with replatforming, refactoring and converting COBOL applications due to their vast experience in managing mainframe and Power technologies. They can perform an in-depth MAPA (mainframe application performance assessment) and ROI analysis of which apps need to be converted first due to factors such as:

  • Mission critical apps with an immediate lack of legacy support or developers

  • Primary monolithic apps that would benefit the most from breaking out into microservices or event-driven, containerized architectures for a reduction in compute and operational resources

  • Apps that limit typical user interaction due to interface/COBOL limitations (green screens with limited views)

  • Slow performing apps that would benefit from faster user experience (often customer facing)

  • Apps that are paramount for internal primary technologies to enable future agility and integrations

  • Any applications that need increased proactive security or AI/ML features added for increased functionality (Google cloud native models can be massively effective in development time reduction)

A couple of powerful tools Kyndryl utilizes are Stratozone and CAST when it comes to application assessment. Kyndryl also tightly aligns their approach with the C.A.M.P. methodology Google created for cloud migration journeys. The TCO of maintaining the current state of operations must be compared with the cost of hosting in a hyperscaler like Google Cloud or any other option, but make sure to include the increasing COBOL developer problem costs and losses potentially associated with a sudden lack of support for any changes in the future, period. That’s hard to put a price on but a best guess must be made…this isn’t an insurance policy, this is a definite change gleaming on the horizon. Waiting until there is no other option obviously makes this whole motion much more difficult and stressful. It also reduces all the added beneficial features to app transformation that taking the appropriate time brings. The key is to not ignore the growing need for staying ahead of the curve as day to day activities often have our attention swept away in other places.


Diagram of a sample application modernization decision tree.

::: Transformational Strategies :::

Transforming a mainframe solution is a multifaceted approach, there are many ways to modernize. Completely recoding mainframe COBOL apps is the smartest thing to do long term, but it isn’t always needed. Efficiently aligning with the app’s lifecycle and desired functionality/feature set is pivotal. Here are some options that aren’t as well known currently but offer benefits to many different scenarios.

  1. Break out the existing COBOL code into microservices by utilizing APIs. This is one of the quickest ways to optimize monolithic architectures, it still leaves the future of COBOL app support unanswered though. This option could be a solid choice as a middle ground while waiting for the app’s code to actually be converted to something current or replaced.

  2. While the best practice is to convert COBOL apps into a modern language like Java, mainframe COBOL is decently portable and can be refactored to work with AIX which may make more sense than emulating. This applies when evaluating the viability of emulating a mainframe environment which adds another layer of latency inducing software as opposed to running the code in a physically adjacent hyper-scaler offering. Using mainframe COBOL compilers to transform code into AIX compatible runtimes can potentially save on the time it takes converting apps to a completely new language while offering compatibility with Google Cloud’s IP4G offering. This is important when utilizing other Google Cloud offerings like Big Query and GKE for utilizing the benefits of datacenter adjacency. For example, real-time analytics and SAP solutions often see immense improvements when utilizing Big Query natively. Behind the covers, Google Cloud offers an IP4G (IBM Power For Google Cloud) marketplace offering with Converge, who strategically places their datacenter infrastructure next to Google Cloud datacenters for the best customer experience when utilizing the platform. This is critical when aiming to complete a mainframe transformation that still performs like a traditional on-prem deployment. What is key to be aware of is what else the COBOL app is using in terms of middleware such as CICS, IMS, VSAM, DB2, etc. when refactoring. Also, the data on AIX COBOL is ASCII and for mainframe it’s EBCDIC. This can sometimes affect calls like: SORT, MERGE, LE and even things as subtle as IF statements so the planning stage is critical. This can still be part of a winning strategy as some depreciating apps may not need to be converted, rather just refactored into a right-sized, hosted environment. This approach only works in some situations, other apps may require more work than it’s worth to fix the compiler errors, assembler routines or other integrations. The other benefits when refactoring as opposed to emulating like license cost savings, more adequate hardware choices and staff retention play a part in utilizing this option as well. IBM and others offer compilers like this for AIX COBOL to also integrate with web services, XML and Java. It is one path of least resistance to modernizing however much like the option I just discussed, it is still only a bridge while waiting for modernized app code that offers increased integration benefits, natively reducing latency in hybrid or multi-cloud solutions.

  3. Use a code conversion tool like Google’s G4 offering which has technical teams to support the process. This is the preferred option by far. There are a few different COBOL converters out there, each with their own maturity level and benefits. It’s important to work with established solution providers and integrators when embarking on this path. The G4 tool is definitely a powerful ally when converting code and cuts out the time it takes to start from the ground up. “It inspects the meta-information gathered from all source code business logic, job control, data definitions and schema files, configuration files, and other source codes that make up the application landscape. It breaks down all source code using tools such as preprocessors, generated parsers, linkers and modelers to build a comprehensive meta- information model called G4 Hyper Model. This model eases metadata queries, enabling consultants to visualize an application’s current architecture from different perspectives. This benefit allows consultants to choose the best migration strategy, including the feasibility of automated conversion tools.” Keep in mind that with all of these compilers and conversions, there will always be code revisions and modifications necessary after the resulting transformations. Google together with experienced mainframe partners like Kyndryl offer assistance in this undertaking and are helping many companies today navigate their transformation voyage. This is a sustainable and efficient long term strategy that also enables application code features to be added or changed in the process as well.

  4. Clearly define a hybrid modernization approach. You can either move, refactor or convert. Set a timeline for which critical applications must be converted first, then which apps can be refactored and eventually converted in time. Next, which apps should be emulated or remain as is with the intention of sunsetting them in the future. Many cost analysis reports you will read about modernizing application code highlight the workforce reduction savings and positives of development agility. I personally think the zenith of reasons why revolves around proactive behaviors for success in the current trends of a quickly and constantly evolving industry. Staff doesn’t have to be reduced, learning just has to take place; and if you work in technology, when does it not? For example, “Hey team, you know our COBOL applications better than anyone and now, we need you to learn a modern language as we convert them for future agility and growth.” Results may vary lol, but why let go of the most experienced insight into your solutions?

  5. Google just announced an offering called Dual Run that will even further assist in replicating mainframe environments into GCP seamlessly by utilizing parallel processing and when available, Kyndryl will be there to help deploy it. I will further add to this section as more details are released but this option will definitely expedite the transformation process while benefiting from Google Cloud’s resiliency, scalability and security.

Companies are constantly moving away from the mainframe for a more intelligently refined approach to infrastructure and to drive more innovative business solutions that last. It’s not about just treading water, it’s about surfing the wave of change all the way to shore. Sure, it’s a digital beach in this case, but it’s safe from the technological storms and virtual sharks that tend to find the unprepared. 😅🏖

::: Next Steps :::

Once again, converting the code is the best long term solution, the other options may work in a pinch. In closing, it’s simple. Can you afford to not refactor, modernize or transform your current mainframe solution? I would ask can you afford to not have a geophysically redundant datacenter solution? Can you afford the stunted business outcomes as a result of professionals focusing on maintaining as opposed to future-focused growth? Can you afford to not update or fix your applications 5–10 years from now?

Thanks again for reading and here’s to creating a winning strategy that lasts!

Comments

bottom of page