Lessons from IBM Eagle-IBM Systems z TCO Analyses
A company running an obsolete z890 2-way machine with what amounted to 0.88 processors (332 MIPS) planned a migration to a distributed system consisted of 36 distributed UNIX servers. The production workload consisted of applications, database, testing, development, security, and more. Five years later, the company was running the same in the 36-server multi-core (41x more cores than the z890) distributed environment only its 4-yearTCO went from $4.9 million to $17.9 million based on an IBM Eagle study. The lesson, the Eagle team notes: cores drive platform costs in distributed systems.
Then there is the case of a 3500 MIPS shop which budgeted $10 million for a 1-year migration to a distributed environment. Eighteen months into the project, already 6 months late, the company had spent $25 million and only managed to offload 350 MIPS. In addition, it had to increase staff to cover the over-run, implement steps to replace mainframe automation, had to acquire additional distributed capacity over the initial prediction (to support only 10% of total MIPS offloaded), and had to extend the dual-running period at even more cost due to the schedule overrun. Not surprisingly, the executive sponsor is gone.
If the goal of a migration to the distributed environment is cost savings, the IBM Eagle team has concluded after 3 years of doing such analyses, most migrations are a failure. Read the Eagle FAQ here.
The Eagle TCO team was formed in 2007 and since then reports completing over 300 user studies. Often its studies are used to determine the best platform among IBM’s various choices for a given set of workloads, usually as part of a Fit for Purpose. In other cases, the Eagle analysis is aimed at enabling a System z shop to avoid a migration to a distributed platform. It also could be used to secure a new opportunity for the z. Since 2007, the team reports that its TCO studies secured wins amounting to over $1.6 billion in revenue.
Along the way, the Eagle team has learned a few lessons. For example: re-hosting projects tend to be larger than anticipated. The typical one-year projection will likely turn into a two- or three-year project.
The Eagle team also offers the following tips, which can help existing z shops that aren’t necessarily looking to migrate but just want to minimize costs:
- Update hardware and software; for example one bank upgraded from z/OS 1.6 to 1.8 and reduced each LPAR’s MIPS by 5% (monthly software cost savings paid for the upgrade almost immediately)
- Take advantage of sub-capacity, which may produce free workloads
- Consolidate System z Linux, which invariably saves money; many IT people don’t realize how many Linux virtual servers can run on a z core. (A debate raging on LinkedIn focused on how many virtual instances can run on an IFL with quite a few suggesting a max of 20. The official IBM figure: consolidate up to 60 distributed cores or more on a single System z core, thousands on a single footprint; a single System z core = an IFL.)
- Changing the database can impact capacity requirements and therefore costs
- Workloads amenable to specialty processors, like the IFL, zIIP, and zAAP, reduce mainframe costs through lower cost/MIPS and fewer general processor cycles
- Consider the System z Solution Edition (DancingDinosaur has long viewed the Solution Edition program as the best System z deal going although you absolutely must be able to operate within the strict usage constraints the deal imposes.)
The Eagle team also suggests other things to consider, especially when the initial cost of a distributed platform looks attractive to management. To begin the System z responds flexibly to unforeseen business events; a distributed system may have to be augmented or the deployment re-architected, both of which drive up cost and slow responsiveness. Also, the cost of adding incremental workloads to System z is less than linear. Similarly, the cost of administrative labor is lower on System z, and the System z cost per unit of work is much lower than with distributed systems.
DancingDinosaur generally is skeptical of TCO analyses from vendors. To be useful the analysis needs context, technical details (components, release levels, and prices), and specific verifiable quantitative results. In addition, there are soft costs that must be considered. In the end, the lowest acquisition cost or even the lowest TCO isn’t necessarily the best platform choice for a given situation or workload. Determining the right platform requires both quantifiable analysis and judgment.