Subscribe

Is it a bird, is it a plane...

No, it's a configuration manager.

Clive Brindley
By Clive Brindley, solution architect and pre-sales manager within the BTO business unit at HP Software + Solutions SA.
Johannesburg, 05 Jul 2011

I have yet to meet a configuration manager who can strut the hallways of an IT operations shop and be the envy of fellow colleagues, with whispers of 'there he is, he is the one'. That might sound a little far-fetched, but the reality is that the job of a configuration manager today has got to be one of the most challenging in any IT shop.

The process of configuration management (CM), as it is known in ITIL, is a critical underpinning enabler for many of the other processes such as change, incident and availability management, to name but a few. Get it wrong and bad things happen - services fail, SLAs are missed and the boss normally comes knocking.

Too many CM projects have failed because participants have tried to overcomplicate what is needed.

Clive Brindley is solutions architect at HP Software South Africa.

The vision of CM is spot on; understand what IT components (applications, networks, servers, storage, etc) exist, how they are configured and most importantly, what they do for the business. It might seem like I have greatly simplified it, but in a sentence, that is it. Too many CM projects have failed because participants have tried to overcomplicate what is needed, but I guess that is what humans do very well - create complexity where it is certainly not needed.

Three amigos revisited

In a previous Industry Insight, I discussed the variances of configuration, asset and inventory management (the three amigos). While they might all seem very similar, they have different purposes. CM is not like inventory management or about knowing everything that exists in IT, but rather what IT should know about IT stuff. The stuff that business runs on, the vital business functions. Don't tell me about the 7 000 desktops there are across the business - I would rather know about the magic that makes 'order processing' function for the business.

This magic is called the service model or service map, among other definitions, and is the fundamental structure that configuration management is concerned with. It is this model that allows for impact assessment in change management and service outage analysis in incident management, for example. Without this model, it is nearly impossible to manage business risk and support the agile, changing ecosystem of IT.

So let's for a moment assume that the 'hero' configuration manager has all the data models, CI attributes, service dependency information, CI states and configurations information nailed down. These critical business services are modelled with all the technology linkages, monitored and provided to the required consuming processes. Great, but what happens when things change? A scenario, perhaps to illustrate the conundrum, is offered.

The 'order processing' business service is underpinned by a cluster of Web application servers that interface to a two-node application cluster, which stores all the data in a relational database with an HA configuration. Of course, in between all of this critical infrastructure, are networking cables, switches, storage tiers and more. This very service model is made up by using discovery technology that scans the infrastructure every couple of days or even hours, collects detailed configuration information, and very importantly, determines how these items are connected. A bit of tribal knowledge is sprinkled into the mix, and voila, there are the business service maps. Never believe vendors that say they have solutions that automatically build service maps. Technology maps maybe, but not business service ones - for this the human cerebellum is needed, to know that this server, running this application, is used for processing Internet orders. I digress...

These maps are important because they are needed to detect if things are changing, and if so, why and what the potential impact is. The problem here is that the company is now living in a very dynamic, instant-on and always-changing environment. Gone are the days where there were dedicated and locked down infrastructures. Virtualisation and the cloud must now be dealt with. The server a company is running on now might be a different one in five minutes, because the system decided something bad was happening and needed to initiate a failover onto another platform, automatically. The application had no idea it was moving and is now at the other side of the data centre - neither does the configuration manager, unless he runs another scan and detects that something has changed.

Slight hitch

The problem is he might have only run the scan five hours after things moved on. In the interim, someone raised an emergency change to apply a patch to a critical switch, the very switch that was now orchestrating the connections of the 'order management' application farm. Bang, it all comes down like a stack of cards and everyone asks how. Things have suddenly moved into the realm of 'run time configuration management'.

What I mean by this is the ability, in real-time, to detect changes in the virtualised and cloudy worlds of new data centres, and update the service maps and technology linkages. Without automation, users are going to be paddling upstream, and in no time the configuration manager will go from hero to zero in the blink of an eye.

Today, real-time performance and fault management solutions are tracking everything that is happening in the virtualisation and cloud layer. These management platforms will immediately know when hypervisor, for example, decides to cut a VM over to a neighbour due to a hardware fault. Why not take this real-time information and send it to the configuration management solution, which will use it to update the CI's configuration, and importantly, its linkage to other stuff.

I am really excited about this concept, because users do not need to deploy additional monitors into the data centres, they can use what they already have (not an SOA pitch, I promise). Run time service models might be another name to give this concept, but it is upon everybody and everybody needs to be prepared.

Everyone wants to be a hero and strut their stuff, even the beloved configuration managers.

Perhaps there will be a new model on the catwalks soon, coming to a data centre near you...

Share