Several months ago I wrote a post in which I opined that good IT service management practices could help companies ease their transitions from on-premise to cloud computing. In particular, establishing a service catalog, one of the foundational recommendations of ITSM, should make it easier to determine which internal services are good candidates for migration to the cloud and help ensure a smooth transition for those that are selected, I wrote.
Then earlier this week I saw a two-part Keep The Joint Running blog post by Bob Lewis, president of consulting company IT Catalysts, that makes the point that several key IT Infrastructure Library (ITIL) practices are not compatible with the cloud. The posts feature an informative (and bonus: funny) Q&A with Lewis' friend Rick LiaBraaten, an "ITIL guru." According to his LinkedIn profile, LiaBraaten is a consultant for Aeritae Consulting Group's Service Management Practice and a senior ITIL consultant at Concord Technology, so his expertise is pretty clear.
LiaBraaten tells Lewis that while some recommended ITIL practices (service catalog, maybe?) are compatible with the cloud, some of its core suggested processes are not. For instance, says LiaBraaten, most organizations will find themselves integrating different cloud solutions from several vendors. This will result in "multi-vendor finger-pointing" when a problem occurs, just as it does today in the on-premise environment. But it's a more serious problem in the cloud, he says:
... In your own data center staff experts can get at the technology themselves to figure out what's going on. With cloud-based services they can't, so if IT has assembled a solution from even three vendors, all of which verify their servers are up well, the word "screwed" comes to mind.
With availability management, the issue is a lack of solid management tools. When an application goes down in the cloud, IT organizations must trust their cloud providers to get it back up and running, says LiaBraaten:
... Part of the selling point is that you don't need IT to manage it. That's the SaaS vendor's job. And as long as you consider "trust me" to be a good approach to supplier management, I guess that can work.
ITIL's recommended practices for change management include regression testing each change to make sure it doesn't break anything that's currently in production and creating a back-out plan in case the change does blow up when put in production. Both are technically possible in the cloud, says LiaBraaten, but unlikely to occur in the real world.
It's clear the issues Lewis and LiaBraaten highlight exist in the public cloud. But what about the private cloud? CIOs seem far more comfortable with the idea of private clouds than public ones. Respondents to a silicon.com CIO Jury survey signaled their intents to at least investigate private clouds in 2011 by a margin of 11 to one.
Interestingly, a silicon.com article about the survey includes the remarks of a couple CIOs who characterize the private cloud as simply tweaking internal infrastructures to make them more efficient with added virtualization and automation. While virtualization brings its own set of management headaches, vendors appear committed to addressing them.
The crux of all this, I think, is IT's reluctance to hand over control of its environment to someone else. Gregor Petri makes a similar point about control in a post on his Lean IT Manager's Cloud Academy Blog, writing:
The big difference between traditional IT and cloud computing is that cloud computing is delivered "as a service." With traditional IT we bought a computer and some software. In case it did not work we could fix it ourselves (sometimes a firm kick would suffice). No matter what happened (good or bad), we were the master of our own destiny. ... When something is delivered as a service, there is no equipment to kick and we no longer can say "Move over, I'll do it myself." We likely won't even be allowed to enter the room where the equipment is located or get access to the underlying code and data. If your biggest customer (or your boss, or the boss of your boss) is on the phone screaming at you, that is not a position many people want to find themselves in.
Petri goes on to describe how risk assessment should be a big part of organizations' cloud strategies. Performing a thorough assessment should help allay concerns over losing control. Moving enterprise applications to the public cloud will carry varying degrees of risk, depending on how essential the apps are to operations. For instance, project management apps are more critical for system integrators with penalty clauses or innovators rushing toward a product launch than they are for most other organizations.
Petri advises determining the importance, criticality and impact of disruptions for each service organizations are considering moving to the public cloud. This exercise may actually save you lots of money. For each service they decide to move, organizations must determine what constitutes a "reasonable" recovery period, and how to implement it. As he points out, this could range from simple source code escrow (with the right to keep using the code), to a failover contract with a nearby infrastructure provider, to simply trusting the vendor. No doubt organizations will decide to keep some apps in-house, maybe on a private cloud, because of the sensitivity of the data they contain or other issues.
And guess what? No matter which cloud path or paths IT organizations decide to take, they must carefully consider how any changes will affect their overall enterprise architecture and their business processes. As IT Business Edge contributor Loraine Lawson wrote last week:
It's inevitable, really, because as simple as we want to make technology-whether it's mobile phones, websites, SaaS or cloud-IT systems are like ecosystems: A butterfly flaps its wings and it triggers a virtual tsunami of woes somewhere down the line. Governance, security, architecture-these are the tools for taming the chaos and silos, no matter what form they take.