I'll be blunt. The cost of software is killing the mainframe. Some costs, such as personnel and power are increasing but still are a small piece of the budget. Hardware, on the other hand, keeps getting cheaper with increased performance every year. Software represents the majority of dollars going out the door and impedes hardware upgrades because enterprises have to pay more for the exact same programs.
I'm aware that there's more to the cost of software than tapes and CD-ROM's. Renting and maintaining a development mainframe environment is expensive. So is 24 x 7 support. And let's not forget paying for the crackerjack programmers required for system level software.
I also know of independent software vendors (ISV's) who have survived for years on very reasonable, site-license based fees. They may raise their prices, but the increase is usually due to enhancements or expansions of the software. Personally, nothing is more aggravating than having to pay more for the very same software just because the new CPU runs faster or the box has more processing capacity.
IBM has made some feints in the direction of saving software costs. So far, at least, vendors don't include zIIP and zAAP processors in the overall processor capacity calculations. But how long will that last and are these specialty engines a permanent solution?
It's time to "commoditize" the mainframe.
The first step is following Microsoft's example and bundling the operating system and its parts. In other words, for one price a Z/Os user should get the base control program (BCP), data facility storage management subsystem (DFSMS), a network (VTAM with TCP/IP), a transaction processor (CICS or IMS) and a database management system (DBMS). For fun IBM could go one step further and include language (LE) development and runtime environments. IBM may be a little shy of bundling because of an old, 70's era anti-trust suit, but that was settled back in the 80's. It would also be laughably hard for the government to go after IBM while turning a blind eye to Windows and UNIX.
Second, IBM should go to a cell phone pricing method. Give the processor, a number of peripherals (e.g., open-system adapters), and a certain amount of DASD with the accompanying I/O infrastructure away for free. Any extras, such as additional I/O directors or cryptography processors can be added for a nominal fee. Then, for a monthly charge, an enterprise can use the mainframe up to as many MIPS (millions of instructions per second) are part of their plan. With each plan a company can opt for a hard capacity cap or something similar that allows them to use more processor as needed (like capacity on demand). Eventually, when the datacenter needs an upgrade, it's treated as a plan upgrade with a modest increase in fees.
I can think of several advantages to this plan. Companies will have a predictable monthly fee. They can also know that excess capacity will be available if needed. Software maintenance will be easier as IBM's support center sends out maintenance based upon the bundled software and the plan's profile.
This plan has advantages for IBM as well. It gives them a chance to push the type and quantity of hardware they want out to the customers. Instead of fighting the used processor market, IBM can send out the z10's, being careful to cripple them to meet the desired plan ceiling. IBM might also guarantee itself some income by including one of the more poisonous aspects of cell phone contracts, the two year obligation with early termination penalties.
Of course, there are a couple of flies in the proverbial ointment. There's no guarantee the greedier ISV's (you know how you are) will fall in line with the new pricing structure. Free hardware really isn't free when you consider the required power, environmental infrastructure and technical support mainframes require. But, something needs to be done if IBM intends to keep its flagship floating. It is also time for the ISV's to realize that they too rise and fall based on IBM's fortunes.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2..