Haut Tech

There has been a lot said about the “maturity levels” of SaaS – so much in fact that the concept is becoming meaningless. Are we looking at it from the customer’s point of view? The ISVs business side? or their development side? or are we thinking like a supplier to the ISV? A hosting, platform or component provider to SaaS ISVs? Without some context – the whole discussion is an exercise in “analyst-speak” to put it kindly.

If the discussion is to have any value – it needs to help in some way to clarify the choices that an ISV or start-up entrepreneur has to provide their application as a service. So, let’s put some context in place. Consider an ISV who wants to offer a SaaS product needs to develop and launch, react to a very fluid and competitive market, continue to please customers, and make money. Cross out of this discussion all those who are not forced to make at least some money on day one or even by day 365 X 3. That removes Google and a number of the industry poster children that are propped by VC funding while they “explore profitability.”

So what are the options?

Level 0 – If the ISV has a premise-based product in the market – or just wants to get a product out the door no matter how quick and dirty the process might be – they can opt to simply put up an instance for a customer to access on a server somewhere. Let’s not quibble over whether that takes one server for every customer or if one server can handle three customers – because in the end it is truly an “it depends” kind of situation. How much CPU and memory does the application take? How many users and how much storage does each customer use? Are they roughly the same or different every time? How much of the time are they connected to the application and how many transactions do they run an hour?

This approach is often used to capture a few customers who really want an on demand product NOW, to get a product out into a new market, or just to test how well it might sell. But – it doesn’t scale. Every customer needs a new instance of the server (or every so many need one). Each instance depends on the reliability of that individual server, its maintenance, usage, age, etc. The only way an instance can be ready immediately for a customer when they buy is to have provisioned servers available all the time. By all rights, pricing for this type of an offering should be more than a simple licensed version because the ISV has taken on all the cost and risk of the infrastructure and services required to host the application. If a customer tries it for a while and then doesn’t renew – the ISV now has excess hardware inventory until it is cleaned out and “rented” again. New versions require that each individual server and instance be upgraded. Server maintenance and patching becomes an expensive and risky undertaking so it is often delayed. As many have said – this should just be considered as “application outsourcing” because every instance is unique.

Level 1 - This is really the old “ASP” model. A hosting provider takes on the job of sizing and provisioning servers on demand for the ISVs customers. To some degree the process or the instance is automated and virtualized, but the server and application instance is still individual for each customer. The advantage of this model is the ISV has outsourced the burden of handling servers and provisioning to someone more skilled and prepared. The hosting provider may also contract to provide first level support but most often that is still the job of the ISV support staff. This still has the disadvantages inherent in the one instance per client of the Level 0 implementation and none of the advantages of a true multi-tenant application. Some hosting providers offer additional tenant management tools for this kind of implementation. Some models say that adding significant automation to the implementation process should be broken out as an additional approach – I really think it is splitting hairs.

Level 2 - When this level broken out things can get confusing. Basically this is where ISVs start towards multi-tenancy but haven’t fully embraced it. Some providers at this level offer a common web front end with a discrete database instance for each customer. Some have a centralized database but haven’t integrated subscription management or full multi-tenancy into the application. Hosting may not be based on virtual “cloud” technology so scaling is not clean and is still manual or automated to the server level. The integration of the SaaS business operations is often minimal at this level and if subscription churn or uptake increases significantly it can become a burden. Quite often at this level there is no difference between a regular licensed version of the application and the “SaaS” version other than delivery and pricing.

Level 3 – At this point most everyone agrees that the SaaS offering is a single application on a database that is truly multi-tenant. One upgrade cycle upgrades all customers at once. The sequence from trial to customer including provisioning, implementation, payment, and subscription management is fully integrated. Customer user management is in place and handled by customer administrators. The underpinnings may be based on anything from local infrastructure with clustering to a fully virtualized cloud provider. Some ISVs at this level build their offerings in a way that allows them to provide a local installation for those customers that insist – although that seems to be dropping away in most verticals. At this level there is little room for compromise – there is specific code or accommodation to allow one multi-tenant application, subscriptions, customer/user management and full scalability. This doesn’t imply that all SaaS applications at this level are on fully virtualized infrastructure but they have reached a point where scaling is more rational.

When we get beyond level 3 the idea of maturity begins to get hazy. Some analysts say that the amount of application generalization should be the factor to consider. Does it allow customers to customize their instance without a code revision? Does it allow vertical versions or channel offerings to exist without a separate code base? Does it allow customers to adopt a suite of products on the same platform – in effect growing their subscription horizontally? I truly believe those are market (non-technical) decisions EVERY SaaS vendor should consider during product development. These are the marketing goals that push the product model to embrace The Long Tail and raise the opportunities for profit and success.

So from my own point of view – If we’re going to talk about levels of maturity beyond level 3, they should tell us something about what SaaS ISVs need to do to reach optimal operations with a time to market and cost that allows the earliest possible payoff. They need a path to provide a flexible, reliable and scaleable base from the beginning. ISVs embarking on a SaaS project need to have a chance of winning without a three year development cycle and a large, custom code base.

I would argue that at an early point in product development – components, platforms and standards need to be considered. If simple subscription management is a solved problem – why put the money, time and risk into the project to develop it again? If components ease and standardize the development of the interface or remove the need to develop a common set of routines – will it limit the product too much to use them? If a platform reduces the development to specific business logic – is it worth considering? Is your team’s interest in a new language going to provide you with an edge or does it limit the application’s ability to adapt to broad market changes in the future?

Because of the growth of web applications, there has been at least an equal growth in tools and platforms that speed and standardize the their development. Some are general in nature and some are SaaS specific. Some are backed by large companies and user bases and some are small and niche-oriented. As the recent shutdown at Coghead points out however – they are not without risk. Like when you consider a hosting provider, the risks and rewards of each offering needs to be understood and evaluated. Here are some questions SaaS ISVs should ask to ensure they are getting what they need from platforms and components:

• Does it offer SaaS specific functionality? If provisioning, billing, user monitoring, subscription management, user roles and administration are not part of what you are considering it is a web or general development tool. That doesn’t mean it shouldn’t be considered – but it does shine a light on value.
• How open and standard is it? If your developers have to learn a new language to use it or if it isolates you to the environment it lives on – is it worth the trade-off? Google Gears is a valuable environment if your application is going to use other parts of the Google or Zoho application systems. Apex is useful if your application gains value from the Salesforce community and platform. Outside of those communities – how much value are you really getting versus the cost and risk?
• What is the experience of the “community” using it? The size of the developer community is really of less importance than what their experience may tell you. Coghead had a large community, but too many were not paying subscribers. Why?
• What is the “lock-in?” There is always a lock-in, whether it is tool-centric development and training or a platform that will only operate in the hosted environment the vendor provides. How much of a risk it presents is what should be evalutated. What does the vendor offer to lower the risk? What do you need to do to migrate if the tool vendor no longer supports you? Being in the SaaS business is a risk by itself so being risk adverse to the extent you can’t consider tools and platforms to lower costs, streamline development and get a better product to market is a strategy that can sink you. Knowing your risks and planning to deal with them up front is the key.
• Will it scale with your business? If you have to buy 500 seats before you can sell one subscription – how valuable is this burden? Will it scale back if you volume changes during the year? Is the cost flat (per user), per application, or transaction? Can you build it into your operational cost?

Depending on the platform or tool there may be more things to cover – but these are the most common issues we deal with as we work with our clients. I already see more that will come in the near term as “cloud computing” becomes more accepted, but for now – looking at your options clearly and selecting the most flexible approach you can manage is the best route. You don’t have to get there all in one step – but you should have a roadmap in mind so you don’t waste time and money with dead end development.

Follow Me on Twitter