Modernize the Application, Not Necessarily the Platform
Craig Mullins illustrates why mainframe application modernization should begin with business requirements, not a migration mandate
Modernization is one of those words that everybody in IT uses, but not everybody means the same thing when they use it. For some, modernization means cloud. For others, it means rewriting applications using newer programming languages. Still others equate modernization with APIs, microservices, containers, DevOps, AI or replacing anything that has been around for more than a couple of decades.
And when the mainframe enters the discussion, modernization too often becomes synonymous with migration. That is a big mistake.
It is vitally important to separate mainframe modernization and mainframe application modernization. The former begins by questioning the platform. The latter begins by examining the application, its business purpose, and how it can be improved.
Differentiating between the platform and the applications matters because sometimes the best way to modernize a mainframe application is to leave it on the mainframe.
Start With the Business Problem
Every modernization project should begin with a simple question: What problem are we trying to solve?
Perhaps customers need a better digital experience. Maybe developers need faster release cycles. Or it is possible that business functions trapped inside monolithic applications need to be exposed to mobile and cloud applications. Maybe the organization needs real-time access to operational data for analytics or AI. These are all legitimate modernization objectives.
“We need to get off the mainframe,” however, is not a business requirement. It is a predetermined technical conclusion. Architecture should follow requirements, not the other way around.
Consider a Db2 and CICS application that has processed millions of business transactions reliably for decades. It delivers excellent availability, provides strong security and transactional integrity and satisfies its service-level objectives. There may be very good reasons to modernize aspects of that application.
But why assume that moving it somewhere else automatically improves it? Frequently, that enterprise application is well-suited to—and works best on—an IBM Z mainframe.
The better question to ask is “Which parts need modernization, and why?”
Modernization Offers More Than One Path
Modernization is not a binary choice between “leave everything alone” and “move everything to the cloud.” There is a spectrum of approaches.
An organization can retain an application when it continues to provide appropriate business value. It can expose existing functions through APIs. It can rehost or replatform components. It can refactor troublesome code. It can rearchitect portions of an application to support different architectural patterns. More extensive situations may justify rebuilding or replacing an application altogether. And applications that no longer provide sufficient value should simply be retired.
Different applications—even different components within the same application—may require different approaches.
This is why enterprise modernization programs that begin with a blanket mandate are not ideal. They substitute a predetermined destination for architectural analysis.
Beware of Lift-and-Shift Modernization
One of the most appealing modernization approaches is rehosting, commonly called “lift and shift.” The attraction is understandable. Move the application to newer infrastructure with minimal changes and declare victory. But you have to ask yourself, what exactly has been modernized?
If the application contained inefficient SQL before the move, it almost certainly contains inefficient SQL afterward. If it suffered from poor data design, tightly coupled application components, unnecessary processing, obsolete interfaces or decades of accumulated technical debt, those problems did not disappear during the migration. You simply changed their address.
Worse yet, applications designed around the architectural characteristics of IBM Z may perform differently after they are moved. Mainframe applications have been engineered around sophisticated workload management, high-volume I/O, high availability, transactional integrity, security and tightly integrated subsystems such as Db2 and CICS.
Moving the application without understanding those dependencies can replace one perceived problem with several additional very costly problems.
This does not mean rehosting is never appropriate. It means rehosting should be chosen only when workload analysis indicates it is appropriate, not because somebody decided beforehand that everything needs to move.
Modernize Around What Already Works
Sometimes the most effective modernization strategy is to preserve the proven core of an application while modernizing how the rest of the enterprise interacts with it. The result is a hybrid approach that is quite popular these days.
The hybrid approach can make sense because it retains what works and modernizes only what needs it. Consider a CICS application that contains decades of tested business logic. Instead of rewriting that logic, it most likely makes more sense to expose selected business functions through APIs.
Suddenly a mobile application, web application, cloud service or partner system can invoke trusted mainframe business processes without knowing anything about the underlying implementation. That is modernization.
Likewise, change data capture (CDC) and event streaming technologies can make Db2 operational data available to downstream analytical systems with far less disruption to transactional workloads. DevOps practices can automate database change management and application deployment. Modern observability tools can improve understanding of application behavior across platforms. And AI applications can consume trusted enterprise information originating in systems of record instead of depending exclusively on disconnected copies scattered throughout the organization.
None of these things require abandoning the platform that already performs the underlying transactional processing exceptionally well.
Sometimes, an additional tool can greatly aid the modernization in-place approach. One such tool is IBM Data Gate, which provides an effective way to modernize access to mainframe data without requiring organizations to move their core transactional applications off IBM Z. Data Gate efficiently synchronizes data originating from the mainframe to modern cloud and lakehouse environments where it can be consumed by analytics, AI and high-volume read-only applications. The data to be shared can reside in Db2 for z/OS, IMS and VSAM.
The synchronization approach, which is also used in IBM’s Db2 Analytics Accelerator (IDAA) product, is integrated, low-latency, high-throughput and zIIP-enabled, helping to minimize the impact on the source transaction-processing environment. This is crucial for not impacting existing mission-critical workloads while still exposing mainframe data for modernization.
Data Gate demonstrates how you do not necessarily have to migrate the system of record to modernize access to its data. The mainframe can continue doing what it does exceptionally well: securely and reliably processing critical transactions. And synchronized copies of its trusted data are made available to hybrid cloud, analytics and AI workloads.
Don’t Forget the Database!
Modernization discussions frequently focus on application code and infrastructure while treating the database almost as an afterthought. That is dangerous. Applications can be rewritten. Infrastructure can be replaced. But the data usually survives both.
The database represents years, and many times even decades, of accumulated business information. Its structures embody business rules, relationships, constraints, history and semantics that may not be adequately documented anywhere else.
Migrating an application without thoroughly understanding its data can introduce substantial risk. And moving the data creates additional questions. What happens to availability? Recovery? Referential integrity? Security? Auditability? Performance? Regulatory requirements? Historical information?
These are not secondary implementation details. They are fundamental architectural considerations.
Technical Debt Travels
Another misconception is that migration somehow eliminates technical debt, but it doesn’t unless you put in the effort as part of the migration. But that typically is not done during migration projects, the goal of which usually is to move to the “modern” platform as quickly as possible.
Poor SQL transported to the cloud is still poor SQL. A poorly designed schema remains poorly designed. Unnecessary data movement remains unnecessary. Weak governance remains weak governance.
Furthermore, it is important to understand that inefficient applications can actually become more expensive when moved to consumption-based environments where every additional CPU cycle, storage operation, network transfer, and service invocation contributes to the bill.
Modernization should therefore include an honest assessment of existing technical debt. Fix what needs fixing. Simplify what can be simplified. Remove what is no longer necessary. But don’t assume that changing platforms accomplishes any of those things automatically.
Modernization and AI
AI adds another dimension to the modernization discussion. Enterprises increasingly want AI systems to interact with operational business information. And much of the highest-value operational information in large organizations resides on mainframes. Customer transactions, financial records, insurance policies, inventory information, account histories, and other mission-critical data frequently live in Db2, IMS, VSAM, and other mainframe data stores.
This makes mainframe systems potentially more strategically important in an AI-enabled enterprise. Instead of asking, “How do we move all this data somewhere else?” architects should also be asking, “How can we make trusted operational data securely available to the AI systems that need it?”
APIs, replication, CDC, streaming, data virtualization, retrieval architectures and other integration technologies provide multiple answers to that question.
Again, integration may provide more business value than migration.
Modernization Requires Judgment
There is no universal modernization architecture. A high-volume transaction processing application has different requirements than a departmental reporting system. A regulated financial application has different requirements than a marketing website. A system processing thousands of transactions per second has different architectural considerations than an application accessed by twenty employees twice a month.
This is where experienced architects, DBAs, developers, systems programmers and business specialists remain essential. That is, technology provides options, but experience determines which of those options make sense.
The correct answer may be to retain one application, encapsulate another, refactor a third, rearchitect portions of a fourth and replace a fifth.
That is not inconsistency, it is architecture based on an analysis of business requirements.
Measure Outcomes, Not Movement
Perhaps the biggest change organizations should make is how they measure modernization success. Success should not be measured by the percentage of applications moved off a particular platform. Instead, ask whether modernization produced measurable improvements.
- Did customer response time improve?
- Did application availability increase?
- Did development cycles become shorter?
- Did operating costs decline?
- Did security improve?
- Did integration become easier?
- Did the organization reduce technical debt?
- Can trusted operational data now participate more easily in analytics and AI?
- Did the business become more agile?
Those are modernization outcomes.
Moving an application from Platform A to Platform B is merely an activity.
Modernize What Needs Modernizing
IBM Z has survived multiple generations of computing not because organizations are incapable of replacing it, but because it continues to perform certain classes of enterprise computing exceptionally well. But that does not mean mainframe applications should remain frozen in time.
Applications should continuously evolve to support changing business requirements. Interfaces should improve. SQL should be optimized. Development and deployment processes should be automated. Data should be governed and made appropriately accessible. APIs should expose valuable business functionality. AI and analytics should be integrated where they provide measurable benefit.
But none of that automatically requires abandoning the underlying platform. The objective should never be modernization for modernization’s sake. The goal must be to create systems and applications that better support the business.
Sometimes achieving that goal requires moving an application. Sometimes it requires rewriting one. Sometimes it requires replacing one. And sometimes the smartest strategy is to take an application that already runs exceptionally well on IBM Z and build modern capabilities around it.
Modernize the application. Modernize the experience. Modernize the development process. Modernize the integration architecture. But don’t move the platform unless there is a compelling business reason to do so.
Because ultimately, modernization should be measured by the value it creates, and not by how much technology you managed to move.