Gartner: Databases Are Movin' On Up to the Mainframe
Gartner just published a new report: Study on DBMS Identifies Spending and Deployment Trends. The report describes Gartner's late 2005 survey of over 1,800 organizations worldwide. Gartner asked them about their database spending and platforms -- and their intentions.
I'll get straight to the most interesting statistic: 28.2% of the companies plan to move databases onto z/OS. A "large percentage" will move from Windows, according to the report. Only 7% said they'd be moving any database work off the mainframe. That spread was better than any other platform except Linux: 56.5% said they'd be moving database work to Linux. Gartner noted that a good chunk of that Linux movement would be to mainframe Linux, mostly from Oracle on UNIX.
This survey predates the zIIP. zIIP, available for production this June, should accelerate this trend.
I'm calling this trend data recentralization, after seeing anecdotal evidence over the past year or two, particularly with the "privacy crisis" as organizations once again appreciate their data's value. The department-level or office-level data "islands" just aren't supporting business needs any more (if they ever really did), and there has been at least one business that went out of business because it couldn't protect its data (credit card numbers in that case). New regulations and simple cost reduction are also driving factors in my opinion. Are you seeing these effects in action?
|by Timothy Sipples||April 28, 2006 |
Permalink | Comments (2) | TrackBack (0)
Mass Mainframe Consumption
"China has begun to enter the age of mass car consumption. This is a great and historic advance.” So proclaimed a news agency, Xinhua, some time ago.
It seems that we will soon see mass mainframe consumption as well. What if the functions and robustness of the System z9 technology with its virtualization capability would be available at an entry point for every one? What if the Information Integration Processor, the On demand upgrade capability, enhanced networking and connectivity options and crypto functions were build in?
That would be just the right mainframe for the masses. See Jim´s comments in this piece.
|by Boas Betzler||April 27, 2006 in Innovation |
Permalink | Comments (2) | TrackBack (0)
Many companies are deploying packaged multi-function ERP applications, including one from a three letter company that's not IBM. My colleagues and I are hearing of an interesting problem: the numbers sometimes don't add up. After running through millions of calculations to balance the corporate books, the books don't balance. Is it a software problem? Where? Is there fraud within the company? If running the numbers again provides a different result, which result is correct?
I'll let you in on a dirty little industry secret: most server hardware makes mistakes. A billion years ago, a billion light years away, a star fell into a black hole. The star screamed, expelling intense radiation in its last mortal moments. A tiny fraction of that radiation dodged earth's atmosphere to tickle your server's CPU. Or maybe it's a bad solar flare day. Or maybe a jolt of static electricity knocked a bit out of place. Whatever the reason, CPUs make mistakes from time to time. Unfortunately these mistakes may be getting more frequent as clock speeds, densities, heat, and electromagnetic interference all increase. Back in 1994 the error rate for microprocessors, e.g. X86, was estimated at once per year per 75 CPUs.
There are few systems you can buy that don't make mistakes. The IBM mainframe is by far the most popular of these precision systems. (The others tend not to be general purpose computers.) In effect every instruction runs twice for comparison, providing execution integrity. There's no way you can shut off this feature. z/OS, Linux, and all the other mainframe operating systems enjoy this benefit transparently, continuously. 2+2 always equals 4, even if the cleaning crew commits the grave sin of carrying a mobile telephone within six feet of your mainframe.
Do you care? Maybe. It depends on the application. If Shrek gets an extra one pixel mole on his face in the next digitally rendered sequel, no worries. If your stock portfolio trade gets a zero added, well....
The "three letter ERP" package runs extremely well on mainframe Linux, accessing DB2 via Hipersocket. No one running this way has any mysterious math errors, but we are hearing such reports on other platforms. Any one else hearing the same? Does the boss care?
|by Timothy Sipples||April 22, 2006 |
Permalink | Comments (5) | TrackBack (0)
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 | Comments (54) | TrackBack (0)
The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.