The Configuration Management and Planning process is absolutely essential when starting with Configuration Management. It ensures that the whole foundation of your Configuration Management is well tought out and your Configuration Management System is sustainably built. It is usually executed only once in full detail and then only updated when extending your CMS (e.g. with new CIs / new CI-Classes (Types) / new CI-Relations ).
Experience has shown that the importance of this process cannot be stressed enough. If this process is not given its full due attention, the risk of following an aimless CoM course – with consequential financial impact – is extremely high. It is also strongly recommended that you make sure you have a powerfull sponsor. Configuration Management is a support process for others (think of accounting as an analogy) and it mainly realizes benefits through the processes using it. It is very tempting for those outside to look at the process as “a luxury” (and hence an expendable when it comes to budgeting as it is not “core business”).
Within the Configuration Management and Planning process it is vital that you define what you expect from Configuration Management from the outset. It makes a huge difference if you start with collection of managed physical IT-Infrastructure-Objects like Servers or if you are interested in storing and controling Logical Objects like IT-Services, IT Products, IT-Applications (as a group of “code pieces”).
And keep in mind: At the end of the day (maybe the year or even a decade) you should get the whole tree out of your CMS, meaning the IT Service and all its underlaying related objects. Such as Applications providing Service, Servers running Applications, Middleware managing the transactions, databases storing data, java-code executed, etc. And the processes using your CMS expect reliable, timely, accurate, authorized and traceable data. So keep an eye on your configuration control process. I firmly believe this to be the most important process for the long time success of your Configuration Management.
There is a fundamental difference between e.g. Change Management and Configuration Management. A change can be closed in the near future, but the Configuration Management System will be around for a long time. Therefore a Change Manager (or Incident Manager, or Release Manager, or Problem Manager….) and a Configuration Manager must have by nature very different attitudes, priorities and timeframes.
Again one of my favorite analogies: The product is sold, money has been paid, the accounting record is entered and the customer is happy. BUT your accounting system should remain stable and correct for thousands of future sales too. It would never cross my mind to let my sales manager (or my production manager) to also lead my accounting division.
Tags: Best practices, Process