>Great post! And as one who is tracking software billing >charges for my shop, I can absolutely concur with *all* >of your observations.
Great to hear another data point, thanks! >You missed an option, an ELA/ESSO. My current 2006 charges >are actually *LESS* than they were for all of last year >and we are upgrading every CEC in the shop to z9. And this >is *before* we have exploited our zAAPs, our IFLs, the future >zIIPs and new releases of DB2, CICS, MQ and z/OS! I forgot a couple other software cost reducers, too: 1. With IFLs you get to consolidate lots of distributed software licenses onto a much smaller number of processors, including test and development software licenses. There is a large and growing number of customers who are consolidating Oracle databases, for example. (It also happens to be good business for Oracle, actually, because they get more customers.) I've seen other compelling financial cases for our own software. For example, I've worked with one very happy small business that's running WebSphere Commerce on Linux on z. WebSphere Commerce would have been unaffordable to them on any other platform. Linux software is almost always priced per processor, and a thoroughly virtualized IFL counts exactly the same as one X86 processor. I also went through the same exercise with another small business concerning WebSphere Message Broker pricing. The least expensive was z/OS for their small transaction volume. (z/OS software scales both down and up very well, at least if you're on some sort of workload charging.) Next least expensive was Linux on z, and the most expensive was any distributed platform. And it wasn't even close. (The ratio was something like 2/5/25.) GoIFLs also share existing infrastructure that's already bought and paid for. They share power, data center footprints, storage connections, networking connections, personnel (for system management and other tasks), memory backplane, crypto assist hardware, DR provisions, and most other mainframe facilities that are already available. Not having to pay multiple times over for these cost items saves lots of money. 2. Every year mainframe shops get better and better at monitoring and workload managing their mainframe software environments. Every year the distributed software costs seem to get more and more out of control, in contrast. The effects of management experience, better tools, automation, and generally better software portfolio management are often not counted, but they are very real. >I am actually a little concerned that I may be able to beat >the monthly ELA charges, leaving some money on the table. >Finally, your comments on distributed software are also >(to quote the Brits) spot on! Per processor licenses? >YUCK! I agree. Frankly all software should be priced according to business workload in some fashion. IBM's system isn't perfect yet -- IMHO it'd be nice to get more granular within an LPAR, though technology has its limits -- but it's a lot better than distributed software pricing practices which encourage perverse behavior. For example, many organizations try to avoid proper testing and redundant production installations because their software costs would explode. Software vendors also play this game, vastly underbidding test, development, and redundant production configurations (or striking them from proposals altogether) knowing full well they can come back and charge more after the intial sale -- including, very often, compliance billing (at full list price). - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
