Simple useful rules for defining Configuration Items
We traditionally define what constitutes a CI in terms of Change Management but are there better ways?
The old rule of thumb for what should be considered a CI is "if it is under change management it is a CI". This rule is simple and easy(-ish) to apply, but I have never been comfortable with it.
I wonder if there are things that Change Management manages that need not be regarded as CIs for Service Management purposes, though I can't come up with a good example at this point.
More importantly, using Change as a point of reference adds to Configuration's already inward-looking nature. One criticism of ITIL (and I think it still holds for V3) is that parts of it talk about being service-focused but still smell IT-focused.
I've avoided the use of the term CMDB up to this point but those attempting a CMDB will of course need some clear and firm criteria to resist the scope blowout that I say is almost inevitable.
Perhaps a better Litmus test for whether something is a CI is to ask if it is in the technical description of a Service. This is presumably a subset of the Change-based definition, so the result is a more manageable set. This is kind of circular because one needs Configuration data to answer the question, but any circular definition like that can in practice be resolved by some practical boot-strapping and iterative refinement.
Or an even more narrow definition would be whether the thing participates in delivering an SLA. If there is no SLA for a Service, then the configuration of that Service is of only internal technical interest. This ignores the issue of wanting to understand and improve a service to the point where we can write an SLA for it, but it might be an interesting way of defining the highest-priority or first-cut CIs.
Most of all it keeps Configuration framed in customer-oriented terms instead of geek-stuff.
I'm sure this post is naive and I am overlooking discussion of this question already. I did look in Service Transition to see what constitutes a CI, but found only "everything including the kitchen sink" definitions. 4.3.2 says "selected components" but I can't find any guidance on that selection process. 4.3.4.1 speaks of where to focus initially but not how to define the ultimate scope. 4.3.4.2 gives us the utterly circular definition that a CI is something under the control of Configuration management, then gives us the kitchen sink model again. 4.3.5.3 gives us broad considerations but no useful criteria - this section requires the use of expensive consultants to interpret it for a customer's instance.
So what else is a useful and simple criterion to use in selecting CI types? I look forward to your comments
Made in New Zealand 
Comments
It can be done
"...clearly has created a sophisticated GIS (geographic information system). A system that records tens of thousands of buildings, their location, and their distance from each other. Then there's a database with the names of the tens of thousands of families who live in the buildings, and the phone number of each family. The system has the ability to identify all the families and phone numbers that could be affected by an attack on any given building. Finally, given the numbers involved, there must be a system that automatically makes concurrent phone calls to dozens of families, since everybody has to have the same ten-minute warning.
Ah, and someone put tens of thousands of piece of information into that database.
Such a system costs real money, takes time to set up, and since it is obviously operating close to flawlessly, it was tested, fiddled with, tested, fiddled with, and tested again. The purpose, I remind you, is to save the lives of thousands..."
It can be done. If there is the need for a CMDB, the impediments are motivation and competency. A GIS is a better analogue for a CMDB than an ERP system. I'm not the first to say that and I think we should learn from SCADA systems as well. I've clipped the quote to remove most of the distraction of real world politics that is not relevent to my point. I can provide a link if requested.
if you throw enough money
Mike,
I suppose CMDB can be done, if you throw enough money and resource at it ... although i still do wonder at the combinatorial maths for a big shop.
But anyway let's accept that with a NASA budget and a chinese Army workforce we can do CMDB. I challenge that all that resouce and money is a good business decision, except in a small number of cases.
the analogy I like is a GPS nav in a car. A small number of users get RFOI on it: couriers and emergency vehicles. Most instances it is just there to make the geek happy. Sure he finds his way better but a map would be good enough at massively less investment.
GPS Nav
Not sure the analogy holds. At first skeptical of its value, once I tried the wife's GPS nav I was hooked. No more google maps for the kid's tournaments in some strange school; no more dialing for directions to a new restaurant; no more frantic calls to the assistant for details on a client meeting site. ROI many times over. If that's the CMDB, bring it on.
What is RFOI? Reasonable Fear of Injury?
the nice tidy wrap-it-all-up technical fix
RFOI=FatFinger :) or maybe it means ROI in the Bronx.
A GPS Nav gives you geek-pleasure, but I doubt you have saved yourself the hundreds of dollars it cost, or that you could not have made better use of those hundreds of dollars.
of course CMDB is waaaaay cool, and appeals to all of our inner geeks. it is the one ring to bind them all, the one source of thruth, the nice tidy wrap-it-all-up technical fix that is going to solve all our change and incident process problems. Once we have a CMDB we won't screw up changes any more. We'll never make the wrong priority call on incidents and we'll reoslve them in seconds. And we'll never again have to worry about techoes not writing down what thye did because we can just automagically discover it after the fact.
Install this and all that icky cultural change and process improvement just goes away.
The install team are flying pigs.
Actually sarcasm aside, a CMDB would improve things. But only a bit, and it costs an awful lot for that bit, just like that GPS nav. And unlike that nav tool, it requires a vast amount of ongoing integration development (dynamic changing environment), and data gathering, cleansing, reconciliation and audit. If we spent the same money and invested the same ongoing effort in keeping better records in simpler tools, in inculcating a proper service-oriented culture, in planning and rehearsing our impact assessment process, and introducing a bit more prefessionalism amongst our techs, I'm betting we'd get a LOT more bang for our buck.
I thought GPS was more like your idea...
...of on demand CMDB? You only see the contextual picture that you need to see to get a specific job done
Fly me, I'm a collection of CIs
The aviation industry is quite good at CMDBs as well, despite the tendency of CI's to rapidly transit between sites, though a friend did once manage to lose a brand new jumbo jet for several hours before finding it stood outside his office window. Nuclear submarines (commonly asserted to be the most complex machines) also place great reliance on configuration management.
I'm guessing we could exploit RFID if we had a mind to, it would certainly help me to trace kit that is hidden away in regional office.
CI definition via Event Management automation
I have been taking a monitoring approach to CI identification and CMDB construction for some time now, and I think it works well. It gets the focus on those things that impact a service; which gradually expand over time but usually target initial areas of pain at the outset.
I've wrestled with ITIL's definition of terms as well, but most organizations I've seen should not be spending time with this debate. It only serves to continue the hair splitting between organizational silos and leads to a 'bottoms up', inward (i.e., Change) focused approach to the CMDB. That's not what I learned in my ITIL classes either; it's the service that matters, and cultural change is the change we need to be focused on. I'm not at all convinced that endless discussions about "what is a CI" address this issue.
I use a monitoring tool that takes measurements from every layer of every component of an end-to-end service infrastructure, automatically learns the norms of all collected measurements, and if something deviates from normal behavior will automatically pinpoint which layer of which component is the source of the anomaly. I used to call this a 'CDB', but with the introduction of the CMS in ITIL v3 I suspect it's really one of multiple CMDBs
(or PMDB if you talk to Gartner). Whatever...
This kind of Event Management automation -- coupled with the ability to provide web-based personalized views of the service infrastructure to any relevant stakeholder -- presents fascinating cultural challenges in many organizations and has been the biggest hurdle to its implementation. But that is exactly the thing that needs to be addressed in many organizations!
You could argue that this does not address Change impacts and you'd be partially correct. Work flows and Policy/Process/Procedures are still essential to success, and customers who have done one (monitoring) without the other have not obtained the benefits they might have. However, focusing on service impacts is a very good way to steer your program towards things that matter.
In fact, the big gorillas are onto this --- however the acquisitions they've made and their desire for 'integrated ITSM' muddy the waters to the point of completely diluting the value of this. The automation of Event Management gets lost or watered down to the point of insignificance. You can't automate part of an end-to-end service and expect good results. In addition, the cost and time-to-value of these solutions are a disaster.
While I continue to evangelize the benefits of ITIL, CobiT, et al I am increasingly convinced that the traditional CI/CMDB approach --- focusing on Change Impacts --- leads to a bottoms up, inwardly focused adoption of ITSM. This does not address integration with the business or the cultural issues within IT which are essential to a sustained transformation. You WILL need to address Change, but it should be driven by business need and this kind of monitoring can help you do that.
Sorry for the shameless links to my blog, but it was easier than copying and seemed more in line with 'full disclosure'. In fact, you can see a slide show on this approach HERE; feel free to savage me if you disagree.
Identification of CIs based on Service Impacts can help focus on immediate needs, keep services aligned with the business and allow for gradual tuning as the scope gets wider and deeper into the service infrastructure. More importantly, it can help drive the cultural change that is really needed to successfully adopt cross functional ITIL processes. Event Management automation is key to achieving this.
Better than debating 'what is a CI' as far as I'm concerned.
John M. Worthington
MyServiceMonitor, LLC
Problem with this approach
Problem with this approach is it is a reactive approach to capturing CI data, which means you are a step behind where you want to be. There are discovery tools that will capture your initial baseline for your CMDB then you use them to verify and audit your CMDB data.
MM I agree that CI capture
MM I agree that CI capture should preferably be proactive but I dont understand where autodiscovery comes in. As you so rightly say auto-d tools are for a raw data contribution to initial baseline and then for ongoing audit. They don't capture all CIs, they don't discover complete CI information, and they don't discover all relationships. I've blogged on this (a number of times).
The place to capture CIs in as part of processing a RFC. the RFC should document the stuff we need to know.
The exception is in a dynamic groovy grid or cloud environment, where machines are changing machines. In this case we either (a) live without complete CI information (b) update it manually after the fact or (c) shift to on-demand CMDB (work it out only when we need to)
Building a universally applicable service management vocabulary
Hi Chaps
Not sure if my comments will be in context here but I may have followed a similar path to Jan VB - when I looked for a common and universally applicable vocabulary of words for service management, universal in that they could be applied to service management irrespective of whether the service organization was IT or not, there was no definitive source. I feel frameworks like ITIL have missed a huge opportunity here.
So, when I developed the Universal Service Management Body of Knowledge (USMBOK) I had to similarly dissemble and reassemble a host of concepts, terms, artifact names and the like from more than 300 service management related references. I reviewed the ITIL dictionary and V3 books and found them to be inconsistent and loose in both their definition of key items and use. The resulting USMBOK Lexicon now has over 850 terms.
I then had to invent governance to manage each. Each term is owned by a knowledge domain (roles) and preferably a knowledge area (skills) within the USMBOK, and related to other terms (that part of the specification has yet to be published on my sites). As John points out - defining these types of terms is like pulling on a piece of string or thread, there are other related terms that prove very important and warrant mentioning. So you end up having to create boundaries of ownership - and then governance - and also compatibility. Use terms in existence that are in accepted use rather than invent new ones.
As for Configuration and CIs specifically, the term metadata springs to mind - information about information. Is this what we are talking about - a data dictionary for words we shall use within a specific context? There are a number of books and a few online web sources I referenced when developing the vocab for Service Configuration Management (USM640). At the core of configuration is the word 'relationship'. My approach is that it is all about defining the relationship between a CI and a service so I entitled the knowledge area 'service configuration management'.
Other key terms that came out of the woodwork of working the key activities from a practitioner view included sponsor, owner, approval, and over 30 simplistic descriptions of the relationship of a CI. Back to the thread comment - when I connected USM640 to topics such as Facilities Management and Finance - even more terms blossomed - 'federated', 'environmental zone', 'zero-cost operation', 'rent/lease', 'virtual CMDB' and 'asset'. Naturally, I decided to separate Asset from Configuration because they have very different objectives and skills and pre-existing professional audiences.
Also, the number and type of words, even the way in which a word is defined, may prove use sensitive (see 'nail' - hammer or beautician?). As far as my work - it is all focused on customer value, satisfaction, and the management of services to ensure these two items. Universal Service Management terms and methods applicable to IT and non-IT alike.... hope this helps move the chat along.
Good luck Jan - it is a hard task but it must be done because we need a definitive vocabulary in the profession.
Hold on a mo!
I think I can probably claim to be one of the originators of that rule of thumb, but I think you've only given part of the rule, as most people do.
To quote from a slide from a very, very early V1 Managers Course when we ran them at the Civil Service College:
"CIs are things that can be changed in form, fit and function, and that we can manage"
I think that this is a more meaningful, and more useful version.
The shortened version is very close to a tautology. " How do we know it is a CI? - because we change manage it - why do we change manage it? - because it is a CI"
Does "can be changed" and "can be managed" equal "Is under change management"?
Later on we ( Ivor Evans, Mike Hill, Brian Dennis, Steve Straker and myself) began to overtly make the statement that the management of change is actually about the management of risk to service.
Then Michael Busch in Germany and myself were probably amongst the first to say that CMDB design should start with capturing system agnostic business processes as the high level CIs. That view was actually driven by making the link between ABC cost models and the CMDB. In fact I remember the eureka moment when I had an ABC model slide and a CMDB model slide next to each other and recognised that they could be combined. As an aside I've never since gone back to examine the statement that all CIs have costs associated with them but I suspect it might stand up to some scrutiny.
Activity based costing
So we get towards a definition that says a CI:
- contributes to the delivery of a service and therefore its failure constitutes a risk to the service
- is subject to changes in form fit and function
- has an associated cost (and value?)
- is within our span of control
Is that close to a MECE definition?
Simple useful rules for defining Configuration Items
A CI is used to index related process records in the CMDB. So it is important these drive the requirement. These requirements vary depending on the role an organisation plays for example:
A HW support provider may need to manage change at a part number level
A server support provider may need to manage change at a box level
A customer of an outsourcer may need to manage the change at a service level
The requirement also varies depending on the maturity of an organisation. (Low Maturity) Some people do not know what they support so they index changes by generic types of components - like a bucket CI, (Medium Maturity) Some organisations have details inventories but don't know how components relate to each other so they index changes by individual components - component CIs. (High Maturity) Some organisations have good configuration data and have developed standard builds for groups of components these guys manage changes by approves groups of components - Build CIs.
High maturity organisations also have good release management, SLM etc etc - which have their own CI requirements.
You cannot expect ITIL to prescribe the answer to what a CI is, the whole point of a CI is it can be what ever you need it to be - including groups of other CIs.
whether the thing participates in delivering an SLA
I never said I expected ITIL to prescribe CI. I'm just seeking some simple rule(s) of thumb to simplify or make more practical the all-encompassing guidance in the ITIL books. I think you and I have the same rule of thumb "whether the thing participates in delivering an SLA". The examples you cite would have different SLAs (or more generally "service level expectations" whether codified or not) which would relate to the variations in CI that you describe
Axiomatic
OK, I'm replying to my own post, but this thought was in part spawned by Rob's comment about the lack of a good definition of a CI, although it has been running through my head in a less developed way for the last three years.
Could we recreate ITSM from a very small number of coherent MECE (Mutually Exclusive, Collectively Exhaustive) definitions?
If I know what is meant by:
- A service
- "service"
- management
- governance
- process
- capability
- risk
- change
- event
- request
- incident
- cost
- value
- priority
- outcome
- user
- customer
- supplier
Could I then dervie some simple rules from then and recreate the whole of ITSM?
Obviously that list is thrown together without much thought but I don't think much more would be needed, as long as the definitions were truly robust.
it can be done
James - like Chares' answer - yes, that can be done. I've almost finished the full set of terms that I consider relevant (some 2.500) for Information Management. All terms have been defined in straight-forward definitions (MECE) of one sentence each (subject, verb, object, etc). Hard work, has cost me years of my life ;-). But the result (and the processing) was extremely rewarding. It totally clears your mind from all framework-pollution, and you'll agree that there are quite a few frameworks out there that are badly designed. And yes - it generates new terms and insight, simply by applying the defined components. It had to be based upon very robust paradigms, but now you can indeed 'recreate ITSM' from the definitions set. It beats any existing framework. I hope to finish the work early next year - still polishing and checking internal consistency and relating terms to eachother for web publishing.
Note: the value of such a system is very limited (so I wonder why I put 1000+ hours into it....). It differs from existing terms of widely accepted frameworks. Most frameworks provide 'definitions' that are not definitions at all, they can at best be called 'descriptions'. The definitions I can provide may be much better, but that doesn't mean they will be accepted :-(. They will help specialists in deriving better views and products, but 'the mass' will not be able to work with them.
In other words, a conceptual data model
This is exactly what I attempted in chapter 3 of my book... the methodology for doing this is variously known as conceptual modeling, semantic modeling, domain modeling, and so forth. It's all about MECE. Subtyping and cardinality are the primary forms of business rule expression used in such efforts.
What you will find if you do this are some core ambiguities in the ITSM discourse.
Charles T. Betz
http://www.erp4it.com