Busting the Biggest Myths About Modernization
A hybrid model, making efficient use of the strengths of all available systems, is the key to achieving the lowest possible cost per transaction and maintaining SLAs
By Mark Gambino10/26/2020
You're not the first to tread this path and can refer back to what's worked—and hasn't worked—for other businesses. All that said, you've probably heard a few common misconceptions about modernization. Here are four big ones:
- Moving everything off of the IBM Z® platform will reduce costs and save millions of dollars every year.
- Moving read-only type applications (those that read data but do not update data) off of the IBM Z platform will always reduce costs.
- Modernization means re-writing the entire application.
- Application agility is only possible in the cloud.
Analysts and industry leaders have agreed on the answer: a well-architected combination of cloud and the IBM Z platform—thus, hybrid cloud: a framework that is quickly becoming the new norm across enterprise computing.
So, let's return to that first misconception: what would modernization look like if you decided to move everything to the cloud?
Breaking Down Operating Costs: Best-Case ScenarioTime and again, we've seen new executives try to make a splash when joining their company. In one instance, an executive promised to cut IT costs in half by creating a state-of-the-art reservation system, and getting their company off of the IBM Z platform. According to their estimation, all they needed was five years and $100 million.
But their accountants did the math—and realized that it would take at least 15 years to break even and begin realizing a return on their investment.
Let's break that down. For the sake of the example, let's hypothetically say the annual operating costs for the IBM Z architecture runs around $20 million annually, including expenses related to hardware, software, database, networking, operations, and beyond. Meanwhile, the company expects that a new, state-of-the-art cloud-based system would cost $10 million a year.
As they spend $20 million annually to develop their new system, they're also spending $20 million a year to run their existing system—so, after five years of development, the business has spent $200 million on their reservation systems. Then, after a decade of using the new cloud-based system, costing $10 million annually ($100 million over 10 years), they can expect to have incurred a total of $300 million in expenses.
But if instead of pouring resources, money, and time into this new system, they'd stayed on the IBM Z platform for the entirety of those 15 years, they would have also incurred $300 million in expenses.
So, while this new executive effectively made a splash, it probably wasn't the kind of splash they hoped for. Instead of optimizing what already worked, they doubled their expenses for five years, lost opportunity costs to develop new functionality, and needed to re-write and re-platform their applications and data for the cloud-based system. Beyond those initial pains, they now have a larger, more complicated environment to manage and debug—instead of a single cluster environment on IBM Z, they're now working with dozens of applications and database clusters.
This is all a best-case scenario—if development is dragged out past the expected five years, or the new platform doesn't run as cheaply as expected, their break-even point is now decades, or lifetimes beyond where they originally expected.
Breaking Down Operating Costs: Worst-Case ScenarioNow, let's talk about a worst-case scenario: where the newly developed solution actually costs more to run wholly on the cloud than it did on the IBM Z platform. If you've attended recent TPF Users Group conferences, you likely heard the following stories being shared.
The first story: Company A wrote a brand-new cloud native reservation platform costing upwards of $100 million to develop. After merging with Company B, who used an IBM Z-based reservation system, they had to determine which system to keep.
They did an apples-to-apples comparison of the cost of each bookable item (such as an airline flight, hotel, train) on both platforms. The result? Company A—using their new cloud-based reservation system—only managed 1/3 of the bookable items as Company B, and their operating expenses were 3x higher. In other words, their newly fashioned architecture was 9x more costly than the IBM Z platform. It won't require any mental gymnastics to figure out which system they decided to keep.
The second story shared at the conference illustrates that cost is not the only factor to consider. A financial industry customer developed a new cloud-native system for real-time transaction processing, but once deployed into production, the system had issues processing larger workload volume, reliability, and meeting other SLAs. In the end, the cloud-based system was replaced by a z/TPF system to process that workload.
The key factors in both customer examples are the fundamental differences in architecture. The winning solution was z/TPF, with applications and data colocated on an OS specifically designed for high-volume, write-intensive workloads, all leveraging IBM Z hardware. The cloud-based systems, with its workloads split over dozens of server clusters, running on general purpose operating systems on commodity hardware, created a number of issues. In one case, it was nearly an order of magnitude more costly, and in the other, it struggled with latency, performance and database contention—all factors that impede workload scaling—and made it nearly impossible to maintain SLAs.
Developing a Hybrid ModelAll of this being said, our point is not to run all your workloads on the IBM Z platform, just as you shouldn't run all workloads on cloud. A hybrid model, making efficient use of the strengths of all available systems, is the key to achieving the lowest possible cost per transaction and maintaining SLAs. Your aim should be to progressively modernize key assets, while connecting your components through open standards, leveraging micro and macro services, and building out an event-driven hybrid cloud architecture.
In my next article, I'll discuss the distribution of workloads across the hybrid cloud, and dig into the what, where, and why for designing an architecture best positioned for many more years of success. Then, in future articles, I'll tackle the remaining misconceptions and explain how to modernize existing z/TPF assets, and also how to leverage modern DevOps principles in your z/TPF development process.