The purpose of this blog is to encourage a two way conversation between you and I.  I recently completed a quick video (available at YouTube at http://www.youtube.com/watch?v=vbHNU-QmksUL) that discussed why I believe that information technology (IT) executives would be well-served to look more closely at IBM’s System z mainframe as a centralized SOA/Cloud/Security hub for their enterprises. 

My argument is simply this:

Mainframes already offer advanced virtualization and provisioning — and are years if not a decade ahead of where x86 virtualization/provisioning software suppliers are today in terms of virtualization infrastructure and management.  So why not take advantage of mainframe strengths in virtualization, provisioning, automated workload management, security, and cloud computing by making a mainframe the central control point/clearinghouse for your future cloud environments?

First, let’s start with a common understand of a “cloud” environment.  If you read the myriad of cloud definitions available on the Internet, you’ll find that most describe an environment that is highly virtualized and provisioned.  What a cloud does is it masks the systems management complexity for users — while providing highly utilized, highly-virtualized, automatically provisioned workload environment for users such that they can transparently execute their workloads.

Now, take a look around the computing marketplace:

1. X86-based server managers are struggling to deploy rudimentary virtualization infrastructure and management products on their x86 servers in order to increase utilization rates and decrease management costs. 
2. Midrange/high-end Unix/Linux servers offer more advanced virtualization than x86 servers.  For instance, IBM POWER-based servers offer advanced virtualization features such as fine-grained dynamic sharing of processors, memory and I/O; resources may be dedicated; shared, dedicated processors; extreme scalability and robustness (especially when compared with x86 virtualization offerings); integrated firmware hypervisor; virtual I/O servers layer; hardware enforced isolation; LPARs and WPARs; DLPAR and processor folding; capacity-on-demand functionality; and partition mobility.
3. Mainframes are the gold standard for virtualization — more advanced features and functions than POWER and x86 put together — plus super-strong integration with the operating system, security programs, resiliency programs, and more.  And IBM also offers advanced virtualization/provisioning/-workload management/business process management services designed for mainframe environments.

Considering these three points, it should be obvious that a mainframe is a fully functional, single server cloud environment today.  It is where x86 vendors are trying to get to; and it is what midrange/high-end Unix/Linux servers are trying to emulate.
So, if a mainframe is already a cloud environment — and if a mainframe can centrally manage SOA, security, and virtualization, provisioning, and workload assignment/balancing — why would you go and spend all of your budget trying to build a cloud with less advanced x86 and midrange/high-end Unix/Linux server tools, utilities and applications?  Seems like a huge step backward to me…

Instead, I’d rather see IT investments moving forward into an area called “service management” where collections of services are managed using software that can help IT managers better see what is going on with their assets, servers, networks, etc.; easily control those environments; and automate rote management functions using service management dashboards (see Figure 1).

Figure 1 -- Visibility, Control, and Automation: Service Management


 
                                                                                                                                                                                                        Source: IBM

This is the way forward to building transparent, well managed cloud environments.  Service management tools and utilities enable IT managers to automates redundant, repetitive IT physical and logical system management tasks — integrates those tasks into a single group of common services (such as availability services, or storage services, or risk/compliance/security services, etc.) — and then manage those tasks using a dashboard view that shows how those integrated tasks are performing. 

Moving forward into service management will help your organization build more automated, highly-utilized cloud environments.  So please explain to me the logic involved in not using a mainframe environment to manage SOA and security services in that cloud — and the logic involved in not moving to service management software more quickly…

The purpose of this blog is to encourage a two way conversation between you and I.  I recently completed a quick video (available at YouTube at http://www.youtube.com/watch?v=vbHNU-QmksUL) that discussed why I believe that information technology (IT) executives would be well-served to look more closely at IBM’s System z mainframe as a centralized SOA/Cloud/Security hub for their enterprises.  My argument is simply this: Mainframes already offer advanced virtualization and provisioning — and are years if not a decade ahead of where x86 virtualization/provisioning software suppliers are today in terms of virtualization infrastructure and management.  So why not take advantage of mainframe strengths in virtualization, provisioning, automated workload management, security, and cloud computing by making a mainframe the central control point/clearinghouse for your future cloud environments?

Now, typically, I get three objections to this argument:
1. Mainframes are old technology;
2. Mainframes are too expensive; and,
3. Mainframes are difficult to staff (locating mainframe skilled individuals is difficult).

With respect to the old technology argument, I can prove that mainframes are far more advanced than any other commercial system in the marketplace when it comes to virtualization/provisioning/-workload balancing and security.  In fact, I can list seven other distinct areas of superiority:

1. Networking  — Instead of having to rely on external switches, routers, and cabling, mainframe processors are networked using a switched backplane within the System z. This greatly simplifies System z deployment while reducing networking hardware acquisition and cabling costs.  And using this backplane for heavily message-oriented service oriented architecture (SOA) is far more efficient than using external, comparatively low speed networks;
2. MTBF and high-availability — Over the past sixty years of mainframe development IBM has gotten very proficient in the design of highly reliable, highly-available systems design (mainframes can provide 99.999 per cent high availability). Mainframe application availability is reportedly the highest in the industry (through the use of IBM’s Parallel Sysplex technology and Geographical Dispersed Parallel Sysplex which mask planned and unplanned outages and provides both local and remote disaster recovery). In fact, one IBM customer claims that they kept a specific application continuously available for a decade (10 years)! IBM’s low meantime between failure (MTBF) rate on mainframes is extremely low — and as a result, some industries are able to avoid service shutdowns and save millions of dollars per hour that otherwise could be lost due to equipment failure. 
3. Manageability — Again, over the past sixty years, IBM has worked diligently to lower the complexity and cost to manage its mainframe systems. IBM does this by automating route functions (such as backup/restore, user provisioning, etc.)  — as well as by streamlining administrator user interfaces by graphically enabling its management software. The more IBM is able to simplify management, the more IBM is able to drive down management costs. Current estimates in terms of labor related savings using management facilities on a System z versus those in distributed systems environments show that it takes only five mainframe people to manage the same amount of resources that it takes twenty-five people to manage in a distributed computing environment! 
4. Coprocessors/specialty engines — IBM makes use of coprocessors within its System z chassis to assist in specialized application processing for specific environments. IBM’s zAAP environment is a low-cost workload engine designed to reduce software deployment, integration, and tuning costs for specific enterprise applications (BI, ERP, CRM, etc.). IBM’s zIIP environment focuses on centralizing data from multiple sources on a mainframe such that BI, CRM, or ERP applications can use that data to derive the answers to business queries, or use that data for enterprise reporting. And IBM intends to introduce several additional “specialty engines” over time. Also noteworthy is IBM’s Integrated Facility for Linux (IFL) – a central processor designed specifically to process Linux workloads (this processor has met with solid acceptance and plays a big part in allowing the System z to process “modern” Linux and Java workloads). 
5. Near-linear scalability —  IBM’s System z design along with Parallel Sysplex enables near linear processor scalability (as additional processors are added they perform at nearly 100% of their capacity). Other system designs (such as some SMP designs) can see processor scalability drop by as much as 50% as new processors are added to a system. 
6. Floor space — For IT buyers concerned about floor space, the System z packs a lot of processing power into a relatively small footprint (as compared to the floor space dozens of networked SMP or PC servers might occupy if equivalently configured). And, finally, 
7. Energy efficiency — When comparing the System z to an equivalently powerful distributed computing environment, the System z uses far less power and cooling to deliver the same amount of computing power.

Given these points, I think many makers of distributed systems would be hard pressed to argue that their architectures are technologically superior to mainframe architecture.

With respect to mainframes being too expensive, be aware that this argument is based upon two price points: 1) cost of acquisition; and 2) total cost of ownership (TCO).  When I hear the cost of acquisition objection, I ask the objector if he or she is aware of IBM’s new “Solution Set” pricing.  The beauty of these Solution Editions is that IBM has reduced all IBM stack costs (HW, SW, and HW maintenance) — to be competitive with Unix TCA. Additionally IBM has reduced pricing on System z10 EC IFLs (integrated facility for Linux — a specialty processor that allows mainframes to run Linux) to $75k USD; and memory prices for z10 zNALC environments to $2250/GB. In other words, these Solution Editions and pricing actions help lower TCA — closing the gap between mainframes and distributed servers — and thus taking the steam out of the argument that mainframes cost too much.

As for cost of ownership arguments, I think that distributed computing users would be hard pressed to argue that their systems environments cost less than mainframes — especially after comparing:

• Virtualization costs;
• Provisioning costs;
• Security costs (add up the cost for licensing and managing security across hundreds of distributed servers);
• Networking costs;
• Physical plant costs (wiring/cabling);
• Real estate costs (a single mainframe can replace 250 industry standard servers -- at a fraction of the footprint);
• Power/cooling costs (including electricity costs and costs related to power supplies and cooling equipment);
• People related management costs (I've seen a major mainframe environment being run by 4 people!);
• Infrastructure software costs (mainframe managers tell me that mainframe infrastructure software licenses cost far less than the total cost for infrastructure licenses in distributed computing environments);
• Support costs (mainframes offer the most reliable hardware in the industry with the best meantime-between-failure [MTBF] of any commercial system.  If stuff doesn't go down, then it doesn't need to be fixed -- hence support costs are lowered);
• Controlling/accounting costs -- mainframes offer the best control/account software (for internal billing purposes) in the industry;
• Availability/resiliency costs -- how much does it cost to build a disaster recovery plan and implement it across a network of distributed servers.  I can assure you that managing business resiliency on a centrally controlled mainframe costs a lot less... 

As for the mainframe skills argument, this argument needs to be clearly defined.  Which skills?  (Note that mainframes run Linux and Java applications and there is a skills shortage across the entire industry in these areas — not just on mainframes).  Mainframe management skills?  The mainframe users that I talk to tell me they are able to grow those skills organically (from within their organization) or find them on the open market.  They also highlight that they need far fewer people to manage mainframes — a fact that significantly reduces their operating costs.  COBOL skills?  The mainframe users that I talk to are telling me that they outsource all that old COBOL code to India and China where there are plenty of workers with COBOL skills to be had.  I’ve also talked to college professors who are growing their mainframe education programs.

Be aware that CA and IBM are also investing millions upon millions of dollars into mainframe management simplification.  This involves graphically enabling formerly character-driven mainframe management programs and streamlining the processes behind these programs to make deployment, configuration, and management easier.  Given the discussions that I have had with dozens of mainframe managers, I think this alleged skill set shortage is way overblown.

So here’s my big question for you: “If I have proven that mainframes are not old technology; if I’ve proven that the cost argument is being addressed from two perspectives (acquisition cost and TCO); and if I’ve proven that the mainframe skills shortage argument is overblown — and if I can also prove that there is no better general workload processor on the market with as advanced virtualization, provisioning, workload management, and security features — then why would you not consider a mainframe as a centralized hub for your evolving cloud environment?

In a recent complaint filed with the U.S. Department of Justice (DOJ), an industry watchdog organization (that I had never heard of) known as the CCIA has asked the government to look into alleged anti-trust behavior in the mainframe market segment.  The core of the CCIA's argument is that IBM’s refusal to let other vendors market its z/OS operating environment on the hardware of their choice constitutes monopolistic behavior.  The CCIA seems to believe that if IBM would let other vendors market its z/OS operating environment on non-mainframe hardware, then consumers would benefit by being able to purchase IBM z/OS on less expensive (and less reliable and secure) server platforms. 
 
Like the CCIA, I'd like to see mainframe prices continue to be reduced.  But, unlike the CCIA, I'd rather see price change driven by market ebb and flow, rather than through strong-arm legal challenges by suspect industry watchdog organizations.  In fact, mainframe pricing is already changing, in response to a highly competitive market factors.   IBM has reduced prices for its mainframes between 50-90% this decade (depending on the configuration).  And IBM recently introduced new "Solution Editions" for System z -- packaged hardware and software bundles (such as SAP on Linux on System z) also designed to reduce the purchase price of mainframes. The fact is that IBM has repriced its mainframes in order to compete more effectively with high-end Unix servers that are encroaching on mainframe territory (this is an example of what I mean by natural ebb and flow).  And as a result of this repricing, mainframes and Unix servers are closer than ever in terms of total cost of acquisition price.
 
So, if mainframe repricing is already underway and if other competing systems are now positioned to challenge mainframes (so IT buyers have alternate platforms from which to choose), what is the motivation for the CCIA's complaint to the DOJ?  Here are a few thoughts:

1.  The CCIA sees itself as a promoter of open markets, open systems, open networks, and full, fair, and open competition.  Perhaps the CCIA considers IBM's reluctance to share its operating system (that, I note, represents billions of dollars of IBM investment in intellectual property, which IBM has a right to protect) with its member organizations as a refusal to participate in what the CCIA considers open markets.  At the same time, the CCIA fails to recognize that IBM has made its mainframes open systems that run Java and Linux, for example, in response to a competitive marketplace.

2.  Perhaps the CCIA member organizations are pushing CCIA leadership to initiate these anti-trust proceedings.  I note that TurboHercules, T3 Technologies, Microsoft, and Oracle (all CCIA members) can all directly benefit by forcing IBM to capitulate by handing its operating environment over to third parties.  TurboHercules is an open source mainframe effort that would benefit if it could deploy z/OS on other hardware platforms and take advantage of the billions of dollars IBM has invested into its mainframes and no cost to them.  T3 Technologies has already challenged IBM for rights to use z/OS and lost in a New York district court.  At this week's Oracle World, Larry Ellison has made it clear that Oracle intends to compete aggressively in the server marketplace and targeted IBM systems and advertisements in his presentation.  And Microsoft runs a mainframe migration program.  I'm hoping that the DOJ looks closely at the motivation of these vendors as it considers taking any action in this case.

3.  Perhaps the CCIA has a different motive and sees an opportunity to benefit financially from these proceedings.  According to an InfoWorld article in 2004, Microsoft settled an anti-competition case with the CCIA and Novell (this case was being held before the European Commission) and a major chunk of that settlement went to a CCIA executive.  Of the $19.75 million settlement, it is alleged that the CCIA executive received almost half (as well as a $500,000 salary "bonus" for three years).  This article can be found at: http://www.infoworld.com/t/platforms/update-microsoft-paid-ccia-official-reports-says-711.  With this kind of reward system for issuing complaints and then settling out-of-court, the CCIA and its executive could hit the jackpot with its latest complaint/accusation.

The bottom line in this discussion is that pricing activities to drive down mainframe costs are already under way and that raises the question: What is the CCIA's real motivation for issuing its complaint?  I suggested three reasons, but I'd like to hear your opinion on what you think is happening here.

Last week, an obscure organization known as the CCIA (Computer and Communications Industry Association) that claims to promote “full, fair, and open competition” in the computer marketplace filed an antitrust complaint with the U.S. Department of Justice regarding IBM’s mainframe business practices.  In its complaint, the CCIA alleges that IBM has refused to issue licenses for its z/OS operating system to competitors — a practice that the CCIA apparently finds unfair and monopolistic.  The Department of Justice has, accordingly, issued formal requests for information from IBM as it investigates IBM’s activity in the mainframe marketplace.

The CCIA has based its complaint, in part, on licensing and business practices that pertain to IBM dealings with Platform Solutions Inc. (PSI) and T3 — vendors that wished to sell IBM’s z/OS operating environment on Intel-based servers.  In these cases IBM declined to allow PSI and T3 to sell or transfer z/OS on Intel Itanium-based platforms.  IBM ended up buying PSI; and T3’s complaint was dismissed by the U.S. District Court in its entirety.

Still, the CCIA complaint does, however, raise a number of interesting questions with respect to IBM’s behavior in the mainframe marketplace:

1. Can it be successfully argued that IBM has a mainframe monopoly? 
2. Can it be successfully argued that customers are locked-into mainframes?
3. Should IBM be compelled to provide key intellectual property to whichever vendor wants to use it?  And,
4. Does the refusal to allow IBM intellectual property (z/OS) to be sold on other platforms really constitute anti-trust (monopolistic) behavior? 

The remainder of this blog examines these questions.

Does IBM Have a Mainframe Monopoly?
There are two ways to look at this question:

After considering both points, Clabby Analytics would concur with the opinion that IBM has a monopolistic position in the mainframe marketplace.   But does having a controlling, monopolistic position automatically translate into anti-trust behavior.  We would argue “No”.

The Real Issue: Running z/OS on Other Platforms
What the CCIA is really complaining about is IBM’s refusal to allow competitors to use its intellectual material against itself (in this case, IBM’s z/OS on other hardware versus z/OS on mainframe hardware).  And because IBM is not letting other competitors use z/OS, the CCIA apparently believes that IBM is guilty of an anti-trust activity by creating vendor lock-in.  And this alleged lock-in contributes to high mainframe hardware prices (a situation that the CCIA considers an anti-trust behavior).  

For the DOJ to make an anti-trust case, the DOJ will need to prove that mainframe customers are truly locked in?  Clabby Analytics would argue the opposite: 

If customers can move to other platforms, then they have a “choice” of which platform they can use.  And if a customer has choice, then a lock-in situation does not exist. 

As noted above, IBM customers can use other hardware configurations to build information systems environments that have the equivalent processing power of a mainframe.  So, if hardware isn’t responsible for creating lock-in — then that leaves the operating environment as the prospective lock-in entity.

Operating systems are control programs that enable applications and databases to make use of underlying computer resources (disk, printers, etc.).  And IBM’s z/OS is the most advanced operating environment in the world — the “gold standard” when it comes to virtualization and provisioning; the world leader in security (EAL) level 5; superior service management solutions; and more.  IBM has spent decades building and perfecting this operating environment — and has a right to recoup its ongoing investment in the z/OS operating environment. 

From our perspective, compelling IBM to allow other vendors to use its own operating system against it raises the following concerns:

1. Is it right for the legal system to dictate which markets IBM can compete in and how it competes in them?
2. Is it right for the legal system to force a company to use its own intellectual property against itself and to undermine its own strategies?

If the DOJ decides to pursue CCIA’s complaint, I will discuss these two questions in greater depth in subsequent blogs. 

Summary Observations
Ultimately, the big question on the table is whether other vendors should have a right to deploy z/OS on other platforms.  If allowed to do so, competing vendors could undermine IBM’s mainframe pricing structure by delivering lower cost alternatives to mainframe hardware.  And, to us, that would be really unfair.

The CCIA’s complaint is aimed at driving down mainframe hardware pricing.  But this is already happening — driven by natural market pressures.   Pressure from Unix servers that are moving up into traditional mainframe markets are forcing IBM to become more competitive in the mainframe pricing arena.  As an example, IBM has recently announced “Solution Edition  pricing (see a in depth description of this pricing at www.gomainframe.com), mainframe solutions that bring System z prices down by 50-80% for particular applications (like SAP).  Solution edition pricing takes direct aim at reducing the cost of mainframes by bundling hardware and software together and selling “solutions” at reduced cost.  So, it can be argued that IBM is already taking action to reduce its mainframe price structure — which is the whole reason for the CCIA’s complaint.  This solution set argument should also serve to show the DOJ that the market can take corrective actions by itself — without government intervention.

Also note that, in interviews with IBM mainframe users (and we talk to a lot of mainframe users), Clabby Analytics has identified three challenges that IBM faces in the mainframe marketplace: 1) price; 2) old technology; and 3) skill sets.  With respect to pricing, almost every mainframe customer will agree that mainframes are expensive.  But these customers also tell Clabby Analytics that their investments in mainframes are well worth it for the peace-of-mind that mainframes deliver.  These customers understand that mainframes offer the strongest RAS (reliability, availability, and security), the best virtualization, and the best management facilities in the industry.  So, although mainframes are costly, numerous mainframe customers have told Clabby Analytics that the investment is well worth it.

Finally, if customers see and understand that you get what you pay for when you buy a mainframe — and if IBM is already taking corrective actions to lower mainframe prices — then who is the CCIA really advocating for?  Perhaps this should be the topic of another blog…

1. Spend more money developing SPARC than Sun does now;
2. Spend more money developing Solaris than Sun does now:
3. Have more than twice as many hardware specialists selling and servicing SPARC/Solaris than Sun does now; and,
4. Dramatically improve Sun’s hardware performance by tightly integrating Oracle software with Sun hardware.

1. How much money is Oracle talking about spending?  Spending more money than Sun is spending is "a little vague..." 
2. How many hardware specialists are we talking about (remember, Sun has been through several layoffs over the past few years --  how many hardware specialsts were left?).
3. If Oracle is talking huge investment in Sun hardware and its operating environment, how will it meet its stated accretive financial targets while making this investment?  And,
4. "Will throwing more money at SPARC hardware and software fix certain endemic problems related to Sun design and release capabilities?”

1. On spending more than Sun -- this information is proprietary so only Oracle and Sun really know how much was being spent.  But if the number was low (as we suspect it was), then spending a little more than a low figure is not very impressive.
2. On the number of hardware specialists -- again, if the number of current hardware specialists is low (as we suspect it is due to layoffs and given Sun's policy of letting its business partners handle a lot of support and professional services), then again, we're unimpressed.  
3. On the finanacial investment that Oracle needs to make -- what if Oracle needs to spend at least a billion dollars to make the Sun SPARC line competitive with other architectures.  If that's the case, how will Oracle meet its accretive financial commitment?  (From Oracle's own press release:  "We expect this acquisition to be accretive to Oracle's earnings by at least 15 cents on a non-GAAP basis in the first full year after closing. We estimate that the acquired business will contribute over $1.5 billion to Oracle's non-GAAP operating profit in the first year, increasing to over $2 billion in the second year. )  If you've got to spend a billion or more to make SPARC more competitive, there goes the Sun contribution to Oracle's non-GAAP operating profit.
4. On investing more money into Sun hardware without solving habitual slipped schedules and endemic design problems -- that may be throwing good money after bad.

A Historical Perspective
Point #4 is worth dwelling on a bit more.  <:od>Wikipedia, the Internet encyclopedia, accurately describes Sun’s progress from its inception to its take-over.  But what the Wikipedia article does not describe in much detail is why Sun was so successful up until the bubble burst ─ and why Sun has had such a hard time getting back on track afterwards. 

The following is Clabby Analytic’s view of Sun’s current predicament:

• As a Unix workstation company, Sun’s natural progression was into the low-end of the Unix server market space.  And, because it started at the low-end, Sun found itself in the perfect position when business use of the Internet took off ─ and the need for Unix-based Web (Apache) servers mushroomed.  Other vendors (HP and IBM) were building high-end Unix servers ─ big servers ─ at a time when Sun’s server product line was comprised mostly of small servers.  Sun had no real low-end competition ─ and, accordingly, made huge inroads into the server market.  This “fortunate happenstance” of product positioning enabled Sun to become the Unix server volume leader.  (Note: post 2001, Sun’s competitors had introduced their own low-end Unix servers, making it even more difficult for Sun to recover from the downturn).
• In the mid-1990s, Sun decided to expand into the high-end of the Unix market.  Using its own developmental resources, Sun internal developers had architected their own high-end enterprise servers when, in 1995, another “very fortunate happenstance” occurred.  One of Sun’s business partners, Cray Business Systems had architected a powerful, high-end Sun Unix server (that featured a high-speed switching architecture that enabled Sun servers to scale extremely efficiently).  Cray was sold-off to Silicon Graphics, Inc. (SGI) which immediately turned around and sold this Cray Business Systems high-end UltraSPARC environment to Sun (for a paltry sum of only $50 million!).  And shortly thereafter, Sun’s internal designs were jettisoned in favor of the Cray design.  Not long after that, Sun’s very successful ES10000 was born.  (The purchase of Cray’s design can be classified as one of the best technology deals of the 1990s). 

 But this is where the beginning of the end occurred:

• Although Sun low-end, midrange, and high-end enterprise servers became highly successful, Sun was not able to parlay its initial successes into continued success.  After the bubble burst, there was no white knight in the form of Cray Business Systems that came along with a new technology that could help Sun leapfrog its competitors.  And there was no “fortunate happenstance” that put Sun in an advantageous position after the bubble burst in 2001.  In order to recover from the economic downturn of 2000 and leap frog its competitors, Sun was going to have to prove that it could develop its own game-changing architecture.  And Sun didn’t. 
• Sun’s internal attempt to design and build its next game-changing architecture that could deal with multi-cores and multiple threads (codename “Honeybee”) met with failure as the company turned to Afara Websystems for its next generation microprocessor design (these became Sun T1 and T2 servers).

Constant slippage of successive generations of UltraSPARC processors, combined with delays in the development and implementation of its new chip multi-threading (CMT)-based processors left Sun customers waiting for long, extended periods for product refreshes.  By the time Sun’s T1 and T2 architectures came along, there was huge, built-up customer demand for more scalability, computing power, and capacity ─ so quite a few T1/T2 servers were sold initially.  Meanwhile, other Sun customers, who had been burned by constant delays in product refreshes, started to look elsewhere for alternative Unix servers that could deliver the computing power and scalability that they needed on a more timely basis. 

Parting Comments
It is clear to Clabby Analytics that customer confidence in Sun is waning (big time).  Oracle will attempt to revive that confidence -- but it may be too late.

At this juncture, Clabby Analytics sees Sun SPARC archtiecture as  irrelevant.  In fact, we now see the midrange/high-end of the server market moving strongly toward three microprocessor architectures:

1) mainframe processors;
2) POWER; and
3) Intel Xeon (8-cores and beyond).  

Is throwing money at UltraSPARC and CMT technologies really going to fix Sun’s endemic microprocessor technology problems?  It hasn’t to date — so we have little confidence that increasing the spend on Sun microprocessors is really going to help Oracle extricate Sun servers from their current malaise.

Will the Real Hewlett-Packard Please Stand up?

Is HP Really a Leader in IT for the Business Marketplace?

Some research analysts may argue that HP is a market leader when it comes to building systems and software – and in providing services – to the information technology (IT) industry. (My favorite quote is from Hoover’s Online which says "HP wants to be ‘it’ when it comes to IT"). In fact, HP fosters this image with statements such as "no other company offers as complete a technology product portfolio as HP. We provide infrastructure and business offerings that span from handheld devices to some of the world's most powerful supercomputer installations".

HP Does Not Supply a Complete Infrastructure Stack

Back in 2002, I reported:

Further, I note that hardware makers who own their own infrastructure can tweak that infrastructure to take advantage of advanced hardware functions (instead of building for generic system images) - and these hardware makers can also manage developmental priorities more effectively. And, given that HP is no longer in the middleware business, I see HP as "not in control" of its developmental direction (as, for instance, Sun and IBM are).

The Itanium Disappointment

Back in the early 1990s, HP systems engineers got the bright idea that they could build a processor technology that would blow-away the market’s advanced RISC processors. Accordingly, HP (as well as Intel and some other partners) embarked on a plan to build a processor environment that could compile instructions in software, and then hand off those instructions to a processor designed specifically to rapidly execute those instructions. (Competitor RISC processors compile and execute on the chip - HP’s/Intel’s Itanium EPIC [explicitly parallel instruction computing] processors would only have to perform execution work). This was a great idea - but badly executed:

To add insult to injury, HP decided that it would be a great idea to obsolete all of its RISC processor lines - and to base all of its server lines on this single, 64-bit, EPIC architecture. Accordingly, HP’s customers are being asked to abandon their investments in HP’s AlphaServer- and PA-RISC-based servers and adopt EPIC architecture if they want to continue running their advanced HP/UX and NonStop environments on HP high-end servers.

The HP Supercomputing Disappointment

HP’s broken scale-up strategy also manifests itself in supercomputing. In the supercomputing industry, companies that build high-end servers usually let advanced features and functions that they build for supercomputing environments "trickle down" or "cascade" into enterprise systems architectures, then into the midrange, and ultimately to the low end. Now, look at HP’s situation. Once a leader in supercomputing with its PA-RISC-based entries, HP’s Itanium-based (EPIC) processors show poorly in the Top500 supercomputer listing (only two IA-64 based systems were in the Top500 list - at positions 165 and 427 respectively). To me (and I think most industry analysts would agree), this shows that HP is not investing properly in advanced EPIC-based systems designs - and this bodes extremely poorly for the competitive future of HP’s IA-64-based EPIC (Integrity) lines of processors.

Another way to read the Top500 list is to look at HP’s overall supercomputer market penetration rate. HP has a whopping 42% of this market - with 208 sites using Intel-based x86 architectures. With this many installations, it is clear HP is investing: in commodity x86 architectures. And this also tells you a lot about what HP really is in the server market: it is an x86 server company - or, to be even more precise, HP is an x86 blade maker.

The way that I now look at HP in the server business is that HP is no longer a credible high-end, scale-up systems vendor (given its lack of investment in EPIC-based servers as evidenced by the Top500 supercomputer list - and the limited market acceptance of its EPIC architecture). The company’s move to EPIC architecture has been an immense failure.

Will the Real HP Please Stand Up?

HP’s own marketing materials (http://www.hp.com/hpinfo/newsroom/HP_in_brief_010309.pdf) acknowledge that some people think of HP as a printer company (note: over 20 percent of HP’s revenue [$26 billion] comes from its printer division); others think of HP as a PC company (and in the PC marketplace, its primary competitors are Lenovo and Dell); and still others think of HP as a data center company. HP goes on to argue that it is clearly a printer company, that it is indeed a PC company, and that it ships almost 1/3 of all servers sold worldwide. HP also boasts that it makes telephone calls possible for over 100 million mobile users on a global basis; and helps 50 million customers share over 4 billion photos on-line.