Why there’s no such thing as a CMDB
by Tim Coote | 04 Sep 2007 | Permalink |
CMDB, Everything Else, Featured, Home Page, IT Management, Project Management, Software, Software Business Models, Software Engineering
My boss, when our team was building the architecture methods (see Enterprise Architecture), was involved with the UK Government’s development of ITIL. Because I became aware of both the ITIL documentation and the analysis that we used in developing architecture methods, I think that there’s a significant issue that’s been overlooked by many people who read the ITIL literature. At the core of ITIL pictorial descriptions, there’s the CMDB. However, in all instances that I’ve seen, these diagrams are Conceptual Models. I’ve frequently seen them interpreted as Logical or Physical Models.
CLP is a very useful categorisation of many different architectural artifacts: Conceptual models are mostly communication tools to explain what a system attempts to achieve, Logical models describe how the intention is to be achieved and form the framework for the Physical models which describe what will be used to build the Logical model.
If the CMDB in ITIL literature is a part of a conceptual model, there’s a lot of work to get to a specific physical model for a real organisation – and this makes sense in the context of the ITIL documentation – defining all of the non-functional requirements of the organisation and sets of usecases supported by the different logical components of the CMDB, such as scale, precision, accuracy, currency, consistency, etc.
The big mistake is to assume that a Conceptual model can be built directly without working through the Logical and Physical stages; which seems to be the trap that some ‘CMDB’ vendors are falling in to. A Physical implementation of the Conceptual CMDB could be many different things depending on how it is envisaged it will be used and evolve. The most likely large scale implementations would contain many products and proprietary components, tied together with suitable information flow, integration and management processes, and controlled over their lifetime with appropriate architectural governance.
I’ve seen some product visions which, in implementation, contain so much data that you’d need a small army simply to stay on top of managing the lifecycle state changes for the CIs, let alone having a viable Verification and Audit process to avoid ‘garbage in, garbage out’.
Feeds
Tideway Blog
Mike,
please tell us more. In my experience automation requires very high data integrity – or you just do the wrong thing very quickly.