I thought I'd try to perform a public service to help educate everyone on IBM's new pricing announcement on April 22, 2008. (Demystifying software pricing seems to be one of my unofficial missions in life.) First, the headline: this announcement is *unambiguously good news* for customers: nobody pays more, and many customers pay less. Quite simply IBM is making it even more financially attractive to start new projects with WebSphere products for z/OS. IBM is very directly responding to many of you who did not want to create and manage separate "WebSphere LPARs" for whatever reason(s).
Here's the link to the announcement: http://www.ibm.com/common/ssi/rep_ca/8/897/ENUS208-088/ENUS208088.PDF Here's my personal take. The pricing announcement affects the following WebSphere products for z/OS: WebSphere Application Server WebSphere Process Server WebSphere Enterprise Service Bus WebSphere Service Registry and Repository WebSphere Business Service Fabric WebSphere Transformation Extender WebSphere Message Broker and IBM expects to add these two products as well: WebSphere Portal Enable WebSphere Extended Deployment The announcement is exclusively for z/OS customers, not for any other platforms. All these products are licensed under the IBM International Program License Agreement (IPLA), and they are also known colloquially as One-Time Charge (OTC) software products. That means when you buy a license you own that license in perpetuity for that version (at a specific quantity). You can also buy optional subscription and support (S&S) annually; you buy the first year via another part number together with your initial license. Almost everyone does by S&S, because as long as you maintain continuous S&S you receive new versions as they are introduced at no additional charge. If you let your subscription lapse for whatever reason it costs more to reinstate subscription. Most IBM mainframe software products are licensed under IPLA terms. What's changing now is how IBM measures the quantity you must order if you want to license and use these products. Now, I'm going to assume here you are a sub-capacity Variable Workload License Charge (VWLC) customer sending in your Sub-Capacity Reporting Tool (SCRT) reports each month. I don't think this pricing announcement affects you at all unless you are sending SCRT reports to IBM. IPLA software is priced and licensed according to Value Units (VUs). VUs are calculated directly from MSUs, the common standard for measuring software capacity which you all probably know very well. There is a formula to convert MSUs to VUs (called a "Value Unit Exhibit"). You can find the VU Exhibit in every IPLA software product announcement letter. I think all of the WebSphere products listed above are licensed according to VUE007 (Value Unit Exhibit 7). In VUE007 up to 3 MSUs equates to 1 Value Unit, for example. Value Unit exhibits serve one major purpose: they introduce a volume discount schedule while allowing IBM to publish one price (the price per Value Unit). The Value Unit exhibit means that the more MSUs you buy, the less each additional MSU costs. However, as I've mentioned many times, the minimum order quantity is only 1 Value Unit. So for a small project (or a small mainframe) these IPLA products are aggressively priced. On every other processor (such as X86) the minimum order quantity is 100 Value Units, and more realistically 400+ for any real-world implementation. Those X86 Value Units are calculated differently, but there is a gaping price difference (in the mainframe's favor) between 1 mainframe Value Unit and even 100 X86 Value Units. From an IPLA WebSphere point of view the mainframe quite simply scales *down* in price better than any other platform, and that's a surprise to a lot of people. Just as any other z/OS software, what counts is your peak 4 hour rolling average of MSUs. For IPLA software that's the aggregate peak across your enterprise (across multiple machines if you have more than one) and at any time. For example, if you have two machines, and one machine peaks at 3 MSUs and the other at 2 MSUs, you will need 5 MSUs (translated to VUs) of IPLA software. It does not matter whether the machines are in a Parallel Sysplex or not for IPLA: you always use a single Value Unit Exhibit, per product, across your enterprise. Now you do not get the benefit of any workload "troughs" with IPLA. (Sorry about that. That's one advantage to MLC.) If you peak at 5 MSUs in January, and then you drop down to 3 MSUs in February, then back up to 5 MSUs in March, you still need 5 MSUs. You have to license enough MSUs (Value Units) to cover your highest peak, before you reach the peak. If you only need that higher peak for a short time (a few days), you can purchase "MSU-days" of IPLA software from IBM. Typically you might do that with temporary Capacity On Demand activations. If you inadvertantly shoot past your peak (for the license quantity you have), send IBM an order for more as fast as you can. If you wait too long, IBM will send you a bill, and the bill could very well be more expensive. For all the above WebSphere products what counts are the peak z/OS MSUs for all the LPARs where those products are installed. DB2 tools depend on the DB2 MSUs, IMS tools depend on the IMS MSUs, etc. But for the WebSphere products listed above the z/OS MSUs are used to calculate the quantities you need. For example, if you have WebSphere Application Server for z/OS installed in LPARs A, B, and E, but not in LPARs C and D, you'll need enough MSUs based on the total peak z/OS MSUs for A+B+E. All that is business as usual -- no change yet. So what has changed? Suppose LPAR A is a big DB2 LPAR while WebSphere Application Server is a relatively small percentage of that LPAR. Prior to this announcement that wouldn't matter: IBM would require you to license WebSphere based on the total z/OS MSUs. It's in the LPAR, so the full LPAR counts. If you didn't like that, there was a solution: create another LPAR just for WebSphere. That works very well, and you can still do that. (And there still may be very good reasons to do that, even after this announcement.) Now, if WebSphere connects to DB2 you would have to use the Type 4 JDBC driver (to cross LPARs) instead of Type 2 (for in-LPAR connections). The Type 2 driver is more efficient. But again, that still is often the best approach taking all factors into consideration. But now you can keep WebSphere in the same LPAR, often with a better financial result than before. If WebSphere peaks under 10% of the LPAR, you won't need to license the whole LPAR. IBM has dropped the price on that first 10%. It's a very simple linear formula which you can easily remember: for each percent append a zero. For example, if WebSphere peaks at 2% of the LPAR, that means you need to license 20% of the peak z/OS MSUs for the LPAR. Some people will save 0% on their WebSphere licenses, and some people will save 70% or more on their WebSphere licenses, depending on circumstances. IBM can do this because these IPLA products (or at least the WebSphere Application Server code underneath them) can produce the necessary SMF records to generate SCRT reports for billing. It's yet another step toward more granular sub-LPAR pricing, so you can have fewer LPARs yet not pay for the whole LPAR for certain products with low utilization. And WebSphere products might be low utilization as you get started, so you can more easily justify starting on the mainframe, even for one small application. You also now have more technical flexibility, such as using the Type 2 JDBC driver if that's more appropriate. There are some wrinkles you should be aware of to understand how to take best advantage of this pricing: 1. There is no LPAR boundary here, so it's very similar to how IMS, CICS, and MQ behave within a z/OS LPAR when measuring their peak MSUs. If you want an absolute technical guarantee that your WebSphere MSUs won't exceed a certain amount, that's what LPAR boundaries (including softcaps and group LPAR capacity limits) are best equipped to provide. If you're inside the same LPAR your MSU capping is more nuanced: Workload Manager goals, technical limits on inbound workload (such as firewall and network throttles), etc. Will IBM introduce a vehicle for more rigorous sub-LPAR MSU caps in the future? I have no clue, but I wouldn't bet against it. 2. This new pricing has no direct relationship to zNALC. If you have a choice between putting WebSphere products in standard z/OS LPARs or zNALC LPARs, you might find the zNALC LPARs still make the most sense. However, if you view that, say, 2% of new WebSphere workload in the big LPAR as incremental workload -- indeed it is -- it would be boosting z/OS MSUs only way out at the most favorable part of the price curve. So the difference is at least much closer than you might think. I think for very many customers this new pricing will tip the scales back toward not creating those additional LPARs. 3. Exploitation of zAAP and zIIP by these WebSphere products is still available. There is no software charge for any workload running on zAAPs or zIIPs. As I think through this announcement I'm finding all sorts of ways customers can take advantage of it. Here are just a few scenarios: 1. Adopting WebSphere Service Registry and Repository more easily. WSRR tends to be a light utilization product for customers starting with SOA. (I also happen to think it may be the most important SOA product, because it establishes the central directory for all the business services, describing how to use them and where they are using industry standard interfaces.) 2. Supporting the WebSphere Studio Asset Analyzer reporting interface. WSAA is a discovery tool that's quite helpful for code introspection, and it can help reduce a lot of application maintenance burden (and save money as a consequence). It's also useful for locating potential business service entry points (to then wrap and register them in WSRR). WSAA needs WebSphere Application Server for z/OS to host the reporting server, where users can access Web-based reports summarizing the code introspection findings. Typically this is very light use again because this isn't information every user (or even every developer) would need to access. 3. Situations where the in-LPAR connectors have nice technical advantages, like the Type 2 JDBC driver to DB2. Other examples include the IMS JDBC Connector and the CICSRequest Node for Message Broker. 4. System programmer access. The sysprogs (a lot of you) might be the ones who need certain types of administrative access that the general user population doesn't. And since the general user population vastly outnumbers the sysprogs in most cases, this new pricing fits that sort of usage pattern. For example, you might want encrypted Web access to 3270 screens, and WebSphere HATS (hosted by WebSphere Application Server) would be a really good way to do that so you could work from anywhere. WebSphere Application Server in general might be quite handy, for doing things like hosting InfoCenters and other documentation sysprogs need, or for providing your own Web-based interface to vital administrative functions, like producing encryption keys for tape exchanges with partners. 5. Disaster recovery scenarios. If your mainframe is the only thing that's recoverable quickly -- that's a very, very common situation -- then you can put a bunch of this new WebSphere stuff on z/OS in your big LPARs, pay very little for it for the occasional functional testing, and then recover (with Capacity Backup probably) to your other site with your most critical Web applications ready to rock-and-roll to keep your business afloat while the distributed server teams figure out how to plug things in (if they even survived the disaster). 6. CEO use. I used sysprogs as an example, but there are other user category examples. One might be the CEO. He or she is one user, but those apps better work. So maybe you put the CEO's Portal on z/OS even if the mere mortals use something inferior. Or the CFO, getting the corporate accounts completed in time for the quarterly report to Wall Street. You might have a few users who need premium SLAs, and you can move them immediately to z/OS for a much lower cost. You might then discover everybody should move up, but regardless this new pricing opens up more options. There are many other relevant situations. Anyway, I hope this explanation is helpful. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific 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
