An Evolving Maturity Model for Clouds
In a post on his Wisdom of Clouds blog last week, James Urquhart proposed five phases of Cloud Maturity.
I fully concur with the phases of this maturity model, and with Urquhart's assessment of the current state of enterprise IT on the scale, i.e., most have consolidated, some have abstracted, fewer have automated, and only a handful are experimenting with metering and self service. None have achieved open Internet-based Market capability, yet.
This maturity model is useful, but I can't say I find the first four phase names, order, or definitions to be novel in any way - I've been writing these exact same phases on client whiteboards for about three years.
Maturity Model (MM) Hopping Disallowed
The fifth phase (Market) however, is new and insightful, and it reshapes the preceding four in interesting ways. In other words, if you're on a path to reach Market maturity then certain capabilities must be addressed in preceding phases that weren't necessarily required in preceding models that stopped at Utility. For example, elements of service level management must be addressed in the Automation and Utility phases that were not essential prior to the proposed model. In a pre-Market maturity model enterprise IT could deliver automatic provisioning and pay-for-use to their customer without demonstrating compliance to specific service levels. That won't fly in a price arbitraged cloud Market, so these capabilities important to the Market phase must be built in the preceding phases that correspond to the capability. Maturity models are only useful if the phases inherit all the preceding phase capabilities. If additional Automation capabilities are required to achieve Market capability, then Automation was not really achieved at phase three.
What of Elasticity?
I'm not convinced that this is a comprehensive maturity model, and whether we can fit clouds, both public and private, into one vector such as this. For instance, where does Elasticity fit? Auto-scaling relies on Automation, but would we require it of any environment claiming to be Automated? The pay-for-use implication of Utility does not necessarily mean resources are acquired and released in conjunction with use - metering is not intrinsic to provisioning, and vice versa. Whereas Elasticity, I submit, implies growing and shrinking resources synchronously with customer demand. So, does Elasticity warrant it's own phase in the Cloud Maturity Model? What are the implications of this model for private clouds? Does a private cloud ever reach Market phase maturity?
MM Drafted, Now Where's the Magic Quadrant?
In any case, the proposal of a Cloud Maturity Model is a valuable step in the evolution of cloud computing, and the Market apex of the model seems like a reasonable goal. And there is an army of consultants forming to help enterprises address the climb.
"metering is not intrinsic to provisioning, and vice versa"
I too share this view as it seems to imply that only cloud computing providers will use metering as a provision management solution ignoring the fact that customers in the cloud would eventually meter and charge back from multiply perspectives (meters) and not necessarily those that represent underlying costs from their deployed services or applications.
William
Posted by William Louth on December 15, 2008 at 03:53 PM PST #
Your observation that the first four phases described here are not really revolutionary is well taken, and in fact I'd like to state emphatically that I'm not trying for 'original' here, just 'practical'.
As to your argument that Elasticity stands alone as a phase in the model, I would argue that elasticity is very similar to virtualization--they are technologies applied to solve problems, and are not representative of new ways of managing the data center in and of themselves.
The example I gave with virtualization is that most organizations have done a great job of consolidating through virtualization, but many have not yet grasped what it means to manage the abstraction, not the machine. Go talk to sys admins in most VMWare customers, for example, and you'll find that they know exactly what physical server is hosting each virtual machine. HA and DRS do not have an overwhelming adoption rate, in part for this reason.
Similarly, elasticity can be applied manually or automatically, but the base requirement is that some form of abstraction is being managed. It could simply be instances of a presentation tier image being replicated as required, or it could be complete service architectures being scaled through a combination of infrastructure and systems automation.
Technically, an elastic application may or may not be delivered into resources shared with other applications. So consolidation may not even come into play.
In the end, when the cloud is considered, elasticity typically is a feature granted by abstraction and ripe to be automated, so it doesn't get a separate stage in my opinion.
Finally, your question about whether a private cloud ever achieves "market" is a thoughtful one, and all I can say in response is what Doug Gourlay and I were thinking when we originally sketched this out.
The model was defined in terms of enterprise computing, and our belief is that most large enterprises will create private clouds first, do some hybrid private/public stuff soon after, but seek an environment in which compute workloads can be migrated on demand to a largely open network of capacity providers **including their own infrastructure, if required**.
I would actually question if a public cloud would do anything short of utility...
Thanks for the thoughtful critique. I'm eager to hear your response to my thoughts here.
Posted by James Urquhart on December 16, 2008 at 11:32 PM PST #
@jamesurquhart Thanks for your response. This testing of the hypothesis helps strenghthen the validity of the model. It would be interesting to test the this MM (too bad CMM already belongs to another maturity model,) against levels of application development capabilities. E.g., in which level does Palette of Composible Services belong? I think your Cloud MM holds up for operational capabilities, but we may need a different one for maturity of application development capabilities. Another example: with respect to standard interfaces, how would you sort these into maturity levels: No Published API(1), Proprietary API(2), One Standards Based API(3), Mutltiple Standards Based API's(4), All Services Available Through Multiple Standards Based API's(5)
Posted by Scott Mattoon on December 19, 2008 at 04:58 PM PST #