Original URL: https://www.theregister.com/2013/09/18/configuration_management_misconceptions/

So you think you know all about configuration management

Well think again

By David Norfolk

Posted in On-Prem, 18th September 2013 08:35 GMT

David Norfolk is practice leader with responsibility for development and governance at Bloor Research International. He is on the committee of the BCS Configuration Management Specialist Group.

Last month El Reg published an article by me that introduces the concepts of configuration management. You can read it here. In this article I explore some common misconceptions about the topic and move on to discuss some dos and don'ts.

Let me state straight away that configuration management (CM) is not just about program code.

If you have your game-world avatar moving around a room just as you like it to, you don't want it reverting to an older version that walked through tables and walls when you make a new release. That is where CM comes in, just as much as managing software components does.

Another common belief is that CM is just for the CM group. In fact, it is about assuring service delivery for all stakeholders. A fanatical CM group may even get in the way, by stopping the wider group of stakeholders taking ownership of CM.

Even nerds have feelings

Yet another misconception is that only managers care about CM. Not true: the nerdiest games or software developers care when something they have fixed comes back in the next release and makes them look stupid (although you might need to explain to them that it is something called CM that prevents that).

Some people appear to think that implementing CM is simply a matter of buying a tool, when in fact a tool is only an enabler. Having said that, once you have a CM process, the right tools are enormously helpful.

An equally serious mistake is to think that implementing a CM process, with the right tools, is a one-off thing that will just stick. It won't.

Management must continue to nurture CM. It needs to recognise and appreciate people doing it well and publicise successes – for example, reducing production failures attributed to configuration issues.

Vendors are perhaps indirectly responsible for some of these misconceptions. One is that CM is all about building a configuration management database (CMDB). Vendors sell CMDBs, which hold information about configuration items (CIs) and their relationships.

You are probably wasting time and resources managing a lot of data you don't need

Some tool vendors will have you believe that you can reliably put CIs in your CMDB automatically, using using networked asset discovery tools, so you can easily build a complete CMDB and thus get the best CM implementation ever.

However, if you are just building a bigger, better CMDB, you are probably wasting time and resources managing a lot of data you don't need.

You should do just enough configuration management to help you sleep at night, and no more. You want to manage only the CIs that someone actually wants to use; keeping stuff just because you can is a waste of time.

Hide and seek

Another misconception is that everything that matters will eventually appear on your network at a time when your discovery tool is active. But you simply can't rely on that.

Think about important stuff on a PC without a network connection, for security reasons; or stuff on an old PC with an operating system not supported by your discovery agents.

For that matter, think about stuff appearing twice because your vendor changes the internal ID between releases. Discovery always needs a bit of a human sanity check (yes, Chico, there is a sanity clause).

Of course, it is also a misconception is that a CMDB should always be singular, small and compact. Really, size doesn't matter either way; it is what you do with it that counts.

If configuration management succeeds letting you sleep at night and is delivering quantifiable benefits, it really doesn't matter whether it is using data stored in a small CMDB, a large CMDB, or even several federated CMDBs, some or all of which aren't even called CMDBs.

Configuration management: the dos and don'ts

We often see that governance initiatives yield the full benefits only in mature organisations in which senior management fully supports configuration management (CM).

CM handles relationships between configuration items – and if senior management allows a favourite project to ignore it, failures in related projects are likely.

The repercussions may even rebound on the favoured system, as it is unlikely to operate independently. In these cases CM may be seen as an overhead without benefits.

Light and shade

As I explore later in this article, there is a dysfunctional “dark side” to most things that work – even senior management support – if you do those things wrong.

Let's start with the light side. Having well-trained people with access to good information and good technology-enabled processes works well for CM, as does having the right skills-transfer partners or consultants as mentors.

CM is about helping people manage technology, not about replacing people with tools.

A well-planned and properly resourced CM implementation, with buy-in from the business process owners, tends to succeed. And it should have realistic scope and objectives, agreed by everyone involved.

Start small, demonstrate success and then grow

Start small, demonstrate success with a limited scope and then grow. At all times, communicate clear benefits to stakeholders – and don't stop after implementation.

That is the “light side”, as identified by participants in the interactive sessions at the British Computer Society Configuration Management Specialist Group conference in July 2008. However, a dark side was identified too.

Lack of senior management commitment is certainly on the dark side, but less obviously so is too much commitment or the wrong sort. CM imposed by decree, without consulting the people who have to use it, can be fatal if managers are telling those at the sharp end how to do their jobs.

That is when you start seeing viral adoption of open-source tools. There is nothing wrong with this per se – but it can be risky and wasteful if you are paying for expensive commercial tools at the same time, and if your open-source tools lack a support contract.

An unfeasibly large CM implementation with ill-defined objectives is often associated with poor management support. This is bad news, especially if combined with poor planning and unrealistic expectations of short-term return on investment.

You might think these issues are obvious – but CM implementations do fail and often for these very reasons.

A less obvious cause of failure is a siloed approach – islands of CM. This is perhaps the dark side of the “start small and grow” story.

Blame the tools

It should be a case of think big, build small: your initial, limited-scope CM implementation should be the basis of a larger conceptual framework.

Looking at only the technology while ignoring people, process and data is a recipe for failure too, as is overlooking dependencies on other projects (such as implementation of Agile and systems engineering).

It is also worth remembering that CM is likely to fail if your overall development processes are poorly designed or implemented.

And poor tool selection processes are often a route to failure (as in: “We have XYZ in-house already, it will give us a tool cheap, Gartner says it's OK, we will use that. Now, what does it do…?"). Good tools are an important enabler; bad or inappropriate ones can be a disaster.

To conclude, CM is A Good Thing – but making it work requires commitment, investment and skilled people. ®