Historically, IT organizations have abandoned the mainframe platform for cost reasons. It’s a fact, and there’s no getting around that; it’s true. Now whether that makes sense or not is another matter.
Howard Rubin has mentioned that 68% of production workloads is handled by mainframes, but mainframes only account for 6% of the IT cost. So, dollar-for-dollar, has the mainframe been replaced with a system that has as much throughput? In most cases, probably not. However, you can build a distributed computing solution with transaction throughput capabilities that are equal to a mainframe system, and you can indeed build a distributed computing solution as reliable as a mainframe system. That is also true. But the issue of the cost is probably just a case of the mainframe seeming like Bart Simpson. No matter what happened—it was his fault.
What I mean by that is that the mainframe suffers from being represented by a single entry in the budget, which makes it stand out as something bigger than anything else in the budget. In fact, if you are a large corporation that relies on mainframe computing, then you are definitely seeing a single cost that accounts for a whopping 6% of the entire budget. By itself that is a pretty big number. Nevertheless, this is not a fair comparison because distributed systems aren’t captured on a single budget line…not only is their workload distributed, so is their budget.
So if you are getting off the mainframe for cost reasons, and building a distributed system that has the same throughput and reliability of the mainframe that you are replacing, well, you’ve just lost out on your cost justification. The monthly mainframe bill is a large bill, but what you have to pay to build an equally capable distributed computing system will be much more. Sure, a single distributed server costs less than a mainframe system—a lot less. As well, the licensing fees you pay for the software that particular server runs is a lot less than the licensing fees you pay for the mainframe system.
Of course, you’d never be able to replace a mainframe system with a single server, everyone knows that. But does everyone know just how many of those less expensive boxes you need to build so you have something equal to that mainframe system? Probably not. Enormous throughput capability and five to seven-nines reliability don’t come cheap, and they really don’t come cheap for a distributed mainframe replacement system.
All those boxes also need to run licensed software, so it’s all those boxes multiplied by that smaller licensing cost. Now things are seriously adding up. At the end of the day, think of it like this. If I could show you how to cut the mileage cost of your car by two-thirds and reduce the wear of the car by half, I’m betting that you would probably use your car more frequently and be glad to do so. Think of the mainframe in those term: it’s like getting more out of your car rather than switching from your car to taking a cab or a bus everywhere you go.
What about the applications that are running on the mainframe, and what would be needed to get that functionality running on the distributed solution? Well, how long is a piece of string? If there are applications that should be off the mainframe it is my belief that those applications have already been moved off the mainframe long ago. Really, is anyone running simple payroll systems on the mainframe anymore? Probably not.
What is left are the most complex, but most important, core applications that may be producing 68% of the workload for 6% of the budget. Even so, for most customers I have seen, the revenue that those applications account for is considerably higher than the administrative cost of processing payroll. Those complex applications bring in business revenue, and are not administrative costs. So risk becomes critical in factoring in your migration plan. The risk of migrating an application that helps you adjust cost downwards is nothing compared to the risk of stopping revenue recognition—and then this is where we hear the horror stories of people trying and failing. Not only does the cost of acquiring that revenue potentially increase, but that revenue may all out stop—so hands up for who wants to tell that to the board of a publicly traded company.
And that goes right back to what I said at the start: most folks get off the mainframe for cost reasons and don’t really consider the risk of doing so, or that the mainframe actually may not be just a cost factor per se, but a revenue-generating instrument core to the business. When we delve into the actual costs, the mainframe is quite a bit cheaper to run than a distributed computing solution that is as powerful and reliable as the mainframe. In fact, in some cases, the mainframe is cheaper to run than a distributed computing solution that is somewhat less powerful and less reliable. For instance, recently we worked with a major credit card company that did the math; they were shocked at the results that showed the mainframe was much more economical.
There are, of course, businesses that cannot justify the cost of mainframe computing, and really don’t need that level of power and reliability. Nevertheless, watch what you are doing. If you are looking at applications that help you control costs instead of generating revenue, then maybe you’re looking at the wrong platform. For smaller businesses, less computing power and three-nines reliability is perfectly acceptable. And most of those businesses migrated to a cheaper platform long ago. Those businesses still running mainframe systems rely on them, and run them at a lower cost—both in terms of operational expense and capital expense—than is possible for any other platform providing the same level of throughput and reliability.
Allan Zander is the CEO of DataKinetics – the global leader in Data Performance and Optimization. As a “Friend of the Mainframe”, Allan’s experience addressing both the technical and business needs of Global Fortune 500 customers has provided him with great insight into the industry’s opportunities and challenges – making him a sought-after writer and speaker on the topic of databases and mainframes.