All Your IBM i Base Are Belong To Us

December 16, 2013 Timothy Prickett Morgan

In last week’s issue of The Four Hundred, I gave you my best estimate of what the current distribution of machines by processor family and software group was based on some information I have heard through the grapevine from IBM and my own estimates. The data showed a number of remarkable things, among them the fact that there are some pretty old machines out there in the installed base despite the massive improvements in price/performance with successive generations of Power-based systems in the past decade.

What can be done to ensure that this base of customers, which accounts for over 160,000 production machines in my best guesstimates, stays with the IBM i platform and expands its usage of that platform? That is a difficult question that Big Blue and its business partners are all trying to answer. But first, let’s take a look at that picture once again, just to level set:

Many of us have seen this movie before, during the initial transition from the System/36 and System/38 back in the late 1980s and then again in the mid-1990s when there were still hundreds of thousands of System/3X machines out there in the world. There were, in fact, 275,000 System/3X machines in the field in June 1988 when the AS/400 launched.

IBM converted a lot of that base by having emulation environments for RPG II and RPG III applications running against the relational database built into the OS/400 operating system. Because of the similarities between the CPF operating system and OS/400, the fairly modest number of shops with System/38s made the jump to the AS/400 relatively quickly. There was plenty of grousing about the performance of RPG III applications, to be sure. But the price/performance of the AS/400 was so much better than that of the System/38 that companies made the jump. The reason was economics.

The System/38 was considerably more expensive than a mainframe, MIPS-for-MIPS. I have the data and did the numbers many years ago to illustrate this point. In 1980, after the System/38 had been shipping for a while, it cost approximately $3 million per mainframe MIPS for a high-end box, while mainframes of that era (and using much less MIPS-hungry flat-file databases) cost about $300,000 per MIPS. It wasn’t until the advent of the AS/400, in 1988, when relational computing on the AS/400 cost the same per unit of power as flat-file processing on the mainframe–around $100,000 per MIPS. And over the years, the AS/400 got cheaper and cheaper and with both machines equipped with DB2 relational databases, the AS/400 was about half the cost per unit of work as a mainframe. This is a relative positioning at the high end of the AS/400 through Power Systems lines that has not changed much in the past two decades. And it is absolutely intentional on the part of IBM to keep the relative bangs for the bucks right where they are for these two platforms.

System/36 customers just plain resisted spending money and were not particularly interested in moving from RPG II to RPG IV and from the flatfile database in the SSP operating system to the relational database in OS/400. After many years of wheeling and dealing, IBM got about half of the System/36 base to make the jump, but half just stayed right where they were, using second-hand equipment from third-party dealers to keep their systems going. If it ain’t broke don’t fix it was the rule amongst these customers.

This is also clearly the rule among those 65,000 customers who have P10-class machines using Power5 or Power5+ chips, or indeed, any of the customers with the more than 116,000 machines that are using any Power5+ or earlier chip in the installed base. This is a very large vintage installed base, but don’t get freaked out. The System/3X base was, relatively speaking, of a similar magnitude. Think of this as an opportunity instead of a problem. Because Hewlett-Packard and Dell and Microsoft certainly are.

In 1994, in fact, IBM conceded that what many customers wanted was to stay with the System/36’s SSP operating system and went so far as to create the Advanced 36 platform, which was the first PowerPC-based machine that IBM created and it ran SSP. It was AS/400 iron that literally ran SSP. It was also an admission by IBM that all of the wheeling and dealing to try to get the remaining System/3X customers to move had failed.

IBM needs a similar admission here for the three quarters of the installed base that remains on vintage iron. All of the Moore’s Law improvements in price/performance and modern software features do not mean squat to these customers. At least not at the prices that IBM is charging.

The answer, it seems to me, is to get a system out the door that does, in fact, appeal to customers using vintage iron and OS/400 and i5/OS software releases that are no longer even supported by IBM. Big Blue could always break down and just run those older releases in emulation mode on current Power7 and Power7+ chips or future Power8 chips, which have more than enough oomph to made these environments run acceptably well even if the emulation overhead is just horrible. The point is to get these customers to do something to get onto modern hardware as a precursor to getting on modern software. Imagine a single-socket machine loaded up with memory and flash drives that could run earlier OS/400 and i5/OS instances inside of logical partitions, and do so for a modest cost.

According to the resellers I have spoken to, with the end of i5/OS V5R4 support in September, customers are starting to wake up and realize they have to do something. IBM wants them to just move to a new Power 720+ rack server or better still a PureFlex system with a p260+ server node running IBM i. These resellers are actually asking for bids to sort out their vintage systems when they were pretty much doing nothing earlier in the year. Procrastination is a natural human condition, of course, and replacing a working system, however old, is not going to be a priority. About a quarter of the base stays on relatively current hardware and IBM i releases and, not coincidentally, pays Software Maintenance (SWMA) contracts to IBM.

I think that a baby Power Systems machine that runs earlier OS/400 and i5/OS releases in emulation mode will do the trick for certain customers that want to have machines inside of their data centers and that write their own applications. For others, the answer is going to be cloudy slices. But customers with older applications may not want to do a conversion to get their code ported to IBM i 7.1 or pay third-party software suppliers extra fees to get back on maintenance contracts that they have let lapse over the many years.

Something has to give here, and that something is going to be everyone involved. In a user-focused world like we have today, the idea of software tiering is antiquated. IBM tried a mix of tiered and user pricing for OS/400 software back in the mid-1990s, once again showing it was thinking ahead of the pack, and it has this also for the P05 and P10 software tier. It is time to do away with it once and for all, for the sake of customers who have their own machines as well as for those who want to have IBM i running out on the cloud.

Here’s the fundamental problem for IBM. It has an installed base of customers who have not paid for a software license for anywhere between eight and 11 years and another much smaller installed base of customers who do stay current on hardware and software and who carry the entire Power Systems-IBM i organization. No wonder development has been cut back. It is a wonder there is any development at all, if you want to be honest about it. What IBM needs is a steady and continuous revenue stream coming off IBM i and its related systems software and tools, something that is more predictable and steady and something that is also low-priced and easy for customers to consume and stay current on. The answer is right there in front of you. Let’s use conceptual numbers to make the math simple here, given that OS/400, and i5/OS and IBM i prices have varied by platform at the same software tier over the past decade. It will give you a feel for things.

If a vintage P10 software stack on a machine with two cores cost $24,000 and customers amortized it over 10 years, then IBM can’t charge more than $1,000 per core per year for that software stack. And if that machine can support 25 users, then it can’t charge more than $8 per user per month for that software. (That’s $24,000 divided by 25 divided by 10 divided by 12.) That is the price that vintage machines are telling IBM that their OS/400 and i5/OS systems software is worth, roughly speaking. And, they paid it all upfront so they have no costs whatsoever. So IBM has no revenue stream and therefore its sales people don’t care.

Now let’s look at the active customers. They pay the same $24,000 for the software when they buy a new machine, but they get new machines every four years and they pay for SWMA every year. Let’s set the SWMA price at 25 percent of the license cost per year, which is a little on the high side for the software industry but not egregiously so, and it is also lower than the 29 percent that IBM actually charges. This customer then is paying $48,000 over four years for the software stack, which is $6,000 per core per year. That is six times what the vintage customer has paid per core. If that same machine supports 25 active users, that works out to $40 per user per month. ($48,000 divided by 25 divided by 4 divided by 12.) That is five times the monthly rate. And those who upgrade more frequently pay an even higher relative price for the use of the software. As you move up software tiers, which customers resist doing because the jump from P05 to P10 is very steep, from P10 to P20 is very steep again, and from P20 to P30 and above is also steep, the relative price of the software rises quite fast. But the machines support so many users that it can, if a company has enough users, balance out.

This pricing model also discriminates against customers who have large machines to drive batch jobs or for peak online transaction processing workloads at the end of week, end of month, end of year, or other intense periods of processing that are unique to their businesses.

My point is that this software pricing actually encourages customers to use as little Power processing and IBM i software as possible, rather than encouraging them to put workloads on the machine. Part of the problem is integrating the database with the operating system. (I mean in terms of pricing, not in any technical sense. The database integration is brilliant, but there should be a way to turn it off to just let it have runtimes on certain cores and partitions.). Another part of the problem is that IBM still believes that IBM i can be priced like a Unix-database combination.

Three quarters of the installed base has clearly and plainly explained to IBM that this is not the case. And it has also clearly explained to third-party application vendors that they will not move until the cost of getting current on applications is brought down, too. If IBM and these third parties split the difference with users, some kind of agreement could be reached. A monthly fee for running applications in emulation mode with old operating system releases on current Power iron seems appropriate. Everyone gets something out of the deal.

Let’s go a bit further with this game. Say that about three quarters of those 116,000 vintage machines can be moved. Some will be boxes that go into company data centers and data closets, and some will be slices on a cloud somewhere. Call it 90,000 machines in total. And let’s assume 60,000 go into companies and 30,000 end up in clouds when it is all said and done.

If IBM would use some of its great gobs of cash to make a slew of entry Power Systems machines and create this virtualization/emulation layer, it could lease them out for maybe $500 per month, or $20 per user per month for a shop with an average of 25 users. That’s about as much as a midrange truck loaded up with all the features. (Well, that’s appropriate, metaphorically speaking.) Call it $200 for the system, $200 for the systems software, and $100 going to the third party vendor letting their legacy code run in emulation mode on old operating systems. Everybody gives, but everybody gets, too. For homegrown applications, users have to pay the $100 per month fee to run in emulation. In effect, IBM is giving the third-party software developer access to the emulation layer for free. Those who are building clouds get a 30 percent discount off the entire hardware software stack, and they have to compete with each other with that margin as their income. IBM and third-party software developers are just happy to be getting a monthly revenue stream, and so are the cloud providers, who will no doubt sell backup, recovery, storage, and X86 services on top of the cloudy IBM i server slices. Users have to also sign a maintenance contract with IBM and the third party for their various software maintenance fees, and this is also priced reasonably low. Say 20 percent of the software fees above. So that is $600 per month per machine, on average.

If you do the math, that’s only $648 million a year to get everyone who will move to new iron or to a cloud base on new iron. They get to move their current software and run in emulation, but there is plenty of iron so that’s not an issue, and the users are now in position to modernize their applications by making use of a modern IBM i release in bare metal mode (meaning not emulated) in an adjacent partition. The remaining customers in the base will also continue to spend money, of course, as they are currently doing. Perhaps it will even be less per unit of work, and they will buy more, adding workloads to IBM i.

It all sounds so simple. And guess what? It really is that simple. IBM could have done this many years ago. The good news is this: It is still not too late.