Posted: Mon Nov 03, 2008 1:06 pm Post subject: Configuration Structures
I've seen a lot of documentation saying that Configuration Management should have relationships defined, but I've yet to see a good method for defining the relationships used in a CMDB.
Every now and then you see the term "Configuration Structure", which is something I've run with when developing Configuration Management strategies for the organisations I've been involved with over the last couple of years.
I've not yet had a chance to run a Config Mgmt initiative from inception - I've only really worked to help reign in existing CMDBs that were not much more than asset registers with varying levels of success.
In thinking about relationships, the model I think works best for identifying relationships is to take each discrete Service and depict graphically all of the CI categories that have been scoped and the potential relationships between these categories - for example a server support service might have servers, AV applications, storage devices etc. You then take these diagrams and map the actual CIs to the diagram. This becomes a "Configuration Structure" diagram. You can then see exactly where the relationships are and you can create these in whatever Configuration Management System you are using.
By defining the Configuration Structures as a Service and its components you can have overlap between services for different CIs - A server might be part of both an application service and a server management service for example.
This approach is working ok for me in the environment I'm working on at the moment where there is a smaller infrastructure set that is not too complex with only a couple of defined services, although I'm finding that it would be easier for me if there was a greater granularity to the services employed. I haven't really delved into service design too much myself as my primary job is to work in Change and Config, but how granular should services be? Some of my "application" configuration structures are approaching 200 items including network security devices and firewalls - I would prefer these items to be part of the network or security services...
How have other people on this forum approached the definition and discovery of relationships in their environments?
We've gone with the Service relationship method - we've broken our primary "managed" service (the application we support) into ancillary services - Production support, DR Support, Dev Support, Network Support, Wintel Support, Unix Support etc.
Within each of those service Configuration Structures (defined in V3 as "The hierarchy and other Relationships between all the Configuration Items that comprise a Configuration" whatever that means) we have listed the components that comprise that particular service and how they are related. For example, the application might have a couple of database instances running on a couple of servers and have a web server which serves the app through a web connection, but it doesn't include all of the "ancillary" stuff that goes on - the app service doesn't need to know how the servers are connected in the network. The Network Service DOES however show how the servers are connected to network devices (within reason).
The difficulty we faced (with a fairly broad definition of the "service") is how granular we get. Theoretically, all of the infrastructure we support is involved in delivering "the service" or the application we support, but if one had to draw out all the relationships in a single Configuration Structure, it would get very confusing and messy. The easiest way in my eyes is to break it down further as described.
This approach works ok for a reasonably centralised and controlled system, but I don't know how I'd do it in a larger environment - maybe break down the Configuration Structures by Site as well as "service type"?
Posted: Sat Nov 15, 2008 12:56 pm Post subject: configuration structures
Hi kev, I think you're on the right lines with server, software etc. but recommend you stay away from trying to relate infrastructure devices directly - because it delivers little value and can't easily be understood.
As server will probably have multiple network connections, probably a couple of SAB links and power. Its bad enough trying to get a network diagram of a complex infrastructure, so don't try and represent one in a service architecture. Limit yourself to a service heirarchy for ease of delivery and maintenance, then you won't fail. The aim isn't to create a perfect technical representation of how IT systems work, but a communication system to enable change, incidents, problems, risk to be understood by many.
I develop software covering service mapping and infrastructure devices and we have two product sets as the data structures and needs are quite different - service mapping is heirarchical, infrastructure is peer to peer.
I really like this statement "The aim isn't to create a perfect technical representation of how IT systems work, but a communication system to enable change, incidents, problems, risk to be understood by many. "
It's very easy when defining CIs and relationships to get bogged down in believing you need to know and capture EVERYTHING. I think it's important to consider how the CMDB is going to be used by the various groups - it's great to be able to know exactly how many memory sticks are in a server, but how often is that going to be used by the business during support or when deciding on strategies for service management? It's just as easy to assume the Server has memory split amongst one or more sticks and go looking at it physically (or thru a console) if and when you need to investigate the capacity of the server. (this all depends upon your requirements of course).
When talking to engineers and service managers I put that question to them - how often are you going to need to know this information, how much effort would it take to maintain it in the CMDB regularly versus going and lifting up the CI's skirt and looking as the need arises?
Posted: Wed Nov 19, 2008 5:30 pm Post subject: Kind words
Thanks for your kind words. I used the same statement a few days earlier when I was demonstrating to a customer how to represent their service which had over 130 servers (financial services).
I've found that describing config mgmt as a communication tool gets the right focus. Even when you've delivered a "cmdb" you then have the problem of getting people to use the data, so you have to also create a training or education programme. One technique we've found to be vital is to produce visual service maps so that a service can be validated and also communicated to teams that don't access to the service desk such as outsourcers or data center teams.
I'm not sure if you're in the UK - if you are then there are two occasions where I'm presenting at free external events. 28th November (Cirencester, Glos) and 1st December (London Stock Exchange). Tel +44 7717 883177.
I'd love to come see you speak, but sadly I'm on the other side of the globe!
The idea of a "service map" is I think what I've been looking at myself. Do you have any examples for how you build your services maps? How specific do you get when defining your services and the config items underneath them?
Posted: Thu Nov 20, 2008 8:58 am Post subject: Service Mapping Examples
You can find examples in both white papers, presentations and conference stuff on my web site - from both me and customers. Last time I posted a link to material the admin for this site deleted my post.
If you search in Google for "cmdb visualisation using Visio" you might just come across some material and a web site that could help.
I worked with quite a few organisations now where they followed the CMDB concept, but found when they got there no one used it. Not many of the current service desk toolsets or federated CMDBs seem to be well enough developed for your average IT person to use easily. (I await the comments from other vendors saying I'm wrong). But if it was so easy and "best practice" why is it still so difficult to find real life examples? The presentations at ITIL events are thin on the ground, with asset control or software lifecycle management often being the main deliverable of CM projects, not service mapping.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum