Federation and a CMDB

BEST PRACTICES WHITE PAPER Client Solutions BSM e: bsm@clients.ie t: 01 620 4000 w: www.clients.ie/bsm Federation and a CMDB

Table of Contents EXECUTIVE SUMMARY...1 WHAT IS FEDERATION?...2 Federation and Configuration...2 UNDERSTANDING THE CONCEPT OF FEDERATION...2 Library Card Catalog Analogy...2 Differentiating Types...2 Which Core CI Must a CMDB Store?...3 Value of a Federated CMDB Approach...3 Don t Federate Core CI...3 Normalization and Federation...4 ACCESSING FEDERATED DATA...4 What Constitutes a Link?...4 Methods for Linking to Federated...4 IMPORTANT BENEFITS OF A FEDERATED CMDB...5 WHAT SHOULD A FEDERATED CMDB LOOK LIKE?...5 ADDITIONAL POINTS TO CONSIDER...6 Federation: Not the Answer to Everything...6 CAN I HAVE MULTIPLE CMDBs?...6 DIFFERENT APPROACHES TO FEDERATION...7 base Federation...7 Virtual Stores...7 CONCLUSION...7

Executive Summary Growing momentum behind IT Infrastructure Library (ITIL ) initiatives has turned the configuration management database (CMDB) into an industry reality and the concept of data federation is at the forefront. Organic development and IT management tool implementations have increased significantly in recent years, leaving many organizations with data that is pertinent to millions of configuration items (CIs), such as servers, routers, people, business services, and processes. That data also includes relationships and management data related to the CIs. In these IT-laden environments, federation can provide the foundation for creating a CMDB that is scalable, adaptable to fit existing IT infrastructures, and addressable by all applications that need to provide or leverage CMDB data. A federated CMDB should provide an accurate, single representation of data from which to work, for all IT processes. This paper discusses the concept of federation, how federation should be approached in the context of a CMDB, and the key requirements for building a federated CMDB approach. PAGE > 1

What is Federation? Federation is a method to provide a single way to access data held in many different locations. Federation allows data users to search and utilize data without needing to understand exactly where the data resides or the technology behind accessing the data. As an IT organization evolves, many different types of technologies and systems likely have been implemented that store different types of data for different applications and users. By linking together these disparate data sources, data federation helps provide a consistent way for users to access cross-functional data without requiring organizations to replace their specialized solutions. Federation and Configuration Configuration, as an ITIL discipline, focuses on managing and maintaining information about the configuration of an IT infrastructure. ITIL considers the CMDB to be a key component in configuration management. When it comes down to it, what a CMDB provides is actually pretty simple: a central location for storing basic records related to the CIs (servers, routers, desktops, business processes, and such) in an organization s production environment and the relationships between those CIs. The CMDB provides a single source of record on which IT processes rely, providing accuracy and consistency across processes. However, what ITIL does not define is how to approach a CMDB implementation or how to organize data to create a scalable CMDB solution. This paper focuses on how federation helps answer the how questions related to CMDB implementations. For more information on other aspects of the CMDB and detailed examples of what should and should not be considered as CIs, please refer to the What You Need from a Configuration base white paper available at www.bmc.com/cmdb. Understanding the Concept of Federation Library Card Catalog Analogy Consider the concept of federation, as it relates to a CMDB, as being similar to the library card catalog system. What is a library card catalog? The card catalog found in every library is a single source in which to find basic information on any book in the library system. This is similar to what a CMDB provides to an IT environment. A card catalog provides users with different ways to search for library books, based on title, author, category, and so on. Each method available for finding a single book provides relationships between multiple book reference cards and information on where the actual book is stored in the library. The comparison of the federated approach to a library card catalog is referenced throughout this white paper. Differentiating types When considering a federated approach to a CMDB, it is first important to understand the different types of data that help define a CI and its attributes. This is helpful when determining which data should be stored in a CMDB and which data should not. A configuration item (CI) contains three types of data: > Core CI data: that defines the CI, its attributes, and relationships with other CIs. Example: A server, its name, and attributes (such as amount of memory, CPU speed, location, users) and how that server relates to other CIs like a business service CI. > Detailed CI data: that provides highly detailed information about a CI. Example: Registry information and settings on that server. > Related CI data: Information that does not describe the CI, but rather provides information about that CI. Example: Help desk tickets, change requests, and other incidents related to that server. We can define data about books in a library in the same way: > Core book data: Information such as author, title, year published > Detailed book data: Chapter information, indexes, appendix, page information > Related data: about book reviews, user opinions, related books that might be of interest Dissecting the library card catalog helps us understand which type of data (core, detailed, or related) should be stored in the card catalog and which data can reside in other locations. For example, a library book s core data would be the information that is required for readers to be able to find the books they need, such as author and title, and must be part of the card catalog. However, additional information related to books does not need to be stored within the card catalog. Think about what a card catalog would look like if you were able to search and view chapter information, user opinions, and PAGE > 2

Contributing Factors Objective Measures Measurement Approach > Asset name > Asset type > Asset ID > Amount of memory > Size of hard drive > Serial number > Operating system registry information > Bios configuration settings > Asset documentation > Patch details > System settings > Help desk tickets > Change requests > Service level agreements > Finance information > Impact analysis Table 1. Examples of CI data types so on. That would be overwhelming for the reader searching for books, but would also be a daunting task for any librarian that had to build up and maintain such a detailed repository of book information. In reality, what readers need is a way to access detailed and related information about books if and when they need it, as opposed to having it all stored and available through the card catalog. As long as the card catalog provides a way to find additional information, the reader should be satisfied. This is also true when we examine CI information in a CMDB. You must decide which core information needs to be stored in the CMDB and which information can be kept in other repositories that link to the CMDB. Linking the CMDB to external data describes the concept of federation and the foundation for building a federated CMDB approach. Which Core CI Must a CMDB Store? The CI data designated for storage in a CMDB varies, depending on the environment. Just like the card catalog, IT processes, and users of those processes, must be able to search on information about CIs and how they relate to other CIs in the environment. This information such as the name of an asset, its location, serial numbers, and related business services is considered core CI data. In addition to core CI data, users may need to access detailed CI data (such as operating system information) or related CI data (such as actual help desk tickets). Similar to the card catalog, storing this information within the CMDB would require a massive data repository. Instead, this detailed and related data can be federated and stored in a separate location. The CMDB can then provide a link to that data, enabling users to access it when needed. This means that any information the user needs for any CI can be accessed from a single location. Value of a Federated CMDB Approach Storing all CI data types in a single CMDB would be extremely difficult to maintain and manage. The CMDB would spend large amounts of processing power trying to organize and keep all the data consistent and accurate. Additionally, the more data there is in the IT environment, the less scalable the CMDB. Using the federated CMDB approach, data that should be stored in the CMDB is sorted out from data that should not. By providing a simple means to access detailed and related CI data stored in other repositories, we can build a CMDB that will be much easier to manage, maintain, and scale while continuing to leverage existing investments in different IT management technologies. It is this core value proposition that makes the federated CMDB approach so important (Figure 1). Store #1 Change Request IT Processes CMDB Federated CI and Related Store #2 Helpdesk Figure 1. Federated CMDB model Core CI Desktop Server Network Business Processes Relationships Store #3 Detailed Server Don t Federate Core CI While it is important to federate related and detailed data, it is imperative to not overextend the concept to include the federating of core CI data. Imagine a card catalog spread out over various locations, each of which provides different information about books in the library. If one of those card catalogs is stored in a PAGE > 3

building that closes at 5 p.m. every day and you need information about books that are stored in that catalog, you will be out of luck and there will be nowhere to access that data. You must wait until the building opens for business the next day before you can access that catalog and get the information you need. Similarly, if core CI data in your environment is stored in multiple data stores and one of those stores becomes unavailable, your core CI data is unavailable for use by IT processes and users. To ensure that core information is always available, it is important to store core CI data within the CMDB, and not federated from other locations. Normalization and Federation Another important benefit of a federated CMDB is that it promotes data normalization across CI data stored within the CMDB. What is data normalization? Think about the library card catalog it normalizes book data within the catalog by key attributes such as author and title. Searches based on these attributes are standardized across all books in the library. Imagine if the card catalog allowed readers to search the author Ernest Hemingway using multiple formats such as E. Hemingway, Ernest Hemingway, or Hemingway, Ernest but provided no way to understand that all formats refer to the same author. This example can extend to include the different ways publishers might define the author attribute for their books. Without a standardized, single format for author to normalize the book data within the card catalog, imagine how difficult it would be for readers to search for a certain author. They would need to know exactly how each publisher defined its author attribute. The same holds true for a federated CMDB. When data from multiple sources is linked into the CMDB, the CMDB creates a single, consistent way to represent this data. For example, if multiple discovery sources capture information about a server, and each source names the server type differently, the CMDB will normalize this data into a single name for use within the CMDB. Resultantly, all IT processes will then work from a normalized set of data, regardless of where the data originated. Additionally, users will then have a single understanding of how to access and search CI attributes within the CMDB, because every type of CI is represented in a single, consistent way. Accessing Federated Now that we have an understanding of what federation is and of the different types of CI data that should and should not be federated, it is important to learn how data federation actually happens. How do you actually access federated data through the CMDB? How do you link to the information stored in other data sources? What Constitutes a Link? In the library card catalog, for example, a link could consist of a card that describes where the reader can go to access information about book reviews. Or the card could provide a URL that points to a Web site where the reader can access reviews from other readers, editors, and so on. In a CMDB, a link to federated data means that the CMDB stores information on how and where to access data stored in other repositories. Methods for Linking to Federated Linking to federated data refers to methods for accessing federated data stored in other locations or data repositories. The following list describes approaches that can be used to access federated data through the CMDB. > Documentation: Probably the most simplistic concept of federation, in this approach you create documentation within CI details housed in the CMDB, which tells the user where the data is and how to access it. Example: While viewing a CI, there may be visible documentation that tells the user where detailed data about the CI exists and how to access it. This is similar to the card catalog example previously discussed in this white paper. > Open external application: The user can open up another application that stores information about the CI data being federated. This allows the end user to interact with this data from another application interface, one that is independent of the CMDB user interface. This application could be launched through a Web service, a run-process command, or other program execution options. Example: While viewing a CI, the user could click on a button that would launch another application or URL that would link them to a different interface, one that provides information about detailed or related CI data. > Open user interface: Leveraging user interface (UI) technology provided through the CMDB, UIs can be created within the CMDB environment that link into a federated data store and have the same look and feel as the CMDB interface. Example: While viewing a CI, a user can link to a UI that was developed with CMDB UI technology, which would run in the background and point to data stored in a different data repository. There is no right or wrong approach to implementing federated links; it is simply a matter of preference and the level of integration required. You should evaluate each method PAGE > 4

and understand user requirements to determine which federated link option will work best for federating your data. Important Benefits of a Federated CMDB The greatest benefit of the federated approach is that it enables the CMDB to focus its functionality solely on CIs and their relationships. The overhead required to provide this functionality is not wasted on data that is not considered core CI data. Additionally, the recommended federated approach means that: What Should a Federated CMDB Look Like? The federated CMDB model refines the ITIL concept of a CMDB by breaking up the CMDB and its infrastructure into three layers (Figure 2) including: > The CMDB itself > Related data linked to or from the CMDB (the CMDB extended data) > Applications that interact with these two layers (the CMDB environment) > You need not migrate related data or modify the CMDB to hold core information. You do not need to undertake several data migrations and application integrations to move related CI data such as change requests or help desk tickets into the CMDB. Applications that use this data can continue to access it from where it is currently stored, eliminating the need to modify those existing applications to work with the CMDB. > Transactional data can be stored in databases that are better able to handle a high volume of requests, instead of in the CMDB. is provided more efficiently. Instead of getting all CI data and related information from the CMDB, data consumers can get it from individual data stores and applications that are optimized to provide the specific type of data being requested. With requests for related data being handled by other databases, the CMDB does not need to accommodate all such traffic in addition to CI-related requests. You can spread the load across multiple systems. Extended CMDB SLA Software Config. Service Impact Help Desk Change Requests CMDB Environment Applications CMDB Extended Information related to CIs Help Desk Tickets Change Asset Incident Capacity (CDB) Links Between Records Requests Service Level Agreements CMDB Application Identity Provisioning Contracts Other Related to CIs Configuration Items and their Relationships Capacity Discovery Application 1 Discovery Application 2 Problem Definitive Software Library > is normalized across data sources, optimizing CI search capabilities for end users. As previously discussed, data normalization provides a consistent definition for CI data, bringing consistency and accuracy to all data stored within the CMDB. Because the CMDB provides both data normalization and a core set of CI data elements, end users have a single place to go to search and access all CI information, even if that information is federated and stored in other data repositories. Figure 2. Three layers of a federated CMDB infrastructure model As Figure 2 shows, the CMDB and CMDB extended data layers, when combined, contain the information ITIL suggests be stored in a CMDB. Separating this information into two layers provides a basis for a federated CMDB. PAGE > 5

The CMDB holds only CIs and their relationships. The CMDB extended data is federated CI data that can be either related data, detailed data, or less-important CI attributes that are stored in repositories outside of the CMDB. The data in the CMDB extended data layer is linked to the CI data in the CMDB. By definition, federated CI attributes are linked from their instances in the CMDB, allowing requests to the CMDB to reach these attributes. However, for other types of extended data, the link can be in either or both directions. For example, a change-request record could have a link through which you can access the instances of the CIs it will change, and each CI instance could have a link through which you can access the change requests that affect it. Additional Points to Consider Federation: Not the Answer to Everything Once we understand the concept and benefits of federation, it is important to know that there are limitations in what a federated CMDB can provide for your IT environment. A federated CMDB is not the answer to every IT problem. In other words, a federated CMDB cannot create an automagic environment in which all data, everywhere, can be accessed anytime by any application for any reason. While federation does provide a means to logically approach a CMDB implementation, it will not be the answer to all your needs. A federated CMDB will not provide universal reporting capability. The CMDB cannot provide access to all data across your organization through a single query via a single interface. Although that could be achieved with a huge investment and implementation, it goes beyond the scope of value that federation provides to a CMDB implementation. What a CMDB will create, however, is a single way for IT management processes and end users to access all information about CIs and their relationships, even when information related to those CIs is not being stored in the same data repository. Can I Have Multiple CMDBs? The idea of multiple CMDBs in a single production IT environment is somewhat oxymoronic. A CMDB by definition is a master system of record. In ITIL terms, the CMDB needs to be one master record of information about your CIs and their relationships. The only exception is when an organization has IT implementations that are completely independent and do not need to interact with each other (i.e., multiple geographies that operate independently). The repository for the master system of record for core CI data is the CMDB. There may be extra configuration stores that contribute CI information into the CMDB and may even use CMDB technology; but they do not represent the source of record for CI data. Instead, these configuration stores can be linked to the master CMDB to exchange and cross-update information as needed. In situations where multiple CMDBs or configuration stores exist in an environment, organizations must designate which data store will become the master CMDB. All other data stores then become configuration stores that can exchange information with the master CMDB. These configuration stores may function as a CMDB for the processes that leverage them but, because they are not the source of record for CIs, they are not considered the master CMDB (Figure 3). Exchange Configuration Store #1 IT Processes Master CMDB Configuration Store #2 Desktop Server Network Business Processes Relationships Exchange Configuration Store #3 Figure 3. Master CMDB model PAGE > 6

Different Approaches to Federation In the IT world, there is more than one definition for federation. It is important to remember that some federated data approaches may not be valid for a federated CMDB approach. We examine a few of the other approaches in the following sections. base Federation base federation should not be confused with CMDB federation. In database federation, data can be stored in separate tablespaces and then federated together so the information can be searched from a single location. For example, database federation might be used for storing an employee directory, where names starting with A-F are stored on one database table, G-L names are stored on another table, and so on. This information is then federated together so end users can perform a single query to search across those multiple tables to find a match. There is also a style of database federation that stores, for example, columns a, b, c, and d in one store, and x, y, and z in another (segmenting by column instead of by row). This is essentially the same idea behind the storage of additional CI data in the federated CMDB model. However, neither form of database federation allows for the federation of related data that is stored in different data stores, which may or may not be a database. Ultimately, there are definite conceptual similarities, especially between the column-style database federation and a federated CMDB. However, a key difference between database federation and CMDB federation is that a CMDB supports the idea of additional data and extended data, while the database federation concept does not. Virtual Stores The virtual approach to federation refers to the ability to store data in many different locations without a copy in a central repository. The term virtual is used because a virtual central repository is formed across data sources (Figure 4). Store #1 Desktop one of these systems fails or cannot be accessed, the complete view and understanding of CIs and their relationships is instantly lost. For example, if the data store that holds information about business processes cannot be accessed, a change manager will not be able to predict whether taking that server offline will affect a business process. A virtual CMDB must also constantly manage the flow of data through multiple data sources. When a request is made for CI data, the CMDB needs to determine where the data is, access that data (possibly from multiple places), and then represent that data across data sources in a common way. Because the data is stored in multiple locations, it becomes a challenge to normalize the data so that the CMDB represents it in a common way. Without normalizing the data, it will be difficult to search on CIs and their attributes within the CMDB because each element may be represented differently in different data stores. Conclusion Store #2 Business Process IT Processes Virtual CMDB Store #3 Network Figure 4. Virtual CMDB model Store #4 Server Federation provides the means for building a CMDB environment that successfully can be managed within your IT environment. By understanding and distinguishing between the different types of data that make up your CIs, you build the foundation for defining your federated CMDB and the data that should and should not be stored within it. The federated approach creates a CMDB environment that is scalable and easier to maintain. The main drawback to a virtual data store, in relation to a CMDB, is that organizations must rely on every data store that makes up the virtual environment to be available at all times in order to access a single view of CI data. When PAGE > 7

About BMC Software BMC Software helps IT organizations drive greater business value through better management of technology. Our industry-leading Business Service solutions ensure that everything IT does is prioritized according to business impact, so IT can proactively address business requirements to lower costs, drive revenue, and mitigate risk. BMC solutions share BMC Atrium technologies to enable IT to manage across the complexity of diverse systems and processes from mainframe to distributed, databases to applications, service to security. Founded in 1980, BMC Software has offices worldwide and fiscal 2005 revenues of more than $1.46 billion. BMC Software. Activate your business with the power of IT. For more information, visit www.bmc.com. BMC Software, the BMC Software logos and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc. All other registered trademarks or trademarks belong to their respective companies. 2005 BMC Software, Inc. All rights reserved. 59249 PAGE > 8