IT Investment Research

Red Hat's Goal to "Own" 50% of the Market Now Faces Oracle

Red Hat (RHAT) CEO James Whitehurst led off the March 23, 2011 conference call announcing the operating system and middleware provider's annual results with the low key:

"Red Hat's growth indicates that we are continuing to gain market share." 

Talk about understatement. I would guess so given that I doubt if any comptetitor of any size had more than Red Hat's 20% revenue growth (more to come as we begin to review the Gartner and IDC share tables that will be coming out in the next month).

But remember.  Red Hat's stated goal isn't simply the mundane gaining "market share."  It wants a 50% share (as measured by instances I think but it's been a while since I dug down on this) of both the operating system and middleware-stack markets by 2015. I didn't see any mention of how Red Hat was doing against that benchmark in the conference call. But I didn't see Red Hat backing off that goal either.  

Looking at both sides of that ambition: 

• On the operating software side..
  • Red Hat wants to end up driving over half the world's servers by 2015. That seemed very doable in 2007 when announced because all it meant was mothballing a lot of Digital UNIX, AIX, Solaris and HP-UX systems. (Email to Microsoft (MSFT): You keep your Windows share and we'll take everything else.)
  • That was both logistically and technically sensible. In the process Red Hat saw its products becoming a mainstay on the mainframe as well. Also contributing to reaching the goal: there will be a lot of justifiable double counting as stacks like Red Hat's (and so far it's the only real game in town) forms the underpinning of virtualized Windows and VMware servers.
  • However Oracle's (ORCL) acqusition of Sun changed the dyamics. A very different player enters the mix offering a more intergrated approach up and down the stack.  That doesn't mean the goal should be changed but it affects both the operating system and middleware-stack sides of the equation.
• On that middleware side, holistically, to reach its 50% goal...
  • Red Hat would have to not only displace other potentially more popular open source middleware (e.g., Apache HTTP software) but billions of dollars of "closed-source" software currently in use across the world. (NOTE: The open-source vs. closed-source characterization is not meaningful in understanding or measuring the market but I use it because the open source zealots still insist on drawing this distinction. Red Hat is not a zealot but simply uses open source terms and conditions very effectively as research/development and marketing techniques.)
  • To literally accomplish its goal, Red Hat would need to displace 50% of the $20-$30 billion worth of IBM (IBM) CICS and Oracle (formerly BEA, formerly Novell, formerly the real AT&T) TUXEDO shipped in the last 30 years, the $20-30 billion worth of MQ Series, TIBCO (TIBX), etc., shipped in the last 20 years, the $20-$30 billion worth of IBM WebSphere and Oracle WebLogic and Application Server shipped in the last 15 years, the $10-$20 billion of Oracle, SAP, IBM and so forth integration servers, development tools, ESBs, portals, and so forth. Now we're talking about a real challenge and that assumes you do not define middleware the way Oracle and IBM do, including business intelligence and collaboration software and just about everything else -- including databases -- except ERP and customer relationship management.
  • No matter how you measure 50%, Red Hat would have to displace existing installed software at an astonishingly rapid rate over the next 6 years to reach its goal because the overall software market is only growing 5-6% (and the middleware market basically tracks the overall software market).
  • In addition, competitively Red Hat needs a database product because as many times as not, that is where the decision is made and the operating system and middleware stack decisions flow from that.  Monty, where are you?

 But the good news.  I don't think Red Hat lost any ground against its ambitious goal in 2010.

-- Dennis Byron

Infor and Lawson: What a Pile of... Systems Integration Challenges

On March 10, in commenting on why it would be a good idea for some industry-centric enterprise software supplier such as Cerner (CERN) or JDA (JDAS) to take a look at Lawson (LAWS), I said:

I can't dismiss the hint... that privately held Infor might acquire Lawson but that would mean it's a fire sale...

Well get on your asbestos gloves.

But this does allow me to run my annual post that tries to remember and list all the enterprise-software companies that used to be independent but that are now a part of Infor.  Here goes:

Agilisys (out of SC&T), Aperum, Arzoon, Baan, Boniva, Brain, Daly Commerce, Comshare, Dun & Bradstreet, Elevon, e.piphany, EXE Technologies, Extensity, Formation Systems, Foundation, Future Three, Infinium (nee Software 2000), Ironside, JBA Software, Lilly Software, Marcam, MAPICS, Mercia, McCormick and Dodge (M&D), Ohio Community Library Consortium (OCLC), NxTrend, Octane, Pegasus (not Pegasystems), Provia, Softbrands, StarBuilder, SunSystems (not to be confused with the server manufacturer acquired by Oracle), Symix, System Software Associates (SSA), Varial, and Vision.

And if the Infor buy-out offer is accepted by Lawson management and Carl Ichan, add BCM, CareScience, Confer, Enwisen, Healthcare.com, Healthvision, HCI, HIE, Hublink, Integrated Media, Intentia, Mobis, Movex, MPower, Noblenet, Outlaw, Pixel, PM Sims, Riley Dike Dosher, Rouge Wave, Scase, Xcare.net and Lawson itself -- which grew pretty much organically -- to the list.

-- Dennis Byron

Forbes Says IBM's Social Commerce Concept Bigger than ERP

There's an interesting post on Forbes about IBM, Sterling Commerce, customer relationship management (CRM) software, analytics and other like subjects the week of March 14 that answers a question I posed months ago: Why Is IBM Getting Back into EDI?

Forbes answer: Because the 50-year-old electronic data interchange (EDI) concept that morphed into electronic commerce 20 years ago is now something called "social commerce." And IBM thinks the opportunity is bigger than ERP. In fact the opportunity is so big that IBM is deploying several thousand salesmen, programmers and consultants in a new "practice" to take advantage.

But that launches three new worrisome questions for investors in my opinion: What's "social commerce?" How big was/is ERP? Why do I need a "practice" to take advantage of it?  So here's my take:

What's "social commerce?"

As defined by Forbes (meaning apparently by IBM), it could

"change not just the way companies sell products and services, but also their creation and production, and servicing — in effect, a new type of enterprise software platform."

My problem is that that definition sounds like every piece of information technology I've done market research on from the GE Model 58 in 1970 to LinkedIn. From a software point of view, that would mean it's an amalgam of ERP, EDI, CRM (the concept, not the company), business analytics and every variation of the word platform I've heard from IBM's own Project San Francisco in 1994 to CRM's (the company, not the concept) force.com. But it most closely sounds like ERP.

How big was/is ERP?

At its height when it dovetailed with Y2K paranoia, ERP was doing a couple of hundred billion a year in software and services.  Those are 1998 dollars.  Those are both kinds of services: implementation/training and on-going maintenance (which isn't about fixing things as I've explained elsewhere on this blog).  I am not even counting the dollars companies spent with management consultant companies to tell them they needed ERP software and services.

Today the local stamping plant can get what Boeing paid Baan and others a gizillion dollars for in the 1990s from Intuit (INTU) Quickbooks. (Of course, the local stamping plant can't build 747s.) The modern day ERP capability even has a lot of things 1990s ERP didn't have like Internet deployability, CRM, real-time analytics, business process management, and more (which all kind of sound to me like "social commerce.") Yet, as happens, the "opportunity" has shrunk to about a hundred billion a year. In 2010 dollars.

So is "social commerce" bigger than the old ERP or the new ERP? 

Why do I need a "practice" to take advantage of it?

Apparently, IBM is talking about the opportunity that needs management consultants to tell enterprises they need the concept. Those are the guys that work in "practices." This is not about three guys pulling all nighters to turn your Facebook page into the Sears catalog. Or even your force.com platform with Unit 4's Coda into a working ERP capability.

That doesn't surprise me given that I think IBM's long term strategy is about consulting and business process outsourcing, not software and technology. According to Forbes, IBM will have more salesmen than consultants and developers combined dedicated to the "social commerce" practice. That should tell the savvy investor all they need to know.

-- Dennis Byron

Investors Should Look at Lawson Software Rumors through Industry Prism

According to the Pioneer Press according to Reuters, Lawson (LAWS) is back in play by its own choice.  Previous rumors flew in June 2010 when legendary corporate raider Carl Ichan took a large position in Lawson.

The big four in the enterprise software market -- IBM, Microsoft (MSFT), Oracle (ORCL) and SAP  -- get listed as the likely prospects in these reports. But the underlying Reuters story provides a hint of why any possible Lawson merger/acquisition might go in another direction.  It notes the fact that Lawson's strengths are in healthcare and retail. 

This industry-centric factoid points out the hidden secret of ERP -- and enterprise software in general. This factoid should be the most relevant to enterprise software investors. Although most applications and even middleware are talked about in terms of generic, horizontal functions such as general ledger, inventory management, sales order processing, or application server, the hidden fact is that all of these functions and more (MRP, BOMP, DDA, EMR, POS -- I could string these out all day) are very different industry by industry, 4-digit NAIC code to 4-digit NAIC code.  All of the leading software providers other than IBM and Microsoft know this and tune their applications and middleware to those major industry-specific needs.

Therefore SAP with its strengths in process manufacturing would not be a good candidate for taking over Lawson. There would be little synergy in sales forces and even developer mindsets. Neither would Oracle be a good candidate for the opposite reason; through its acquisitions of PeopleSoft and Retek in the past, it is already strong in healthcare and retail. Why would Oracle add more disparate applications it would later have to integrate? (Yeah, I know.  Oracle acquisitions aren't always logical.) 

[Viewing a likely white knight for Lawson through the industry-centric prism breaks down when thinking about IBM and Microsoft however.  The application strengths of these two companies are horizontal and generic: collaboration via Notes/Domino and Office/Sharepoint respectively.  Either company could pull it off but I doubt either wants to. 

• [IBM just does not want to get back into the ERP market despite the fact that it invented it.  Lawson is an important IBM partner so IBM might acquire Lawson in self defense but that would be the only reason I could think of for IBM acquiring Lawson. 
• [And the fact that Lawson is such a big IBM partner is also why Microsoft would probably not want to get involved.  Not to mention the fact that it really should get out of the ERP business and give up on the Great Plains/Solomon/Navision experiment. But Microsoft might want to double down which is the only reason I could think of for Microsoft to acquire Lawson. 

[I can't dismiss the hint in the report that privately held Infor might acquire Lawson but that would mean it's a fire sale and there is also no investment play there.]

So keeping the industry-tinted glasses on, a better white knight for Lawson (assuming it is on the block) might be one of the healthcare ERP players such as Cerner (CERN), McKesson (MCK), or Siemens (SIEM) or one of the retail ERP players such as JDA Software (JDAS) or Micros Systems (MICR).  But ask yourselves whether these suppliers have the deep pockets -- or the egos -- to play the game of driving up the Lawson share price the way market action March 8 and March 9 indicates?

-- Dennis Byron

SAP In-Memory Enterprise Software: The Death of Middleware

There's been a lot of analysis lately about the death of the PC and the death of the enterprise.  So introducing the possibility of the death of middleware makes for a good segue into SAP's March 9, 2011 announcement of a new road map of in-memory applications.

This is the stuff Hasso Plattner's been working on at his Institute since his retirement instead of playing golf.  This is the stuff Hasso was going to hand to Shai Agassi on a platter before Shai went off to build electric-car charging stations and thereby become the twenty seventh most influential person in the world. (Oh Shai, what might have been.)

But I digress. There is some meaning to my "death of middleware" headline even though I don't believe it. Middleware basically exists because computers used to have 8KB of memory, kids. (Right, that's KB, not MB.) So, early programmers had to figure out how to get just the data and instructions that were needed into memory just when they were needed.  At first these instructions were on punched paper tape, then cards, then magnetic tape 3/4" wide, then... well you get the picture.  Eventually someone figured out that the paper, cards, tape, etc. didn't even have to be in the same room... or on the same continent. Along the way, someone cutely called the software that coordinated all this to and fro "middleware," the stuff in the middle between the hardware and application. (Email me if you want to argue that it means in the middle between the user interface and the database.  You can probably even find where I wrote that somewhere.)

But what if the size of memory was not a restriction?  Programmers would have written the applications in an entirely different way. Big ERP systems would work like Intuit (INTU) Quicken. Welcome to the new SAP R/3 or whatever SAP is calling it these days. SAP says the roadmap consists of:  

• New analytics that analyze massive amounts of data in real-time (the whole idea of data marts instead of data warehouses was a result of the same memory limitation described above viz a viz transactional apps).
• New transactional applications and rewrites of SAP's existing solutions that also take advantage of real timeness.

In theory, this will reduce redundant layers and let SAP in-memory-technology customers do operations, planning and analytics at the same time. SAP claims that it 

"... eliminates the need for data caches, aggregations or (even) batch processing. Eventually, in-memory computing technology will help customers reduce their database usage and reliance on disks (or paper tapes or punched cards or magnetic tapes so heavy it took two operators to mount them), leading to a (sic) fewer layers and a simpler architecture." (parenthetical phrases added by Byron)

There are a lot of implications in this for virtualization, mobility and even -- I hate to promote the term -- cloud computing.

As per the press release linked to above, SAP announced some instantiations of this approach as well. Interestingly the list mirrors the first analytical/optimization applications announced by SAP in 1998 or so. There is some logic to this because such things as planning and optimization of business processes are exactly the sorts of things that you want the actual line managers and professionals working on in real time... with no IT people or business analysts in between. There's no real demand for running receivables against the ledger this way (although you will be able to).

So not only is middleware really not dead (I just wanted to suck you in), neither is ERP.

-- Dennis Byron