From silos to services: using CMDB federation to enable an ITIL Version 3 configuration management system

Transcription

1 From silos to services: using CMDB federation to enable an ITIL Version 3 configuration management system

2 Executive summary IT organizations must reconcile two opposing forces. On one hand, improving business outcomes through IT initiatives such as IT-business alignment, service management, datacenter transformation and application quality requires cross-domain information sharing and collaboration around the perspective of services provided to the business. On the other hand, the increasingly dynamic and distributed nature of IT environments creates more specialized management silos and fragmentation of the very business service information that needs to be shared. The IT Infrastructure Library (ITIL) Version 3 introduces a conceptual solution to this problem: the configuration management system (CMS). A CMS creates a common view of business services by providing access to information across IT silos, thus facilitating an IT organization s transformation from a focus on technology to a focus on business outcomes driven by the services IT provides to the business. By using a federated approach to a CMS, IT organizations can dynamically access information across teams and tools, resulting in faster, better, business-aware decisions that improve business service quality and cost. IT organizations pursuing greater information transparency in general, or ITIL specifically, should consider the practical requirements of a federated approach. Managing elephant parts A legend tells of six blind men discovering an elephant for the first time, each gaining individual insight to the strange beast by feeling the one elephant part closest to them one feels a trunk, one a tusk, another a leg, and so on. Their later attempt to arrive at a consensus about the true nature of the elephant devolves quickly into chaos. One can t help but wonder why the blind men didn t take turns feeling each part, so that each could know the whole. The increasing complexity and specialization of IT management has a tendency to focus management domains on increasingly discrete elephant parts. Yet the high-value initiatives and thorny challenges IT organizations face today demand that specialized IT functions make better, faster decisions that factor in the effects on other elephant parts, and ultimately the whole elephant the service provided to the business. This means that IT specialists need more seamless methods of incorporating information from other specialized domains and toolsets into both daily and strategic decisions. Whether the initiative is ITIL or datacenter transformation, security or compliance, cost reduction or business alignment, a trunk specialist must more frequently understand something about the tail. Consider: 2

3 Any practical, sustainable approach to cross-domain information sharing should be as distributed and dynamic as the IT environment it is managing. Different service desk technicians assign several user-reported application incidents to different level-2 technicians, unaware they are all related to the same router event already being worked in network operations. Redundant firefighting ensues while the end users remain uninformed about a workaround option and estimated time for the fix. An application support engineer spends hours trying to isolate a performance problem without seeing recent change records that would have uncovered the root cause in seconds. Following his company s change process, a database manager approves the migration of files to a new storage area network (SAN) partition, unaware the partition is scheduled for end-of-life the next day, resulting in a four-hour service outage on a businesscritical application. The security team can t see change request audit trails for infrastructure that underlies controlled applications, requiring weeks of effort by multiple overtaxed teams to manually pull the information together for Sarbanes-Oxley auditors. Scenarios like these play out daily across IT organizations, reducing service quality and raising the cost of service delivery and support. In each of these cases there was vital information that could have solved or prevented a problem, but the information was owned by different teams that don t talk to each other, inaccessibly partitioned across multiple systems with different contexts and data models. Accessing this data and putting it in an actionable context for the decision or action at hand typically requires a level of manual effort rarely available with today s compressed timelines and lean staffing. IT environments are already highly distributed and dynamic. With increased adoption of service-oriented architecture (SOA), virtualization and wireless devices, they are rapidly becoming more so. IT organizations must maintain management specialties to deal with increasingly granular, fast-changing business service components such as web services and virtual servers, system and business transaction events, user identities and access privileges, incidents and changes, service costs and service level agreement (SLA) status. With increased specialization comes increased risk of making local technical decisions that lead to unintended global consequences, ultimately degrading service quality, impeding time to market, raising service costs and increasing compliance and security risks. Sharing information across IT management domains is becoming more critical at the same time that information is expanding and becoming more specialized. How can this paradox be resolved? It is clearly not practical to build a monolithic IT management system that processes and stores all the information on all the parts and aspects of all business services in one place. Nor is it practical to foresee and hardwire integrations for all the permutations of cross-domain data sharing requirements. Any practical, sustainable approach to cross-domain information sharing should be as distributed and dynamic as the IT environment it is managing. A manager of one elephant part should be able to access a current, detailed understanding of other elephant parts on demand, in an actionable context. ITIL Version 3 outlines a valuable concept that points the way forward toward making this practical today. 3

4 The configuration management system provides a practical approach for transitioning the focus of an IT organization from technology to business outcomes. The ITIL Version 3 configuration management system In 2000, the IT Infrastructure Library (ITIL) Version 2 called attention to the concept of the configuration management database (CMDB) as a single source of truth about the IT environment. The CMDB was focused mostly on providing a shared physical description of IT s elephants business services comprised of configuration items (CIs) such as infrastructure components, business services, applications, processes, documentation, etc. and their relationships to one another. Lacking detailed guidance or pre-packaged offerings to draw clear boundaries about what breadth and depth of CI data to include, some IT organizations built massive custom repositories that tried to incorporate vast amounts of both CI and related management data (such as incidents, changes, asset contracts) from dozens of sources. This interpretation of a CMDB proved too vast to make work or sustain, and simultaneously fell short of providing the completeness and accuracy of information IT professionals needed to do their jobs more effectively. In 2007, ITIL introduced Version 3 with a broader endto-end service lifecycle orientation. Version 3 helps IT organizations manage much more of the business service elephant, from cradle to grave, through 27 management processes versus Version 2 s nine. ITIL Version 3 recognizes that as organizations mature toward a greater focus on business outcomes through continual service improvement, they need greater business service visibility not just of applications and infrastructure, but also service management information, how services relate to business processes and non-it service assets, and how they all interact in the value chain. Recognizing the need for a richer, broader information set to enable this larger service lifecycle perspective, Version 3 introduced the concept of the configuration management system. The configuration management system provides a practical approach for transitioning the focus of an IT organization from technology to business outcomes by providing a more complete, shared picture of the services IT provides to the business. Each IT management domain can access information managed by other domains that relate to a business service and its components, from detailed middleware configurations to server settings, incidents to software licenses, service SLAs to service users. As tools and processes from IT strategy, applications and operations are linked to this shared business service context, IT management and specialists can quickly make better business outcome-aware decisions by continuously improving service quality, cost and risk throughout the service lifecycle. The ITIL definition of a CMS reveals how it expands upon the concept of the CMDB: A configuration management system is a set of tools and databases that are used to manage an IT service provider s configuration data. The CMS also includes information about incidents, problems, known errors, changes and releases, and may contain data about employees, suppliers, locations, business units, customers and users. ITIL Version 3 Glossary 4

5 Figure 1: Whereas the CMDB is characterized as a database, a configuration management system includes tools for information integration, knowledge processing and presentation. The Integrated CMDB provides a unified point of access to information from a variety of sources, including physical CMDB repositories. Presentation layer Change and release view Asset management view Configuration lifecycle view Technical configuration view Quality management view Service desk view Knowledge processing layer Query and analysis Performance Reporting Modeling Monitoring management Information integration layer Common process data and information model Schema mapping Metadata management Integrated CMDB Data reconciliation Data synchronization Extract, transform, load Mining Data and Information Sources and Tools Project Documentation Structured Project Software Definitive Media Library CMDBs Data integration Platform Configuration Tools Software Configuration Management Discovery, Asset, Management and Audit Tool Enterprise Applications Among the differences between a CMDB and CMS: Typically, a CMDB is a single, physical data store whereas a CMS is a logical store that accesses data distributed across many systems. A CMS accesses one or more CMDBs, plus other systems and repositories, each of which is responsible for a portion of the total service information. The CMDB is described simply as a database. A CMS is a system, including tools for information integration, knowledge processing and presentation. A CMS consists of not only core configuration information in the CMDB, but also extended configuration details and management data about a CI (e.g. incidents, problems and changes) that is required to support the CI s full lifecycle. A CMDB focuses primarily on infrastructure relationships. A CMS includes more explicit guidance on how to model other aspects of services, including service assets such as organizational, process and knowledge assets. By putting its arms around a bigger picture of service management, the CMS concept in ITIL Version 3 is more comprehensive than a CMDB alone. By showing how a CMS can be a virtual system fed by many distributed systems, it is also more flexible and scalable than a CMDB alone. Whether or not an organization is pursuing ITIL Version 3, the distributed approach to cross-domain information sharing it recommends is a practical and powerful way to improve service cost, quality and risk through a collaborative service view of IT. As Dennis Drogseth, vice president of industry analyst and consulting firm Enterprise Management Associates, explains, With or without ITIL, companies need something like a CMS to organize and better integrate fragmented management tools. 5

6 Typical data integration approaches Most IT organizations, whether aware of the CMS concept or not, have traveled at least part of the way down the road to service information sharing through a variety of data integration methods. As the diagram in Figure 1 illustrates, there isn t a single silver bullet technology to build a CMS that applies to all uses in all organizations. The mix of approaches for a given organization will factor in integrations already deployed, IT and business priorities, organizational structure and politics, the tool environment, how and when the data is to be consumed within a process, and of course, the nature of the data to be shared. Traditional integration approaches, however, each have limitations in meeting the growing need for cross-domain service data access. Point-to-point integration The most common approach to data sharing is pointto-point, hard-wired integration among applications and repositories. Point-to-point integration can be an economical data sharing approach when there is certain information that only two applications will ever need to share. Or there may be a millisecond-order performance requirements as with highly synchronous transactions between two applications. It is also appropriate when two applications need to replicate data from one another. Finally, there is the practical consideration of using integrations that already exist and are performing well enough. However, if one believes that far more data must be shared across many domains to meet IT s biggest challenges such as IT-business alignment or datacenter transformation, there are significant limitations in using point-to-point integrations as the primary basis for a CMS. First, in a many-to-many scenario where more than one application needs data from more than one source, the number of point-to-point integrations can become very costly to set up and maintain. The integrations are also brittle a change to the application on either end of an integration usually requires modification or replacement of the integration. Finally, and most importantly from a service perspective, two hard-wired systems are unlikely to share an accurate service context. For example, a change manager wishing to verify that there were no negative impacts from a recently completed database change could use a pointto-point integration from her change management system to see the database s performance status in an event management system. But it would be far more complex to query about the health of the service were there any negative impacts to the applications or middleware that depended on that database? Data warehouse Another approach to consider is a data warehouse that consolidates many cross-domain attributes about many business services in one place. Data warehouses play an important role in a CMS by providing reporting and analytics on large volumes of data across a span of time, such as monthly service cost analysis or projecting likely incident demand for a new business service based on patterns set by previous services. 6

7 But for most companies, data warehouses cannot serve as the only CMS integration mechanism because the latency (delay) in loading information from source systems to the data warehouse is too high for many uses of a CMS. Much of the information IT managers need on a daily basis is highly dynamic, changing hour-to-hour or minute-to-minute. The availability state of a server, recent operational events from monitored applications, incidents currently open, the progress of a change request and the status of an SLA are just a few examples of information that require up-to-the-minute accuracy. Much of it would be unusable or unreliable just seconds after loading into a warehouse. Replication into a CMDB For organizations that already have or are considering an Integrated CMDB, another approach to consider is replicating (copying or propagating) data from external sources into the CMDB database. Just as there is a place for a data warehouse in an Integrated CMS, there are also cases where replication is appropriate. For example, it may make sense to replicate information that is relatively static (does not tend to change within a day or week) that must be available to consuming applications in milliseconds. Data from discovery tools is the most common example. Organizational data, such as business units and cost centers, may also be needed to quickly place CI users, owners and locations into fast context for client applications. As already seen with a data warehouse, daily batch replication is not suitable for the highly dynamic data that many IT operations scenarios depend on. But even when limiting the possibilities to static data, it is relatively easy for a CMDB to suffer from mission creep and quickly bloat to an unmanageable state given the many constituents who ultimately want to access cross-domain data. The early failures of overly ambitious CMDB projects that collapsed from the weight of trying to be all things to all people have already shown this is not a practical approach. Companies tempted to replicate a mere subset of management data to keep the CMDB more manageable might do their best to guess which data will be frequently accessed enough to make the cut. But making accurate predictions about which subsets of data will be needed over time by a variety of specialists is perhaps even less likely than successfully managing a petabytesized CMDB. Although point-to-point integration, data warehouses and replication offer solutions to some CMS uses, a more dynamic and flexible approach is needed to create the scale of data sharing demanded by today s broader IT and business initiatives. Making the CMS a reality with an actionable federation approach A more scalable and flexible means of enabling a CMS is through a federated approach. Wikipedia provides a general-purpose description of database federation: A federated database system transparently integrates multiple autonomous database systems into a single federated database. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging together several disparate databases. Through federation, a virtual CMS is created by linking data from multiple repositories through a common service context. As ITIL explains, Often, several tools need to be integrated to provide the fully automated solution across platforms, e.g. federated CMDB. (ITIL Service Transition, 7.3) A federated approach allows specialized management tools and repositories to exist in their current forms, using federation services coupled with an Integrated CMDB to facilitate the sharing of this specialized information among various IT management domains. With a federated approach to a CMS, an organization s existing tools and repositories work with information in an Integrated CMDB to form a large virtual database of information related to the services IT provides to the business. The Integrated CMDB physically stores core service data focused primarily on identifying CIs, basic attributes about each CI, and the dependency relationships between CIs and services. Extended service data is all the other unreplicated data that remains in external sources but made accessible via federation through the Integrated CMDB. 7

8 ITIL Version 3 refers to these external data sources as data and information sources and tools. For the sake of brevity, this paper will simply refer to them as federated data sources, or simply data sources. Federated data sources are simply tools and repositories that hold service information other management domains may need to access. Federated data sources may hold information about certain CI attributes or the management of CIs, or they may be the authoritative source for a class of CIs (e.g. a Lightweight Directory Access Protocol (LDAP) server may be the authoritative source for people CIs). Federated data sources may include any number of IT management tools (service desks, event management systems, IT asset repositories) as well enterprise systems such as LDAP, HR and enterprise resource planning (ERP) systems that may provide detail about service users, service provider partners, cost centers, financial records, etc. These systems do not need to be modified to participate in the federated CMS: Federation adapters (data adapters to specific data sources) make selected data from the federated data sources available on demand. An actionable federation analogy: travel website The practice of federating data is a common and proven concept, amply illustrated by many websites. For example, arranging a trip has been made simpler and more powerful through travel websites such as Expedia, Travelocity and Orbitz. Any one of these sites provides a single logical information source that federates across many disparate sources, from airline, hotel and rental car systems to street maps, attractions and activities. A single query to the travel website returns a coordinated set of answers spanning air, car, hotel and even sightseeing attractions. These results are actionable: they can be sorted, reworked based on new parameters such as different travel dates, and ultimately transacted upon. Similarly, a federated CMS can provide a single point of query about virtually any aspect of a business service, from infrastructure components to applications, detailed configurations to specific management data, regardless of where and how that information is independently managed and stored. Core versus extended service data A chief concern in CMS design is determining which data about the services provided to the business will be core (physically stored in the Integrated CMDB), and what data will be extended (federated from external data sources). Although there is no one precise answer to fit all organizations and cases, there are some best practices to consider. To keep the Integrated CMDB manageable, core service data is typically reserved for the minimum CI data needed to establish a model of a service configuration, and thus provide a context for linking to the appropriate extended data. Data is typically treated as extended service data (left in the external data sources, not replicated) when it is not needed to establish a model of a service configuration. Often (but not always) this data is more detailed, less frequently accessed, and/or more dynamic (changing more than once a day) than core service data as a practical consideration it may be simpler to access such data on demand from external data sources rather than replicate it into the Integrated CMDB. Extended service data can include both configuration data (information about the service and its components), as well as management data (information relating to the management of the service and service components). Some configuration and management data may be processed data (i.e., information that is the result of business logic applied in the data source application). 8

9 Figure 2: A federated CMS approach allows specialized management tools and repositories to remain in their current forms. The Integrated CMDB facilitates the sharing of this specialized information among various IT management domains. Federation services are tightly coupled with the data model of the Integrated CMDB, using its stored CI and service mappings to map extended service data into a common context. Client (consumer) Client integration SVC owner End-user experience Integrated CMDB Core service data Discovery Configuration Federation Registry setting Scheduled change Project and portfolio J2EE UNIX Clients WANs SANs User identities SLAs Owners Extended service data Changes Incidents Events License usage Projects Costs Business service automation SLA status Compliance status Security status Configuration data Management data Processed data Application quality Service desk Your environment Asset Business service management LDAP Outsourcer s CMDB Data sources For example, a set of CI records representing basic information about the configuration of an SAP Financials service and the dependency relationships among its software components and supporting infrastructure is physically stored in the Integrated CMDB as core service data. With a federated approach, the CMS can be queried for this core information in the Integrated CMDB, and also the extended information managed independently in federated data sources. CI data in the Integrated CMDB becomes the jumping off point to access far richer information about SAP Financials in federated data sources such as: Configuration data Detailed settings for the virtual server instance running an SAP Financials module in VMware Registered SAP users in an LDAP repository The record of what configuration setting changes were made to an associated load balancer in a network management system A business process step in a business process management system Business value and outcomes expected from a service in a service level management system Management data Recent planned changes to SAP Financials in the service desk system A software license governing the use of an underlying Oracle database in the asset management system Online/offline status of a database server Known defects for the current SAP Financials release in an application quality management system 9

10 Processed data Compliance status of SAP Financials users access rights in an identity management system Server configuration policy compliance status in a server automation system Transaction status of a high-value payment going through SAP Financials as reported by a transaction management system Multiple CMDBs As we saw in the previous summary of how a CMS differs from a CMDB, a CMS includes an Integrated CMDB that can access information from more than one CMDB. ITIL provides an example of where multiple CMDBs may need to be accessed through the CMS: In the commonly encountered partially outsourced service provider, some elements of service management will be outsourced while others will remain in house, and different elements may be outsourced to different external suppliers. For example the network and hardware support may be handled by supplier A, environment and facilities management by supplier B, and multiple applications suppliers and incident management handled internally. The service desk will access information to assist them from the CMS, but that system will derive its data input from discrete repositories each one a CMDB owned and maintained by the three parties but working together to supply a single consistent information set. ITIL v3, Service Transition, A similar multi-cmdb scenario may be appropriate for existing tools that have their own special purpose CI repositories considered to be CMDBs. Another multi- CMDB scenario may be appropriate for distributed IT governance models where business units each have their own discrete IT services yet share some common services across the enterprise. By federating to CMDBs as data sources, a CMS can provide a consolidated view of all the discrete business unit services, shared services, and their inter-relationships. Making federated information actionable A key requirement for maximizing value from a federated CMS is ensuring the information it provides is actionable, i.e., usable by applications and users to make service-aware decisions and take service-aware action within their roles to improve business outcomes. With an actionable federation approach, federated service information is accessed and used just like the application s own native data. The key to actionable federation is a combination of transparency and context. Behind the scenes, queries from client applications involving CMS data are directed to the Integrated CMDB, which in turn queries both the physically stored data in the Integrated CMDB and federated data in external sources. The physical location of the federated data is transparent to the client application. Query results are then delivered to the client application in context of its own data model and user interface so they can be programmatically consumed, displayed, sorted and acted upon by the client application s business logic. 10

11 Combining transparency and context is the key to making federated data actionable. Thus, actionable federation allows IT specialists from one domain (e.g., network management) to use their familiar tools to access information from data sources in other IT domains (e.g., application management) without learning how to use unfamiliar interfaces. Not only do they not need to know which data source holds the desired information, they do not even need to know they are querying the Integrated CMDB. As far as they can tell, the application they work with every day now simply has a richer set of information available to it. With actionable federation, the extended service data is delivered to the fingertips of specialists at the time and in the context of the decision or action being worked on. Hence, the CMS enables different IT domains to function collaboratively by leveraging the power of the combined information around the common context of the CIs that make up a business service. Conclusion A federated approach to information sharing is emerging as the most practical, scalable and sustainable method for supporting IT initiatives requiring greater collaboration across management domains. ITIL Version 3 s recommendation for a configuration management system (CMS) will increasingly drive industry investment in both technologies and best practices that embed federated approaches into the fabric of IT management, whether or not they are ITIL-centric. As IT organizations make further investments IT management should consider how those investments will support higher service quality and lower cost and risk with a federated approach to cross-domain collaboration and automation. 11

12 To learn more, visit Copyright 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Oracle is a registered U.S. trademark of Oracle Corporation, Redwood City, California. UNIX is a registered trademark of The Open Group. 4AA1-5978ENW, May 2008 Technology for better business outcomes