When I worked at HP OpenView in the ServiceDesk team in Amsterdam I was in fact hired solely for performance engineering and testing. At that time (2003) I had very little experience of ITIL but I had spent a large amount of time at Borland thinking about possible designs for service management solutions for Java enterprise applications. During my performance work which focused on issues with the design of the HP model I came to the conclusion that the HP approach was fundamentally flawed. This was probably easier for me to see because I did not have the baggage that others had inherited from their initial attempts at a CMDB offering in the ITSM product OpenView had acquired.

Following on from this I looked in detail at the other management domains and how HP had tried to tackled them and came to a similar conclusion - the interpretation of ITIL was wrong (not that ITIL is prefect) and the translation to a product design was poor. I became the official party pooper for the whole of open view - the joys and sorrows of a vision.

regards,

William

Let me try once more with regard to the second last paragraph. The managed model of the particular user laptop is hidden (encapsulated) within the entity it is associated. This allows us to model more CI types but be more selective in the instances as well as the life time of the (change) management sphere.

Simply - management models need to be contextual. We need different types of models with different levels of control and life cycles that reflect their usage within the context of the particular IT management organization and balance overhead with value.

regards,

William

The information model represents the complete state of the universe (a IT domain lets say). This state can be highly dynamic (volatile) and static and spread across many repositories (information stores). One should not constrain a repository to represent some persistent store such as a registry, database or file system. A repository could have a life cycle that is as short as the lifespan of an operating system process.

The managed model is a subset of the information model that is placed under control in terms of a change management process. It is possible to have nested or multiple manage models with each having a sphere of control that is tied to the life cycle of an entity including an IT management domain, CI, or even an incident. At the end of the day a diagnostic image generated in the event of an error within a production system is really a snapshot (and subset) of the information model. Some of the information model might relate to items and aspects of the current manage model(s).

The problems with current CMDB systems is that they do not distinguished between what is actual managed and what is unmanaged but and possibly pulled on demand from federated repositories (note I said repositories rather than federated cmdb’s). Now this distinction is actually good for end users of systems including service desk users trying to ascertain lets say the the system state of an users logging a service call related to his/her laptop. The hardware units might be part of the manage model but not necessarily the software packages but knowing the software packages installed might be useful within the context of that particular service call but not within the overall IT management. The software packages belong to the information model but are not placed directly under change management because the overhead of its management is deemed higher than any perceived benefits. Now when this issue arises today within organizations adopting ITIL with the current crop of solutions the immediate reaction from the change and configuration management team is to place all software packages installed on laptops in the CMDB. The CDBM starts to grow and grow and all those export and import scripts keep ITIL consultants busy all day long. But I understand we (IT management) do need to track lets say the provisioning of new software on the users laptop but the problem is that the CMDB designers always want to model every instance of the CI type which means all other user laptops. The solution is to create a manage model which represents the current state (hardware and software packages) and proposed state (transition) and tie its management sphere to the life cycle of the service call and associated work orders. This lessens the overall workload of the global management model and makes change management model local and hopefully efficient.

I am rambling a bit here but I hope I have started to paint my vision which is simpler (at least from a process) and more scalable.

Kind regards,

William

I just had a quick scan through the specification which to be honest I have not really tracked and I am somewhat disappointed that there is not a clear distinction between the information model and the managed model within the CMDB. This is something I introduced at OpenView during a time I was contracted to HP for solution design. I had though when I left that others would have taken this up and maybe so but apparently not within this specification which seems more focused on the data source adaptors. I need to really read this in greater depth.

In my opinion the biggest mistake made is not having this distinction as it then opens up the possibilities of other data sources that are more more dynamic, transient and less managed though very important when performing incident and problem management. In my model the actual runtime state of systems and components which can bear some resemblance to the static and managed configuration is also accessible to ITIL processes. In fact I based my whole design of JXInsight JVMInsight on this.

I introduced this in version 4.1 (http://www.jinspired.com/products/jxinsight/new-in-4.1.html) and further extended it in JXInsight 5.1 (http://www.jinspired.com/products/jxinsight/new-in-5.0.html).

It is like merging of delta debugging with configuration management where configuration reflects the software execution model and not just the files and records that parameterize the operations of systems and processes.

I intend on writing up a blog entry that explains this and shows how CMDB concepts can be brought into the developers world.

kind regards,

William Louth
JXInsight Product Architect
CTO, JINSPIRED

http://www.jinspired.com