Amongst the mass of three-letter abbreviations (TLAs) that permeate the langauge here at Microsoft, there are two that I’ve been giving a bit of thought to in the past few weeks: ISVs (Independent Software Vendors) and CSVs (Cloud Services Vendors). Putting aside that there are over 17,000 TLAs available and we seem to be having to reuse some already, there is an interesting set of business challenges surrounding the ability for a company who is an ISV making the leap to becoming a CSV.
First, some definitions.
For me, an ISV is a company that produces software that it (hopefully) resells to more than one customer. They are different from consultancies who develop bespoke sofware in that the latter are providing services to deliver something unique (possibly incorporating products from ISVs as part of the overall set of deliverables). There is a bit of a ropey definition on Wikipedia here: http://en.wikipedia.org/wiki/Independent_software_vendor (or at least will be again when the SOPA Blackout passes).
A CSV is a company that delivers a software service via the Cloud (read: Internet). This is a little less clear-cut than the world of ISVs, because where the boundaries of a Cloud service begin and end is far less clear: is a service like SalesForce a Cloud Service? Almost certainly. What about online services like Match.com or NetFlix? It’s less clear to me. And how about a web-based company that supplies real-world goods or services (like Amazon or even Tesco.com)? Who knows…
It’s easy to get hung up on nomenclature. The important thing is that the Internet is giving companies the opportunity to use software to extend their business services in ways that have fundamentally changed the way we view the value proposition underpinning the use of software. IT used to be used to do stuff quicker and cheaper. It now also drive revenues and create new markets in ways that much IT strategy thinking can’t really still get its head around.
I recently started re-reading Clayton Christensen’s The Innovator’s Dilemma. It’s one of those books that gets bandied about in business conversations like The Tipping Point to an extent that one can forget what the heck the point of the book really was. At the nub of Christensen’s work, for me, is the idea that disruptive technologies seem to come about with product innovation into a new market that then eventually backfills into encumbent vendors’ territory. The case study he gives is of the evolution of hard disk drives, where new, smaller types of drive initially were more expensive per megabyte, but gained traction in the market by helping to develop entirely new products: 5″ drives weren’t of much interest to DEC and Wang who used 8″ drives in MiniComputers, but they helped to foster the arrival of the microcomputer from IBM and others, for example. Part of the encumbant Innovator’s Dilemma is that your current customers tend to hold you to your current technology.
In that context, how might a “traditional” ISV move to becoming a Cloud service vendor? The starting point is to look at the differences between the two:
First of all, the product propositions are very different: on the ISV side, the customer generally is buying the rights to install, manage and use a piece of software. In a CSV world, access to a set of software-based services is what is being provided. There is a whole set of expectations around service (and service levels) that are more than just time to respond and time to fix that form the cornerstones of a traditional ISV software maintenance agreement.
The cost model is very different for the customer in the two models too: an ISV product incurs capital cost in the aquistion of licences, and potentially of hardware too; there are the project change costs of time to implement (often greatly overlooked) and then there are operating costs on an ongoing basis associated with support and specialist staff. For a Cloud service, whilst much of the cost shifts into operating budgets, there is still an upfront change and aquisition cost to get up and running. From the supplier’s perspective, the revenue in a Cloud service is likely to be at a slower, but steady stream in comparison to the lumps of cost associated with selling software licences. All of this of course, though, assumes that there is some cost associated with the purchase of the licence and with the use of the service – many new entrants to the Cloud world challenge all the assumptions that the old software industry has had about how to make money.
Who a product is sold to may also fundamentally change in a Cloud services world: one of the most impactful ways in which SalesForce disrupted the CRM market was by selling their offering directly to Sales people, rather than via the IT department (IT didn’t need to be involved, said SalesForce, because there product needed nothing but a browser and an Internet connection – although many in IT governance might disagree with that). So, if a Cloud service is to be consumed by a group other than the IT department of a business, a traditional ISV might need to focus more strongly on the end consumers rather than schmoozing IT. You can guarantee that any Cloud-only entrants to their market will be cutting out the perceived IT “middle-man”.
There is, I am sure, much more that is different.
So how to make the leap? Well, especially in a world where startups can start up with next to no capital investment (as a result of the pay-as-you-use infrastructure and platforms like Azure and AWS), an ISV is likely to be in a position where a startup might be challenging them directly or indirectly. Can adopting a startup mentality be a way to try to stay in the game?
It can be really difficult for a company to be able to significantly change its business when that directly impacts on its customers. One of the lessons from Christensen is that if you wait for your customers to ask for the “new”, it will probably be too late because disruption will come from new firms finding new customers to build their businesses, and then taking hold in more established markets later. But could a new business be incubated by an existing enterprise, much in the way that, say, First Direct was incubated as an almost stand-alone business by Midland back in the 1990s?
My hunch is that to stay ahead of pure Cloud start ups, ISVs will need, at very least, to start by re-drawing their business model and then working out how Cloud technology can help rather than seeing the move to Cloud as being merely a matter of switching infrastructures. Adopting a startup approach might be a credible way to do that, releasing some of the shackles of the present in the process…