“Huh?”, I hear from my friends, ”SaaS (Software-as-a-Service) isn’t for all Enterprise Software?” Let me explain.
This has been something I’ve been talking about from “the beginning“, but never got around to putting it up here for discussion. I was finally prompted by a conversation I had over dinner with Richard Goering last week at the EDP Symposium and Workshop. I could tell that he wasn’t expecting this perspective from me, and his question was a follow-up of what I’d said in my presentation earlier in the day.
The reality is, the world is not as as straight forward as some would have us believe - especially in some markets. Thousands of software applications have characteristics that create barriers so high that delivery in a “salesforce.com“-like SaaS manner doesn’t make sense. At least for a long time.
Now that we have a clearer definition of what SaaS is within the Cloud Computing stack, and we have a fuller understanding of the use models of software applications, we can more clearly see and articulate the nuances, layout the challenges and reasons why SaaS doesn’t make sense all the time, and what the alternatives are.
Software-as-a-Service Characteristics
Firstly, starting at the beginning, here is the Cloud Computing stack (I’ll go into more detail in a later post).
Cloud Computing Stack
The top layer, SaaS, today includes applications such as CRM , online docs, tax preparation, social networking, etc. The characteristics of this layer most relevant to our conversation are:
- These applications were written from the beginning to be web-based
- They are applications that deal with what I consider the outer-circle of a company’s IP (a Rolodex, business processes, for example)
- They do not require interoperability with any other software application or data
- The user interface is consistent across all users
- In the main, these applications were created by market segment newcomers
Platform-as-a-Service Characteristics
The second layer, Platform-as-a-Service (PaaS) is a bundling of compute resources, storage facilities, datasets, an integrated development environment (IDE), and some proprietary APIs. The characteristics for this layer are:
- Tools to develop, debug, and deploy new software applications
- You have to use the infrastructure of the PaaS vendor
Enterprise Software Requirements
When we step beyond the “safe” outer layer of IP and start dealing with the “crown jewels” of a company, what do we find?
- An installed base of millions of lines of code that has been used for years or even decades
- Applications that work with (or are used to generate) a company’s core IP
- IP protection concerns vary
- Applications that are part of sophisticated and complex flows of third-party applications and databases
- A varying degree of customization in order to meet customer-specific work flows, data formats, and other internal “standards”
- Vendors with shareholders and investors that base their investment upon expected business models and revenue streams
The Rub
All of the above enterprise software characteristics present challenges to a company in moving to a SaaS model. However, the most crucial aspect of this list is that it’s not all one-sided. If the list were purely issues for the vendor or the customer, then a straight forward migration can be imagined due to simple market forces. But when both sides of the purchase equation have reasons to stick with the status quo, migration is stymied to the point when only a really large economic imperative causes the shift to occur out of necessity…or it takes a much longer time for the natural migration to occur. It took Salesforce.com about 10 years to go from being an ASP startup to a $1B SaaS company. Even though the rate of change is increasing, we’re still talking about a while. Don’t believe me? Have you taken a look over a bank tellers shoulder recently? Or an airline booking agent? Surprised to see the DOS app running there? It’s running in a shell, but it’s still DOS.
Having said that, the transition will occur. The question is, “How?”. It will be a while before companies go out and rewrite their software to be “pure-SaaS”. In the meantime, we need to look to scenarios where a move to the cloud makes sense, and we need a different type of SaaS to support the move. Let’s call it “Hybrid-SaaS”.
The Move
I don’t think there’s any argument that we have an economic imperative and cloud computing is very attractive. So the pieces will eventually fall into place, but what will that transition look like? Here are two plausible scenarios:
The Little Guy
This would be a small company with a limited sales channel and a need to find growth somehow. So they’d be more willing and able to explore mixed business models easily differentiating between product brand, level of service, market segment, or geography, etc. If they have a differentiated product, great, but if they’re competing with an incumbent the agility of a Hybrid-SaaS model may provide them an edge in penetrating “the long tail” of a market.
The New Product
This is a new product within a large and established company. The scenario is exactly as Geoffrey Moore described in a presentation I attended a few weeks ago. Although the large company has a strong and established sales and support channel, the challenge to the new product is that it is essentially ignored. The new product is risky for the sales organization as it could sour a relationship if something goes wrong, and that could impact existing business. Also, the new product is not likely to be purchased “in volume”, and so the return on what would be a hard and long evangelical sale is not there. This scenario kills new products and hinders large companies moving into new market segments. Another opportunity for “Hybrid-SaaS”
There are more, but this will do to get us started.
Getting Started
So now we have a couple of realistic scenarios in which a company or a business unit would consider moving to the cloud. The economic imperative is established, but so many hurdles remain. In a later post I’ll go into more detail (this is already getting way too long) of what Hybrid-SaaS looks like, but for now, let’s break down the problem and go back to our friend Geoffrey Moore. This is the Technology Adoption Curve, it’s inevitable, and we need to start somewhere.
Hybrid-SaaS
If we were to put software into the cloud, what would the solution need to look like?
- No re-write of the product code
- Easy installation of the software as-is
- Zero IT overhead
- Cloud and data center agnostic
- Manageable by marketing, sales and applications engineering
- Easy, secure, and manageable access for customers
- No change in licensing mechanisms
- No client-side installs
- Scalability across an entire market
- Collaboration tools
- Management tools
The solution needs to meet these requirements technically. Because we’re not going to re-write our code, we need to start at the infrastructure layer (IaaS) and build up.
We also need to look at some early adopter use-models. Scenarios that get value out of the cloud in a way that is in line with business objectives.
How do we leverage the Cloud?
Using the cloud and monetizing the delivery of software via the cloud may be too much of a challenge initially. IP is still a concern to many customers. Business models need to be tested, etc. However, there are ways that the cloud can be used to materially impact a business, increase revenues, lower the cost of sales, and shorten the sales cycle. Here are some of the usage models for when your software is on the cloud in an environment that meets the above requirements:
Pre-Sales
- Lead generation
- Self-qualification
- Self-education
- Training
- Evaluations
Post-Sales
- Account penetration
- Self-education
- Training
- Upgrade campaigns
Development
- Third party collaboration
- Beta testing
- Focus groups
Using the cloud in this way, value is extracted and existing business models are maintained and actually enhanced.
Fundamental to all of this activity is a deepening of the engagement between the vendor and the user. From this point we can begin to approach the chasm with a greater understanding of what life on the other side should look like for both sides of the vendor/user equation…because it’s not straight forward.
Posted under Xuropa, industry
The Economist this week published an article (Tanks in the Cloud) that talked about an attempt to fill in the cloud market knowledge gap left by industry analysts such as Forrester Research. The problem the analysts have is that the further down you go in the Cloud stack, the less forthcoming companies are in divulging their revenue numbers. Companies say even less about the number of servers they have in their data centers (which is where the tanks come in).
