This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuration Items
Each element in the IT environment is an individual entity requiring accurate capture of its attributes. The representations of these entities in the CMDB are Configuration Items (CIs). A CI is a software model that contains the attributes of the represented entity. In databases, this is described in the schema. Each entity consists of several attributes of specific data types (for example, string and integer). Each instance of the entity is its own CI (for example, 200 identical servers equals 200 CIs, all with the same schema, but as independent instances with some unique attribute settings). A CI can be physical—that is, real and tangible (for example, hardware and software code)—or it can be logical abstractions of these (for example, business processes and distributed applications).
If we examine 300 Windows servers and 20 Cisco routers, this subset of the overall environment represents at least 320 CIs. We say “at least 320” because it is possible, indeed likely, that each device is built from other devices. For example, each Cisco router may consist of a chassis and multiple cards within the chassis. It is possible to treat the entire router as one CI, but it makes more sense to also break down the CIs to more granular levels. We explain why later in the book, but the short reason is that it enables more flexible abstraction models to be constructed and manipulated.
The concept of a CI must be extensible. Some believe a CI is the most atomic level only, but a CI is also a more complex assembly of lower-level CIs. In the server example, a physical server has special attributes. A virtual server also has special attributes unique to that virtual instance, even though it is resident on the physical server. This relationship between the two means they will share certain attributes, but also contain other attributes unique to each perspective.
Applications, business services, and customer organizations are also CIs (see Figure 2.2) at even higher levels of the CI hierarchy. Similar relationships link these various layers to reflect reality. To accurately capture and maintain the atomic details as well as the relationships, the CMS and the CMDBs are built upon traditional relational databases and object-oriented models, as well as a myriad of other formats that include text files, Simple Network Management Protocol Management Information Bases (SNMP MIBs), and software Application Programming Interfaces (APIs). The object-oriented technologies are especially important in the continued development of Configuration Management information. We cover these technologies in more detail in Chapter 4.
)
Figure 2.2 Example Configuration Items
Each CI has several attributes associated with it. Some are compound abstractions that refer to a number of other CIs (the Department CI consists of several Employee CIs). By simply viewing the CIs as individual items, it is difficult to envision how these various CIs interact to form something more useful. We need to link the correct objects and attributes by creating the appropriate relationships, as shown in Figure 2.3 by the dark black lines.
)
Figure 2.3 Relationships among the CIs
Here the CIs are linked to expand on the appropriate attributes, and it becomes easier to navigate the map of CIs to each other and to their impact upon the overall service. The links can be established in many ways, such as relational database table references and Java class pointers. When we talk relationships in the CMDB, the links are best implemented with XML. We explain these relationship links in more detail in Chapter 4 and Chapter 6, “Integration—There’s No Way Around It!”
In this example, you can also see how there is common data across some CIs. Good database administrators try to normalize the data to eliminate the possibility of data overlap. With distributed objects, the normalization is a bit more difficult. In this particular case, it is possible that these specific attributes might be linked in from an Asset Management database as yet another CI.
You will see many references to relationships in this book—maybe so many that you will find the repetition annoying. We relentlessly preach about relationships for a reason. They are indeed the glue that binds everything together to result in information that is more meaningful. Without adequately capturing relationships, the CMDB crumbles into a worthless disarray.
A CI can be a small morsel of data or it can be a complex, multilayered composite of other CIs and other composites, or it can be any level in between. This flexibility is essential to a smooth Configuration Management process. Do not limit your perspective of a CI to just the infrastructure devices. Such a myopic perspective makes the system of CMDBs inflexible, fragile, and even more complex than the object-based model. This is one aspect of the discipline (or lack thereof) noted in Chapter 1, “The Need for Process Discipline.” The future of the operation can be placed in jeopardy if these deleterious factors exist.
CI Candidates
Many elements of the IT and business environment qualify as CIs as we describe in Chapter 5, “CMS Deployment Strategy.” Ideally, every identifiable unit of importance can be captured in the CMDB, but realistically, you will be driven by your business service needs and bound by priorities, staffing, and technology capabilities. Exactly which CIs you incorporate and in which order will be determined by each of these factors. Existing technologies offer plenty of information that can help. In Chapter 4, we cover how this data is leveraged. Configuration items fall into many domains, which are discussed in the following sections and in yet more detail in Chapter 5.
Infrastructure CIs
When people think of a CMDB, they usually limit their perspective to the infrastructure elements (servers, routers, storage, and so on). This is a myopic view, but the rationale behind this mode of thinking is understandable. Throughout much of the history of IT, what is now called the CMDB was known by various other terms, the most common being an asset database. This infrastructure-centric view persists today, even though the CMDB contains far more than infrastructure elements.
Such a database was used to maintain a record of the individual hardware assets owned by the enterprise. Advanced organizations expanded the asset database to include software also. An asset database represents a limited subset of a CMDB, but an important one. It is often the initial phase of a CMDB journey because of this historical view (and the fact that much of the data has already been collected).
Infrastructure is most closely associated with the hardware devices in the environment. For each device, many attributes are identified, collected, and maintained. Figure 2.4 shows a few common attributes of a CI representing a server.
)
Figure 2.4 A few server CI attributes
Even in this simple server CI, you can see some attributes that raise additional questions. Attributes such as manufacturer and model are straightforward, but what about CPU architecture and operating system? CPU architecture could be Intel x86, s/390, or SPARC, and each opens up its own unique twist on the basic server definition. The operating system could be Windows Server 2003, Red Hat Enterprise Linux 5, VMware ESX 3.5, or even something like OpenVMS 7.2-1. Each of these attributes requires more detail, detail that may be unique to Windows, but totally irrelevant to Linux, for example.
Where such extensions are needed, object-oriented (OO) technologies can link the relevant extended attributes. This raises some interesting debates about precisely what constitutes infrastructure. Traditional examples of infrastructure are network devices (such as hubs and switches), servers, storage (including disk drives and SAN hardware), and mainframes. This is what we typically consider to be hardware.
As we continue to embed more sophisticated intelligence into the hardware, the line between infrastructure and applications becomes blurred. Virtually every single piece of today’s hardware is a complex mixture of genuine hardware (for example, silicon, steel, and plastic) and software (for example, operating system, BIOS, microcode, and embedded web server). For the sake of the CMDB discussion, we consider infrastructure to be the self-contained package of hardware and its embedded software. Infrastructure is hardware and software.
Software infrastructure differs from applications, as we describe in the next section. This is sometimes called system software, but software infrastructure extends beyond traditional system software (such as Linux and VMware) and into those elements that support applications (such as Tibco and JBoss). Although they are software, we recommend that infrastructure should include these software elements as well as traditional hardware. Infrastructure is no longer limited to those tangible hardware components that require electrons. The basic intelligence that manipulates those electrons also counts as infrastructure.
The structural and behavioral aspects of certain attributes will morph over time. Virtual servers are a good example. Whereas a server once supported a single operating system, it can now support many.2 The operating system attribute must now be abstracted to link to multiple possible virtual operating system instances (virtual machines [VM]) on a particular physical server. To complicate matters even more, that relationship between physical to virtual server can now be highly dynamic (for example, VMware’s VMotion software easily shuffles a VM from one physical server to another).
Your CMDB plans, architecture, technology, and operations must be flexible enough to address these frequently shifting requirements. This is a major reason why object-oriented technologies are becoming more popular for the CMDB. An OO approach enables you to adapt data structures to changing demands. IT systems are irreversibly becoming more dynamic. The so-called cloud computing3 that is gaining popularity marks an acceleration of dynamic systems, not a plateau.
Application CIs
Applications are the software elements that are directly touched and felt by end users. Examples include Microsoft Exchange, Siebel, and a custom shipment-tracking system. Products like SAP, Microsoft Internet Explorer, and Adobe Flash Player can also be seen as applications, but here we are getting more into the domain of software infrastructure, as we just pointed out in the section on infrastructure CIs. What you deem an application and what is software infrastructure is up to you, but you should be consistent within the context of the CMDB.
As you build out your application-level models, you will find that many applications are abstractions built upon other applications. The gray line between applications and software infrastructure is where these situations will occur. Some applications that are used by some end users (such as a database front-end) may become software infrastructure for another, more complex application (for example, a shipping application built on top of SAP and using this database).
The value of clarifying the demarcation between applications and software infrastructure comes when using the CMDB for more sophisticated purposes. We cover these purposes in more detail in Chapter 9, but we present a simple example here—one that is deeply desired, but also extremely difficult to achieve.
Consider the exercise of identifying the root cause of an application performance anomaly. The application consists of many software and hardware components, so the first thing we need to do is understand the structure of the application’s relationships to these elements (see Figure 2.5). The hierarchy of the relationship map will be multiple tiers for the typical modern business application.
)
Figure 2.5 Example of tiered application structural relationships
To determine the root cause, this structure is navigated, and each component’s impact on the overall application behavior is assessed. This assessment first capitalizes on the relationships that bind the various components together, as they form the paths followed in the navigation. They give us visibility to potential cause-effect mappings and significantly narrow the field of possibilities.
The performance, availability, and configuration state of each of these components can then be analyzed. The mapping significantly reduces the set of possible root causes by including only those elements that truly matter to the application in question. By narrowing the scope, you can then attack the problem more effectively.
Of course, it would be wonderful if you could automate this analysis to the very end, but this remains a dream for now. This is where the difficulty arises with application analysis, but such is the topic for another book.
In Chapter 9, we offer more guidance on how the CMDB/CMS works in conjunction with the Change Management process. In that chapter, we also show how changes can point to many of the root causes of a myriad of problems, including the elusive application performance problem. It all begins with having accurate configuration data or—as we like to call it—the truth. You must also not forget that there is a Continual Service Improvement component to ITIL v3; some of which we describe in Chapter 8, “Continual Improvement for the CMS.”
Known Error CIs
There is a condition in Incident and Problem Management called a known error. A known error is an incident or problem whose diagnosis is complete, but whose final resolution is either delayed or implemented with a temporary fix. As incidents arise with the known error as a root cause, operations staff should be able to quickly identify the known errors and take appropriate action. Actions include proper notification of affected users and possibly implementing work-around solutions. As the operation gains experience, the known errors are tied to resolutions. This forms a cause-effect linkage that accelerates resolution. The error is detected, and the resolution is immediately found and presented. The responders therefore have a map to guide them to speedy service restoration.
One of the more important management aspects of known errors is the need to capture them and maintain them throughout their lifecycles, including through end-of-life. To enable this, a known errors database is maintained. Many of the common Service Desk products now include some form of known errors database. Service Desk staff developed a need for this database for the purposes we mention here, as they are the front lines of the IT organization. Vendors of Service Desk automation software responded to this need with full inclusion of a known errors database or supplying it as an optional module.
Naturally, the known errors database represents yet another family of CIs for the CMDB. The value of this class of CIs helps streamline many of the daily functions such as incident analysis and long-term pattern analysis for Problem Management, capacity planning, and continuous improvement.
The known errors are related to infrastructure, application, and other classes of CIs. These relationships need to be captured and mapped, as the known errors are attributes of these “host” CIs. The known error attributes are subject to change, and there can be multiple known errors for a single host CI, which could be dependent, for example, on their particular environment, configuration, or architecture, so the object model must support such a zero-to-many set of similar relationship attributes.
Business Process CIs
If applications are abstractions of infrastructure, the next step above applications is the business service level. Like applications, there can be multiple layers of business services (for example, a web-based product ordering service is a component of the broader supply chain automation service). At the highest level of this structure are the business processes. Chapter 5 and Chapter 7, “The Future of the CMS,” have figures that demonstrate this notion of business services sitting atop the remaining IT structure.
Business process modeling is a functional domain unto itself within the IT community. It is one of the tightest integration points between IT and the business and is increasingly owned and controlled by the business side rather than the IT side. Unfortunately, the CMDB and CMS vendors do not yet offer complete solutions that automate the discovery of the services without significant human intervention. The current state is still very much silo oriented, but it is changing.
You should work with the business community and the Enterprise Architecture organization to incorporate business process information into the CMDB/CMS. Stay up to date with the standards being developed by the Business Modeling and Integration Domain Task Force so you will be prepared to input your work more easily into the vendor tools when those tools do come along. All parties will benefit. Newer developments are making this much easier now because standard object modeling and integration technologies are gaining acceptance.
Standards have been under development for over a decade. Standards took a positive turn in 2005 when the Business Process Modeling Initiative (BPMI) merged with the Object Management Group (OMG) to form the Business Modeling and Integration Domain Task Force (BMI).4 BMI and OMG are responsible for some standards, OASIS for others, and the W3C for still others.5 The flexibility offered by XML allows for many derivatives to be developed. That’s the good part of XML-based standards. The downside is that it allows for many derivatives to be developed. You can easily become overwhelmed by the plethora of standards available.
As you pursue the CMDB, your role in the selection of these specific standards will be limited. You should leave the painful selection to those in the Enterprise Architecture team (who have this responsibility anyway), but we highly recommend you collaborate with that team to help determine the optimum path to linking the business process standards with your CMDB. Chapter 4 provides the basis for your discussions about a federated structure with the architecture groups.
Much discussion is taking place about Business Service Management (BSM), the higher-level aspects of IT that produce and manage technology in the eyes of the business, not so much in the eyes of technologists. The business processes and the business services that feed them are the linkage between core IT (infrastructure and applications) and actual business value. The relationships between and within these tiers enable us to determine business impact of a server failure, for example. Without these relationships, assessing the business impact is mere guesswork—and very often wrong. Accurately understanding business impact via the CMDB and its use cases is absolutely essential if you want to position the IT organization as a valued business partner. Just as it is in all other functions of IT, the CMDB is a fundamental supporting pillar of BSM.
Business processes are an often-overlooked element of the CMDB because of the aforementioned misconception that the CMDB is all about infrastructure. The omission of business processes further exacerbates the “us and them” division between IT and business. Inclusion of business processes ensures more business relevance to the CMDB and enables use cases to have more value to business service management efforts. The result will help change the language from “us and them” to just “us” in a unified journey toward business execution excellence.
Human CIs
Human beings are the most important elements of any business. IT services are no different. You and your colleagues, your end users, your reporting structure (in both directions), vendors, partners, and many, many others all contribute to your technology and business services. How each of these people fits into the overall picture is a requirement of any good CMDB. “People” are identified, tracked, used, and managed according to each individual’s contributions and responsibilities. Here are just a few attributes of people that are useful:
- Identity. Each person needs a unique identity, sometimes called a digital identity. This identity is a complex data structure far beyond the person’s name. Among the many attributes tied to the human CI is a unique key, a means to identify that John Smith is the John Smith you think he is. Software tools used to manage IT services are notoriously disjointed with respect to identities. Each usually has its own identities, requiring tedious replication of data across tools, data that nearly always falls out of sync. Common identity management technologies are finally showing promise to unify identities across tools, but the various tool vendors must support them. Happily, there is increasing momentum to support common mechanisms like Active Directory and Kerberos.
- Authorization. After identity is established, the next step is to assign authority to take certain actions. These authorizations can be for specific software or built into managed infrastructure. Here also, the multitude of mechanisms and individual points of management greatly complicates this situation.
The identity and authorization must be intertwined. Companies are using identity management products that work in conjunction with other products using AAA protocols6 and related technologies to understand, manage, and enforce access controls, control privileges, and other authorization policies.
When a management software function is executed, it must ensure that the action is allowed (for example, “Can I change the OSPF parameters on this router?” or “Can she view the schema of the HR database?”). Proprietary and isolated mechanisms can support these actions, but managing the dizzying array of identity-authorization mappings without automation technologies is intractable.
Here lies the solution to this dilemma and one that is already starting to take root in IT organizations. Configuration and Change Management (CCM) products highlight a good example that is bringing some sanity to the tedious and error-prone tasks of manual configuration change execution. The tool manages a common AAA mechanism for all covered elements and then the tool itself is executing the changes. The disparate access controls are managed centrally in this common tool.
Logically, each CCM tool has a strong CMDB at its heart, so the tool can sufficiently understand the configuration of what it is acting upon and various policies regarding these actions. The result is a common platform for normalizing task execution that is faster and more trustworthy, but there are yet other benefits to the CMDB effort.
CCM tools include a CMDB, so they are valuable as elements of an overall CMDB architecture. By virtue of their basic function, they almost always do their own discovery of their covered domain and usually more effectively than other discovery tools in their domain (there are many). This means the data is highly accurate. As you build out your wider CMS, these tools are effective CMDBs for their individual domains.
- Roles. Individuals are the soldiers in the service management war, but these individuals can be classified to guide common tasks across a related team of individuals. You have many of these teams, and members can belong to multiple teams. The teams may not even be formal; they just have common goals, so we’ll call them roles instead.
By assigning authorizations to roles, the tools that drive actions can be simplified. Instead of managing authorizations for each individual, you can just manage them for roles. The system then cross-checks roles with people who are assigned to those roles.
Roles institute an additional layer of structure into the human CIs, but the additional layer is well worth the minimal overhead because of the operational simplicity we just mentioned. As with the known errors CIs and many others, the model requires flexibility to support many roles per person. Here the relationship will be at least one role, but probably more.
The human CIs are certainly included in the bigger CMDB structure (CMS, to be more precise). You need not and indeed should not create this CMDB from scratch. Leverage what already exists, a data source full of excellent data on your people. It’s called the HR database, and it is most often embedded within software tools used for HR functions, such as Peoplesoft.
In Figure 2.3, we showed a CI called Employee. The populated Employee CIs and their attributes can all be extracted from the HR database, requiring little additional embellishment for CMDB purposes. You won’t need a lot of the detail existing in the HR databases (they won’t give it to you anyway, nor should they!), although basic identity information (for example, employee number, name, department number, title, reporting structure, and roles—if they exist there) will be very handy and more available.
Document CIs
Finally, we present another class of CI that is often overlooked, despite repeated references in the formal ITIL positions on the CMDB and CMS. That class is documentation. Together with known errors and other sources, they embody what some call Knowledge Management. We view this as a valid categorization.
Documents are different data types than those normally maintained in a CMDB or relational database. They are files, such as PDF, Excel, MS-Word, and so on. The document CI has as a core attribute, the path name or (preferably) the URL that points to the document file. The host CI (infrastructure, application, and so on) then points to the document CI as appropriate.
If you need to see the installation instructions for a Dell PowerEdge™ M600 server, the attribute for the installation guide in the document CI can be set to the specific PDF document on Dell’s web site, or you can have your own internal copy (likely a better idea). The UML diagram for the Order to Cash business process can be a PDF link included as an attribute in the business process CI for Order to Cash.