Reducing your dependence

Jeff will probably follow up with a more complete analysis later, but I couldn’t resist a quick response to Phil Wainewright’s post:

So by allowing Oracle's license revenues to decline, Ellison is reducing the company's dependence on a shrinking revenue source.

So now losing is something to be congratulated for. I get it….. In that same vein:

- When a company loses money, they're reducing their dependence on profits.

- Free Jeff Skilling. He should be applauded for reducing Enron’s dependence on employees.

- Let's also thank Larry for reducing his shareholder's dependence on returns.

Phil has been mesmerised with with Oracle’s version of three card monty. Find the growth! Is it under maintenance? Under service? Under database? Under middleware? Did we buy it? Did we earn it? Anyone can win! Put your credibility down and find the growth!

Phil, the way you win 3 card monty is by not playing it in the first place.

The Software Sales Arms Race

I had a post brewing on the topic of software sales & marketing when Erik Keller beat me to the punch with a great analysis of software economics.

Vinnie seized upon Erik’s post to hammer on his favorite topic that software companies spend an insufficient amount on R&D and too much on sales and marketing. I believe this is true too, but I don’t think Vinnie appreciates why this is the case and why he himself is part of the problem.

The ballpark economics of your average successful enterprise software company looks something like this:

100% sales
80% gross margin
15% R&D
35% Sales & marketing
10% General & administrative
20% Operating margin

Sales & marketing spend has fairly strong economies of scale because investments made in brand building and customer relationships can be amortized across a wide variety of products. This is why the mid-sized vendors in Erik’s analysis have worse margins.

Interestingly, software R&D is exactly the opposite: it has strong diseconomies of scale. The bigger the development organization gets, the more coordination work is required and the more cost per line of code developed grows.

The whole sales & marketing mechanism, and the parallel decision making buffers and gatekeepers in the customer organization, is what Coase would call a transaction cost. That is, these activities exist because commercial software application development and application consumption live in separate companies. Mr. Customer doesn’t immediately grok or trust what Mr. Vendor creates and so they both erect staffs of people to manage the interaction so they’re both sufficiently protected.

In the ideal world, vendors would build products and leave them at their doorstep where customers would costlessly find them and consume them. Similarly the customers’ economics would greatly improve if they could readily find products and consume them with a high degree of trust and rapidly realize their value.

In reality, this is not the way our industry works, and instead we have an unnecessarily adversarial relationship between vendor and customer as well as a whole lot of money wasted doing what Reagan called “trust but verify.”

This isn’t just theory, it’s what most in the software industry have experienced for the last 20 years. From personal experience in competitive sales opportunities, I’ve seen the company with superior products lose to the company with superior salesmanship. If you’re the CEO of a software company and you see this too, how can you afford not to spend that extra dollar on sales and marketing when it produces a superior return?

What we’re really seeing is a prisoner’s dilemma for software vendors where the payoff matrix looks something like this:
(eat your heart out David Cowan)

The end result is we’re all in jail. CIO’s are positively bombarded by the vendor community. Cold calls, warm calls, mailings, webinars, partner referrals, trade shows, you name it. In response, CIO gatekeeping and evaluation has become more and more sophisticated (enter Vinnie). Thomas Otter gives a great description of what this looks like today for vendors. All of this costs a ton of money for everyone involved and for the most part everyone’s investments (vendor, competitor and customer) cancels each other’s out.

Meanwhile the line of business in an enterprise has become quite put off by all of this. The just wanted some technology to solve a problem. The “pull model” Erik describes in his post is basically a way for the department or the line of business to circumvent this whole exercise. That means they’re finding their way around the software vendor’s sales force AND their own IT department (Vinnie’s clients).

I think the pull model is one way to cut the sales & marketing Gordian knot, but it comes at the cost of a proliferation of point applications across the IT environment which is the world we came from just a few years ago.

The other solution to the problem that I’m surprised Erik didn’t mention is for the industry to consolidate around fewer channels. Credit to McKinsey’s Ken Berryman who has often predicted that the enterprise software industry is not now, but may soon start, to look more like the pharmaceutical industry. A few big companies build and maintain the sales and marketing machines and the smaller biotech startups develop innovative treatments while leveraging the larger company’s channels.

In this same way, a few of the major enterprise software vendors will keep the big sales & marketing machines running while the smaller vendors leverage that infrastructure. Take advantage of the sales & marketing economies of scale. Avoid the R&D diseconomies of scale. Sadagopan made a reference to this value chain desegregation in his post on the same topic.

In the end, I think both of these models will grow in popularity. Departments will consume more open source and on-demand applications to circumvent both vendor sales and the IT department. At the same time, the big software vendors will play more of a trusted advisor role to the central IT groups and reduce the sales & marketing costs of smaller companies. In either or both scenarios, the solution to our industry’s problem is a little more complex than “cut your SG&A spend so you can cut my price.”

Yet another Jboss post

So many good comments on the Jboss acquisition, I’ll try to pick some of the best and add a few of my own.

1) I’m with Jason that a big catalyst for this deal was the fact that Red Hat was the only company out there that could pay this price and still keep it accretive to their revenue multiple.

2) Based on Mark Fleury’s 2004 blog post, I think all the bloggers out there can sleep a little easier knowing that you can insult a company publicly and still get them to give you $350 million.

3) I’m curious to see what the channel conflict implications are. Red Hat has always been in a fantastic position where they are liked by almost everyone and offend next to no one. This has given them a lot of free channels including IBM, HP, Oracle, BEA, SAP and Dell among others. That is really unprecedented in high tech to have so much free sales and marketing goodwill. Jboss has friends too (HP and Novell notably) but nowhere near as many as Red Hat. In fact Jboss competes with many of the aforementioned. This could prompt IBM, Oracle and BEA to look at alternate Linux distributions now that Red Hat is fielding competing products. A few articles are starting to hash out how these issues will start to surface.

4) My biggest concern from the rumored Oracle acquisition of Jboss was it would trigger a flood of venture capitalist ambulance chasers who would fund free alternatives of other successful software franchises in the hope they could get bought out by the player with the most to lose. Red Hat’s acquisition does not send such a clear market signal. So far Red Hat is the only player with both the interest and the currency to pay these sorts of prices. With just one major buyer out there, VC's have the hope but not the assurance that an open source investment will get competitive bids when it’s exit time. Contrast this with the consumer space where a VC almost always has 4 or 5 doors to knock on.

5) Whither Red Hat?

More than a little prone to hyperbole, Dana Garnder's post points out that between Linux, its partnership with Xensource, Jboss' acqusition of some Sun/Netscape products, and Jboss' core product portfolio, Red Hat is almost in the stack business, competing with the majors. If so, that's a massive business model shift for Red Hat. Some have questioned whether such a transition can be accomplished just by acquisition:

Although they both seek to sell to high-level IT executives, Red Hat's software is generally used by Linux systems administrators while JBoss' software is aimed squarely at Java developers.
"They haven't been chasing the same customers, which can be a challenge," said Dave Gynn, director of enterprise tools and frameworks at open source services firm Optaros. "It's good in that it opens up opportunities, but at same time, they haven't been selling to same customer."

Dana Blankenhor gets the last and best word on this subject:

Either this deal will blow up in Red Hat's face or Fleury just bought Red Hat.

Many thanks to all involved for keeping enterprise software interesting.

Open source presentations at Software 2006

Software 2006 continues to provide good fodder for posts. Five companies presented in the Open Source Software Showcase last week:

- Collabnet (development community tools)
- Digium (PBX software)
- Ingres (database)
- Zimbra (e-mail server)
- Compiere (ERP)

The presenters had markedly different takes on what it meant to be an open source business both in terms of their product development models and their business models. For others at this session please correct any characterizations I’ve gotten wrong.

Product Development Models

Collabnet seems to have developed their product in a pretty traditional salaried development team/release schedule model. This was ironic considering the product itself is supposed to enable companies to emulate the open source development model which looks nothing like the aforementioned.

Digium felt the most like the Linux development model. A number of volunteer developers suggesting additions to the code and a few strong editors deciding what made it in to the release.

Ingres was developed much like some of Sun’s new open source products: several releases under a closed, dedicated staff approach, later launched as an open source app.

Zimbra was developed by a crack, single site, salaried startup development team. Their open source development model looked most like a Jboss or SugarCRM where development is mostly captive but testing/bug-fixing comes from the open source community.

Compiere’s development model seemed similar to Digium. Some degree of actual new functionality is coming from the open source community.

Business Models

Collabnet was predominantly hosted with a subscription fee. In addition, they have a free community edition. While Collabnet was in the Open Source Showcase, the development and business models appeared pretty similar to a Salesforce.com. Of course that’s a perfectly good business to be in, but not particularly open source.

Digium gives the software away but charges for the PBX hardware and licenses the software to competing PBX manufacturers.

Ingres’ revenue model seemed like the Red Hat approach: free for the GNU license but it’s possible to license “certified binaries” that comes with some extra perks like indemnification.

A funny moment in the Zimbra presentation was when the presenter said: “You can have the basic version for free, but if you want to use Microsoft Outlook, cluster, do backup, or patches, we’ll charge for that version.” Gotcha. You can also have my car for free, but if you want a door, a steering wheel, an engine and some seats, I’m going to have to charge you for that. That said, the demo itself was really slick.

I couldn’t figure out how Compiere was making money (they claim to be profitable). All versions of the product were free and the implementation was done by partners. They only have 8 or 9 customers, so that seemed like an insufficient maintenance base to keep the lights on. I’m guessing there’s some freelance consulting work that flows back to Compiere.

So like many of the big trends in software, because open source is invoked so often, it has come to mean everything and so now it has almost no specific meaning. With five “open source” companies as diverse as these, I think it’s officially impossible to be “for” or “against” open source or believe it’s the “way of the future” or a “flash in the pan.” Rob's feedback from LinuxWorld was quite similar to this takeaway.

Software 2006 part 2 - customer panel

A fun discussion with two senior IT execs: Motorola’s Toby Redshaw and Shell’s Con Goedman.

My favorite part of the session was some great validation statements on my earlier post on the value proposition for SOA/ESA.

Toby Redshaw: “We’re getting some fantastic results from web services. Projects that took 6-8 months and an army of people before are down to a day or two.”

Con Goedman: “The biggest innovation we’re seeing are those that get the technology people closer to the business user’s needs.”

Toby also mentioned a few of the next gen appliance vendors I cited in this post was mentioned by Motrola’s CIO (Cassatt, Netezza).

The two big admonitions for SAP and peers came through loud and clear:

1) Shorten implementations. Customers want 30-50 days to get to value, not 9-12 months.
2) Focus on business user value (not just CIO/IT buyer value)

Another great quote:

“Toby, what do you see as the trend in software pricing: License? Maintenance? Subscription? SaaS? Success fee?”

“You know Eric, we just don’t care. Money is money.”

Jeff called that one about a year ago (on his old blog).

Software 2006 part 1

Ask and ye shall receive Jason. I attended the first day of Software 2006 as well, so I thought I’d add my voice to that of Will Price, Jeff, Zoli, Sadagopan and others who are also here. Some observations:

Interest and Interaction

Echoing Zoli’s comments, we enterprise software folks aren’t a very lively bunch are we? The conference is very well attended by all corners of the software community, but between presentations there was only the most grudging, perfunctory applause. Also the low interaction between the audience and speakers implies to me we’re still a ways from a participatory web 2.0 ethos in the enterprise.

Trend Surfing

MR Rangaswami kicked the conference off by reviewing the big themes of the past two conferences: offshoring and industry consolidation (this year it’s the ecosystem). It struck me how quick our industry is to jump on the latest trend and believe it’s going to sweep the market. A year passes, we forget about the old trend and move onto the next one, without much of a post mortem.

The irony of MR’s trend review is it was immediately followed by a host of presentations that proceeded to compete on who could interchange the same 4 buzzwords in the most creative way. “InnovationSaaSOpenSource?” “OpenSourceSOASaaSInnovation!” “InnovationInnovationOpenSourceSOASOA…” Every once in a while someone would throw in a “web 2.0” just to mix it up.

These are all big important trends in our industry but sometimes they were interchanged indiscriminately despite the fact that they’re extremely conceptually dissimilar. It was like a screenwriter pitching a Hollywood producer with: “Hey, it’s Batman meets Brokeback Mountain meets Pimp My Car!”

My favorite of the keynotes/panelists was Goldman Sach’s Rick Scherlund. He was exceptionally thoughtful and did a great job articulating how many of the new hot trends will co-exist with the status quo they’re meant to tear down:

- multi-tenancy and on-premise
- open source and proprietary
- bottom-up, user based purchasing and centralized, “buyer’s circle” based purchasing

I also attended both of the software showcases on open source and enterprise applications. Each session was comprised of 5 companies doing rapid fire 10 minute presentations/demos. These were very thought provoking and will be the subject of a future post.

IBM's new service hub

A few weeks back I referred Jeff to this article describing IBM’s move to develop a “service development hub" in India thanks to a new $200 million investment. The general idea seems to be that IBM Global Services teams will identify enterprise services that customers need during an engagement, spec the services, create them in India, and reserve the right to reuse them for future client engagements.

I find this move to be intensely smart which is typical of IBM when they choose to break out the big checkbook. I also think this investment is a harbinger of several larger trends in enterprise technology, many of which can be traced back to the onset of SOA.


1) A new way to build a business in IT services

IT services has never had a particularly good business model. It has high fixed costs, low barriers to entry and relatively low operating margins.

The advent of the Indian players (Wipro, Tata, Infosys, etc) have made this an even worse business for the incumbents, challenging the classical model of large, on-site engagements with high daily rates.

IBM’s investment in a SOA development center shows us that reusable intellectual property is the only thing that will separate many an IT consulting business from a glorified temp agency.

If IBM builds up a repository of reusable enterprise services created during various client engagements, they’ll be able to bid for new customer projects at the same prices as an Accenture or Wipro but execute them with fewer resources thanks to the reuse. This has been made possible because of SOA: IT assets created in one project can be reused only because their documentation is inherent in their functionality (i.e. they’re self-describing).


2) The beginning of the end of enterprise software’s own “Bretton Woods system”

In the mid-1990’s, life was pretty straightforward in enterprise software. You lived in 1 (and only 1) of the following 3 camps:

- You could be in the applications camp, which at the time was JBOPS, plus a growing number of e-business application vendors.

- You could be in the technology platform camp, which at the time was Sun, IBM, Oracle, BEA, and Microsoft. Every application vendor would pick one or more of these platforms to build on.

- You could be in the systems integration camp (Accenture, EY, and the rest of the big 5) and implement the technologies of the aforementioned two camps.

Each camp played a unique role in the ecosystem. The apps vendors understood customer processes, the systems integrators were the honest brokers & client confidants, and the technology platform vendors tried to create a common denominator of skills and technology for everyone to build on.

In today’s emerging SOA world, enterprise services are nether application nor infrastructure, and SOA applications are neither custom nor packaged. As these old product and service distinctions start to blur everyone is getting back into everyone else’s business. IBM has been in the systems integration business for some time, and thanks to NetWeaver, many of the major application vendors are now in the technology platform business.

Because of this SOA hub announcement, IBM isn’t back in the applications business per se, but it is in the repeatable business logic business which isn’t so far away. I’d be surprised if we didn’t see Accenture, CGEY and the rest follow suit with pre-packaged enterprise services or process patterns becoming a differentiator for client engagements.

3) A new take on the offshoring model

I’m always been something of an offshoring skeptic. I think the benefits that come from low labor costs and 24x7 development are usually offset by added coordination costs and the number of extra links in communication path between the developer and the end user.

With a SOA approach, one can keep the process and user interface creation work close to the users in their respective markets. But since the enterprise service creation is so tightly specified (via WSDL’s), it can be offshored with a minimum of coordination costs. Hence IBM’s ability to centralize service creation in one site versus the 17 they have today.

In this way, organization can follow architecture, versus today’s offshoring model which tends to segregate work along steps in the development process (e.g. someone codes, someone else tests or maintains).

Whether you believe SOA is revolutionary, evolutionary or neither, it does seem to be changing the economics of the enterprise technology business and the roles of the different players in the ecosystem.