IT Infrastructure : CMDB Aims To Be

A CMDB must achieve specific goals to be successful; Advice: prioritize the issues, map IT processes to those issues; Then determine data each person needs to get the job done

Every week, IT inboxes fill up with announcements, articles, webcast invitations, and case studies related to configuration management databases (CMDBs). Yes, it’s a barrage, but it is fueled by some very real needs. IT organizations are desperately trying to improve collaboration between silos of technology expertise, bridge the gap between business performance demands and IT support activities, and improve the relationships among development, testing and operations groups. Many of these problems exist because infrastructure management information is not accessible beyond a specific management application. Service desks, software provisioning tools, networking tools, server management products, and so on all store configuration information separately, in different formats. This makes it extremely difficult to audit, correlate, and analyze information across different technologies to answer a specific question, whether it is something as simple as, “How many servers do we have?” or something more complex, such as, “What services will this database change affect?” While information access and sharing does not heal all wounds, it does go a long way toward bridging the communication gaps that have been part of IT organizations for much too long. Hence the seductive appeal of a solution that can be a “single source of truth” for all of the configuration and dependency information about technologies and business services. It can serve as an automation catalyst for any number of collaborative processes and tasks, because IT and business staff can access the subsets of information they need to perform tasks or make decisions. Information Technology Infrastructure Library (ITIL) represents this “single source of truth” as a repository and, as ITIL’s popularity has skyrocketed, so has its naming convention — the CMDB. (See “What’s in the Name?”) Needless to say, vendors have been working hard to deliver products to meet the growing demand. BMC Software was first out of the gate with a solution capable of federating information from multiple existing management tools, and it is now promoting the ROI of early adopters. CA and IBM Tivoli released their solutions last year. HP, EMC and Symantec have made several key acquisitions, and Microsoft is launching SystemCenter. Much of this vendor activity has focused on providing the technology as well as the process templates and scenario planners that will help customers and prospects make the journey from the idealized concept of a CMDB to a workable implementation. Yet for many enterprises this is still an exhausting journey. It is easy to get bogged down with any number of questions. Does a CMDB replace asset management or service desk solutions? Who owns the CMDB and the data it contains? What is the underlying data model, and how extensible should it be? Amid all of these important questions, one thing is clear — if it is to be successful, a CMDB must be implemented in the context of achieving specific goals. Enterprises have no patience for grandiose integration projects; too many of these have sunk to the bottom because planners only focused on the tip of the iceberg. To melt the iceberg into manageable ice cubes, many IT organizations are paying more attention to the planning process by doing the following: Prioritizing CMDB issues according to business impact Determining which IT processes address the issues and which people are involved in those processes Determining the type and currency of data each person needs to complete his or her part of the process Matching requirements to vendor capabilities. Prioritize CMDB Issues This first step is important for three reasons. First, it is crucial to get executive buy-in and leadership for any project that spans different organizational groups. By starting with the issue that is most visible and important to key executives, IT can garner the level of interest and support it needs to keep the CMDB project on track. Second, this prioritization helps secure IT’s position as a business enabler, because by doing so it aligns its efforts with specific business goals. IT organizations that are viewed solely as maintenance groups are more likely to find themselves under budget and outsourcing pressure. Finally, by understanding the business impact, IT can determine the metrics it needs to document to gauge the success of the CMDB project. There are many potential starting points: problem resolution, for example, is a favorite for many enterprises. The evidence is mounting that many service outages are self-inflicted by ad hoc configuration changes. A 2005 survey of 227 J2EE application managers listed configuration and tuning problems and changes to applications as two of the top three causes of application failures. Services are delivered by a wide range of distributed, heterogeneous, interacting technologies: therefore, seemingly innocuous changes to a server configuration can have far-reaching service performance and availability implications. Finding that single problematic configuration change within a complex maze of technology is extremely difficult without the ability to map all the resources associated with the service and quickly compare “before and after” configurations of those resources. Anywhere from 60 to 80 percent of mean time to repair is spent trying to determine the source of the problem and what has changed. This is where a CMDB comes in handy. It can be designed to contain models that describe how resources interact with each other to deliver a service, configuration details about each resource, and historical information about the relationships and configurations. Access to this type of information allows support teams to find and fix problems faster, thereby minimizing the financial risks to the business. Policy and regulatory compliance is another hot issue that focuses a lot of attention on configuration and change management. Many governmental regulations require some means of documenting that an enterprise has active control over the ways in which its infrastructure changes. Similarly, enterprises are looking to minimize their security risks with active configuration and change controls. CMDBs are at the heart of configuration and change management processes. The idea is to represent various configuration states (actual, ideal, and planned) so that IT can both perform and document the comparisons needed to determine infrastructure compliance with authorized policies. The goal here is to improve the level of compliance as well as to reduce the cost of audit reporting. While much of the focus for CMDB deployments centers around cost reduction, some enterprises are more concerned with business agility. The rate of deployment of new applications continues to increase; more companies are moving new applications into production on a weekly and monthly basis. I worked on benchmarking studies with CA Wily in which we found that in 2005, over a period of less than two months, 47 percent of J2EE application managers reported new application deployment cycles, compared with 33 percent in 2003. Add to that Forrester’s report that the average failed change requires 25 hours of IT staff remediation effort, and you will see that IT simply cannot support that level of application change without solid controls in place to get the deployments right the first time. A study of 98 companies performed by the IT Process Institute (www.itpi.org) showed that top IT performers were able to implement five times more changes — with a 12 percent better success rate of infrastructure changes—than the group of medium performers. In this case, the CMDB becomes the repository holding answers to such risk assessment questions as, “What other assets are dependent on the targets of the proposed change?” or, “What business services are affected by the change?” This type of information dramatically simplifies the risk assessment process. As one ITPI interviewee put it, “It is not that we don’t make mistakes anymore but that we have become more scientific in our approach to mistakes. Mistakes are seen more as learning experiences, and the mistakes have become fewer and farther between.” Processes and People Regardless of the starting point chosen, understanding the processes and people involved is critical, because ultimately the project is about improving and streamlining collaboration. Collaboration among diverse groups with different agendas does not happen naturally. While CMDBs can be implemented as physical technology, actual adoption and use of CMDBs is a highly political process. This is true for both large and small IT organizations. Each group or individual must experience the benefits of the CMDB implementation; otherwise, expect adoption to stall. For example, an enterprise can map out a problem management process that starts with identifying a specific infrastructure event and continues with assessment of the business impact, assigning responsibility, and so on. Yet the map should also include the individuals involved and the lists of benefits each would receive should a CMDB be implemented. (See Fig. 1.) There are many process templates from vendors and consulting organizations that can help IT start this mapping activity. We adapted BMC’s workflow diagrams for the examples in this article. IBM Tivoli Unified Process (ITUP) is a free downloadable tool that provides detailed documentation of processes and role responsibilities based on industry best practices. CA has process maps, demos, educational services and acceleration programs. Best-practices templates and kits are available from organizations such as Pink Elephant and the IT Process Institute. The process determination step is also important for limiting the inevitable scope-creeping tendencies. Since a CMDB is the foundation on which every IT process rests, early projects are particularly prone to scope creep. Once the planning is started, it is easy for folks to keep adding new issues, considerations and requirements. These add-ons can be difficult to rein in if the processes and constituents are not identified early. Information Needs and Sources Once the processes and people involved are determined, the focus shifts to understanding the actual details of the information itself. What are the actual information needs of the people and processes involved? This requires understanding the type of information involved, the level of detail needed, how current and secure the data must be, and what types of collaboration are needed to perform various decisions and tasks. In the problem resolution workflow example, operations staff require access to service-infrastructure dependencies to assess the impact of the event, but not detailed configuration details about each device. However, the currency of the dependency information may vary. For example, enterprises with virtualized server infrastructure may require real-time dependency information for accurate impact analysis. These considerations make each enterprise CMDB implementation unique. Where is the information stored? The data sources question is very interesting, because almost every management tool has an internal database that stores some level of information about the infrastructure it is managing. Therefore, implementing a CMDB will require an approach to: Data reconciliation, for resolving conflicting data resident in different information sources about the same configuration item. Reconciliation is usually implemented as policies that designate specific tools as the trusted source for specific types of information. Data federation, for communicating with these existing management tools. One federation approach is to replicate and store in a central place reconciled, core information about configuration items and pointers to more detailed data in specific management tools. (See Fig. 2.) The details of the scope of that core information can be driven by the needs of a specific common task. Another federation approach eschews data replication and instead depends on policies to reconcile and coordinate information dynamically accessed from existing management tools. Both approaches can be used to implement various management processes, and the choice could be driven by performance and scalability of the specific solution being considered. How should the information be maintained? Data maintenance has delivered the killing stroke to countless attempts at implementing shared configuration data in the past. Every administrator can attest to having seen inventory lists become useless within days or weeks of initial creation. True, automated discovery and reconciliation of inventory, configuration, and relationship information have significantly improved over the last five years, and thus successful collection of accurate CMDB information directly from the infrastructure itself is a more realistic proposition. Yet integrating this automatically collected information into the CMDB raises several issues. The CMDB must have the ability to represent different configuration states, such as the actual configurations of technologies in the production environment (which may include ad hoc or unapproved changes) and the ideal or approved configuration of technologies in the production environment (which is consistent with approved change processes and compliance policies). The data management processes that synchronize and resolve these different datasets must be explicitly understood for the CMDB to retain its use as the various processes and people adapt and change infrastructure information over time. Organizations that take the time to understand their actual data sharing needs will get a good understanding of the type of CMDB implementation that will be successful. Vendor Matching Once you understand your own needs, plan and vision, then you can start the search to find a vendor — not a simple task, for several reasons. It can be hard to keep from rolling your eyes at the nearly identical marketing blurbs on every vendor’s website. Yet an important part of the selection process is understanding the vendor’s vision or design concept. A design concept is made up of the assumptions and ideas behind a product’s development and implementation. For instance, what problem is the vendor intent on solving? What are the vendor’s assumptions about the environment in which the problem exists? How does it see the evolution of IT’s operational processes as the solution is adopted? These seemingly fuzzy questions are important, because the vendor must be an active partner in the success of the CMDB project. These are not throw-away projects that can be readily scrapped and restarted. Instead, they are the foundations upon which IT can continuously improve the performance of its business in the future. The success of the initial implementation and long-term enterprise-vendor partnership is often tied to how well vendor answers overlap with enterprise answers to these types of questions and will be the topic of our upcoming research reports. Another problem is the tendency to zero in on features the vendor believes are differentiating regardless of their applicability to the particular enterprise situation. The goal is to remain focused on your needs for: Visualizing the available information Representing various information needs in terms of type, level of detail, currency, and so on Reconciling conflicting information Federating and integrating information with existing solutions Managing different states of configuration and dependency information — current, approved, pre-production, and so on. Is That All? Of course not! There is always something else to consider — the CMDB standards that the vendors are working on, process automation technologies, auditing capabilities, SOA-based data integration — the list goes on forever. However, the planning process is complicated enough as it is. The key is staying focused on what is important — business goals, processes, and people and their information needs. Only then does it make sense to start talking about the technology needed to support them. The software vendors are increasingly aware that this is not just a technology feature race — the evidence is in their process-related offerings, their brand simplification, and their sales-force retooling. Yet the competition will be intense. CMDB solutions are fundamental and, if initially successful, can open up any number of other projects for both IT and its vendor partner. This is why CMDB evaluations must be entirely driven by actual IT needs and realistic business goals.