Working with clients over the years has taught us that your organization’s CMDB ( Configuration Management Data Base) can be both your biggest asset and the easiest sandtrap for Service Costing projects. Understanding the strengths and weeaknesses of your CMDB will allow you to set initial expectations for integration and plan a roadmap to maturity in partnership with the CMDB team and the data owners.
A CMDB is the central repository for the assets in your organization, their attributes and relationships. Correctly configured, it will ,for example, tell you what servers your applications run on, how much storage those servers have allocated, what type of server they are, and if they are development or production. That is just one example of how you could leverage the CMDB to build the cost components in your model- but when things are not configured correctly, the data can quickly go askew. Here are some of the most common problems we see in CMDB installations, and are things you should assess for:
•Asset Classes not well defined– Every asset has a class, or type. It is a “server” or “application”. If the classes are not well defined, we see desktop software getting mixed in with applications and applications with services. Check with your CMDB owners and see if there are published guidelines, then spot check the data to see if it follows those guidelines.
•Relationship Type usage is inconsistent- The immense power of the CMDB is unleashed if there is defined and consistent usages of relationship types. If you know that “runs on” is always used in one case and “hosts” is used in a different case, the CMDB can become incredibly powerful. Too often we see that the out of the box drop downs are available in all cases and without guidelines data owners choose what makes sense to them, but there is no consistency. If you are using an auto discovery tool, it can be configured to fill these in with defined logic-be sure that configuration was set.
•Relationship Coverage is incomplete- Remember the 3 Cs of Data- Consistency, Completeness and Correctness. If the relationship values are not required and are only filled in part of the time, it looses value to your allocation model.
•Orphans- These are assets that do not have any relationships specified. If you are going to leverage relationships to calculate allocation metrics, these assets will not get their fair share of the costs, and everyone else will be overcharged.
•Bad Relationships- In the modern IT Environment, change is a constant. This means that relationships in your CMDB need to be updated as part of a change management process. If this is not required, or you do not have auto-discovery in place, it is too easy for a relationship that was true a year ago to be incorrect today. It is also important to pick the correct granularity of relationships in your CMDB so that this does not require constant effort and syncing. If you have a highly virtualized server environment with auto-load balancing and your virtual servers are being constantly shifted from one host in a cluster to another, the relationship should be from the virtual server to the cluster- not to an individual host. The design of your CMDB can have impact to your Service Models, so make sure you spend some time with the team and understand the level of detail available and why.
- Circular Relationships-Enterprise class systems have many moving parts- applications, middleware, databases, servers, storage, etc. It is all too possible to accidentally create circular dependencies in your CMDB when you have lots of moving parts whose data entry is owned by several teams. Most CMDBs do not error check for the circular dependencies ( and they may be physically true, although this is a point of potential risk for the system). However, if you are going to “follow” relationships to calculate cost allocations, a circular relationship will throw your model into an endless top spin. When these are 3 or 4 step circular relationships, they can be very compute intensive to find, especially in a database with millions of rows. We highly recommend that you do an extract and use an offline tool to find them and make decisions about the impact to your design, rather than trying to write complex code in your CDMB and bringing your production instance to it’s knees. This will require code ( not simple SQL queries) to find, as SQL cannot do the recursive actions required.
- Meta Tag/Attribute Completeness- sometimes, for one of the reasons above, you many not be able to leverage a defined relationship in your CMDB. Do not fear- the attributes are here. Many times when a CMDB relationship fails, you can leverage attributes to link data and create new relationships. For example- the “runs on” relationship may not be consistently used for applications, but then you discover that there is always a server host name for an application entry. That attribute tells you which server the application “runs on”. Understanding which classes have useful completeness for which attributes can be a powerful design aid as you plan out your service models.