« Mainframes, SOA & Sex | The Mainframe Blog Home | 2+2=4. Really. »
About That "Expensive" Mainframe
I've pondered the question of how to explain mainframe economics in much simpler terms. Unfortunately the average IT professional is not well schooled in economics or accounting in my experience, but I have an idea how to capture this issue succinctly. It goes something like this:
Question #1: What percentage of your business transactions (or business activities, if you prefer) does the mainframe fulfill?
Question #2: What percentage of your total IT budget does the mainframe represent?
One company I visited last week answered "85%" and "50%," respectively. Even if 50% is an overestimate -- a lot of companies allocate all sorts of non-mainframe costs into the mainframe budget -- a quick back-of-the-envelope calculation still suggests that this company's IT costs would more than triple if that 85% were to move onto the platforms supporting the other 15%. That's not exactly a bargain, is it?
In some cases a question #3 is in order (depending on the answer to question #1). Question #3 might be, "If you were to increase the mainframe percentage from X to Y, how would that change your total IT budget?"
OK, blog fans, what do you think? Do these questions make it easier to help the time-pressed CFO understand why the mainframe is a bargain?
| by Timothy Sipples | April 3, 2006 Permalink |
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e200e5507dd8748834
Listed below are links to weblogs that reference About That "Expensive" Mainframe:
Comments
this would start to be really powerful if we had a few examples, the the customer was prepared to be public about the role of the mainframe...
Posted by: James Governor | Apr 4, 2006 11:31:49 AM
The mainframe is the coolest thing in the data center!
In talking with mainframe customers above 2000 MIPs, I'm told by clients that, on average, 80% of the customers' mission critical applications/transactions run on the mainframe, and that the cost of this is about 20% of the total I/T budget.
Can this be true?
If you take an insurance company they might tell you that their core mission critical applications include: claims processing, policy admin, sales & marketing, and customer service. These applications might drive 80% of the mission critical transactions for an insurance firm's business and often run on the mainframe.
It's relatively easy to determine the actual cost of running these applications on the mainframe by adding up the monthly hardware lease costs, monthly software costs and to look the company telephone directory selecting the names of the people who do mainframe "stuff". In the US, people costs are about $100,000 per full time employee (fully loaded salary & benefits). These costs are often 20% of the total I/T spend.
In a lot of cases, the cost of the mainframe computing environment as described above is about 20% of the total I/T costs. The balance of the costs -- the other 80% -- is in the distributed Unix and .Net environments.
To the extent these costs and simple analysis are close to actual costs then the question to ask is "If 80% of the total I/T budget drives the distributed environment but only 20% of the core applications/transactions then shouldn't customers consider moving workload off the distributed environment to the mainframe?"
This analysis doesn't even begin to consider the value the mainframe creates in terms of data security (z/OS Encryption Facility), data serving and SOA transformations. Data security alone is expensive when one considers audit, privacy and compliance all of which can be done at a responsible price point on the mainframe.
When this value is considered then the tipping point is even more toward the mainframe.
The mainframe is great for mixed workload and usually comes up in the short side of an economic compare with a distributed solution when a head to head compare is made of running an application in a Unix/Intel box vs. a mainframe. When a more sophisticated analysis is done comparing the incremental cost to deploy a new application an existing mainframe vs. the cost of new Unix/Intel servers then in many cases the mainframe wins.
I would conclude with two points. If electrical consumption & cooling are important then the "mainframe is the coolest thing in the data center". If protecting the environment is important then the "mainframe results in zero net impact on the planet" because it uses less power and less cooling.
Posted by: Bob Hoey | Apr 4, 2006 6:42:31 PM
The economic argument is really quite compelling and it is hardly a new one. IBM and the software vendors have been making this exact pitch for at least the last decade.
Having been deeply involved in hardware planning, purchasing etc in large banking/finance shops (long ago and far away) I can assure you the people who make the financial decisions crunch the numbers very carefully. The green eye-shade guys can usually tell you to the dime what it costs to purchase mainframe systems and run work on them. That is a "mature" area of corporate infrastructure accounting.
There have been some pretty smart people making the economic case for the mainframe as the server of choice and even so, it has not exactly been blowing the doors off in the mindshare marketplace. Why is that?
I suspect that the picture is more nuanced than simple cost benefit analysis especially when you factor in the development side of things. Even so, if you could get your financial picture in front of the financial people in the purchasing organization you would likely carry the day.
What really happens is that the financial and business decision makers only see a pre-cooked list of choices. They don't have the time, skill or job responsibility to put items into that list.
In effect, the show is rigged ahead of time. And it is not necessarily a bad thing in the long haul.
The folks who do the rigging are obviously less interested in the financials - we'd be having a different discussion if they cared. But they are more interested in their own aspects of the business. Their decision points are not strictly financial ones, but they are no less valid. Read my friend Jim Porell's posts about fixing the on-ramp.
Mindshare is an awfully complicated beast. I think we need to have a lot richer and more compelling set of justifications for the platform than simple dollar cost and we need to find ways to get those things in front of the "fixers" early and often.
This is one of those areas where Microsoft and the *IX vendors have just marketed the pants off IBM. The "they stole the servers" ad blew people away, so it is surely possible to "sell" the platform to a much wider audience.
But a small ad-buy here and there isn't going to cut it if you really want to affect mindshare. IBM has just done a lousy job at that.
Posted by: Chris Craddock | Apr 5, 2006 5:41:05 AM
James - an exampled re: Timothy's question #3:
Computerworld reported that Baldor Electric consolidated eight Unix servers onto a mainframe, which boosted performance by 40%, and decreased IT spending from 1.7% of sales to 1.2%...and additional reductions are expected.
http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,103916,00.html?from=story_picks
Posted by: Tim Washer | Apr 5, 2006 6:46:34 AM
I've used the following approach to add a visual dimension to the two questions you pose. I ask for the CIO to give me a tour of the data center. After the tour, I ask these questions:
1. What % of the floor space would you estimate is consumed by the mainframe if you include storage, tape, network, application test and development and disaster recovery
2. What % for distributed systems
3. What % of the profit producing applications run on the mainframe
4. What % on distributed systems
The most extreme example was a company where about 10% of the floor space was used for mainframes, yet they ran 95% of the profit producing applications. Typically it's 10% of the floor space and 50% of the profit producing applications. If you can get the CIO or CFO to spend 30 minutes touring the data center and asking those questions for their company, it will make it easier to gain their agreement to quantify the real costs.
Posted by: Ernie Fernandez | Apr 5, 2006 1:18:28 PM
I recently visited one of my mainframe clients, and the architect I was visiting with said "Our CIO recently said that he wondered why IBM wasn't recommending that we move ALL of our work to our mainframe, since it works so well and is the best, by far, platform for availability that we have." I thought that was a pretty insightful comment, and very appropriate. While not every single application in my clients' world is appropriate to run on the mainframe, a lot more apps ARE appropriate for the z than are currently running there. I frequently ask this rhetorical question to my clients and fellow IBMers: "Why is the mainframe not the *default* choice for deploying your applications?" Once upon a time, it was the ONLY choice, and somewhere along the line it became the exception rather than the rule.
I have seen/heard a couple of clients talk about how much of their budget they are spending on "the mainframe", but not once have I heard them mention what percentage of core business function resides there. That is THE relevant question.
When doing platform selection, the architects out there in the world use many criteria for selecting an OS/hardware platform for application deployment. But the most predominant platform selection criteria is the "ideology" of the architect and/or CIO/CTO. That is what we must work to change.
Posted by: Bill Seubert | Apr 5, 2006 3:55:37 PM
James - Hannaford is one example. See
http://www.byteandswitch.com/document.asp?doc_id=85563&WT.svl=news1_1
Quote "Installing the mainframe helped the retailer reach the halfway mark in a major five-year server consolidation effort, which has already seen 300 Intel-based HP servers removed from Hannaford stores. “We have another 300 that are due to be removed in the next two years.”
Posted by: Peter Norris | Apr 5, 2006 3:56:55 PM
James - another example. BBH are discussing their use of zOS and Linux on the mainframe.
http://www.watersonline.com/public/showPage.html?page=298266
Quote "For BBH, the mainframe has been the central component of its computing infrastructure for the past 25 years and it currently runs between 75 to 80 percent of its applications on the system, which represents up to 4 million operating transactions per week."
"BBH plans to use the SuSE platform to support newly developed applications moving forward, which would have been developed in the Linux-on-Intel or Sun Microsystems Solaris environments."
Posted by: Peter Norris | Apr 5, 2006 4:23:35 PM
I've posted a response to this on my blog, but the trackback thing doesn't seem to work. Here's a quip:
The economic questions make sense, however, they leave out a very real side of things: when most CIO's consider the "other" side of the IT budget, they also have to factor in things like laptops, desktops, routers, monitors, etc, that let most of their people connect to the mainframe. That number is a fairly high percentage. It's not all about the server.
url: http://www.beyondobjects.com/jgaither/2006/04/about-that-expensive-mainframe.html
Posted by: Jeremy Gaither | Apr 5, 2006 9:54:47 PM
Great thread. nice to see so much participation... and thanks for the pointers peter.
Posted by: James Governor | Apr 6, 2006 6:26:11 AM
Over the past 15 years I have had the opportunity to visit with numerous mainframe shops. I have yet to visit an account that has added mainframe staff (people) to support the growth of their mainframe server needs during this period -- no matter what the growth rate! Commonly, you will find businesses that have grown their mainframe capacity 10X over the past 6-10 years, and they will actually have fewer people managing the platform today versus say 10 years ago. Given staff costs are IT's #1 expense, the staff productivity advantage of the mainframe is a prime advantage (and also one not widely appreciated).
Posted by: Bob Warpinski | Apr 6, 2006 3:32:57 PM
A difficult challenge in comparing costs is to quantify the more subtle or hidden costs of computing. My experience shows that if a business will look hard at these costs, the value of the mainframe environment becomes an easier case to justify.
For example, what is the cost and the risk mitigation for disaster recovery and business continuity scenarios on the mainframe vs. other computing platforms? I have had customers say the cost difference to plan and test D/R scenarios was $200-300K/year less on the mainframe. Reasons included the amount of intelligence and automation built into the mainframe environment and the skills/trust of having successfully completed these tests for years or even decades.
In general, all centralized computing environments provide challenges to fully describe efficiencies and savings gained. However, there are many systems management aspects where the capabilities of the mainframe platform (hardware, O/S, customer culture, etc.) allow this platform to do things that are hard to do elsewhere.
Security is another area where it is possible to look at costs and risk mitigation to derive high value to a business of the mainframe platform. One does not need to use doomsday scenarios to show significant value from the integration of security throughout the mainframe environment, including the *people and process* parts of security, which many times are the weak link of the chain.
I have found that many TCO studies stop with the easy to measure costs (hardware, software, support/maintenance, direct people costs). By understanding how a given application supports or enables a business, then matching those qualities or capabilities against the various computing platforms being studied, you can start to find areas of actual cost, of cost avoidance, of hidden costs (off the budget of the specific person/department making the purchase, etc.), and strategic value that a mainframe offers. You can work into actual dollar amounts or into value delta's (e.g. - Platform A delivers 50% extra value to my company, so I will select it if the final cost is within 50%) to be discussed and justified to financial people. The good news is the higher up the organization you go, the less "outside of my budget" issues can be found. There are people who care about the big picture. You need to work on engaging them in the process.
Posted by: DeWayne Hughes | Apr 6, 2006 3:37:33 PM
Most of the "expense" comments come from comparing the cost of hardware on a mainframe to the hardware on another platform using some capacity conversion ratio. As many have said before, large IT departments do not have a good grasp on what it costs to run their distributed environment or what they are "paying" in lower availability, security exposures, etc. One reason that the mainframe isn't real visible in the industry marketing is that there are many more vendors (hardware and software)and consultants that make money off of server proliferation. Because of the much larger number of those who benefit from server proliferation versus mainframe processing, leaving this perception to "IBM Mainframe Marketing" to fix is unrealistic. What we need are more mainframe users who stand up in public forums with comments such as "whenever I get a UNIX cost figure for a transaction processing application, I multiply it by 3 to 10 times to estimate what it will really cost me as compared to the mainframe cost that I am shown as a comparison". So why aren't these statements more commonly heard in the trade press? My guess is that those who are astute enough to know to do this consider it their competitive advantage over those who do not.
Posted by: Steve Zehner | Apr 6, 2006 4:22:17 PM
With every release the mainframe has evolved to be functionally richer- not only in the acclaimed scalability, performance, etc dimensions but also in the arguably less "glamorous" areas such as change management. Change management, the nemesis of any IT shop, is not a trivial cost and grows geometrically with each additional networked node added. Change management includes the cost of configuration changes associated with networks, systems, data and operations.
If companies tallied up additional costs they would incur for change management functions on distributed server environments, the ROI of the mainframe would strike several additional points in its favor.
The costs of change management and repair (include help desk costs, training costs, test costs, patch costs) for thousands of Unix and Windows platforms eclipse those on the mainframe. For instance in security, the administration of change to policy can be effected fairly rapidly on the mainframe. And those changes would be quickly enforced. Can one say the same about managing changes to security policy for all distributed desktops or Unix environments? Health Checker helps preempt configuration change problems. SMP/E helps with systems software installation process which over the years has been further automated. According to analyst studies the cost of patches applied to other environments (sometimes hundreds per quarter) run at estimates of $200 per desktop per change.
The costs of change, configuration and patch updates and the accompanying impact on problem resolution, help desk are often ignored in typical TCO studies. These critical costs, albeit a portion of the "labor penalty" of distributed computing, identify the mainframe as the more cost effective solution.
Posted by: b sannerud | Apr 6, 2006 6:02:04 PM
I am all in favor of simplicity, but MF I/O is just barroque. z/OS users are hamstrung by ECKD 3390 geometry and 64K track (non-EF) access method limitations, even though there hasn't been a real 3390 in about a decade - it's all just tiny stripes of data emulated on vastly larger SCSI drives. A 3390-3 is only about 1% of the size of the 250GB drive in my PC!!! Much of the management complexity of the I/O farm is self inflicted.
That isn't a leadership position. Other platforms offer scale, speed/feed and configuration complexity advantages over z/OS, if not over the MF in general. FICON and SAN may solve part of that, but geometry problems embedded in software mean that the access method issue will be with us forever.
Everything Joe said was on point. I/O and functional parallelism models really do break down along the lines he (and Greg Pfister) described, so depending on your workload mix, the same box can scream along or not. Memory bandwidth, I/O latency and the speed of light really are universal speed limits.
One of the big risks to this platform is that many "modern" workloads tend to naturally fall into the parallel-nirvanna Joe described. That means it is hard to justify a zBox for those workloads on price/performance alone, especially when software costs are factored in. A few years ago IBM published benchmarks comparing identical Websphere workloads between z/OS and zLinux, with each benchmark run (separately) on the -same- z900 box. In other words, the hardware was normalized out of the picture. IMO there were two interesting results.
One is that z/OS just vaporized Linux in head-to-head throughput (TPS.) This is attributable to superior workload management on z/OS and (probably) that DB2 does a better job ON z/OS than DB2-UDB does on Linux. However, the other interesting and/or surprising result is that WAS could run moderately complex JAVA transactions in the range of several thousand TPS on BOTH operating systems. This doesn't directly address relative mainframe I/O efficiency, but it suggests fairly strongly that if price/performance were the dominant crtiteria, then z/OS would lose badly. And in the server consolidation case, as Joe mentioned, most of the baby penguins do next to no I/O anyway so if there was some inherent advantage it would be moot.
In their usual semi-psychotic way, IBM's own non-MF businesses (pSeries, xSeries) actively compete with zSeries in the market and for allocation of development $$. And adding to the injury, their own software stack (WAS, DB2-UDB etc) is vastly more expensive on z/OS than zLinux on the same box. Given the huge chunk of revenue that rides on z/OS and zSeries, you'd think some higher power might have imposed some sanity on that before now. Sadly not.
Please don't misunderstand the intent of my criticism. When you're in a fight for your life, you absolutely have to know your enemy. I believe the mainframe is the "best" platform for secure and manageable enterprise computing as long as IBM doesn't manage to kill it with neglect. However, we as a community still tend to make blanket claims for platform advantages that are no longer true. Like availability...
The MF is still compelling when you consider its overall balance of system design. We just have to be careful to avoid focusing competitive attention on areas where our advantages are thin or non-existent. Talk about security, data integrity, manageability etc. and you can win. Focusing on drag-race comparisons will only get you beaten.
BTW> If this Greg Pfister is the same guy who has been posting on comp.arch for the last decade or more, he works for IBM anyway so licensing his works ought not be a big challenge for IBM.
Posted by: Chris Craddock | Apr 7, 2006 1:12:18 AM
Oops! That reply should have gone to the Linux I/O thread. Sorry about that chief. I'm just killing some sleepless time in the early hours of the morning at our annual sales kick-off meeting and I was obviously not paying real close attention.
Posted by: Chris Craddock | Apr 7, 2006 1:23:05 AM
A lot of the comments seem to center on how "easy" it is to administer the mainframe platform versus the unix or windows environments. I think that is a matter of the environment itself, and not the platform it is running on. I have worked in both environments, and it is simply a matter of perspective.
In a proper unix and windows environment, there is no difference in pushing out a change to twenty or 20,000 computers. I have done both. I have worked in a mainframe environment where it was more of a problem to deploy a change to a dozen LPAR's.
On the other side of all that, I have seen changes that were much simpler on the mainframe. Installing a few OS changes is simply a matter of cloning the right volumes, making a few changes, and booting (er IPL'ing) off the new volumes. You can do that with a unix environment, if it is set up properly. However, changes like that are almost impossible in the windows environments.
Further, if more companies do start using mainframes instead of unix/windows servers and desktops, do you propose that the average user of those systems give up their workstation and move back to a dumb terminal?
Security is another concern that mainframe-centric people always seem to boast about. From a compliance perspective, hardening tests in the industry rank unix/linux, windows, and z/os the same. From a vulnerability perspective, I think it is a matter of availability and usage. Thunderbird (the other browsr) was considered secure, until its usage rose above a certain point. Then, hackers and researchers started testing it. They found security vulnerabilities. The same is true with MacOS. For years, Apple said it was more secure. Usage rose, and they have had quite a few security problems lately. If the availabiliy of z/os and the zArchitecture was wider and more approachable (cost wise, available training, etc), I suspect that you'd see the same pattern emerge. Security by obscurity isn't good enough, and any improperly configured system has risks.
All in all, each platform in the market today has viable economics, or they wouldn't survive. There is no magic formula to prove that one platform is better/cheaper than any other platform.
Posted by: Jeremy Gaither | Apr 7, 2006 10:38:55 AM
As far as I can see no-one has pointed at "The Dinosaur Myth", which you can find at http://www.arcati.com/dinomyth.htm or on IBM website. This is an independent review of costs of mf, unix and wintel, including hardware, software, personnel etc. I think you can guess which one comes out significantly cheaper.
Unfortunately the mainframe's biggest enemy is perception - it is seen as generating large upgrade bills (so does the other stuff but it does it in more frequent smaller lumps), and the IT departmenmt does not normally present their results in a business like fashion. Telling me I had 94.5% availability of Oracle frankly bores me rigid as a business man. Telling me how much you generated / saved for me and how much it cost is far more interesting.
Posted by: Peter Armstrong | Apr 8, 2006 3:55:44 AM
Here are some answers/comments to several threads in the blog so far. And some more food for thought..
a. To answer part of the original question, the IT budget breakdown for many of the enterprises I visit is very typically 20% mainframe, 20% UNIX servers, 20% Windows servers, 15% data network, 25% desktop and other devices. And yes, 80-90% of the OLTP trans are ultimately handled by the mainframe, although all trans originate from desktops, ATMs and the web and may pass through several Windows and UNIX servers on the way.
However, to claim that all that non-mainframe stuff is unnecessary or not valuable is way out. Each of these major components has a different role. So, to get started in this debate, it is very important to describe the current, and likely future, role of the mainframe. If you want to define the mainframe simply as the world's best CICS/DB2 server then fine, but that is way too narrow, and it is a self-fulfilling definition that is not too useful.
b. There are several serious questions that can be asked about IT value - for example, what is the value of a Windows desktop... or an email service... or voice over IP... or blackberries ? For a CFO, and a CEO, all these value statements usually need to be netted out to a combination of approx current $$ cost, required $$ investment, current value to the business, incremental value to the business and technology risk. Many of the comments in this blog seem to be focussed on current mainframe cost and current value (ie OLTP transaction handling) rather than new functions/applications. These are two very different, but closely related, topics.
c. To establish current cost and ongoing operational value is important. With mainframe OLTP applications it is relatively easy to establish a cost per CICS transaction. But simply stating that the mainframe is processing 10 million transactions per day at a cost of 1 cent per tran with world-class efficiency and 99.99% availability is usually not enough to prove its value.
One obvious thing to do with this is to show how it has changed over the years, and in most cases this cost per core operational transaction has indeed reduced significantly - through reduced hardware and software unit transaction costs and static headcount. However, you cannot easily compare this with the UNIX/Windows world to get a meaningful 'apples for apples' comparison
UNIX and Windows servers in a large enterprise do very different tasks from the mainframe - they run different workloads. However, for a CFO, we can usually show that the various platforms are running efficiently and to what extent they are exploiting 'best in class' IT processes. We can get metrics (eg utilisation, cost, performance) that can be used to measure efficiency and report a scorecard to a CFO for various application types on various platforms. But, there is no doubt that the mainframe hardware and software costs are highly visible items in the total IT budget and a prime target for discussion.
It is impossible, IMHO, to compare, say, the current value of a desktop with a mainframe, or a data network. They are just different. It is also very difficult to quantify the current value of the mainframe... in most cases the mainframe COBOL/CICS/DB2 applications do actually run the business, they are hard-wired into existing business transactional processes, and the CICS transactions are typically very efficient (in terms of low pathlength and staff costs) and secure. But these applications are not necessarily the best when considered in terms of business flexibility (the IT change and security processes are often deliberately resistant to change), and are also open to the criticism that 'I wouldnt start from here if I were building a new application with today's most recent technology'.
d. It starts to get more interesting when you look at the cost of investing in a new application that might run on several platforms (eg Linux, SOA, J2EE, ERP applications) This is where the relative (incremental) platform costs are more transparent and, with greater care, more comparable. Different workload types are likely to run faster/cheaper on different platforms so there are important tradeoffs to be made between function, performance, cost, skills, risk, availability, security etc in these investment decisions for various application types.
e.The death of Moore's law is going to have a number of very interesting consequences. The most obvious will be to accelerate the move towards more 'scale-out' application architectures that can respond to increasing demand by adding more blades. This is already happening with many streamable 'read-only' cached data, text, image, audio and video sources. But it is likely that somewhere in the middle of all this new stuff will be several bottlenecks - of which the most obvious will be transaction-based databases and document-based/workflow databases - which will require 'scale-up' clustered hardware and software components.
f. This leaves the mainframe at an important cross roads. With the advent of SOA, we are seeing the need for increasingly flexible 'composed' business processes which will most likely have a major (and probably unpredictable) impact on transaction volumes and pathlength. This will drive the strong need for highly responsive dynamic workload management, very large scale databases and transaction handling applications and high integrity etc. Placing many of these transactional functions on one instance/image will most likely significantly reduce the overall costs of interaction and the complexity of the whole application. These are all strong indicators for a major future role for the mainframe.
However, it will also need to be affordable. Such a 10-50-100x increase in pathlength, at current mainframe price points and Ts&Cs, will result in many short-sighted decisions to put applications on 'cheaper' platforms, only to find that in the long run it would have been cheaper on the mainframe, or indeed only possible with the mainframe as the integration hub.
Consequently any discussion of the issue of mainframe cost/value also has to focus on a new paradigm of Ts&Cs that can deliver demonstrable, ongoing 'short-term' reductions in cost per core operational CICS-DB2 transaction whilst also quantifying its valuable and cost-effective role as a major central critical component of future enterprise-wide SOA based services.
Posted by: david heap | Apr 10, 2006 6:18:04 AM
I noticed the ComputerWorld article on Baldor was referenced in this blog. I am from Baldor that this article referenced.
The people that have a mainframe and don't exploit it just don't understand TCO.
To be honest, I could have never written up a TCO case and gave it to the CFO and it be approved.
In my case, I have a proven track record of working at the business level and solving business problems, so the CFO has left me alone.
I converted all our applications to run on Z-Linux and the database server to be on z/OS and would never consider anything else. The economics are real!
We have seen our TCO go down significantly and our percentage of sales go down from around 2% several years ago to the most recent month it was less than 1.1%. This is not because the CFO was dictacting it, it was because it was easy to do with the z-series and the consolidation of all our servers onto one machine. Easy to manage, easy to grow, zero downtime, and the i/o performance blows away any other server technology.
I am at a Gartner conference this week. One guy commented that the only people who use a mainframe are people who grew up with a mainframe and don't know any difference. When I tried to argue, he just did not want to hear it.
We have tried Windows, Unix, AIX, HP-UX and Linux on Intel. Cheap up front, but guess what. Many people to maintain, all kinds of problems, severe downtime issues, Virus'es, clustering technology that takes in excess of 30 minutes to failover, memory leaks, and general unexplained failures. Who needs it.
Run it on Z, never been down because of a hardware failure since implementing cmos technology.
Give me two hours with anyone that will take a honest look at the Z and I can sell them!
I hear the poor souls at Gartner complainingg of their San's, Server Growth, people out of control, Virus'es, etc. I just sit and smile! If they only knew how simple it could be!
Anyone interested in our success story, please send me an e-mail!
Posted by: Mark Shackelford | Apr 10, 2006 8:29:42 PM
It bugs me a little bit when I see IBM pitching its blade servers for consolidation (you've seen the TV ads and the full page ads in the management-by-magazines), when I believe they should be pushing more System z (is that this week's name?).
And in every one of those magazines (up front) is a multi-page foldout ad for MS SQL Server implying how one can manage the entire GNP of a medium-size country on it.
I'd love to see IBM take success stories such as Mark S. from Baldor and leverage these in their advertising - whack the CTOs, the CIOs and the CEOs with clue-by-fours.
But then again I have not drunk from the marketing Kool-Aid®, so I obviously don't know what I'm talking about. I'm just a lowly assembler systems software developer.
Posted by: Ray Mullins | Apr 11, 2006 5:06:41 PM
I have been enjoying this thread. I think that looking at the cost of the mainframe through the metrics of percent of transactions, floor space and budgets is an interesting idea. I wish that I had thought of it.
I have not seen much from a software perspective. I think IBM has made great strides in trying to make the mainframe more cost effective from a software cost perspective. The use of licensing based on work load and usage helps CIOs understand their costs and more specifically, what drives those costs. I feel that ISVs need to make more use of metrics and usage when building their contracts. The C level executives see large one-time fees coming from the mainframe and their minds wander into ‘how can I make this cheaper.’ Servers don't carry large one-time price tags, but eat away at budgets in little bites.
If software costs were more easily understood and without large one-time fees, the mainframe may once again be viewed in a better more way, based on value. I feel this approach may spur mainframe growth.
Posted by: Alan Bain | Apr 12, 2006 9:39:03 AM
I have to be rather circumspect about wading into pricing and value discussions because I work for a major ISV. However, it is no state secret that customers are only interested in paying less every year for the same basic functionality. That's just economics 101. I would argue that it has been so long since we've had any real innovation in the mainframe space that everyone's (IBM's, customer's and ISV's) perceptions of "value" have become jaded.
To go with a car analogy, in our business we have some timeless classics like a '57 Chevy Bel-Air and people continue to pay (more) for those. But let's face it, there's only so many times you're going to be willing to pay for a '65 Buick with bench seats and an AM radio. We badly need some fresh products and fresh thinking. We're in a very mature market that is long on steak and short on sizzle. If we were getting gee-whiz press and the associated mindshare it might be different. Bring on the innovation and watch things change!
Posted by: Chris Craddock | Apr 12, 2006 7:32:46 PM
Reading the comments by Chris Craddock brought back many memories - it is always good to hear from past customers.
Chris made a number of comments about ECKD and carefully pointed out that he was referring to non-EF data. To the casual reader the significance of this may easily be overlooked. Although all recent disks have emulated 3390's the geometry of the 3390-3 has only limited the track size. Volume size is no longer a limit and PAV supports multiple concurrent I/O's to the same volume. z/OS MIDAWs in of z/OS and the z9 family can dramatically improve thoughput and response for EF volumes.
The ECKD concept of z/OS not only provides a basis for guaranteed delivery of I/O to the target destination but also is complemented by a channel subsystem which offloads I/O management - critical to running many I/O operations in parallel and avoiding the security and integrity issues common to drivers in some distributed systems.
I agree that programs which implement low-level CCW based (RYO access methods) or low level interfaces to some standard access methods may require changes to benefit from access method enhancements, but the assertion "geometry problems embedded in software mean that the access method issue will be with us forever" ignores the basic precept for z/OS end-users - that applications use high level interfaces so that the middleware can be updated to exploit operating system enhancements. Using that premise the many Windows applications/utilities which used to be dependent upon FAT or FAT32 etc.
The "complexity" of the I/O farm also ignores the close integration of SMS constructs with data characteristics and workload management. I can accept this description for Linux on System z prior to the NPIV, but this was limited to SCSI devices.
Chris, you will remember from the 1980's the adage "the best I/O is no I/O". That is the concept behind WebSphere on z/OS. In a distributed system it is common for the application server(s) to access the data via TCP/IP (a network I/O). With JDBC4 on WAS for z/OS WebSphere accesses DB2 directly. The inherent security and workload management of z/OS enables WebSphere and DB2 to coexist with security, integrity and performance management.
I noted with interest your comment that 'many "modern" workloads tend to naturally fall into the parallel-nirvana'. What we are really seeing here is a shift in where the state data resides from the application and middleware to the DBMS. This shift actually increases the criticality of the DBMS for availability, security. integrity, scalability. DB2 on z/OS is clearly the leading solution here. The mainframe is an excellent platform for data serving to stateless distributed applications as well as to co-resident applications. Add to this the increasing requirement for data privacy and a "single copy of the truth" for corporate data and a single mainframe based data repository makes a great deal of sense - I am sure you of all people will apreciate I did not say repository manager ;-).
You correctly highlight that both WAS on z/OS and under Linux on System z can scale to high volumes. However, your conclusion that z/OS will have a higher TCO is not necessarily correct. There are several examples where I have seen customers compare TCO for WAS on multiple platforms and determine that z/OS was the lowest cost. This depends upon application patterns and can be highly dependent upon data location or integration with other applications. As SOA acceptance increases this is likely to become even more compelling. The announcement of zAAP and more recently the press release on zIIP are clearly designed to address TCO issues without losing the benefits of z/OS systems management and a shared memory model.
I agree wholeheartedly with your summary, that there are areas where the mainframe continues to have major advantages. And I certainly agree that drag racing measurements are normally single metric and unrepresentative both of real life workloads and the mainframe design points, however they are popular because they are easy to do. This leads to point measurements which totally ingore the synergy and purpose of the operating system and effectively devolve the operating system function to a distributed group of systems management products and operating processes. Any apples to apples comparison should include these systems management costs and infrastructure optimisation.
The challenge we face is that most benchmarks are rifle-shot measurements out of context with the business. They are often conducted by technicians with limited budget and terms of reference. The challenge for the mainframe is to have a holistic business which is required to highlight its considerable TCO strengths
Posted by: John Crooks | Apr 18, 2006 1:07:34 AM
In a blog Chris said "I would argue that it has been so long since we've had any real innovation in the mainframe space". I would love any suggestions on the type of innovation that would change the perception. When I see many of the "innovations" claimed by other platforms it brings a wry smile to my face.
The Unix vendors are claiming "leadership" by providing virtualisation. The hardware virtualisation lags the System z virtualisation with IRD and WLM integration. Solaris is claiming leadership with containers. With some minor differences these are similar to the address spaces introduced with MVS in 1972 but lack the necessary hardware architecture such as storage protect key to ensure the robustness the mainframe has been delivering for decades.
In systems management competitive platforms are touting input based performance management. These also are similar to SRM and MVS/SE SRM enhancements from the 1970's.
Very few alternate platforms have true channel sharing. Those that purport to actually provide a service in a separate LPAR rather than the integrated hardware based solution of MIF on System z.
These types of innovations are, in reality, step functions of a follower attmepting to catch up.
As a server we should never expect a mainframe to directly deliver end-user interfaces. GUI, multi-media interfaces are the domain of workstations not servers. While products on the mainframe can drive these interfaces via HTTP etc, its role is not to convert them into the final multi-media output.
From a software perspective the mainframe fully supports J2EE, XML, Unicode. TCP/IP etc. IBM has totally revamped its mainframe software portfolio and it is designed to fully exploit the latest application development techniques and tools. The mainframe is a full participant in SOA and its ability to handle mixed workloads makes it an excellent platform to run multiple related, time critical applications.
The innovation of parallel sysplex has not yet been matched some 10 years after it was introduced. If the mainframe is not innovating what does that say about alternatives?
If there is any issues which gets the attention of executives in the finance industry it is security. The cryptography built into the z9 chip and the PCI based crypto co-processors is industry leading. Add to that the z/OS based key management system and again we see leadership which has been unchallenged for almost 15 years.
I know that RAS is a boring subject but the recent z9 announcement further increases the gap in hardware RAS. Microcode drivers can be upgraded non-disruptively, books can be replaced non-disruptively, I/O can be replaced non-disruptively and a failing system oscillator can failover non-disruptively.
The one are of innovation where the mainframe has been a clear leader is the I/O subsystem. The concept introduced with S360 in 1964 of I/O offload were further extended with 370/XA in 1982 where the hardware virtualised the channels to the operating system and handled path selection and retry.
Rather than continue ad nauseum I would contend that the mainframe has a history of innovation which has come to be accepted whereas progress made towards this standard by other platforms is often considered innovation.
Chip frequency is often viewed as innovation. A simplistic "drag race" comparison of Intel and Unix frequency and single task execution against a mainframe chip highlights the deliberate design trade-off made by the respective engineers. Intel and Unix have targeted single purpose solutions (raw speed) vs multi-purpose solutions (throughput). Unfortunately many have misunderstood how to interpret this and have assumed that this shows Intel and Unix technology innovation.
Actually the reverse is true. The innovation in cache management and RAS design which contribute to reliable throughput are not measured and not understood. The mainframe is guilty here, not of lacking in innovation, but rather of not marketing the innovation
At the end of the day I believe the mainframe's problem is not innovation but rather communication of this innovation.
Posted by: John Crooks | Apr 18, 2006 1:53:22 AM
