Service level management: A dynamic discovery and optimization approach
IEEE Transactions on Network and Service Management
A performance and usability comparison of automated planners for IT change planning
Proceedings of the 7th International Conference on Network and Services Management
| Hi-index | 0.00 |
We describe best practices for deploying a Configuration Management Database (CMDB) that we have developed during several recent client engagements. Given the complexity and novelty of CMDB solutions that deal with discovering, storing and tracking actual Configuration Items (CIs), many enterprises rely on service delivery organizations - such as IBM Global Technology Services - to perform the configuration and roll-out of the system into production. This can be either done on the customer premises (within the scope of a so-called project-based service engagement), or by subscribing to a managed service, and thus leveraging the IT service management environment that the service provider has already set up. Often, enterprises severely underestimate the effort involved in setting up IT service management infrastructures by mistakenly equating the setup of such a complex system with the mere installation project of a shrink-wrapped, self-contained product. This, however is not the case: The immense heterogeneity of data center resources makes that no single vendor can cover the breadth of managed resource types when new product versions ship every 12 months, often by means of integrating acquisitions into the product portfolio. Consequently, today's IT Service Management systems rather resemble construction kits and frameworks that require a good deal of tailoring and customization to become useable and useful to the customer. The present paper attempts to provide an insider view into the issues that a CMDB deployment architecture needs to address. In our work, we found that the success of a CMDB deployment project can be attributed to a set of tradeoffs and best practices, especially when it comes to tuning the performance of the system and orchestrating the distributed components of a CMDB so that they work well together. By grounding our work in a concrete case study and by referring to real-life requirements, we demonstrate how to develop an operational architecture by using an off-the-shelf CMDB product. We point out the key design points of our architecture and describe the tradeoffs we had to make, which we subsequently distill into a set of best practices that have been successfully applied in sizing, estimating and implementing subsequent CMDB deployment engagements.