Modeling data in a Configuration Management System (part 2)

In my previous post, I was writing that even when you get the right combination of discovery and integration capabilities, you are still faced with the challenge of modeling data in a way that people can make sense and use of. Let’s not get distracted here by the fact that some environments are easier to model than others, or even by the question of how the business CIs get into the picture. Instead let’s acknowledge that there will be some manual work involved no matter what and let’s look at the kind of product capabilities that can help customers handle that part better, faster and in a way that is sustainable.

 

It all starts with the ability to query – the ability to query graphs that is. By necessity, all CMDB products have such capability. But not all have the features that you would expect. For example, being able to indicate that a branch of the query is optional, as in “we want to capture it as a valid ramification if it’s there but we still want the rest of the graph to match if not”. That’s called Relationship Cardinality. Pretty important imo. By the way, we just announced HP CMS 9.0; and in the UCMDB product, you will see that we now have indicators to represent that information directly on the graph while before you had to look at the properties of each relationship. With that, you can picture at a glance what the core skeleton of the query is.

 

Of course there is another aspect of topological queries that must not be neglected and that is the result – what gets displayed. Let’s think of a basic query that builds from object class X and has two mandatory branches. In any CMDB out there, these graph conditions will determine whether object instance Xi is a match or not. But what will you see when the query returns its result? What you want to see up front is the graph that matched the query – no less, no more. Unfortunately some CMDBs don’t remember the query’s envelop at display time and just give you Xi or Xi plus n levels of expansion around. If you were a biologist trying to isolate a molecule starting from a particular type of atom, you would want to see your molecule at the end of the experiment – not just an atom or that atom plus a few atoms around that may or may not belong to the molecule of interest. Restituting the context established by the query definition is important from that standpoint. What makes it fundamental is the fact that a topological query is just a building block in your modeling project.

 

At the simplest level, you will want to be able to leverage that query in a view where you can group nodes together using a regular expression on some attribute for example – the idea being to visually compress the matching graphs but without losing their true scope (we call that a pattern view at HP).

 

If your query returns a large number of matching graphs that should really be split into multiple views, then what you need is the ability to parameterize your query. Most CMDB products offer that capability. Where UCMDB tries to go one step further is by letting you define a template that will contain the parameterized query, some folding rules for the visualization and even permissions. That way, the N views that you wanted in the first place get create faster as template based views. And if you edit the template, the N views inherit the change.

 

So far though, we have only looked at how to scope relevant graphs of objects and how to control the display without degrading the scope. The next step in modeling (for some that’s where modeling really starts) is about providing a higher level context around the data that is initially available in the CMS. That context can be a logical context, an application context or a business context. Typically it materializes in the form of a new CI. That CI becomes the basis of a model that contains a slice of the IT environment. To stay away from the can of worms (i.e., is that parent CI a business application, a technical service, a business service or a business process? Etc) and also because we use that name in UCMDB, let’s call it the base CI.

 

In its simplest form, a model is composed of a base CI with relationships pointing to other individual CIs that have been selected manually. Typically, these individual CIs can be organized in logical groups within the model. UCMDB supports nested models as well; plus you can manually scope the model by defining a chain of CI types known as a reveal path. Since static models require a lot of maintenance, some CMDB products have a concept of rules that can automatically add CIs to a model. In UCMDB, that functionality is known as watch points. Alternatively it is now possible to define a pattern based model using a topological query to dynamically capture designated classes of object within the matching graphs.

 

But models, whether they are static or dynamic, have a limitation in the sense that they always show the same face. Hence another important capability that you want from your CMDB is something that has to do with “being able to see what you care about” beyond the base view of a model. I was on Google Product Search a few hours ago and they had a nice set of entry points that they had created on the front page for Father’s Day. So I picked the first one: Flat panel TVs; and instantly I was looking at a sub-view providing specific information about that kind of product. Now if you were interested in cordless drills, there was another sub-view for that. UCMDB has implemented that concept of perspective since 8.0. Practically a perspective is like a template (i.e. a packaged graph query) but in addition it has a contact node to indicate which type of CI in the base view is a valid entry point for that perspective. With UCMDB 9.0, that capability has just become more powerful where you can now have multiple perspectives per view (like one for the Network Admin expanding into IP endpoints, one for the Application Manager expanding into running software, and one for the Security Manager showing maybe the installed security patches – out of the same base view showing computer systems). And, yes, you can do a perspective on top of another perspective.

 

What I have tried to illustrate in just a few paragraphs is that being able to model existing resources from within your CMS requires a rock-solid graph query capability that can preserve its scope. Then you need a palette of tools that can build on top of that (having a good workbench at the UI level can only help). All that must come from your core CMDB product.

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.