isham research
IBM's - largely zSeries - software portfolio is at the same time a major success and a major problem:
Software revenues increased 6 percent (8 percent at constant currency) to $3.8 billion compared to the prior year's fourth quarter. Overall, IBM's middleware software revenues grew 10 percent at constant currency. IBM's premier data management and WebSphere products grew 48 percent and 43 percent, respectively. Operating system revenues fell 2 percent. The company's total gross profit margin in software improved 1.8 points, to 85.2 percent.
(From IBM's 4Q 2001 Earnings Report)
Overall IBM earned nearly $13 billion (US) from software in 2001, at a gross margin of 82.5%. That means software accounted for a third of IBM's income. As much as its customers would like much lower software prices, they wouldn't be in the interests of IBM's stockholders or - over the long term - its customers. But there is another problem. Although large zSeries systems show a cost-per-seat for large applications lower than almost any other platform, IBM's licensing practices not only present a barrier to new applications - they actively discourage continued use of small ones. The last few years have seen a succession of sticking plasters, splints and kludges being applied to the problem - yet the only result has been to put licensing issues beyond the understanding mere mortals and into the realm of numerous error-ridden tools.
Undeniably this issue should have been tackled years ago - preferably in 1989, before it was created in the single dumbest move IBM ever made* - pricing software by system size rather than application size. The marvellous concept of Graduated Monthly Licence Charges resulted in a user with a 20 MIPS IMS DB/DC workload and a 600 MIPS CICS/DB2 workload actually paying more for the former. If things had been done differently, UNIX and Windows might never have got a foothold in the data centre. At Lou Gerstner's first encounter with large customers he was shaken warmly by the throat and told to 'do something' about software charges - the result was Bob LaBant's famous announcement of the demise of Groups 90 and 100 and the later PSLC levels C and D. Focussing on the largest users is quite natural - everyone worries most about their best customer - but can be shortsighted. In the modern world - as Enron, Global Crossing and Swissair have shown us - size is not irrevocably linked with stability.
But now IBM has a $12 billion problem; how to price its mainframe systems to make them competitive at the low end without impacting a major profit line. Linux is not yet the answer - good 'enterprise class' Linux applications are still few and far between, and even fewer are truly scalable. Linux also lacks platform-specific availability enhancement for zSeries and is no longer quite so 'free' - SuSE now asks $11k per engine for the mandatory support contract bundled with its latest distribution of 31-bit Linux/390, rising to $14k for the 64-bit version.
zSeries has a number of unique selling propositions - chief among them its famous 'five nines' availability. But this availability is the product of a synergy with its operating system - Linux on zSeries doesn't yet produce it. zSeries and z/OS are the products of long parallel evolutions and zSeries needs some form of z/OS to realise its full potential.
IBM has not had an entry level mainframe using a current architecture for some time. "Flagstaff" - the original planned successor to the Multiprise 3000 - was cancelled over two years ago. But now it has one - the z800, built for IBM by Hitachi using largely IBM technology. The novelty is that one of its operating systems is a cut-down - and dramatically cheaper - version of IBM's flagship z/OS.
With the z800 IBM is targetting new application workloads both within and outside its existing customer base, as well as at smaller users moving up from an established Multiprise 3000. The new version of z/OS - called z/OS.e - is designed to support web-serving object-oriented and similar new applications but not traditional legacy workloads written in COBOL, PL/I and FORTRAN. The z800 has Coupling Links and is therefore a parallel sysplex candidate with great potential as an offload engine for large users. This is a strangely artificial situation; there is little technical justification for such offloading and the only 'problem' it solves is entirely the result of IBM's own pricing strategies.
A key issue is how applications running under z/OS.e are to be charged. IBM stated prior to the announcement z/OS.e itself will be charged at '10 cents on the dollar', i.e., at 10% of the full version's charge. In fact it's priced like z/VM 4.x on a 'per engine' basis. Given the legendary bullet-proof nature of z/OS (based on twenty-five years of IBM unconditionally fixing security exposures) z/OS.e will be an extremely attractive option for any company sick and tired of worrying about front-end security. That covers just about all of them.
The z800 can operate under z/VM, Linux, z/OS, z/OS.e or any mixture - charges will be based on the capacity available for each, using a technique initially developed by Amdahl. z/OS.e will only be supported on the z800 - but large users will be able to attach z800s using z/OS.e to existing Parallel Sysplexes and benefit from the better price/performance with applications such as web serving. z/OS 'full function' and its middleware will be charged at preferential rates - comparable to the Multiprise range at the low end, ramping to z900 levels at the upper end.
This leads to a little complication. Where a z800 has one or more IFLs installed, they are simply ignored for charging purposes. No one (yet) cares about how many MSUs an IFL may have - Service Units are specifically a z/OS concept. But a z800 running both z/OS and z/OS.e will need to have MSUs defined for all modes of operation. z/OS.e will only run in specific LPARs (named zSOExxxx) and IBM insists on a call-home audit link.
Overall, IBM could be in for a shock. The z800 & z/OS.e combination is hitting the market at a time when security awareness has never been greater, and just after Microsoft's imposition of new licence terms and conditions has woken many users up to the size of their hidden software bills. Even Linux/390 is not free - SuSE demands $11,000 an engine for the support contract mandatory with its 31-bit distribution. The first z/OS.e users will be those who already know and appreciate z/OS's legendary robustness - and think it's ideal for front-ending their existing z/OS systems at a tenth of the price - but others are not likely to be far behind. Both Microsoft and Sun can respond easily to the price/performance, but neither can whisk several decades' attention to security issues out of thin air - and certainly not by taking a month off from coding. True security is a design issue, not a coding issue.
* Followed, in order, by losing control of the PC architecture, the price paid for Lotus, the price obtained for Lexmark, and the internal adoption of SAP/R3.