Evangelizing Mainframe
Print Email

Thinking of Removing an Application to Cut Mainframe Costs? Think Again!

Over the years, I’ve seen organizations look at migrating workload off of the mainframe and handling that work with a “cheaper” platform. Many of us know there are multiple problems with this strategy; I am going to focus on one area, the idea that removing an application or workload will reduce cost.

It seems intuitive. If an application is moved from the z/OS platform to another system, the z/OS costs should go down, right? Think again!

Rarely do I encounter a single application that contributes to a large part of the mainframe expense. Those that do are there for good reason (think availability, performance, etc.). Realizing this, organizations most often choose not to migrate them.

Looking at mainframe software and hardware pricing, you will see a sliding scale in many pricing models. Most often, as incremental capacity increases, the price decreases with both hardware and software. The bottom line here is moving one application out of the z/OS environment potentially removes a capacity requirement that’s at the lowest price point available for a given installation. The net effect is the overall cost attributed to the remaining workload will usually increase, a fact that has political consequences, especially for organizations using a charge-back model for mainframe service.

More importantly, cash flow on the platform frequently remains the same, in other words, no real money is saved on a yearly basis when an application is removed. There are a few reasons for this. In many cases, the stack of software for the mainframe is shared among all applications. For example, many applications use both CICS and DB2; this effect is even greater with monitoring and systems-management tools. Removing one application doesn’t obviate the need for all of these tools and subsystems. There might be some incremental change in cost if a vendor bills by usage, however, even then, the usage must be enough to affect the overall average to realize any savings. In some cases, hardware capacity can be deactivated for a savings in maintenance, but again, the usage removed must be large enough that a CPU change will not cause a shortage of capacity for the remaining work. Many organizations also pre-pay maintenance, so the short-term effects will again amount to nothing.

As mentioned, hardware and software vendors motivate customers to do more business with them by decreasing costs as capacity increases, removing a single application that doesn’t amount to a large portion of mainframe capacity will not necessarily translate into future savings either. For instance, base costs are figured into hardware purchases that must be covered to even put a machine on the floor. If you haven’t removed a significant portion of the workload, the future hardware cost is likely to remain the same.

Another factor that’s often underestimated is migration costs. Even with a simple subsystem there’s a great deal of systems-engineering work required to provide a brand new environment. When organizations underestimate this effort, the result is a Catch-22 of sorts. Once an upfront investment is made to move an application, it’s often politically difficult to pull the plug; so when overruns arise and estimates are reworked requiring additional investment, the cycle continues. I’ve seen one organization that’s more than 10 years into a mainframe migration, and its real mainframe cost is a very small fraction of what has been spent to remove it. In other words, it’s been a real disaster!

Taken together, you can see why you owe it to your organization to provide a detailed, in-depth, thought process on mainframe total cost of ownership. When adding the expense of new platforms to deploy applications, which I have seen cost two or three times that of the mainframe run rate, it becomes very clear that removing applications from the mainframe is the wrong thing to do to reduce costs! There are many better areas to look at to reduce costs, which will be the topic of a future blog post.

Chris Gombola is Enterprise IT Architect with 13 years of experience at IBM.

Posted: 1/9/2012 7:32:03 AM by Chris Gombola

Print Email

Join Now!