Cloud Maturity Models Don't Make Sense

An issue that's been roiling the cloud computing blogosphere the past few months is the notion of a maturity model for cloud computing, which I oppose. Multiple maturity models (say that three times fast!) already have been defined for a variety of IT subjects, including business processes and at least five or six different ones for SOA, alone.All of these maturity models have their roots in the well-known Capability Maturity Model Integration (CMMI), the late '90s process improvement approach that tried to provide organizations with industry-wide metrics so that they could measure the effectiveness of their enterprise IT projects. The basic idea was to lay out some milestones or, more accurately, 'stepping-stones' that IT departments could achieve as they climbed a stairway toward some idealized computing or process goal. In the case of CMMI, these steps were five maturity levels ranging from Level 1 to Level 5, which defined whether an organization is at an Initial, Managed, Defined, Quantitatively Managed or Optimizing level. On achieving the top Level 5 step, an organization could be said to have reached the "Optimizing Level," which means it was focused on continuously improving processes and product quality.

CNET's James Urquhart's recent "A maturity model for cloud computing" describes the following five stages of evolution "for an enterprise data center trying to achieve cloud Nirvana."

Dr. Dobbs's Jake Sorofman has the following five levels in his Cloud Computing Adoption Model:

Earlier this year, ZapThink's Ron Schmelzer debunked the whole idea of SOA maturity models in an essay, "Forget Maturity Models -- It's Time for an Agility Model."

Schmelzer goes on to make a persuasive argument that proposes a broader metric, based on his earlier Seven Levels of Loose Coupling, that could be used to measure the appropriate agility of a specific project or initiative. Whether or not you agree with Schmelzer, and his main point that "not all service-oriented projects need to have the same level of agility as others," much of his criticism of SOA Maturity Models can be directly applied to Cloud Maturity Models, especially if your focus is on software as a service or even capacity as an automated, self-administered service, which is what many organizations seem to be looking for in their current cloud experiments.

It strikes me as more nebulous than Nirvana, if the highest level of a Cloud Maturity Model is a measure of an organization's overall skills, policies, consistency and practices when developing cloud applications -- but your measurement isn't capable of rating specific projects. If your Cloud Maturity Models does let you rate specific projects, how do you factor in projects where cloud-less local storage (or even cheaper, slower cloud storage) make the most sense? Case in point is the real-world example I recently wrote about a cloud application that used both solid-state drives (SSDs) and hard-disk drives (HDDs) in a complementary Video on Demand application, where "hot content" that needed the fastest possible IOPS (streaming new releases or the most popular movies) relied on performance-optimized SSDs, while "cold content" that needed the largest possible capacity for storing thousands of classic movies used capacity-optimized HDDs. To quote Schmelzer again:

If SOA maturity models are ill-defined and confusing, Cloud Maturity Models make even less sense.