Tightening the Definition of SaaS and Cloud

I've recently been exposed to two vendors offering "cloud" and "SaaS" options to replace two in-house legacy enterprise/corporate (not customer facing production) systems.

In this process, I connected some mental dots that there are really a few flavors of SaaS, and the distinction is quite important with respect to enterprise architecture.

The two service offerings can be roughly thought of in this way:

• The offerings were touted as SaaS and cloud
• New software that is better than our current in-house legacy systems (regardless of whether we host or they are "in the cloud")
• The software is hosted by the software provider, unknown what type of "cloud" IaaS is under that provider, if any (perhaps just virtualization in their own DC).
• The software instance is spun up by the provider specifically for us.  It is a copy of the software, dedicated to us.
• The software can be extended a lot - add-on modules can be activated through configuration changes, bespoke modules/code can be added.  Kinda-sorta like a pick-and-mix or evolving PaaS model
• Software upgrades must be rolled out with associated consideration of any bespoke changes that have been made.
• Security restricted to only be available within your corporate intranet
• Flat monthly rate per user charging model with volume (# of users) price breaks

As the two service reviews went on, the dots finally connected, and I realized I had been *marketed* too more effectively than I'd like to admit.

The above isn't "cloud" or SaaS, at least not with the definition I'm going to take here.  It is actually a hosted managed service offering (MSP or ASP).  At best it's a halfway-house to cloud and SaaS.  All you've really done with this approach is shift some techops and infrastructure responsibilities from in-house to the service provider and reduced your in-house economies of scale (assuming you have to maintain those skills).

For something to be a cloud/SaaS offering in my terms, here is what it needs to be:

• Public Internet facing
• One centralized installation shared by many customers
• Powering the service is an IaaS
• Can quickly scale up/down with virtually no cost to make the change (costs changing proportional to increased/decreased usage)
• Horizontal fault tolerance design (HW redundancy becomes irrelevant)
• Focused offering
• Service addresses a specific functional requirement, it isn't an omnibus offering
• Vibrant user community making suggestions of how to improve the product
• Quick time to market for new features
• Strong product management and vision
• Product improvements put live appear immediately for all customers
• One exception: "beta" version may be option in by the customer, but certainly under the customer, not vendor, control  
• No rolling upgrades for each customer once a new release is ready
• A complete set of APIs ("API as a storefront")
• Almost all functionality available via the application is available via API
• Well documented
• Hardened (API security, rate limits, et al)
• Ready for mash-up integration with other focused offerings
• Usage based billing
• Proportional to amount of computation, storage, and connectivity you use (IaaS transparency)
• Additionally factoring in the value of the SaaS itself
• No billing related to seats, users, or CPU cores

In noting the difference between the two, I'm not advocating one or the other.  The choice of course depends on circumstances and strategy.  I'm also making no effort to address the common enterprise concerns of cloud such as security, data ownership, and business continuity.  However, I do have a very strong view which way the IT world is going and given the choice, I know which I'd select.