The Curious Technologist & The Case of the Analogies

Sometimes technicians, to paraphrase the character of Ian Malcolm, are: “… so preoccupied with whether or not they could, they didn’t stop to think if they should.”

As the new analyst for The ITSM Review, I was presented with the objectives and characteristics of the role – namely that of The Curious Technologist.

As I embark on this odyssey, I want these articles in particular to be a little more anecdotal in nature, as this subject can be as dry as toast (see what I did there?)

Incoming…

I landed in the world of ITIL back in 2005, when bids were looking for my organisation to demonstrate ITIL alignment and revolved around seemingly holy grail of Configuration Management

A simple gallop around potential contacts in the geographic regions, and within the various departments showed that everyone had their own ideas of what Configuration Management.

There was actual configuration setups of machines, to the rigidly adhered to ITIL descriptions in the book.

Welcome… to Jurassic Park!

Perhaps my favourite, certainly for Configuration Management was the ‘Jurassic Park’ principle.

Ask any technical group what their discovery tool does, and you will receive the most complex, macro-ridden spread-sheets with all manner of data widgets that can be scanned.

Trying to change the mind-set of technical folk to focus on configuration item data that is relevant is a challenge.

In the film, as the main protagonist, John Hammond, is smugly announcing his plans to literally unleash recreated dinosaurs on the unsuspecting tourist public, a mathematician specialising in chaos theory sets him straight.

Sparring from the start, the character of Ian Malcolm chides him for taking work that others have done, and just taking that extra (terrifying) step.

Sometimes technicians, to paraphrase the character of Ian Malcolm, are: “… so preoccupied with whether or not they could, they didn’t stop to think if they should.”

Whilst maybe not as (fictionally) fatalistic, this is true when we looked at the depth of scan-able data versus what is actually required to make Configuration Management achievable.

The next logical step was to analyse the list of discovered widgets but to ask two key questions:

  1. How frequently is the data element scanned?
  2. How current is it kept and used as part of another process?

Not surprisingly, a lot of things are scanned once, and never once referred to again, or even updated again.

The linkage with Change Management in particular proved to give us the grounds to define the “highest” common denominator, which is the most typical configuration item to be affected in a change.

And therein lay the basis for our definitions (in this case) on standards.

 “Here in my car, I feel safest of all…”

Perhaps my most constant analogy of all was one that was taught to me as I was preparing for my first billable project.

In moving to a new role recently I was fortunate enough to be working on a different service desk tool, and indeed my late career was often spent moving clients from one tool to another.

There is no real difference in the raison d’être of a tool – it exists to take a ticket from the start of its life-cycle journey to another.

Processes are the fuel that will drive that engine – but essentially a ticket is opened, it is assigned, it is resolved or closed.

Not unlike a car.

I could give anyone of you the keys to my car and with a few moments of familiarisation someone could drive it away.

Simplistic analogy?  Yes.

But it is often a necessary first step in detaching recipients from their emotional attachment to whatever tool is being replaced.

Welcome to… The Curious Technologist…

A lot of these articles may well be anecdotal, but in my years of watching some of the best consultants at practice, the ability to boil down a complex requirement or approach sometimes requires a more simplistic touch.

After all, if the prospect of moving to a new set of tooling meets with barriers straight away, then how will the deployment ever move forward?

Sure, the use of film lines or pop culture may cause me more amusement than my audience, it does bring a mechanism to channel people’s thoughts along a different line, which is vital in the complex environment we often work in.

Image Credit

Rob England: What is a Service Catalogue?

"The menu analogies we see all the time when talking about service catalogue are misleading. "
"The menu analogies we see all the time when talking about service catalogue are misleading. "

We are looking at railways (railroads) as a useful case study for talking about service management.

What is the service catalogue of a railway?

If you said the timetable then I beg to differ.  If you said one-trip, return and monthly tickets I don’t agree either.

The menu analogies we see all the time when talking about service catalogue are misleading.

A menu (or timetable) represents the retail consumer case: where the customer and the user are one.  In many scenarios we deal with in business, the one paying is not the one consuming.

The service catalogue describes what the customer can buy.  The request catalogue is what the user can request.  Consider a railroad cook-wagon feeding a track crew out in the wilds: the cook decides with the railroad what to serve; the staff get a choice of two dishes.

The cook’s services are:

  • Buying and delivering and storing ingredients
  • Mobile cooking and eating facilities
  • Cooking food
  • Serving food onsite

That is the service catalogue.  The railway can choose to buy some or all of those services from the caterer, or to go elsewhere for some of them.

The menu is a service package option to the “cooking food” service.  The railroad chooses the options based on cost and staff morale.  The menu gives staff the illusion of choice.

First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Dangerous goods transport (the ethanol delusion generates huge revenues for US railroads)
  • Large loads transport (anything oversize or super heavy: huge vehicles, transformers, tanks…)
  • Livestock transport
  • Rolling-stock transport (railways get paid to deliver empty wagons back their owners)
  • Finance (a railway can provide credit services to customers)
  • Ancillary freight services: customs clearance, shipping, security…
  • Passenger transport
  • Luggage
  • Lost luggage
  • Bicycles
  • Pet transport
  • Food and drink services (onboard and in stations)
  • Accommodation (big Indian stations all have dormitories and rooms)
  • Tours and entertainment (party trips, scenic trips, winery trips…)
  • Land cruises (just like a cruise ship but on rails)
  • Travel agency
  • Bulk goods storage (railroads charge companies to hold bulk materials in wagons for them awaiting demand: they provide a buffering service)
  • Rolling stock storage (in the USA railroads make money storing surplus freight wagons for other railroads)
  • Rolling stock repair (railways repair private equipment for the owners)
  • Private carriage transport (in many countries you can own your own railroad carriage and have the railway carry you around; a fantasy of mine)
  • Property rental (many large railways are significant landlords)
  • Land sales

Where’s the timetable or ticket pricing now?  It has such a small part in the true scope of a railway’s services as to be trivial.  More to the point, it is not a service: tickets are request options associated with one of many services.  Users don’t request a service: “I’d like an email please”. No, they make a request for an option associated with a service: provision email, increase mailbox, delete account, retrieve deleted email etc…

People confuse their personal consumer experience with business: they try to apply consumer experience models to business processing.  Most customers don’t want a service catalogue “to look like Amazon”.  They want meaningful business information.  The best vehicle for that is usually a text document.  The users/consumers of a service(s) may want to see the requests associated with that service(s) in an Amazon-like interface.  Sometimes there may even be a valid business case for building them a groovy automated request catalogue, but it is not the service catalogue.

The service catalogue defines what we do.  It is not simply an ordering mechanism for customers.  That is that personal/business thing again.  A service catalogue has multiple functions.

  1. Yes it is a brochure for customers to choose from.
  2. It also provides a structure to frame what we do as a service provider: availability planning, incident reporting, server grouping… Once we have a catalogue we find ourselves bring it up in diverse contexts: “we see the list of services show up in the table of contents”.
  3. It is a reference to compare against when debating a decision
  4. It is a benchmark to compare against when reporting (especially the service levels, but not only the service levels)
  5. It becomes a touchstone, a rallying point, an icon, a banner to follow.  It brings people back to why we are here and what we are for as an organisation.

You don’t get that from Amazon.

Then we come to that endless source of confusion and debate: technical service catalogue.  That deserves a whole discussion of its own, so we will look at it next…