Deconstructing ITSM

6 January 2017

It’s not doing anything, it’s just sitting there!

Filed under: history,requirements management,tools — Joe Pearson @ 16:55

Over the years I’ve told a number of people how I got into service management (or possibly, bored anyone who will listen).

I joined IBM in 1985 as a Systems Engineer (which is a technical role in the marketing branches backing up and supporting the sales teams). On joining, branch management asked me what I knew about data networking.

“Um – nothing really.”

“Good, you can be our trainee network specialist!”

And the network specialist team (2 or 3 people at the time) decided I should focus on network management tools.

So I set about learning what networking was and what network management tools were.

This was in the time of IBM’s mainframe networking architecture “SNA” and the introduction of the “Token-Ring” local area network technology. The network management tools were an acronym soup of mainframe-terminal-based tools like NCCF, NPDA, NLDM and others, which a year or so later were merged into the NetView product which still lives on.

And I began joining others on customer calls and looking at how customers were using these tools and the areas they needed help with.

It wasn’t long before I observed that more than one client was saying effectively the same thing:

“We installed the tool (as you recommended) and there it is (usually a 3270 terminal in the corner of an office or machine room logged in to one of the tools) – it’s just sitting there, not doing anything.”

And the question “what are the tools supposed to do?” became for me the defining question of network management, and later of service management.

It might not have been right to ask “What did you want it to do?” because that might have challenged the implicit trust in the IBM sales person’s recommendations, but the discussions usually brought up the key factors of service management, which are just as important now even though tools and technologies have changed massively.

  • So, what DO you want it to do? – requirements management
  • Monitor and control things – what things? – configuration management
  • Alerting when something goes wrong – what qualifies as “wrong”? – service levels, performance management (acceptable response times and component utilisations), design for availability (it’s not an alert state when a backup or test node goes down), etc
  • Diagnosing performance and capacity issues – how much traffic and how many users was this network designed for? – capacity management, service design
  • And so on.
  • Curiously, the idea of process management wasn’t very prominent at that time. The IBM Red Books, with technology based guidance, and the Yellow Books, key inputs to the original set of ITIL books, were around and provided practical how-to information, but it was some time before we realised the value of processes as things to be defined, documented and managed in their own right.

Implementing tools without prior, and on-going, understanding of the users’ expectations from the services, and the processes, people and information that drive the tools, is a recurring headache in IT service management.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: