Standing in the Field
Notes from SJS Application Server Field Engineering
Standing in the Field
Notes from SJS Application Server Field Engineering
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
Discovered a new utility today: Mail.appetizer. It's a plug-in to Apple's Mail.app. When you receive a new email, the plug-in displays a transparent window that has a preview of the contents of the email. You can click on it to bring up the email in Mail.app or just ignore the window and it will disappear in a few seconds.
This allows you to quickly triage emails. If an email is important, you can open it up and immediately respond. But if it is just some piece of electronic bureaucracy, the preview pane lets you know that you can safely ignore that "new messages waiting" indicator. All without having to leave your current application. It's probably the coolest use of transparency that I've ever seen.
Simple, useful, cool, pretty. Very Mac like.
(2004-10-20 22:14:28.0) Permalink Comments [1]
When I got my new Application Server job I decided that I was going to use this blog to post some of my presentations, papers, and notes regarding J2EE and Sun's application server. This decision led me to invest in a little site redesign. Both to improve the UI and to make it stand out from the rest of the blogs.sun.com crowd. (Previously I had been using a slightly modified version of one of the standard Roller templates.)
If I have to say so myself, I'm pretty pleased with the results. There's still some tweaking I need to do here and there, but the design is really pleasing to my eye at least. The new page validates, which is nice, and it's actually a CSS box layout which I usually shy away from. It probably looks like crap in Netscape 4.x, but I think that people still using Netscape 4.x are used to that already. I'm a little nervous about it looking OK in IE, but I don't have any Windows machines I can test with.
Some site credits:
Remaining todos:
OK the site update is posted and looks pretty much the way I intended. I was worried about how all of the Roller macros would expand in the new layout and CSS, but it seems to be OK. I've tested in Safari and Mozilla and it looks good. I'm a little worried about the various flavors of IE: I'm using CSS box layout that I know gets a little wonky in IE. But I've compensating for all of the IE bugs that I know of. If you are running IE 5 or 6, drop me a comment and let me know if the box layout looks OK. (There should be a top box with the title and a photo, a content box on the bottom left, and a navbar on the bottom right.)
I'll post some more details tomorrow, but it's late and I just wanted to get these layout changes done tonight while traffic is low. Most importantly, I'll let you know a little bit about the banner photo and about the CSS resources I used to help build this design.
(2004-10-18 00:20:59.0) Permalink Comments [4]I'm updating the site template. The site may get a little wonky in the meantime. Stay tuned.
(2004-10-17 23:04:58.0) PermalinkThis is the second part of my follow up to Bryan Catrill's post about software economics. The first part of my follow up can be found in an earlier post.
Both part one of my follow up and Bryan Catrill's original post discuss some of the interesting implications of software's near 100% gross margins. Even though software has a high fixed cost to write, once it is written each new customer is effectively pure profit. But while this is true in theory, in reality customers are quite expensive. And the biggest reason, at least in enterprise software, is support costs.
In the typical enterprise software deal, the customers will pay a one-time licensing fee and then a annual support contract fee that includes upgrades, patches, and phone based support. There are minor variations: sometimes upgrades are a separate fee, and sometimes onsite support is included. But the important bit is that enterprise software is rarely a one time transaction: there is a recurring obligation from the vendor and a recurring fee from the customer to pay for those continuing services.
The first thing to note is that the gross margins on software support are much more "normal" than software licenses. There is an incremental cost to the vendor for each new customer. The largest of those costs is the labor cost in fielding phone calls from customers having trouble and helping them resolve their issues. If it takes eight hours to resolve the average customer problem and the average customer calls support once every two months, each new customer will cost the vendor 4 man hours of labor every month. Of course the average time to resolution and average number of calls are going to vary widely based on the individual product. But the important part is that these support contracts have incremental costs for each new customer and therefore the gross margin is less than 100%. In fact, for many (most?) vendors, these support services are so expensive to provide that they lose money on every customer.
So let's reconsider our example from part one in more detail. Imagine a start-up company that is making a new software product that sells for $10,000 per CPU. After a couple of years of building up their product, and $10million in development costs they sign up 100 customers, with an average deal size of $75,000. The average customer also has a support contract that costs $15,000 a year. The company staffs a support desk to service their customers that costs the company $1.8million a year. They are also continuing development with a labor cost of $4million. In theory, life looks pretty good for this software company. They have revenue of $7.5million and costs of $5.8million: they are profitable, which is much better than most software companies.
But there is a nasty problem here: the company doesn't have any direct incentive to keep their customers happy. Each existing customer is costing them more money than they pay in support fees every year. New licenses are very profitable, but existing customers are just a drag on the company's profit. There are lots of indirect reasons to keep their customers happy: references, positive press, more licenses. But there is no incentive for the company to be offer good customer service on the support contracts: the company is incented to provide the least amount of service that it can in order to keep the customer happy.
Another problem is that the average software sales person doesn't make any commission on support contract renewals. (Probably because the margin is so much lower.) So the sales people are even more incented to move on to the next new customer and ignore the existing customers. Most sales people are long sighted enough to see the value in having satisfied customers and do what it takes to keep their old customers happy. But happy customers do not pay the bills for enterprise software sales people.
There is one nice side affect of this however: high support costs encourage the development of high quality code: especially in mass market software. Every bug costs the company real money in the form of support desk labor. But even if a company is lucky enough to have a profitable support services division, the gross margin on services is still going to be much lower than license revenue.
These problems were tolerable in the dot com era when software companies had rapidly rising revenue. The new license revenue outweighed the support costs. Plus it was the dot com era, showing revenue growth was perceived as more important than ongoing profitability. But once the dot com boom turned into the dot com bust, software companies found their revenue declining. There have been three net results that I have seen:
Software subscriptions are likely to remain controversial for some time to come. Companies don't like the idea of renting software. They don't like being so legally dependent on a vendor. They also don't like increasing their recurring costs. But subscriptions, or something similar, seems to be an inevitable trend at this point. The software industry needs to find a business model that works for both vendor and customer. And by making the vendor dependent on subscription renewals, and therefore dependent upon customer satisfaction, we will see a more sustainable model for both parties.
(2004-10-17 21:42:15.0) Permalink Comments [2]Yesterday I promised to make a post about some recent changes regarding my job at Sun.
One of things that has been keeping me so busy recently is that I've accepted a new role at Sun. I will be leading the Application Server Community of Practice within field engineering. While I'm still negotiating some of the finer details of my new job, the short description is that I will be facilitating all of the pre-sales and post-sales activity for Application Server in the US.
I've always been a J2EE kind of guy and have a long history with the Sun application server. (Including my book, although it's getting somewhat dated.) So I'm excited by the potential of this new job. I'm going to have the opportunity to really take my own knowledge of the Sun Java Application Server to the next level. While, at the same time, getting to work with some top notch people in the management of both field engineering and product engineering.
As you might guess, this role is going to include a lot of both education and evangelism. So part of my plan for this new job is to leverage this blog. Expect a revamp over the next weeks as well as regular postings about my experiences in the field with the application server. I already have one good anecdote, but I'll save that for another day's blog entry.
(2004-10-06 22:12:29.0) Permalink Comments [2]Well it's almost a month later, and I still haven't finished my article on software economics. I've been busy, as always, but I've also had some recent changes in my job that have been distracting me. More on those job changes tomorrow.
But since I don't think I'll be able to finish my article in the foreseeable future I wanted to post what I have so far. As a reminder, this article was to be a response and follow up to Bryan Catrill's recent post.
As Bryan Catrill pointed out one of the interesting aspects of software economics is the fact that the gross margin of software is effectively 100%. (Although I'll debate this somewhat in part two.) This has all kinds of interesting consequences, many of which Bryan points out in his original article.
One of Bryan's points is that an existing software customer is relatively price inelastic. In other words, once they are locked into a vendor, they will generally continue to buy regardless of changes in software price. The exception being if the software cost exceeds a the cost of migration: what Bryan terms the FYO point.
In contrast, however, customers that are not locked into a vendor can be quite elastic in response to price. There may be 100 companies willing to spend $10,000 a CPU for your software, 400 more willing to spend $2,000 for your software, 6000 willing to pay $100, and 100,000 more willing to use it if it were free. So software vendors have the choice of either charging everyone $10,000 per CPU (in which case you end up with a niche high end product and only one million in revenue), $2,000 a CPU (you end up with more customers, but the same about of revenue), $100 (less revenue, but lots of customers.), or even offer the product for free and make revenue offering consulting and support to the large group of customers.
One result of these circumstances is "tiered pricing". The Sun Java System Application Server is a classic example of this. Sun's application server comes in three different "editions": Platform, Standard, and Enterprise. Enterprise edition is the complete product and has a list price of $10,000 per CPU. Standard Edition is the same product, with a couple of features disabled and it lists for $2,000 per CPU. Platform Edition has a few more features disabled and is free. Theoretically this is the best of all possible worlds: customers get a price commensurate with their needs. The vendor maximizes their revenue by tapping both low-end and high-end markets. But this is a hard balancing act. The hardest question being, what features are needed only by high-end customers? You don't want your low end product to be crippled so much that no one will use it. But you also want the extra features of the high end product to be compelling enough to win over the high end customers.
Tiered pricing isn't unique to the software industry, of course, But the effective 100% gross margin of software means that the tiered pricing tends to be very extreme. Apple sells iBooks in three tiers ranging from $1,099 to $1,499. Honda sells Accords in tiers from $15,900 to $23,300. But a price range of $0 to $10,000 has a much different impact, especially when printing a CD costs to the same amount to Sun regardless of which edition it ships to a customer.
Further complicating this issue is that the cost of sales and customer expectations will also change as you change the price point. If you have a $10,000/CPU product, your customers will expect hands-on attention from a sales force, long evaluation periods, analyst coverage, and 7x24 support. If you charge $100/CPU, customers will expect a lot less: they will buy over the web. They will have lower expectations of support and services. Evaluation periods will be short. This is only natural: companies are are trying to avoid getting locked into the situation that Bryan describes. A $100 investment is a lot easier to abandon than a $10,000 investment. But the net result to vendors is that pricing not only affects the revenue you make from a product, but also how your product is perceived and purchased.
There was a discussion on the Joel on Software forums about this. Joel writes about the fact that customers will sometimes avoid less expensive products because they are perceived as "cheap". He also talks about certain price thresholds. Under $500 and your product can be bought by a low level manager on a corporate credit card for departmental use. But,
[A]s soon as your price gets up in the $3000 level, the amount of approval it needs is so absurd that you are not going to sell products without a salesperson making a few visits. Hiring the salesperson, sending them out to make presentations, hotels, airfare -- now it costs $50,000 to get the sale done just in sales closing costs. That's why you see a lot of software products at $100,000 and a lot under $3000, but anywhere in-between and it's impossible to make sales.
This really resonates with me because Sun Java Web Server has a list price of $1,495/CPU and Sun Java Application Server Standard Edition has a list price of $2,000 per CPU. Which makes a lot of deal sizes in that five figure range that Joel warns about, and I've seen the challenges that price range brings. It's hard for Sun to justify putting me on a plane to do a demo for a potential $10,000 deal. But on the other hand, volume wins. So Sun wants these midrange products to be successful. It's a difficult balancing act but, as always, Sun tends to err on the side of customer satisfaction.
The net result of this is that software pricing is arguably more complex than any other industry. The 100% gross margin on software means that the relationship between price and quality is tentative at best. There have been free products (including open source) that have been very high quality. And many very expensive products are what Joel Spolsky calls "consultingware": software that ends up being nothing more than a framework to be used by consultants. And, at the risk of sounding like I am patronizing my boss's boss's boss's boss's boss's boss, the net result of all of this economics lesson is that volume wins. Although a large percentage of the software market is in sales to the Fortune 100, it's really the small to mid size companies that make or break a software product. Because the small to medium market is where the cost of sales is the lowest. And because the small to medium market is were the volume is. Since the cost of printing CD's is effectively zero, every additional customer goes directly to the bottom line as profit.
More on this later this week when I post my second part discussing the real costs of software.
(2004-10-05 19:54:12.0) Permalink Comments [4]Well it's almost a month later, and I still haven't finished my article on software economics. I've been busy, as always, but I've also had some recent changes in my job that have been distracting me. More on those job changes tomorrow.
But since I don't think I'll be able to finish my article in the foreseeable future I wanted to post a summary of what I had been thinking.
As a reminder, this article was to be a response and follow up to Bryan Catrill's recent post.
As Bryan Catrill pointed out one of the interesting aspects of software economics is the fact that the gross margin of software is effectively 100%. (Although I'll debate this somewhat in part two.) This has all kinds of interesting consequences, many of which Bryan points out in his original article.
One of Bryan's points is that an existing software customer is relatively price inelastic. In other words, once they are locked into a vendor, they will generally continue to buy regardless of changes in software price. The exception being if the software cost exceeds a the cost of migration: what Bryan terms the FYO point.
In contrast, however, customers that are not locked into a vendor quite be quite elastic in response to price. There may be 100 companies willing to spend $10,000 a CPU for your software, 400 more willing to spend $2,000 for your software, 6000 willing to pay $100, and 100,000 more willing to use it if it were free. So software vendors have the choice of either charging everyone $10,000 per CPU (in which case you end up with a niche high end product and only one million in revenue), $2,000 a CPU (you end up with more customer, but the same about of revenue), $100 (less revenue, lots of customers.), or even offer the product for free and try to make revenue offering consulting and support to the large group of customers.
Further complicating this issue is that the cost of sales and customer expectations will also change as you change the price point. If you have a $10,000/CPU product, your customers will expect hands-on attention from a sales force, long evaluation periods, analyst coverage, and 7x24 support. If you charge $100/CPU, customers will expect a lot less: they will buy over the web. They will have lower expectations of support and services. Evaluation periods will be short. This is only natural: companies are are trying to avoid getting locked into the situation that Bryan describes. A $100 investment is a lot easier to abandon than a $10,000 investment. But the net result to vendors is that pricing not only affects the revenue you make from a product, but also how your product is perceived and purchased.
There was a discussion on the Joel on Software forums about this. Joel writes about the fact that customers will sometimes avoid less expensive products because they are perceived as "cheap". He also talks about certain price thresholds. Under $500 and your product can be bought by a low level manager on a corporate credit card for departmental use. He also says,
[A]s soon as your price gets up in the $3000 level, the amount of approval it needs is so absurd that you are not going to sell products without a salesperson making a few visits. Hiring the salesperson, sending them out to make presentations, hotels, airfare -- now it costs $50,000 to get the sale done just in sales closing costs. That's why you see a lot of software products at $100,000 and a lot under $3000, but anywhere in-between and it's impossible to make sales.
This really resonates with me because Sun Java Web Server has a list price of $1,495/CPU and Sun Java Application Server Standard Edition has a list price of $2,000 per CPU. Which makes a lot of deal sizes in that five figure range that Joel warns about, and I've seen the challenges that price range brings. It's hard for Sun to justify putting me on a plane to do a demo for a potential $10,000 deal. But on the other hand, volume wins. So Sun wants these midrange products to be successful. It's a difficult balancing act but, as always, Sun tends to err on the side of customer satisfaction.
(2004-10-05 06:51:39.0) Permalink| « October 2004 » | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 7 | 8 | 9 | ||
10 | 11 | 12 | 13 | 14 | 15 | 16 |
19 | 22 | 23 | ||||
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | ||||||
| Today | ||||||
