Fog is just a cloud you can touch.
So instead of “Private Cloud,” wouldn’t “Fog” be a better choice?
You can, interestingly enough, build ITIL-compatible Fogs. The Cloud? Far less likely. As last week’s interview with ITIL guru Rick LiaBraaten revealed, The Cloud is deficient with respect to at least four ITIL core processes: Problem Management, Availability Management, Performance Management, and Change Management. We covered the first three of these last week (“ITIL vs The Cloud: Pick One,” KJR, 1/10/2011). To continue:
KJR: Let’s talk about Change Management in The Cloud.
Rick: Short discussion. I can sum up Change Management in The Cloud in two words: You Can’t.
KJR: Is it really that black and white?
Rick: Just about. No matter how IT handles Change Management, to be professional about it, and to follow ITIL guidelines, you have to regression test each change to make sure it doesn’t break anything that’s currently in production. And, you have to have a back-out plan (again, an ITIL guideline) in case the change blows up when you do put it in production.
KJR: Why would this be so hard for Cloud vendors to support?
Rick: That’s a rhetorical question, right?
Theoretically, Cloud vendors could provide test environments for every upgrade, for their customers to use in regression testing. I don’t know of any that do that now, but they could.
But a back-out plan? Cloud vendors would have to support multiple versions, just as software vendors do now, so their customers could opt out of one or more upgrades until they’re ready, or until their production version finally passes out of support … typically, in three to five years.
Sure, it’s technically possible. But it would blow up the Cloud’s economic model, which is built on the assumption of commoditized infrastructures.
KJR: Well, okay, but so long as the Cloud vendor doesn’t change its interfaces, isn’t this more of a theoretical problem than one that crops up in the real world?
Rick: Gee, Bob, thanks for being such a terrific straight man. You know as well as I do that this is anything but theoretical. Last year, for example, Microsoft upgraded Hotmail and somehow, many customers couldn’t reach it with Internet Explorer.
If something that simple can blow up from an upgrade, imagine the sheer enjoyment of figuring out a problem with an applications portfolio that integrates NetSuite and Salesforce … even if IT isn’t connecting both of them to an internal data warehouse.
KJR: You’re welcome for the set-up. Have another Leinenkugel, and riddle me this — if The Cloud is really this bad, does it mean CIOs should just take a pass on it until Cloud vendors figure all of this out?
Rick: Not at all. The problem is that a lot of the people who are touting The Cloud seem to be financial analysts, not IT professionals. So they make a big fuss about companies getting to spend OpEx instead of CapEx. But for companies with a strong cash position, that isn’t really a benefit, just a trade-off.
I can see how companies with heavily leveraged balance sheets might find it attractive — high debt means limited access to capital — but it’s hardly a compelling reason to move so far backward.
Another touted benefit is out-of-the-box usability. It’s more psychological than real. When IT installs a COTS solution, business managers typically insist it be customized to support their current processes. With a SaaS solution, the same business managers are suddenly delighted to find process workarounds so they can use the new technology right away.
KJR: So where does The Cloud make sense?
Rick: Remember when the personal computer first started to leak into the enterprise? It was a completely unmanageable gadget, and it didn’t matter. In large enterprises, employees used it for spreadsheets — something they couldn’t do at all before. They used it for word processing, which PCs did cheaper and just as well as expensive, dedicated word processors, which were also unmanageable gadgets.
Small businesses used PCs because they made scaled-down computing affordable.
It’s the same with The Cloud. Large enterprises should use it when it lets them do something they can’t do at all before, and for capabilities where limited manageability isn’t a serious issue.
Mostly, right now I’d say The Cloud is most interesting for small businesses, because it makes forms of computing affordable that have been out of reach until now.
KJR: Is that your big finish?
Rick: No. My big finish is pouring each of us another Leinenkugel.
Now this “Cloud” thing: Other than being faster and cheaper, it sounds like many of the attributes were a part of “Time Sharing” circa 1970 +/-
I totally agree with John Blair in his comment that “This Cloud thing. . . . .sounds like many of the attributes were part of Time Sharing”. There is really very little that is new in the world of IT – we just resurrect things, give them a new name, update technology and away we go.
Thanks for this series!
I really have to disagree with Rick on this. The description of ITIL is overreaching and sits on a flawed assumption of control—there are many things that go into enterprise IT that are beyond our control, and therefore need to be an interface to ITIL. He is also generalizing hundreds of different providers under the term “cloud”.
Consider that in any large IT system (1) we rely on power suppliers and (2) we rely on network suppliers. Both of these suppliers define an interface to us, but make frequent changes behind that interface that we have no knowledge. Nor should we. IE, we didn’t need to file a change when Xcel powered up the new Gas-Fired Power Plant, and we don’t need a change when Qwest installs a new router.
Cloud providers are the same way—they define an interface to you that should remain consistent without you needing to change anything. For example, SalesForce delivers an interface to the customer through a User Interface and set of Web APIs. Upgrades are delivered three times per year and are thoroughly tested with the User Interface. Web APIs are backwards compatible, leaving it to the customer to decide when to upgrade the integrations.
Cloud and ITIL are entirely compatible—it just forces us to realize that we don’t have control, and that’s okay. Understand the abstraction and the interface. And if your provider can’t maintain a consistent, stable interface to you—that’s a provider problem, not a ITIL problem.
Comments are closed.