# Cloud is a state of the business, not just IT

In my last blog I posited that cloud and by extension cloud management was a strategic versus tactical activity and as such should have the appropriate people involved in definition gathering and decision making for a variety of reasons. Now, I’d like to cover several examples of why cloud management is strategic in nature and clarify why the CIO, and others outside of the purely technical staff are critical to project and solution success.

## Cloud isn’t just a more powerful engine in the same old car

For a legacy IT organization to adopt cloud solutions without significant organizational realignment and improved business participation, the benefits would largely be wasted. It’s akin to thinking you can put a modern 500-horse power engine in a 1970’s economy car and get all the same performance and protection characteristics you would enjoy in a 2012 model year luxury sedan.

In fact, the introduction of cloud without organizational improvements would likely increase enterprise risk and potentially cost. The real opportunity of a cloud operating model comes from the alignment of technical solutions, people, and process. So when a business opportunity presents itself, your processes and technology will seamlessly keep pace with the natural development of the initiative.

Keeping pace means more than just creating a new pile of IT resources quickly, it means a repeatable process that also provides the appropriate controls and governance in order to minimize risk to your business, provided at the appropriate value to the opportunity.

For those trying to figure this realignment out, here are examples of how your cloud operating model (which includes cloud management) can provide real differentiation in the way IT solutions are delivered.

## Contestability: an economic theory that can save you money

A real cloud-operating model enables you to plug in different cloud providers, different hypervisors, different hardware, different PaaS solutions, different provisioning systems, monitoring systems, etc. Through true contestability you have the opportunity of replacing key portions of your infrastructure for better or lower cost solutions, without risking the larger framework or architectural design of the environment.

• Can you use a mix of external providers such as Amazon EC2, TerreMark, Savvis, and CSC?
• Easily change from HP to Cisco hardware (or vice versa)?
• Switch from VMWare to HyperV 3 (or vice versa)?
• Can you easily adopt a new provisioning/scripting framework like chef/puppet/cfengine?
• Reuse the policy enforcement and auditing system you currently have while making any of the changes above?
• Reuse your procurement portal and provisioning workflows while achieving the above?

If your answer to these questions isn’t, “Yes, it would be easy and relatively inexpensive,” then you aren’t operating under a true cloud-operating model. Very few companies have these kinds of capabilities, because until just recently the management platforms needed didn’t exist. But they are coming online and are different from traditional enterprise software in that they were designed from scratch to be abstractions above hypervisors and cloud providers.

Plus, there is very little traction in this space from established vendors, the majority of which all want to build vertically integrated solutions that specifically do not allow this form of inter-platform competition.
It’s easy to get lost in the cool technology here and lose focus on how you would actually achieve a vendor neutral platform and what the financial impacts would be. As an example, let’s start with the Commonwealth Bank of Australia (CBA). It was able to cut its IT spend by 10 percent by encouraging its vendors to compete for workloads.

CBA did it by implementing a cloud management solution and then performing expert vendor management to allow it to quickly adopt new vendors and to gain leverage over existing ones. In just two years it pulled this off using off-the-shelf software and freed up $100 million a year going forward to reinvest in new capabilities. ## Think IaaS+ Many companies implementing a cloud solution completely miss the boat on their first pass. IT often focuses so hard on basic server provisioning that they lose site of the bigger picture. While server provisioning is interesting, it’s likely one of the smallest benefits. The real advantages are obtained by moving up the stack and giving the business the ability to deploy applications and solutions much faster. The primary examples are any company wanting to deploy Agile Development, DevOps, or PaaS solutions. A great example of using a cloud management operating model is UBS and its workplace automation solution. UBS implemented a cloud management solution to deploy virtual desktop infrastructure (VDI) but not traditional VDI. Instead the UBS version of VDI is a mixed set of services that are delivered to iPads and Android devices backed by a set of traditional desktops to do the workflow automation. The user almost never sees the desktop, and the desktops are stateless. Further, depending on the user, it automatically routes them to a freely available desktop in the correct country, running the correct software and profile for that individual. ## Complexity reduction Another major benefit of a cloud management platform is that it coalesces many different solutions and products under a single umbrella. This complexity reduction can directly translate into increased uptime and improved stability as well as cost savings. A major financial institution with 15000 servers was able to save almost$30 million a year just in complexity management.

Reduced work orders to configure solutions, fewer vendor products, fewer project managers allocated to managing change and best of all fewer meetings. It all adds up. This is why your cloud management strategy has to integrate many different things.

It’s not enough to say you are just going to focus on deployment of a virtual machine (VM). You need to focus on how you will deploy that VM’s storage, networking, compute, DNS entries, the software on the VM, and the firewalls in between. You also need to consider where to deploy or what regulations will apply depending on what you’re deploying and where it’s deployed, etc.

Leave out any of these and instead of a single simple solution you have something that requires project management, meetings, and more. Not having these systems fully automated and managed by a policy configuration engine also means that the risk of failure due to simple things like fat fingering mistakes go up dramatically.