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?)
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:
- How frequently is the data element scanned?
- 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.