Welcome to the cloud and service catalog blog. This blog and its LinkedIn communityare dedicated to the creation, sharing and distribution of cloud management and service Catalog best practices, ideas and trends

Service Catalog Community

stats

Incomplete Thoughts on the Service Catalog and Automation. There's That Hopey-Changy Thing Working for Me

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.