Recently, I've been talking to clients about "what it takes" to operate IT services in the cloud. Clients have purchased substantial virtualization and cloud technologies, but in some cases they haven't put them to use, or haven't gained the expected benefits. Why? Well, technology is important but without having the right organizational structures, roles, skills, and processes established, efforts to gain value from cloud computing will be hampered if not entirely unsuccessful.
Perhaps what is needed is a Cloud Maturity Model; a framework to help organizations determine what "cloudy" things to do, how to do them, and what the expected benefits should be.
Before writing this blog, I went to the Google-machine to see what others had to offer around a Cloud Maturity Model. What I discovered was not what I consider maturity models. Most models either offered very product-centric views, glossed over infographics, or narrowly focused on certain delivery models such as Public cloud or Platform-as-a-Service (PaaS).
Growing Desired Cloud Capabilities
I want to focus purely on cloud capabilities, whether delivered public or private, IaaS, PaaS, SaaS, or other XaaS. I'll start by defining the basic expected capabilities of cloud, and the benefit each capability provides. We will want to measure and understand how mature we are in each of these cloud capabilities:
Elasticity - It's difficult to manage the fluctuating demand curve for many IT services. The "gap" between supply and demand can result in wasted IT costs. The inability to not meet demand can cause user dissatisfaction or worse (healthcare.gov comes to my mind at the moment). Traditional fixed IT assets do not scale up or down easily. Simple example: Desktop teams do their best to estimate storage needs on PCs when procuring, configuring, and deploying desktops. However, most users consume a fraction of the storage available. And in a few instances, some users need greater capacity than is available. Procuring, installing, configuring, and transferring data to new, larger hard drive, takes a long time, and can be very expensive. Meanwhile, tons of excess storage capacity on the PCs means $$$ wasted. I roll the feature of "Utility" into elasticity - acquire, use, and pay for only what I use from a service; hourly, daily, weekly, yearly, etc.
On-demand, Self-Servicing - Many IT service requests can be directly initiated by the user. Users don't want to go through layers of help desk support, or talk with three different teams to procure servers, network, storage or apps. In addition, users don't want to wait weeks or months to receive a service: requests need to be fulfilled, well, on-demand.
Ubiquity - Users can technically access IT services from anywhere, anytime, on the end-point device of their choosing. Regulations, policies, and security may require certain restrictions but that should be a business decision, not a technology constraint.
Security - Ubiquity is great for convenience and productivity but organizations need to know their data will be protected and applications will not be compromised. People need to know and trust their identity will be safe. Cloud brings additional and unique security challenges. For example, where is data physically stored and how accessible are applications and services over the Internet. Taking it a step further, will services in the cloud support continuity of operations?
Transparency - Clearly state what a user gets from a service, and how much they pay for the service. For example, users with access to a Windows 8 desktop with 32GB RAM, 500GB disk space, and the Microsoft Office 2013 will be "charged" $15/month for the desktop and an additional $6/month for Office. Business managers, finance directors and CFOs will love this type of transparency.
The Maturity Levels
I don't want a complicated maturity model at this time because I think cloud is still in it's early stages for many IT organizations. I'm not going to propose a model with 5 or 10 levels. And I'm not going to state it has to be scoped at an enterprise-level or organizational-level to have value. I believe there is value in applying a cloud maturity model to just an application, service, or set of services. In terms of maturity levels, I propose a simple categorization of Low, Medium, and High for each of the above mentioned cloud capabilities. Broadly speaking, here is what each category equates to in terms of cloud maturity:
Low: Either non-existent, limited, or not gaining any expected benefits from the cloud capability.
Medium: The capability is established and some benefits are realized, but not fully or not all possible benefits.
High: Gaining significant, tangible benefits from a cloud capability.
I realize the above categorize are vague. I was going to offer examples but I think my examples are actually proof-points that a certain level of maturity has been met. So, in my next blog entry I'll offer a draft matrix for a Cloud Maturity Model with the Y-axis listing the capabilities and the X-axis the maturity levels. Each cell will have "proof-points" for demonstrating a level of maturity along with the expected benefits or Key Performance Indicators (KPI)s. Later, I'll add steps to achieving each level by suggesting the required changes to organizations & roles, process, and technologies.