One of the trends I'm seeing lately with start-ups I work with and in general is the idea of multiple models of software delivery. As the name suggests, the delivery model is the way in which software is delivered to the user. Here's a fairly comprehensive list of the range of delivery options:
- Sell CDs for installation on premise (yes, companies still do that - especially gaming)
- Make software available for download for installation on premise
- Make software available on-premise via a physical appliance
- Make software available for on-premise via a virtual appliance
- Make software available for installation as an internal cloud
- Make images available for installation in an external cloud
- Offer software in a dedicated hosting environment (sometimes referred to as Virtual Private Cloud)
- Offer software-as-a-service via a client application
- Offer software-as-a-service via a browser-based GUI
- Offer software-as-a-service via an API
Increasingly, software companies are facing a dilemma as to the best delivery model for their business and many are opting for a "multi-delivery" model or multi-modal software delivery. A typical scenario is the vendor will offer the software both for installation on-premise and as an on-demand service. Wordpress and Atlassian were early pioneers of this approach, with the latter offering products such as JIRA, Confluence and Crucible for both download and as a hosted solution. And on the big vendor front, Microsoft is pursuing a Software+Services strategy.
Another common approach is offering the software for installation on-premise and as an Amazon Machine Image (AMI), and often with a corresponding pay-per-use pricing model. GigaSpaces is one company pursuing such a strategy, as are larger vendors such as Red Hat.
Vendor Considerations for a Software Delivery Model
As we continue to figure out the bold new world of marketing cloud computing, the delivery model is a key question. The answer varies by the vendor's analysis of the future of their product category, particular situation of the vendor, the nature of the product and marketplace conditions.
Here's a closer look at these considerations with some accompanying examples.
Marketplace Considerations for Software Delivery Models
The first question to ask is: Do we believe that in our market the cloud delivery model will eventually become mainstream? If so, within what time frame will it hit critical mass? And what are our own adoption and revenue expectations (and constraints) for that time frame?
The definition of critical mass is subjective. Let's look at the problem from the perspective of large incumbent vendors, ISVs with existing on-premise business models and new entrants, i.e., startups.
Large Incumbents
Incumbents, whose current business model is based on generating revenues from an existing on-premise delivery model (whether upfront or subscription pricing), face a classic innovator's dilemma. Although they may believe that eventually the market will move to a cloud model, it may be years before the adoption level will be such that it will significantly impact revenues. However, if the market is going in that direction in what time frame and at what level should the company invest in the new model? If the company underestimates the speed in which the cloud market will develop, it may suffer losing ground to young upstarts (as was the case between Siebel and Salesforce.com in the CRM market).
But incumbents face significant resistance in moving to a new model because of potential conflict with existing revenue sources. There might be pushback from the sales force, whose livelihood depends on commissions from large upfront license sales. There may be issues of revenue recognition, which favors upfront, and even subscription models, over pay-per-use pricing. They may face shareholder and analyst expectations for revenue and profit growth that conflict with the new model.
Given that it is very difficult to predict the odds and the rate of new technology adoption, companies need to assess the risks of making each move.
With incumbents, we have seen different approaches that suit their markets and their situation. Oracle, on one extreme, has famously derided cloud computing and made little investment in that area as compared to other large vendors. This makes perfect sense. First, it is in Oracle's interest to maintain the status quo given its extremely profitable business model in which all the risk lies with its customers. Second, as Oracle sells mainly infrastructure and applications to large enterprises, and makes most of its revenues from recurring support and maintenance fees on existing installations, that cash cow is not going to run out of milk any time soon. Third, if any newcomers grow large enough to take a piece of Oracle's pie, they can always buy them, as they have done repeatedly and aggressively. MySQL anyone?
Microsoft, as already noted, has taken a different tack, much more conciliatory toward the cloud with a hybrid approach. This is because many of their revenues are actually from consumers and small-medium businesses as well as developers, all of whom are moving to the cloud more rapidly in certain areas. This is a threat across many of their cash cows, including Exchange, Office, SharePoint and the many .Net and infrastructure components. The level of aggressiveness in which Microsoft is moving these different products to a cloud delivery model seems to correspond well with how important these products are as current cash generators and how rapidly they think the movement to cloud will be in these various categories. So note the slow movement on Office Live, and the rapid movement on infrastructure with Azure, Exchange Online and SharePoint Online.
On-Premise ISVs
Small and medium ISVs, who already have ongoing business with on-premise software, may face the toughest choices, depending on how much cash they have on-hand and their current rate of growth. If, on the one hand, they have little breathing room and the ability to make significant investments in an on-demand delivery model, and on the other hand, their market is rapidly moving in the direction of such a delivery model, prospects are bleak. So they need to either raise the additional funds to make the necessary investments, or entertain the idea of an acquisition, even if conditions do not seem ideal, as this may be the peak of their value.
Failing to act quickly will result in the decline of growth and loss of business to startups free of the baggage associated with an existing on-premise model.
If the necessary investment is made, ISVs need to be fairly aggressive in transitioning their revenue model from on-premise to the cloud.
Startups
Most startups don't face potential conflicts with an existing business model, but they too must take the time horizon of adoption into account. They will require different levels of industry adoption if the plan for success (however that's defined by management and the investors) calls for $6 million in Year 3 revenues as opposed to $20 million in that same year, for example. It also depends on the amount of money the company has raised (i.e., how much breathing room does it have), and the appetite the investors and management have for risk and the potential need for additional investments.
As a case in point, take a look at two companies in the same Application Performance Management (APM) product category: New Relic and AppDynamics. Both companies were founded by ex-Wily Technology executives (acquired by CA), and both seem to have set out to disrupt their own previous creation and update APM for the new, cloudy world.
There are many differences between the two products, but for the purpose of this post, the key is in the delivery model. At least for now, New Relic chose a pure cloud delivery model (SaaS) and AppDynamics opted for an on-premise delivery model (software needs to be downloaded and installed).
Clearly, the management teams of these two companies have very different views on the future of the market, or at the very least, on the rate of adoption of the cloud delivery model. It will be interesting to see how things play out between these two.
Interestingly, New Relic started with the Ruby-on-Rails market, which as I have written before, tends to be an early adopter of cloud computing. New Relic has recently ventured into the Java market. AppDynamics started with targeting the Java and .Net markets, both representing much larger, and consequently, more conservative markets. So far it seems that New Relic's bet is paying off, but admittedly they released their product earlier than AppDynamics.
Operational Considerations for Software Delivery Models
The pure cloud delivery model is very compelling from a software development and operational point-of-view. The company that delivers its software as a service (via a browser or an API) only needs to support a single code base, and can perform a lot of "magic" (such as auto-scaling) thanks to the tight integration between the software and the infrastructure, which it has selected and fully controls.
In contrast, the software company that sells on-premise products usually needs to support a wide range of environments and platforms including hardware, VMs, operating systems, databases, application servers -- and multiple versions of each at any given time. This multi-environment support is not only costly, it is prone to problems. It also slows down innovation, because each release of a new feature or version needs to be developed for and tested on multiple platforms and combinations of platforms.
An on-premise company could limit itself to a narrow range of supported platforms, or even to a single "stack" -- and all software companies do in fact limit themselves in some way. But by doing so they are forgoing a certain portion of the market. They face a difficult trade-off of a small addressable market versus an unwieldy product.
The cloud delivery model, however, is not free of its own unique challenges. The most notable challenge being that the company has to run the service itself. This means dealing with a whole set of considerations -- at the IT operations level -- that on-premise software companies do not have to deal with, such as building a multi-tenant system that can scale, is reliable, secure and continuously runs at acceptable performance to customers with a wide range of requirements. In short, the company that delivers software-as-a-service, needs to deal with the infrastructure -- and that's no trivial task.
Thankfully, cloud computing itself alleviates some of this challenge. The whole point of cloud computing, and specifically infrastructure-as-a-service as envisioned and implemented by Amazon, was to reduce much of the complexity of managing the infrastructure (not to mention eliminating the need to procure and configure it). So it's no surprise that companies such as Heroku and Twilio actually run their own platforms-as-a-service on Amazon's IaaS (but transparent to their own customers). A little "cloud-on-cloud action", if you will.
In essence, they are outsourcing -- or should I say cloudsourcing -- the infrastructure. To be fair, this does not completely eliminate the need to deal with complex operational issues, but it certainly reduces much of the challenge and as mentioned above, even creates opportunities for competitive advantage.
An interesting case study is Engine Yard. The company, which like Heroku, offers a Rails PaaS, initially ran its own dedicated infrastructure, which it (and its investors) heavily invested in. When Engine Yard started its business, Amazon Web Services and cloud computing in general had not quite reached the level of popularity -- and hype -- that they have now. But that quickly changed. In addition, Heroku had launched its own EC2-based service, and presumably Engine Yard needed to respond to market conditions, as well as what one can only assume, the internal operational pressures it was feeling from running its own infrastructure.
In January 2009, the company launched Engine Yard Solo, which offers the EY RoR stack running on a single Amazon EC2 instance. Several months later, the company launched Engine Yard Flex, which also runs on AWS, but allows running an application on more than one EC2 instance. Today, after a bit of name-changing and repositioning, the company offers Engine Yard Cloud, which is essentially what was previously named Flex and runs on EC2, and Private Cloud, the old EY dedicated infrastructure, clearly aimed at larger customers with a Fractional Cluster (slice) option that starts at $4,000 per month and Dedicated Cluster option which starts at $20,000 per month.
Business Model Considerations for Delivery Models
In theory, both pure on-premise and pure cloud delivery models should be able to pursue any business model; in practice, they can't. Let's break-down "business model" into some of its components and take a closer look.
Pricing Model
There are three basic pricing models: upfront perpetual license, subscriptions and pay-per-use. The latter -- pay-as-you-go or utility pricing -- is the model that most aligns the interests of the vendor with those of the customer. The upfront license model actually puts the interests of the two parties at odds. It is for that reason that I -- and many others -- believe that the software industry is moving towards pay-per-use across the board.
Although not impossible, a pay-per-use model is very difficult to implement with on-premise software. It would require some kind of metering technology which would have to "call home" with billing information. Not completely unheard of in the software industry, but something that significantly complicates things.
Software-as-a-Service, on the other hand, can easily implement a pay-per-use model (as well as the other two models). So I believe that over time they will be increasingly exposed to competitive pressures on the pricing model, putting them at a serious disadvantage.
Using New Relic pricing as an example, they provide on-demand pricing based on hourly usage, a monthly or annual subscription based on number of hosts, as well as an all-you-can-eat package (essentially, an upfront license) for their enterprise customers. AppDynamics will be hard-pressed to match this flexibility.
Another great example for the power of pricing with an on-demand service is Heroku. Besides the fact that their pricing page is beautifully designed, it demonstrates the flexibility of platform-as-a-service pricing -- and perhaps more importantly -- how easily one can add and remove premium features and scale the application.
Customer Acquisition
The software industry, including in the enterprise, is rapidly moving away from the top-down sales approach to customer acquisition via a bottom-up adoption model. A successful bottom-up adoption strategy is all about streamlining the on-boarding process and removing any barriers so that individuals can try and buy the software (or service) with very little need for approvals, budgets and resources. Clearly, a software-as-a-service delivery model helps in removing many of these barriers.
If the organization relies on large top-down sales, and is convinced that is the right model for it to thrive, then it actually wants to construct some barriers for bottom-up adoption, in order to force a top-down decision at some point. An on-premise delivery model would be the clear choice in such a case.
Multi-Modal Software Delivery
As mentioned in the beginning, many software companies are choosing -- for a variety of reasons -- not to make the decision of software delivery model a mutually exclusive one, but rather use multiple delivery models. Among the big vendors, Microsoft is the most outspoken on the topic, trying to balance its current cash cows with the increasing competition from Google and other cloud and SaaS providers.
But what's been interesting to me is what startups have been up to. The trend is particularly noticeable among open source companies, which is part of the reason why following a podcast with James Urquhart and I, Matt Asay asked if cloud computing is a natural conclusion of open source.
One of the companies I have been consulting on strategy and marketing for, Sauce Labs, is the classic example of this trend. Sauce Labs was founded to be the commercial company behind the popular open source testing framework Selenium. It pursues both the classic "open core" model of providing commercial support for and premium editions of the open source versions of Selenium via a subscription pricing model, as well as providing a cloud service, what they call Sauce OnDemand, which enables testing with Selenium using a software-as-a-service model.
I believe we will see this trend growing, as it provides open source companies (and software companies in general) a much better fit for the bottom-up adoption model, allows for a much more scalable, higher margin business -- and aligns perfectly with the customer's needs and interests (the onerous of reliable software is on the vendor, not the customer).
As always, a new approach also brings new challenges, and in a sense, pursuing a multi-modal delivery model suffers from the downsides of both approaches -- have to run service operations AND maintaining multiple versions of on-premise software.
What are your thoughts on delivery models? If you're a vendor, have you had this dilemma and are there other considerations -- for or against -- which I left out? If you're a customer, what would you like to see vendors do?
Any other thoughts or examples? Please leave them in the comments below.
Recent Comments