Chris Hoff has a new post over at Rational Survivability where he attempts to make sense of when a SaaS solution should or should not be considered “cloud.” In his analysis, Hoff atttempts to strictly apply NIST’s cloud computing definition to various types of SaaS offerings (say hosted email vs. Salesforce.com).
I think that this approach, while intellectually interesting, is perhaps a bit off the mark. While NIST’s framework for cloud computing is generally accepted on the surface, the lower-level distinctions they make may not be so universally agreed upon. A perfect example of this is contained in this NIST “essential characteristic” of cloud computing:
Location independent resource pooling. The provider’s computing resources are pooled to serve all consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. The customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.
This is the one NIST cloud characteristic that most mixes requirements of users and providers – and applies most to IaaS and perhaps PaaS solutions. How a SaaS provider manages their internal infrastructure to provision an on-demand, elastic, metered and internet-accessible application is irrelevant. SaaS need not be built on IaaS foundations to be considered a cloud computing service.
NIST aside, I think that the bigger issue is whether, from a business perspective (vs. technical), the following question from Hoff has any meaning:
If a SaaS offering is not built upon an IaaS/PaaS offering that is itself characteristically qualified as Cloud per definitions like NIST, is it a Cloud SaaS offering or just a SaaS in Cloud’s clothing?
If you are a CIO, CEO or other executive tasked with choosing between solving your requirements with in-house software & systems or a SaaS solution, does how the SaaS solution is architected internally really matter? I’m assuming that the technical requirements that do matter to the buyer – functionality, scalability, reliability, etc. – are addressed adequately, of course. Beyond that, why do I care if the underlying technology meets NIST’s cloud definitions for IaaS?
The answer is simple – I don’t care. If an application meets the generally accepted pre-cloud definition of SaaS (provided generally in an on-demand, elastic, metered and internet-accessible basis), then as far as I’m concerned, it’s cloud.
Under the covers it could be running on a single IBM mainframe and I’d still call it a cloud application when viewed through the lens of the business.
And ultimately, isn’t that what matters most?
John Treadway 
“And ultimately, isn’t that what matters most?”Depends upon who your audience is. If it's an end user, the answer is “perhaps,” or “absolutely” even.If you are an architect, a security professional or someone being held to a definitional nuance in order to measure SLA's, compliance or understand how an offering might affect you, the answer is “absolutely not.”These self-absorbed “the only opinion that counts is the business” approach is just as much navel-gazing as a bunch of technologists sitting around debating one another.Do you really think my audience for that post is a CEO or a CIO?Further, in case you haven't noticed, the efforts of the Federal Government are being very much guided by the NIST guidance. Those responsible for implementing, managing, governing, auditing and securing the amorphous thing called cloud do consider the things I'm talking about important.Want to know how I know? Because I was presenting to them right along side Peter Mell from NIST two weeks ago.So while I may be “off the mark,” I might suggest we're aiming at different targets.I enjoy your perspective, it's just very different than mine./Hoff
Chris – I think you may be taking this a bit to an extreme. I know that SLAs, compliance, security, etc. totally matter. They matter to technologists and should matter a ton to the business (though they are often overlooked, I know). Your post is not about any of these factors. Instead it was an attempt to create a construct for deciding whether or not a particular SaaS environment fit the definition of Cloud Computing – starting with MX Logic. Or at least that's how it reads to me even if you intended otherwise.The underlying technology is important insofar is the total solution satisfies the technical or standards hurdles necessary for meeting the governance, security or operational needs jointly defined by the business and technology groups responsible for the project. Your audience is people interested in cloud computing — and that very well may include both CIOs and CEOs. Don't underestimate your impact out there. People look to you for guidance because of your experience, position and obvious chops. And no, I'm not telling you to be responsible to CEOs when you post.The title of your post is about definitions and what kicked it off was your gut rejection of MX Logic as a SaaS provider. Might I suggest that while we may have different targets, we both need to be wary of collateral damage?John
SQUIRREL!LMAO.<eom>
Arrgh! 😀
John,Though I do not disagree with your conclusions from the architectural point of view, I do wonder if there's not a related issue of collaboration implied by this particular NIST characteristic. Specifically, does my instance of the SaaS offering limit collaboration to only my users, or can people attached to my instance collaborate with people attached to other instances? This may seem like splitting hairs, but there are real-world business implications. For example VMS (Vendor Managed Services) requires collaboration between persons from different companies. A true SaaS VMS application would allow me to track my people's time while they similtaniously report appropriate data to the client or vendor for approval in their instance. I need my data to be secure to me, but the data that needs to be approved should be shared with the appropriate accounts. The end result is the client or vendor gets what they need and so does the service provider while maintaining their own instances.An analogy borrowed from social networking is the difference between Facebook and Ning. Everyone on Facebook is their own “instance” and can connect to anyone else where Ning is a collection of social networks with each as a silo of users. Though Ning will let you join as many networks as you want, you must post separately to each.Just my two cents…