The model is not  about
–>  a rich data model (HP Universal CMDB)
–> gaining best-practices process structure and control as specified by ITIL (BMC Atrium CMDB)

Because:   ITIL does not provide a lot of guidance in the area of Service Asset and Configuration anagement and its not about  collecting as much data as possible….

It goes beyond: It is about providing a predefined, simple, easy to use, holistically integrated model to guide the customer to successfully exploit business value with configuration management.

I suggest, that instead of concentrating of managing all Servers, all Applications, all Services with Configuraiton Management, start to think of the tree (see an example below). Think of, define, start managing the tree of one/some/all of your services. Doing so, I give you the following 5 hints:

1. Concentrate on Logical CIs
2. The tree reflects your organization
3. Group sensibly
4. Manage border logical/physical
5. Concentrate on the relevant

.

A more detailed interpretation:

Talking Service Knowledge Management System (SKMS) most people think of “Known Errors” first. It is true, this is a very important part of SKMS but by far not everything. In addition to standardized, electronically available information, which are for examples stored in the CMS/CMDB (which is part of the SKMS)  and maintained with Service Asset and Configuration Management Processes  Service Knowledge Management (SKM) is about ALL knowledge relevant for service provisioning.

Its processes are not only about maintaining the SKMS but should also cover:

a) “knowledge transfer” –> how to collect (and/or create) and  deliver the right knowledge to the right people at the right time in the right format

b) and “knowledge data management” –> how to externalize knowledge in the form of standardized data records so that it can be stored and maintained in the SKMS

But, despite the promising name this process owns, it does not cover more holistic Knowledge Management Theories such as:  ”Nonaka & Takeuchi:  SECI model / Knowledge Spiral” or  ”Organizational Learning” which has been fore example defined by Peter Senge .

Today we launched our ComAdvisor.  Invest 10 minutes of your time to answer 10 questions regarding your business case, your environment, your experience and you get convenient suggestions on how to improve your configuration management system. This is free of charge and there is no need to register.

German version is available here.

Below the GERMAN presentation including script of my speach: CoM_ITSMFDE_Bandi_Life

If you are interested in an English Version, please do not hesitate to contact me.

NO !     Whatever your approach is to build, extend, fill your CMDB.  It will take a while until you have the complete, perfect solution.   But you don’t want to wait forever to show results !  Therefore think of extending the data (CI, CI-Relations) you already have in your CMDB/CMS with discovered objects/attributes.

Be aware of the fact, that according to ITIL there is a difference between a CI and a “discovered object”.  A CI (CI-Relation) is metadata about a Service Asset (Service Asset =  Capabilities (Management, Organization, Processes, Knowledge, People) + Resources (People, Information, Applications, Infrastructure, Financial Assets) which is managed with the configuration management processes, specifically which is under strict configuration control (=change control). That means that in every moment of time you can say what was the state of it then and who, why, when requested and approved every change on it.   Even if you store your discovered data historically, you will not be able to comply with that high quality standard.

An analogy here:

*Discovered Object =  you rob your piggy bank and discover 560.– CHF (or so)

* a CI = you get your bank statement and you see that on November  15th  you had 110.–  CHF,  you got salary on November 22th, you withdrew on the ATM on November 25th, you paid your bills November 30th etc. Thats why you have a balance of CHF  xxx on your account today

So if you start using discovered data to meet your customers (e.g. other ITIL Processes) requirements for configuration information, make sure that the quality level you can deliver is transparently documented and meets expectations.

You will get a lot of information when discovering your configuration. Please select carefully which information you need or you wan’t to use in your CMDB/CMS.  Configuration Management is about the delivery of requested and reliable metadata of the configuration but not about storing the most data about the configuration!

Except initial load I do not see that a general replacement of  all your CMDB/CMS data with what you get from discovery as being a good solution.  You might end up with worse quality and you might loose the status accounting chain.

And remember, even discovery data is NOT real time data. In case you face a problem with a server you always also need to get real time data e.g. via a monitoring product or on the system itself but, if you take customer orientation seriously you allow the to launch such a product either from the CMDB/CMS or from the Discovery Result Screen.

My suggestions are pragmatic. They do not necessarily apply to a company which has plenty of resources (or the enforcement of legal constraints)  and the power to force process compliance to execute configuration control/change control down to the lowest level

Start with the fundamentals:  Don’t be to ambitious. Don’t try to manage each and every IT Object as a CI.  Think of the configuration tree I mentioned above. Actively define what object-classes your sponsor/customer requires and of what quality the data (Objects & Object-Relation) needs to be.  For more details about configuration tree, how to model it, what is relevant in this area refer to my previous article:Don’t do top-down, neither bottom-up, but tree by tree.

Invest into the relationships.  Yes, I know that is a painful topic. As in real live, it takes time, regular care, a good amount of patience and even passion.  Focus on the most important relationships to start with. Define exactly who is responsible to execute configuration control on a relationship when.   Most of the time, you will find an organization or a person in your company who manages this relationship in “real” (real = not in the metadata). E.g. the service manager liaise with the customer. The customer in this case is for sure somewhere very close to the business process. e.g. the business process owner. So the information, what business process uses which service is there in reality, as its the customers the Service Level Manager deals with.

If you have your configuration tree defined, be Smart.

a) In most cases, it does not make sense to model and maintain e.g. every CPU in a server as a CI. Why don’t just model Server-HW (and of course Server-OS above it…. ) as a CI, put this under configuration control and then attach all more detailed information from your discovery tool? Same story, don’t model the CI with 750 attributes – remember you will need to apply configuration control on these – think of modeling the CI with the important attributes and only put these under configuration control and add discovered information to the CI. Don’t forget to transparently state what quality your customers can expect from each entity/attribute.

b) Maybe you have a very well managed and highly accurate service catalogue.  Why don’t just either replicate (or federate) data from there into your CMS and state that configuration control (& change control) for services is done in the other system. ITIL says that every change has to be executed in a controlled way with the so called change process, but ITIL does not prohibit your change management process to be implemented in several instances. (I agree, thats maybe not the most efficient way, but reality sometimes require to divert from the perfect solution…) .  But remember, that won’t solve you the problem for the relationship between your service and a) your business process (up) and b) your b) Infrastructure Service or IT Resource (however you model your tree).

c)I guess, your code pieces are already managed in a central CVS and to compile/build/deploy you maybe also have additional information in there, like database subsystem to bind the package against etc. This is an excellent source for more information, especially also for relation-information.

Automation is the key. Whenever you hear of automation initiatives, try to jump on the train. Try to attach configuration control onto an automated process. Try to integrate configuration control requirements into automation. I will elaborate on this topic more in a future blog entry.

What does this mean:    explicitly define a configuration tree ?

Strictly speaking, your configuration is not a tree structure but a graph. You will find references skipping CI-Class-Levels, you will find recursions and even if you own a tool which can graphically show your configuration you will end up with too much information and therefore not have the value you expected.

By explicitly defining a configuration tree I suggest that you sit down and faciliate your configuration so that it can be managed, becomes meaningful and generates additional value e.g. for processes like IT Financial Management, Capacity Management.  That includes sensible groupings, effective omissions and focusing. Use some of your important services to verify your configuration tree structure. If you intend to work with a hierarchy of more than 6 levels be aware that it gets very complex.

With the class structures defined (including the transition from physical to logical)  you analyse the gap between what you already manage as CI’s and what is missing (or what is to much) and then concentrate on implementing the whole tree for some first single services. Try to persuade one or two of your service owners or service managers to volunteer piloting. If you have succeeded doing so, onboard the other services in cycles.

I know, that sounds very simple and very easy, but be assured, its hard work and includes a lot of discussions and negotiations.

1. Diligence of prudent definition of what the tool should do
2. Integration with other processes
3. Structure of your CMDB/CMS/Configuration Tree

1. Diligence
I own a wonderful electric drill (it was a birthday gift). It is packed in a cool black/yellow case and I display it in my library on a book shelf. Using it, is something different. I always have to think of where to hang this picture, measure its exact position, guess the size of required screws and anchor bolts. If I am happy I get the hole around there I want it to be and meets it designed purpose. Then I only have to verify the result with the water level and clean up. I am proud of my tool, but honestly, without all the definitions and integration work around its pretty useless, isn’t it?

Configuration Managagement consists of 5 sub-processes

• Configuration Management and Accounting
• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Verification and Audit

So before spending money you need to draw these processes and then think of what parts of these sub-processes can the tool support? What procedures should the tool provide to allow verifcation and audit with discovered data ? What standard reports do you need? What possibilities for impact analysis do you need? Is it possible to group CI’s? Can attributes of a CI being filled from different sources? What is the priority of such multiple feeding? What are the mandatory attributes for all CIs? Can you extend your CI-classes? How are relations managed?

2. Integration
If you briefly scan through some of the popular ITIL Overview picture you very often see the CMDB/CMS in the middle providing relevant metadata for all other processes. Therefor its easy to comprehend why integration is such an important topic when talking about a Configuration Management Tool.

Most of the interfaces deal with data to be read out of the system e.g. Impact Analysis, Change History of a CI. There are three important other integration areas:

1. Configuration Control has to be integrated with Change Management
2. Verification and Audit needs procedures to get existing Discovery tools data and procedures to compare them and provide interfaces to easily connect with existing other inventories
3. Automation

3. Structure
This goes into the same direction as the diligence entry. You have to define the configuration tree you want to manage before you purchase a tool. You need to have at least an idea of a meta model you want to deal with and the architectural prerequisites. Do you intend to store logical and physical CI’s? What relations do you want to manage? Do you need to group certain CIs to provide better usability through adjusted granularity? How do you intend to connect your logical CI’s with the physical CI’s?

And dont’ forget, Configuration Management is like Financial Accounting: a very long term activity and you don’t change the structure of your balance sheet every period, isn’t it?

If you contact us via Email, we are able to provide to you a set of requirements for a Configuration Management Tool.

We know, that within these three areas clearly defined controles are applied and enforced. So to speak, strict Configuration Management is applied – only difference – the Configuration Items (CI) are not IT Objects but screws, engines, pharmaceuticals, money. 

Such strict requirements regarding the accounting of the IT Objects (CIs) do not (yet?) apply in all areas of Information Technology.  Very often Service Providers can not deliver required transparency regarding the usage of the IT components,  such as what version of a software, has run when on which configuration; what is the change history and what was the reason of change, what are the impacted other CIs.

To provide competitively priced  IT Services it is essential to manage your relevant IT Components with the Configuration Management processes to provide a reliable and accurate data base (CMDB / CMS) to be used by all your  Service Management processes and as a solid base for automation and optimization.