Keystones and Rivets

Trying to cross No Man's Land

The Pebble and I work well together.

But he is an Arts graduate, so I have to humour him from time to time.

This entails having to listen every so often to one of his “stories” about history or politics. 

Today, for some reason, he decided to explain why the Red Army initially collapsed during the German invasion of Russia during 1941. 

“Barbarossa”, “Lebensraum”, “OKW”,  “Timoshenko”, “Smolensk”, “Stavka”…

The Pebble often talks about interesting things but occasionally he uses too much terminology.  As is sometimes the case, after a few minutes I felt my eyes glazing over.  My mind started to drift into that strange state where you feel conscious and unconscious at the same time.  The lights were on, but there was definitely nobody home.   

His talk about matters military must have had some impact though.  Through the haze I began asking myself - when did IT last go into battle with a genuine understanding of what the business was trying to do?

When did Business and IT last plan together strategically, agree tactics, and march together with clear objectives?

How about ten years ago...?

Rolling Rocks and Landing the Catch

A couple of years ago we were invited to visit a few companies in Silicon Valley to chat about what we were up to.  It was a great trip and one of the perks was being taken to some fantastic seafood restaurants.

During one meal there was a long discussion about the problems companies have with project prioritisation in complex environments. 

One humorous comment that stuck with me was, "I don't mind rolling the rock up the hill and getting near the top only to see it roll all the way back down again.  It's rolling the rock up the hill, getting half way and having to just hold it steady that I can't stand - an occasional change of scenery would be good."

Working in IT, we’re all rolling the rock up the hill.  It tends to be the nature of the industry to load IT staff with lots of work, all of which needs to be completed in a hurry. 

It could be that we’re involved in a couple of projects, busy with procurement, testing parts of a system, fielding user queries, fault fixing, or trying to catch up on the often neglected paperwork to keep either the change board or auditors off our backs.

When it comes to scheduling our work, we could all come up with differing priorities for new tasks depending on our current workload, or how we perceive a task’s relevance.

So if a problem or failure occurs, how can we ensure that it is given the correct priority from an enterprise perspective?  If we leave it to the individual to decide the priority we cannot guarantee that we get a consistent approach to IT delivery across the enterprise. So what can be done?

Understand Value to Enable Communication

Last week FT.com and Techworld quoted some research from Micro Focus into the financial value IT systems provide to business.

Many companies have managed to control IT budgets by ensuring spend is focused through authorised procurement channels, consolidating supplier lists and rationalising software and hardware assets.  Others have gone the extra step of outsourcing to gain even greater visibility of IT spend.  There are plenty of techniques documented on cost management.

A nut which is more difficult to crack is how to value IT and quantify how this spend contributes to business performance, so the figures quoted in the research made for interesting reading:

Micro Focus research, carried out in companies with revenues from $100m up to over $1bn, shows that less than half of all CIOs & CFOs (48%) ever try to quantify the financial value of their IT assets. Only 37% of CIOs have tried, compared to 60% of Finance Heads. Less than a third of all respondents (29%) from both groups, ever try to quantify the contribution all their IT assets make to the business' performance.

Just over a third of CIOs have tried to find out the financial value of their IT assets.  And that is in an industry with a spend of over $1 Trillion per year.  Are there many other industries which could get away with that?

Are CMDBs worth the trouble?

During the past 12 months I’ve been asked with increasing regularity about the value of Configuration Management Databases (CMDBs).  In this post I’m going to summarise my answers to some of these questions I’ve been asked; as always with a bias towards how best to align business and IT.

On that note, it is worth pointing out that a CMDB is focused firmly on IT, not business. Sure there are some business benefits to be gained, but only as a consequence of CMDB implementation forcing change on the management and delivery of IT.  The great hope is that these changes will improve IT service, consequentially allowing IT delivery to become something that "just works", allowing IT to have more constructive conversations with the business.

To start with, there follows a brief description of what a CMDB actually is and what it often promises to deliver.

A CMDB forms the basis for much of the delivery mechanisms of ITIL v3. The concept is that you have a repository which holds relevant information about your assets, and how each asset relates to any other asset.  An asset, in the context of a CMDB, is termed a Configuration Item (CI) and may be an item of hardware, an application or a service.

So is the CMDB the repository, the data model (how the data in the repository is structured and used), or the data held within it? Unfortunately that depends which vendor is trying to sell you it.