Original blog can be found at:
http://community.ca.com/blogs/mainframe-voice/archive/2013/07/15/using-facts-to-go-on-offense-against-distributed-fud.aspx?c=sm
In my last post, “Myths and Misconceptions about the Costs of Mainframe Computing” I wrote about the challenges facing IT executives who see their department’s task list grow year after while their budgets shrink, and how the financial analysts and business managers are likely to take aim at the biggest line items. The result is that mainframe takes a hit because its costs are neatly conveyed as large line items while distributed costs are distributed across the financial report. Fighting budget battles is no fun and can easily take more time—and have a greater impact on overall IT department performance—than the real work of IT. But since many of you are likely to have to fight those battles, here are some points to help you.
To go on offense (or at least provide a robust defense), you need to shift the conversation from obtrusive or highly variable numbers on the spreadsheet to a reasoned discussion around the total cost of ownership (TCO) and total cost of acquisition (TCA) of various parts of the IT infrastructure. No reasonable business professional will ignore the facts of the situation. However, given insufficient and/or incorrect information, even reasonable business pros can—and will—come to faulty conclusions and make poor decisions.
When making IT purchasing decisions, in addition to the obvious incremental costs of hardware and software, ask whether your business management takes any or all of the following into account:
-
The cost to power IT equipment (servers, switches, etc.)
-
The cost of the space occupied by IT equipment? Do you even have enough space to contain additional servers and switches
-
The cost to cool IT equipment. In many cases, an increased workload can be absorbed by System z equipment already on the floor (by simply enabling the additional needed capacity), meaning there is no incremental cost for your System z equipment.
-
The additional cost of all of the above for development/test/QA environments
-
Enabling backup/recovery, disaster recovery and/or business continuity capability in the environment
In many cases, the distributed system "bid" does not include any of these costs. When you parachute a new workload into an existing System z environment, it tends to already have these capabilities "in the base." The incremental cost can be far less than having to newly establish these capabilities for a distributed implementation. -
The cost of new personnel to manage the systems. Typically on System z, as long as the workload is not a complete departure from what is currently in the environment, the demands of new workloads are easily absorbed by existing staff. My observations show that the number of administrators for an IT group is a function of the number of servers. The cost of the required additional admins required by the new implementation should also be included into the distributed bid.
-
The cost to upgrade or refresh the systems: make sure that the bids cover enough time to include at least one hardware technology refresh at some predicted application growth rate
Also, there's this funny thing about the cost of System z software: for most products, incremental increases in software capacity always costs less per MSU than existing capacity--each incremental MSU costs less than the previous one. This means is two things: first, the cost of the added capacity will actually be less than the capacity you are already using. Second, adding new capacity reduces the average cost of all of your current capacity. That’s right, adding new workload actually reduces the cost of the workload that is currently running.
With regards to the fact that variable costs draw attention when high as discussed in my previous post, a little conversational jiu-jitsu might be helpful. Rather than responding to the complaint in a defensive way, "Well, it was a busy month. Last month, the cost was only 70 percent," try turning it around. Remember that overall cost of the distributed infrastructure (when fully discovered and added together) is going to be a rather large fixed cost, regardless of whether the infrastructure performs a single transaction or one billion in a particular month. You can say something like, "Yes, absolutely it cost more this month. We did twice as many trades as the previous month, which cost about 70 percent of this month. What was the cost of the distributed side last month? Was it any different than this month? Do you even know how much they cost? Does that cost include…(and rattle of the list of items above)?"
Finally, this may be a way to get this conversation kick started. An IT analyst named Dr. Howard Rubin has done extensive research into the comparative economics of System z and distributed deployments. His research has found that, when you look at the costs of IT for product or service delivered, companies that use relatively more System z capacity deliver those products and services with an overall lower cost of IT than those that use more distributed. It may be helpful to have some of your company's financial people have a look at this research and consider the impact on your business.
Here are some links:
http://www.rubinworldwide.com/files/Mainframe_Economics.pdf
http://www.rubinworldwide.com/files/Mainframe_Cost_Effectiveness.pdf
http://www.youtube.com/watch?v=Y8PwBKJaSBI
It may just may be true that distributed IT at your company is being delivered in a more cost effective manner. However, if you and your company are serious about good IT cost management, this kind of exercise and visibility can yield other areas where you can become more cost efficient.
