ITSM and cloud computing should be married, but some times I feel like the child of divorced parents.
I'm often tugged to explain the one to the other; condemned to be the unfelicitous Hermes between them. And we know how well THAT works.
I either get condescending nods of fake understanding, like some do to a child --"Yes, of course. But we have to be pragmatic / realistic/ grown up." And all I wanted was a Pepsi or VM.
Or I get is a good thrashing for being technology centric - Hey we can do a service catalogue with roll of toilet paper. It's people and process, Senor vendor stupido. Or... "That service model talk is too theoretical, we have some VM's to spin up."
But it's Spring and there's that Hopey thing working for me. So here are some observations on the cloud / catalog journey.
Cloud computing is a new operational model focused on delivering business agility through process innovation and delivery of everything an enterprise does-as-a-service.
The "new" thing here is that you can think of a service as an abstraction of underlying infrastructure that makes it consumable by a user. There's one part that is customer facing, and one part that is hidden from the user.
In cloud computing, that customer facing part is the cloud API that defines what's available, the ordering parameters, and other elements that lead to a "good and valid order." The service catalog is where this abstraction gets expressed in human understandable terms and choices. It's where the order takes place, and where the customer will manage the lifecycle and consumption of her service.
To use my by now-fatigued restaurant analogies, the item on the menu is an abstraction of food useful for ordering by the customer and useful for the kitchen to know which ingredients and tasks are needed to that standard meal, like a BK Whopper.
You really want to understand how standardization works? Check the cash register of BK. It has buttons for extra cheese, no mayo, add mustard. Check the one in MickeyD's and they don't have those buttons. The menu is actionable at the ordering point.
So far, these concepts should be pretty familiar to my regular readers. But with cloud we are going to take it one step farther: all the food preparation and delivery will be done automatically, without any manual handling to enable the delivery of the service.
In other words, we are not "improving" the process, we are completing eliminating the process by automating all the rules, steps, and data into code. This takes a process from days, weeks or months to seconds and minutes. These automated processes ensure that changes, patches, fixes propagate at large scale and errors are automatically dealt with.
It also means the automated infrastructure is constantly being changed by software. And this is only possible because the cloud model strives for operational simplicity.
This is not easy for datacenter people nor ITSM people.
For datacenter people, the notion of creating standard offers with few if any variants (thik manufacturing instead of custom builds), of having to guess what customers might want (marketing research), to limit a customer's configuration (product management) is hard.
They are used to custom building infrastructure around an application, not the other way around
To have to think of capacity management from how do I ensure I have enough resources for the peak performance needs of an application and so no one yells at me, is new. To have to think of capacity management as demand management (finance and vendor management) is not in the experience-shelf of the cloud team. To think of capacity as sweating an asset as much as possible? Not the usual way of the datacenter; no one wants to see a server sweat, hence the cooling.
Some of these skills are part of what ITSM folk already do, like financial management, service design, demand management, and service catalog. One would think data center folk would be looking to ITSM folk like a settler watching the cavalry arriving to the rescue. Instead, they are often pointing the guns in that direction.
This is because much of ITSM has traditionally focused process as in procedures, tasks, people, etc. Which is fine as part of a journey. But when the focus is automation, the journey changes: the focus moves to standarization, simplification and automation. And this requires technical skills and know how.
From the point of view of the service catalog, it requires tight definitions that include the underlying resources to be provisioned: it could be a virtual machine (VM). If so, what are the technical attributes that need to be specified to get a "good and viable" order? Once we have that, are there options and standards? Are the packages this VM will be part of? Should we even offer a VM or is it really a higher level offering, like a SQL test environment? What are the roles and what will they see?
All this gets loaded into the technical catalog, forms created, rules set, connected to the cloud automation layer. The lifecycle manager (think of it as cmdb that works) now kicks in an tracks what the user ordered and provide further choices for changes.
I could go on and on, and I probably will another time.
Which is why I wish mom and dad would get along because we need both to make succesful clouds. So in the spirit of Spring and the hopey changy thing, I encourage my ITSM people to get their hands cloudy.
-------------
Disclaimer: My parents are happily married for 49 years so far...
ITIL (because it's a monolithic bible?) didn't understand or recognize virtualization and ITSM was a barrier to VMware virtualization technology adoption (want a change ticket with that vMotion? what do you mean it's automated? Sounds like Star Trek with all them VMs being transported in the ether, so we'll need an incident record to track...blah blah).
If you're interested I did a VMworld presentation on these barriers, and I also posted a few on viewyonder.com - because we're seeing the same ITSM-drag on cloud now.
As you delightfully accurately say: another step along the journey and THIS STEP IS ABOUT PROCESS ELIMINATION NOT PROCESS IMPROVEMENT.
The sooner that the ITSM people realise that a process between a consumer and producer is a bump in the wire, and bumps in the wire cost money, and fewer bumps in the wire means more revenue and more profit (or are we doing this for love?) - then perhaps they'll put away their visio diagrams, turn their bleary eyes away from that so-90's ticketing client/server app, and embrace the current state instead of denying it.
What am I talking about?! AS IF! There's no chance, Rodrigo! There's no chance that an entrenched bunch of people who make a living from MORE processes and MORE people and MORE services and MORE books, no chance they will ever EVER embrace something that they perceive as a threat.
As for people who claim "it's not about the technology" (FFS!) they remind me of the people who ruined Bank of Scotland in the late 90s by deciding that IT wasn't a "core competency" for banking. They outsourced it to IBM (experts, right?) and the rest is history (BoS was bought by Halifax, who DID recognize that without IT there is no banking) and IBM lost the contract.
My belief? People are incredibly important, and how things are done (let's call it process!) is also incredibly important, but without the technology vehicle there is nothing.
I'm hoping to meet some guys at the end of May who are working with VMware to produce a paper on ITSM + Cloud + Virtualization, and I see that the ITPI recently published a Visible Ops for Cloud - so there are people who get it, and these are the awesome people we should listen to. Oh, and you too, Rodrigo!
It's ok to have divorced parents, Rodrigo, sometimes it's just not worth trying to get them back together. Let them go their separate ways and let the children get on with their lives without their parents' baggage.
Posted by: twitter.com/stevie_chambers | Saturday, April 30, 2011 at 03:05 AM