Modernizing on - not off - the mainframe as a cost-effective alternative

Companies that rely on proprietary mainframe technologies for in-house developed applications are increasingly faced with challenges. Among the typical concerns heard from these organizations are out-of-control licensing costs, diminishing development skills, and the difficulty to integrate these applications with other more open technologies. Together, these challenges pose an important business risk.

Most of these applications however have been around for decades, and enterprises have made considerable investment in them over the years. The unique and often subtle business logic they contain is perfectly tuned to the organization’s business and drives competitive advantage.

As a result, these applications are very hard to replace with COTS (commercial off-the-shelf software). Rewriting them from scratch is a risky endeavor that is very hard to plan for and often fails in execution.

One solution is to perform an automatic “like for like” migration, using conversion tools to bring the legacy application to a more open environment (relational database, modern programming language, cheaper or open licenses), while guaranteeing 100% functional equivalence.

Mainframe Migration Misconception

Today’s “distributed” hardware platforms (Linux/Unix/Windows) offer stability, reliability and scalability that is comparable to that of mainframes, often at a fraction of the cost. This may lead to the misconception that any migration of a legacy mainframe application necessarily means abandoning the mainframe platform, replacing it by Linux/Unix/Windows.

While replacing the entire platform is feasible, and may be desirable in certain situations, this exercise involves much more than migrating just code: one must consider and implement alternatives for the entire surrounding ecosystem of the application, such as printing, job scheduling, security, archived data, integration with external systems, disaster recovery, and so on.

The converted application needs to be integrated with the new platform yet remain compatible with the old on each of these points. Staff needs to be hired or retrained for the new platform, and procedures need to be updated.

Sometimes, however, much of the cost and effort of the ecosystem replacement can simply be avoided, by migrating the mainframe application but remaining on the mainframe platform.

Technology Update

As initially stated, the issues that many CIO’s face are often caused by “legacy”, not by “mainframe” technology as such. Much of what is available on mainframes is increasingly open: COBOL remains one of the most ubiquitous programming languages in the world and is backed by ANSI and ISO standards. DB2 is SQL compatible, and supports integration using ODBC and JDBC among its protocols.

Mainframes run Java and speak the language of the web, and many parts of mainframe applications can be maintained and debugged remotely using the latest IDEs. For these mainstream technologies, licensing costs and skill shortages are rarely critical issues.

But what about proprietary 4GLs, CASE tools, and pre-relational databases like SAG Natural Adabas or CA IDMS? The lack of suitable skills and the licensing schemes employed by some vendors are quickly becoming a primary concern for CIO’s invested in those technologies.

What can help here is an in-platform technology update: take the dependency on closed technologies out of mainframe applications and replace it by mainstream mainframe technologies, without touching the application behavior or the underlying platform.

As in all our mainframe migrations, this too is what we call a “like for like” migration: the application’s functionality can remain 100% identical, meaning zero impact on business users.

What’s different here is that the “surrounding ecosystem” remains untouched as well, meaning zero impact on infrastructure and external interfaces, zero or near-zero impact on support staff, and a quicker and less complex migration project.

What you achieve is the update of the underlying technology on which your application operates: prerelational databases can be replaced by DB2, proprietary 4GLs can be replaced by COBOL, specialty TP monitors can be replaced by CICS.

Key Ingredient: Automated Testing

Apart from reducing impact on business users, a “like-for-like” migration has another important benefit: the correctness of the converted programs can be measured by comparing the behavior of the converted applications with the originals. Same input should yield same output, period.

This process of comparing before and after can be automated. The original application inputs and outputs can be recorded using tools that are readily available on the source platform. The testing tool then replays these scenarios on the converted application and compares the results. This procedure can be repeated any number of times without the need for business users or dedicated testers, dramatically reducing cost, effort and time spent on testing.

Automated testing with scenario discovery is the key ingredient to reducing project costs of automated mainframe migrations, enabling straightforward planning and project management even for large applications. Many cases are documented where automated migrations with automated testing are completed in under 12 months.

Opportunity: Optimizing License Schemes

As soon as you’ve abandoned your legacy technology in favor of more mainstream technology, considerable savings can be achieved on licensing costs. IBM licenses for CICS, DB2 and Enterprise COBOL are generally much more permissive than equivalents from vendors such as SAG and CA.

But there is more. By carefully exploiting specific licensing options offered by IBM (such as zNALC) or by shifting workloads to zIIP or zAAP processors, additional important cost savings can be achieved.

Last but not least, the mere fact that you are considering a mainframe migration could put you in an improved negotiating position with your vendors. Because your mainframe migration is a fixed price project, you can clearly demonstrate the business case for each scenario (do nothing, migrate on the mainframe, or migrate off the mainframe). Armed with this information, perhaps you can inspire your IBM representative to go the extra mile.

Enabling Future Growth

A mainframe-to-mainframe migration can get the most prominent business risks out of the way quickly, and provide IT and business with means to re-enable growth from day one:

• As skills for mainstream technologies are easier to find and cheaper to attract than niche knowledge, development teams can be staffed more flexibly and in-line with business demands
• Staff can be more productive thanks to modern development and testing tools. For instance the same automated testing tools used during the migration can also be used post-migration, for regular application development
• Increased processing power and hardware capacity can be purchased without the typical and sometimes excessive increase in ISV license costs. This makes it possible to realign hardware capacity more “comfortably” with growing business needs
• Application data is no longer shielded by proprietary interfaces and can freely integrate with a multitude of applications (data warehouses, analytics software, reporting tools…) that have built-in support for relational databases. Industry standard interfaces such as ODBC and JDBC allow new development (for instance in Java on z/OS) to integrate directly into the same database without restrictions or risk of further vendor lock-in.

Apart from these short-term benefits, a migration towards open technologies can also be part of a longer term strategic vision of not being dependent on a single vendor for one’s core technologies. While it’s unlikely that IBM mainframes will soon become a bottleneck to your enterprise, it’s reassuring to know that the technologies now used by your modernized applications are to a large extent interchangeable or compatible with products available on practically any other platform out there.

Consequently, a mainframe-to-mainframe migration can be an empowering stepping stone on the path to full modernization that will make a possible future migration off the mainframe a lot less painful.

"Like for like" Migrations

Getting a grip on licensing costs, modernizing your application architecture and integrating with your enterprise is very well possible while remaining on the mainframe. Modernizing on - not off - the mainframe may be a cost-effective alternative that provides you with a modernized and open application environment while leveraging previous investment in mainframe technology.

Astadia's automatic “like for like” migration approach makes this a straightforward, predictable, fixed price project.

‍