Standing in the Field @ Valley Forge

Standing in the Field

Notes from SJS Application Server Field Engineering

« Mail.appetizer | Main | Annotations Preso... »
Thursday October 21, 2004
Software Economics Part 2.5
software economics icon

A few follow ups to my last software economics post. I'm anxious to get back to more technical topics, but Chris Rijk brought up some good points worth further discussion. I quote from Chris' comments several times below.

" I was a bit surprised that the general theme that it is typical for support services to be unprofitable. Many companies also offer multiple support options - eg bronze, silver, gold and platinum. The general impression I see in the press is that support contracts are a cash cow, not a drag on the business."

Yes, most companies do have tiered service offerings. Sometimes the tier is determined by the size of the product order, and sometimes based on the amount of a premium the customer is willing to pay. And, yes, it does seem surprising that the service business isn't a cash cow. It certainly is a cash cow in other businesses: consumer products for example.

So why is enterprise software support a breakeven or money losing proposition? The hands on attention required by enterprise level customers, as well as the difficulty in reproducing enterprise level complexity. Picture the typical J2EE application server deployment. In in addition to the application server itself, a very complex piece of software, the deployment consists of:

A failure in the application could be caused by any of the above. I frequently work on escalations that take thousands of hours of analysis from Sun. A "continuous effort" escalation will have staff working on the problem around the clock as well as a half dozen other people working part time on the issue. Only to find out a week or two later that the problem was with a third party product or a some bad code written by the customer. It's hard to turn a profit when a single escalation can consume so many resources.

"In addition, R&D can be spent to reduce support costs . . . . Apart from simply having fewer bugs, this can include better defaults options, making it harder to go wrong with settings, self-tuning software, self-diagnostics and corrections, remote monitoring and so on. Given the huge huge steps forward Solaris 10 has in this regard, I was a bit surprised that this wasn't mentioned."

Yes, there definitely is an effort from Sun in this area. Solaris 10 is one example, and so are the Java Enterprise System and the performance ergonomics of Java 5.0. This hasn't been one of Sun's strengths historically though. One of Sun's perceived strengths was how "tunable" the systems were. Solaris and Java both had lots of knobs and buttons to allow users to tweak performance. It's only recently that Sun has invested in the R&D to self-tune a lot of those knobs and buttons.

I was also surprised to see relatively little mention of upgrade licensing. (maybe because generally Sun sells a RTU for any version on any platform?) For a lot of larger software companies, a lot of revenue seems to come not so much from "new" licenses, but upgrades.

There are some exceptions, but upgrade pricing is much more common in consumer software and enterprise desktop software than enterprise server software. Most maintenance contracts for enterprise server software that I've seen (including those from Sun) include upgrades.

Another "trick" is to pull support for older versions when a new version comes out.

I'm sure that that seems like a trick from the customer's perspective. But that's just another way that vendors try to reduce their costs. There's only so many different versions of a product that a vendor can afford to support. Each version takes up lab machines, training budget, and requires endless compatability tests. So when a new version is released and older version is often dropped from support to make room for the new version.

(2004-10-21 21:22:18.0) Permalink


Comments:

Post a Comment:

Comments are closed for this entry.