Steve’s latest post on Sun opening up JES reminds me a trend I’ve been seeing and theorizing about over the past year. The case of the disapearing sysadmin.
Software is Worthless Without People
Here’s the excerpt that stoked my memory, with emphasis added:
One of [Sun’s] customers, used to having Jonathan’s home # for support, suddenly discovers that the software he’d been paying for is now available for free, and says “HA! I’m not paying you $500K for something that’s free!” The punchline, of course, is that upon discovering that they’d essentially be on their own not if – but when – something goes wrong, they add it right back on the PO.
Distilled down, this says that the value in Sun’s software is shifting from the bits to the services and support layered on top of it. That’s a bet that a lot of folks within the software world are making right now. Is it the only way to make money in software? Nope. Is it going to be the dominant pricing format? Not in the next year or two, probably, but longer term? Maybe.
I don’t know if it’s literally true that Sun does not have a customer in the world that runs an unsupported product in their datacenter, but figuratively the point is made: enterprises want problems with the software to be someone else’s problem. Therein lies opportunity, as they say.
In the support I’ve done for the past few years, I’ve noticed that it’s a rare find to get a systems administrator or DBA on the other end of the phone. The software we build is a systems management application: it’s a sort of sysadmin in a box. (The company has been expanding up the corporate ladder, but that’s another story.)
As with most enterprise applications, there’s a whole lot of whirling bits and blinking lights under the covers: an application server, a database, a web server, and all the little glue in-between. The other “exciting” part of the application is that it’s whole goal in life is to interact with other computers and applications, sucking out monitoring data (the digital answer to the question of “hey, how you doin’?”).
Now, whenever one computer thing talks to another computer thing, all sorts of problems and errors occur, and you need a person to sort them out. Usually, this “sorting out” means setting some configuration, adding some permissions to an otherwise restricted device, or cleaning up after a messy application. It’s the kind of thing that’s obvious to a person, but completely baffles a computer. (Technically, to say it “baffles” the computer is to be way too kind in anthropomorphizing the computer.)
The Vendor is the SysAdmin
The job of sorting things out for the computer is the purvey of the systems administrator (a sysadmin) or, in the case of a database, a database system administrator (a DBA). In the “the old days,” a vendor could sell some tool software to a customer, the customer’s system would need some sorting out to get the software to run, and the vendor would get ahold of the sysadmin or DBA and say something like “yeah, you need to switch over your primary hoopty-ha to accept tokens with goo-gazits,” and the sysadmin would say, “oh yeah, they disable that by default. Will do. Switching over the hoopty-ha, boss.”
And it was fixed, and your support call lasted 5-10 minutes.
Now, I never lived in such times. I live in the age of the disappearing sysadmin: there are very few sysadmins (as I envision them) in corporate American anymore. My theory is that customers are looking towards enterprise vendors to not only sell them the raw tools, but also all the servicing. This is Carr’s world of “IT doesn’t matter”: you don’t staff up experts in areas that are out-side the core-compentency or domain of your company. To do so would be to waste money, ’cause they’re not going to do anything to differentiate you from your competitors. If you’re an insurance company, you don’t get a bunch of expert IT wonks to keep all your computers happy: you get a bunch of genius risk assessment experts, marketers, lawyers, and those people who come up with all those byzantium policies.
A la carte Sysadmin
Instead of paying for those wonks, you pay an enterprise vendor a shit-load of cash, and call them up whenever something goes wrong. This works out well for you, because IT vendors (now-a-days) are desperate to keep customers and will do anything to keep them. That is, you can usually get them to do things like sit on 5 hour support calls to get your afore mentioned hoopty-has all goo-gazited up correctly. And, you know, you don’t have to worry about maintaining your own cranky stable of IT wonks: not to mention not having to pay all the ice berg “overhead” like health-insurance for them. Nope, you just pay that one fat bill every few years to your vendor.
Vendors: Get Some Sysadmins
What this means for enterprise vendors, of course, is that they need to start staffing up for these expectations. As time goes on, customers will be expecting more and more sysadmin support from vendors, if they haven’t already. Many vendors probably have the belief that their programmers — the people who wrote the enterprise software — can fill this role. That’s far from the truth though: the skill-set of a good systems administrator and that of a good programmer are rarely in the same person.
More importantly, you probably haven’t hired with this in mind, so you can’t just dump the sysadmin role on your programmers. (I mean, you can try, but your customers will stop being so happy to send you checks after they get shitty service, and some of your programmers, longing for the Divine of the Abstract while they’re wallowing in the icky-goo of a sysadmin’s tasks, will up and leave.)
The Software as a Service Angle
The whole web-based SaaS fits with the vendor-as-sysadmin trend to a great degree: with “nothing” to install but a web browser and maybe a simple desktop app (think of Flickr as a good model for this with their web based app and a simple Uploadr thick-client tool), you don’t really need a legion of IT wonks to take care of the boxes that your enterprise apps run on. Nope, you just fire up the web browser, and any errors you see are completely in the court of the vendor you’re paying for that web app. You couldn’t even sysadmin the app if you wanted to: you don’t have access to the computers the app runs on.
From the vendor’s vantage, offering SaaS has the potential to save money: it’s much easier to troubleshoot problems on your own systems than you’re customer’s systems over the phone. Not to mention you can actually be pro-active in fixing problems and preventing them from occurring (everyone who’s done any enterprise software support has the story of the customer who did something like edit a configuration file, delete a vital file, or otherwise do something a long-beard would roll his eyes at).
Selling Software and Service
One customer once told us, “we evaluated your competitors, vendor A, B, and C. In the end, you were all more or less the same: we could easily fit your app into our business process [not the other way around, you’ll note –Coté]. But, you guys had the best customer service, so we went with you.”
That is, the software on it’s own wasn’t the major differentiation, it was the software combined with the service. More importantly, the value, in this case, shifted more towards the service than the software. As Steve points out, this means you can open source (or “give away” from the perspective of the money-folks) your software and still make money.
This probably isn’t true for every vendor right now, but I’d wager a few bucks that they’ll go that way soon. Hell, they used to just give the software away with the big iron. It wasn’t ’till later that we injected value into the software itself. It’ll probably take another few decades before the cycle comes full circle and software, once again, becomes second fiddle to the service, and other goods, the vendor provides. That is, the enterprise software market will become a conversation.
Update: the SaaS strategy that Ray Ozzie’s “The Internet Services Disruption” memo talks about fits nicely with the above as well.