SmoothSpan Blog

Vinnie Mirchandani has a question:

Why hasn’t the $75B in software maintenance fees Oracle collected over the last 5 years resulted in more innovation?

He’s created quite a discussion spanning several blogs and writers, which is neatly summarized here.  Even a couple of Oracle spokepersons have gotten involved.

I’m not exactly sure why Oracle is singled out, because you could say the same of pretty much any large software company: SAP, Microsoft, whomever.  I don’t propose to debate that here.  I did point out that Oracle’s strategy of acquisition is an innovation by itself relative to most of its peers.  Vinnie countered that it doesn’t produce the kind of innovation that Intel, Apple, and Cisco have going on.  And so I respond thusly:

Cisco innovates by acquisition.  That’s why they’re on your list, Vinnie.  In fact, they’ve created a thriving ecosystem where an entrepreneur can be acquired more than once by Cisco. 

Personally, I think this is the best route for really large companies to innovate, but it takes a certain culture.  Not sure when your execs are investment bankers whether you think that way.  More likely you think about whether you can get a higher multiple on the revenue stream you acquire, and of course that’s just what they’ve done. 

But there are only so many Big Co’s for them to acquire left.  I think Tom’s note about Ellision’s SaaS investing is pertinent.  Perhaps he views SaaS as the farm team for a future round of acquisitions.  If so, he’s got his own ecosystem, and we just haven’t seen it unfold yet.  Most of those companies aren’t big enough to matter to the Mother Ship.

Vinnie asks a sub-question that I do want to explore here, because it is interesting and doesn’t get talked about much.  In the comments of the post I refer to, he says:

Why should stability require a continued premium? should not SLAs evolve in line with SaaS SLA, quality with CMM and Six sigma advances etc, help desk costs decline with automation and offshoring?

Therein lies an interesting story. 

It turns out the On-premises companies deal with a host of issues that SaaS companies seldom do, and it is these issues that account for a lot of the costs.  I’ve compared notes with a number of CTO’s, and our rough estimate is that something on the order of 40-50% of the engineering budget is consumed by:

–  Patching old versions.  With on-premises, many times customers refuse to move forward to the latest releases.  As a result, vendors are stuck providing patches that can be applied without installing a new release.  This is an extremely time consuming activity.  In the worst case, it requires every bug you’ve fixed in a later release to be individually re-engineered, re-tested, and re-packaged, for each of the older releases.  Just the thought of it is enough to give an organization pause when contemplating any major architecture work because that means the bug might have to be fixed in two completely different ways on either side of the architecture change.  SaaS companies are effectively immune to this because they update releases much more frequently and push the updates to every single customer as soon as they are ready.  I surveyed Customer Service departments for on-prem software companies one time and asked how many of the problems being reported were fixed in the most recent release.  The answers that came back ranged from a low of 40% to a high of 80%.  That’s another way to quantify the tremendous waste that preparing and supporting these patches brings.  Most SaaS customers simply never see the problems because they’re fixed transparently behind the scenes as soon as even one customer has a problem.

–  Supporting multiple platforms:  This is another painful cost.  There is an Unholy Matrix of Testing that is multi-dimensional.  Each dimension is a platform component:  OS, Application Server, and Database Server would be the least number of dimensions to consider.  Add to that various kinds of inter-application integration and any other dependency between two pieces of software.  Now drag out the data sheets for all the versions of a piece of software that are currently being supported.  Mark off every single release of each one of those platform components in a row of the dimension.  It’s a combinatorial explosion.  Yet, if you support all of those combinations and permutations, you are warranting to customers they can choose whatever they’d like and it will work.  Reality is that no vendor tests them all, they test the most common ones.  So there are exceptions that creep in that result in more patches (which per the above get applied to lots of releases that many different customers are using), and that through the magic of continuous process improvement add more steps to doing new releases so they can be avoided in future.   BTW, even for Oracle, this is not under their control.  They bought into all sorts of support commitments.  Peoplesoft and Siebel certainly didn’t only support the Oracle RDBMS, for example.  Also, the platform vendors unilaterally do all kinds of things to mess up your game plan.  They quit supporting versions.  So now you have to certify some new version on one of your old releases so an important customer doesn’t have to go through the expense of upgrading.  How do SaaS companies avoid this?  They only support one canonical platform because its all happening behind their firewall, not yours.  They can keep it as the latest platform and keep every customer on the same one.  Huge savings there.

Is it fair to pass those costs back to customers through lack of innovation for maintenance?  I think so.  After all, much of it is motivated by customer desires.  The desire not to have to upgrade.  The desire to use a particular platform combination. 

There ain’t no such thing as a free lunch!

And, yes Virginia, there are real reasons why SaaS is better and cheaper.  It isn’t just smoke and mirrors.

PS  Vinnie mentions outsourcing.  Oracle had been famous for this, or more properly for offshoring.  Used to be that when you lost someone on the team, you could get 2 replacement reqs instead of 1 as long as the 2 were offshore.  Last news I heard from a formal Oracle dev manager was that this hadn’t worked out so well for productivity and they were backing away from it.  Given today’s economy and the availability of onshore resources more cheaply, I should hope so.  Offshoring makes innovation MUCH harder.  Now I’ll wait for the chorus of responses to that one.

PPS Just heard Vinnie was referred to by none other than Marc Benioff in his earnings call!