The world’s banking and financial systems are built on mainframe technology – more than 75% of all banking transactions pass through a mainframe at some point – and the mainframe occupies this prized position for a number of very good reasons.

During the build-out phase in banking infrastructure in the 70s and 80s, it was the only technology that could do the job. Given the demands for throughput and reliability the banks had to meet, there was no choice.

The mainframe has a well-deserved reputation for RAS (reliability, availability and scalability), attributes that have justified its high cost for 40 years. However, costs have become an issue recently and mainframe vendors, including IBM, have been lowering the cost of buying hardware and exerting considerable influence over the cost of software. But while these vendors delivered cost reductions of 15% to 20% a year per MIP, other technologies like the X86 chips from Intel and AMD have consistently delivered cost reductions of 30% to 40% for a comparable amount of computing horsepower. Given the math, it was inevitable that non-mainframe technology would represent the cheaper option, that is, if you’re just looking at the problem in terms of cost-per-MIP and overall scalability. In the diagram here, see the considerable overlap in RAS when comparing mainframe technology with X86-based alternatives.

Meanwhile, the RAS advantage that mainframes boast has been declining despite the ongoing improvements that the leading vendors have made, as the cost of building highly resilient X86-based systems has fallen dramatically, thanks to improvements in hardware and, just as important, middleware technologies that support clustering, load-balancing and fail-over.

Raw computing power is only part of the equation, which includes the RAS we’re looking for and the applications themselves. Unfortunately, few financial institutions have the luxury of simply rewriting their apps to run on a new platform, an approach called ‘rip and rewrite’ with a well-earned reputation for being risky, complex and prone to failure. True, some firms can take advantage of application replacement, where an old application is replaced completely or in part by an off-the-shelf product that runs on a lower-cost platform. But even this approach carries significant risks, and is often seen as prohibitively expensive.

There’s now a third option. Vendors like Micro Focus and Fujitsu offer middleware that natively emulates the mainframe on other platforms, including Microsoft .NET. Instead of rewriting applications in their entirety, this middleware makes it relatively easy to simply port the existing application. Of course, in practice, the process is very rarely as simple as just grabbing the code and recompiling it on the new platform. But while there is inevitably some rewriting to be done, there are now a number of well-documented examples where the amount of recoding required to re-platform legacy applications was trivial compared to the impact of other options.

Clearly, CIOs now have another choice: they can migrate applications away from the mainframe and run them on lower-cost hardware. I’d stress, however, that this approach is another option that needs to be considered alongside the others. It is not ‘the’ answer to the legacy dilemma, and it’s not going to be suitable to every application by any means. For very large applications, those consuming in excess of 5000 MIPS, there is still a very compelling case for the mainframe, but in the 0-1000 MIPS range, the mainframe’s advantage is far less clear – and continues to erode as time passes.

The important thing for CIOs to understand is that while the mainframe is alive and well (and it’s not about to disappear), when it comes to the question of legacy modernization and renewal, there are more options today than there ever were before.

Gary Barnett is Ovum’s research director responsible for open source, intellectual property and on-demand technology, focusing on the strategic issues surrounding technology selection, best practice and strategy. He has also worked on numerous consulting projects for UK, European and US firms on technology selection and strategy, and has run several of Ovum's research practices covering application development, middleware and enterprise architecture.