Definition Disconnect / Two Kinds of “Software As A Service”
October 17th, 2007Most of the time labels and acronyms simplify/clarify conversations. You label something, and maybe shorten it to an acronym, and it acts as a shortcut.
When I talk about “CRUD applications” or “RESTful interfaces” with another developer these terms let us skip ahead and talk about the good bits because we share a common definition.
However, in a conversation with my mom, these same terms obfuscate. Mom hears that I don’t like my work, but I’m trying to relax and maybe take up a hobby.
This disconnect is most damaging when you and the person you’re in conversation with both think you share a common definition when, in fact, you don’t. Let’s call this a “definition disconnect” and press on.
From the management team to the venture capitalists, from the developers to the marketeers, everyone in our industry is wrapped up in a definition disconnect surrounding the term “Software as a Service” that has broad implications for everything from:
(1) how you value your company,
(2) how you build your systems,
(3) how your price your offering,
and
(4) market segmentation.
Keep these 4 criteria handy as you read on.
Software as a Service (”SaaS”) is a term that is inexactly applied to two distinctly different kinds of businesses. Basically anyone whose app hosts its bits in the cloud that would otherwise have been hosted within a businesses’ network gets the SaaS label. This is flawed; here’s why:
Historically, you could split up software products into two buckets:
(1) shrink-wrapped software
and, for lack of a better term,
(2) consult-ware software
Consult-ware might be a contentious term, particularly in an post about shared definitions, but I’m using it as a stand-in for a longer definition about software that comes with consultants who tailor it to match the needs of the company that bought it. “Mass customization software” might be closer, but is hard to say. Heck, it might be enough to say that this is a consultants-vs-packaged software split. Whatever terms you use, read on:
Working backwards through the 4 criteria, consult-ware software:
(4) targeted “up market” customers
because their deep pockets supported a pricing model where
(3) a significant chunk of revenues come from customization/consulting
which requires a
(2) “platform approach” to product building
Conversely, shrink-wrapped software tends to be:
(4) mass-market
with an
(3) easily calculated price structure
that necessitates
(2) a “one-click setup” that minimizes support requests.
I’ve skipped the valuation criteria because covering that would take a bunch of space without significantly enhancing the case that these were two very different kinds of businesses. I think it’s fair to simply say the valuations of Microsoft and SAP should be calculated very differently.
These businesses are worlds apart; this division exists amongst Software as a Service businesses but is largely ignored.
The implications of this are significant, and once again fall along the lines of the 4 criteria defined above. Rather than rehash the same market analysis, which falls along predictable lines, I’ll illustrate this with some observations/pitfalls/considerations:
Many Software as a Service businesses mistakenly place themselves in the consult-ware model. This mistake arises when they embrace broad customization without having a price point (both initial price and maintenance) to support this. This tends to present itself in terms of customizing workflow applications to fit different clients needs.
Smart companies in this situation recognize this and strictly enforce a rule that customization happens at the view-level only. All clients share common models that are populated by customized views. The gotcha here is that your maintenance revenue model needs to support the significant investment keeping this ever growing collection of templates current as you release new features, refactor existing functionality, etc.
Other companies emulate the “one size fits all” shrink-wrapped approach more closely, producing a single version of their software that’s used by all of their clients. Hopefully the app is flexible enough to cover most needs of most people in the market. The common wisdom is that this’ll keep you out of the top end of the market. I’m can’t decide whether I agree with this or not; there are certainly examples of these kind of companies gaining broad up-market acceptance. SalesForce.com probably fits into this category and warrants a little attention:
SalesForce.com’s magic in moving into the top-end of the market has shades of the iPod phenom to it. With SalesForce.com and the iPod, people willingly trade away advanced features and fine-grained control for cachet/buzz. In the case of SalesForce.com, up-market clients are willingly throwing out custom-tailored sales-force automation and rearrange themselves to fit into the SalesForce.com mold.
I can’t say exactly why, but I think part of this comes from providing APIs. APIs don’t have the murkiness of customizing workflows; APIs tend to deal with the models/transactions directly; the workflow becomes the responsibility of the customer who uses the API.
I think the take away from this is that if your maintenance revenues can’t justify workflow customization that you should look for ways to adapt your application to be more transactional so that you can places where APIs are a natural fit.
An example of this from the SalesForce.com world is how they slurp leads into their system — the source of the lead, how it was gathered (the workflow), etc. is all left as an exercise to the customer. They don’t care how you got the lead — website, tradeshow, pulling business cards out of the burrito giveaway fishbowl at Chipotle — but they’re only too happy to take it into their system.
Needless to say, APIs bring complexity for your customers, but it you’re competing-with/replacing what would otherwise be installed software in the middle market or higher, your customer is likely to have a CIO who is well equipped to deal with these things. And, again, the low and lower-middle markets won’t expect much customization, so your good-enough one-size-fits-all workflow will probably be good enough.
In summary, decide which kind of business you’re in and don’t lose track of how that impacts “the four criteria.”