Modeling data in a Configuration Management System

For all the talks about ITIL v3 and the Service Lifecycle these past 2 or 3 years, any large organization today that puts in place the proper processes and tools to manage its business services still faces the daunting task – well it’s never trivial for sure – to model existing IT resources. One can only assume that the new stuff will be modeled at design time when IT has all the clues about what they are doing for whom; but the old stuff that is already out there is a different story. Some of it can be discovered automatically; some of it can be obtained from various Management Data Repositories. Yet any attempt on a large scale to build (and maintain) a topological representation of an IT environment takes some work.

 

Let’s put here that we are in the shoes of a big corporation that has taken the step of deploying a Configuration Management System (CMS) to assemble a single version of truth about their IT. A CMS is indeed ITIL’s conceptual approach to create a common and dynamic representation of business services – one that can reconcile discovered data, replicated data and increasingly federated data. Quickly enough you can get all these data flows “bringing in” Configuration Items – call them objects if CI rings dull – and all their relationships. So we have a topology or more accurately a large amount of disjoint graphs – some highly interconnected with hundreds, possibly thousands of objects, others much smaller. Even if the IT Department is conservative in how they run discovery, those “IT molecules” that become available through the CMS can represent all together tens of thousands, hundreds of thousands or (but then the IT guy would have pushed all the buttons of discovery) millions of objects.

 

As much as customers would want the CMS to present them automatically with all the constructs and all the views that they need at that point, this is not the reality. First, only a few DDM tools on the market have the technology and the content to fully map an enterprise environment. Second, very few CMDB products can do effective and granular data federation against a wide range of MDRs. Even if you get that far, the last leg of modeling which is about making all that data consumable or actionable is the part that is the most demanding for products. Said simply, users must be able to find the right data, scope it, combine it and visualize it in various ways. The only trouble is that we are dealing with complex graphs of objects using a rich data model, vast quantities of data typically stretching across repositories, a landscape that is all but static and plenty of similar situations requiring a similar handling. Being able to define and execute advanced topological queries and computations is a science. Putting that science in motion effectively against that kind of constraints confines to art.

 

If you asked me which products are flirting with art and which ones are not quite there, I would tell you but then you might not take my word for it; so instead I will explain myself a bit… in my next post :-).

Tags: CMDB| CMS| Model| Topology
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Olivier is Product Line Manager for the HP Configuration Management System (CMS) which is comprised of UCMDB, UCMDB Configuration Manager, ...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.