This chapter is from the book
This chapter is from the book
This chapter is from the book
Span
As mentioned earlier, the span of your CMDB documents which items of each class you're going to capture. The obvious question is why you wouldn't capture every item of the types you've identified. There are many reasons for choosing to capture only some of the possible range of configuration items. This section describes some of those reasons and helps you document the span of your CMDB.
Span is all about establishing boundaries, and the ways to describe span are as varied as the kinds of boundaries that can be considered. For an international organization with different regulatory compliance needs in different geographies, span can be used to include only those CIs of some specific class that are in regulated countries. An investment banking concern might decide that workstations on the trading floor are critical but those in general office space are not. Perhaps one division of your organization is going to be sold soon, so you want to exclude all the business applications from that division from your span. You might also define different spans when different outsourcing vendors support different parts of the infrastructure, or even when a single IT organization supports different "customers" with different services. These are all valid ways to establish boundaries identifying which CIs will be in the database and which will not.
Of course, the moment you introduce such boundaries, you start to have issues with relationships. You need to make a policy decision on how to handle a relationship between a configuration item within your span and one outside it. These kinds of relationships can be extremely difficult to support, but sometimes there are legitimate reasons to include them in your span. For example, you might want to include only the items at a specific geographic location in your span; however, because a wide area network line connects to that location, you should include it in the database even though it has a relationship to equipment at another location as well. When this happens, be aware that you are creating a need for special procedures to deal with the relationships. You may even need special features of your configuration management tool to handle relationships between something your CMDB knows about and something it doesn't include. Unfortunately, most of the popular tools today don't offer help with this situation.
Criteria Used to Define Span
This section describes some criteria that can help you determine the correct span of your CMDB. Like those for scope above, these are general guidelines that can be used in conjunction with your knowledge of your own organization and some common sense.
Span Defines Projects
The definition of span can be used to help define projects. For a very large, global organization, it's nearly impossible and very risky to populate the entire CMDB as part of a single, long-running project. By partitioning the span into more manageable chunks, you can create the scope for several phases or releases of the implementation project. Geographic regions typically are a good choice for creating boundary lines, although you need to be careful of global CIs. Business applications that are used throughout the world or wide area network links between different regions are examples of global configuration items that should specifically be named in your statement of the CMDB span.
Your span does not have to define only one kind of boundary. For example, it is quite possible to define a span that includes servers at several geographic data centers and applications from one or more business units together into a single statement of span. This will almost certainly be the case if you follow the advice of Chapter 10, "Choosing and Running a Pilot Program," and start with a pilot program. For that pilot, you might need to bound the span by three or even more boundaries to get a small enough data set to make the pilot workable.
Tools Sometimes Dictate Span
The tools you choose to use sometimes dictate the span of your database. If you have an excellent tool that scans details of Windows based servers, but doesn't work on UNIX servers, you might want to exclude UNIX servers from the CMDB for a while. Once you've implemented better scanning technology, you can increase your span to include those servers. But perhaps you still don't have a good way to capture network information. This is unfortunate, but occasionally you will find yourself constrained by the tools and able to use only the span that those tools support.
Follow the Leader
When choosing the span of your database, it is important to understand the degree of risk your project sponsor will tolerate. The definition of span is the single best way to control the risk of your implementation project because it directly determines how much data you need to gather, manage, audit, and report on. Normally it is best to define the span incrementally so that you can be sure of managing a smaller set of data before trying to grow to a larger set. Your stakeholders should offer guidance in the best way to approach getting the entire enterprise.
Some items might be permanently out of your span, and some may simply be out of the span of a single project but assumed to come into the span later. These should be clearly differentiated. Policy statements should be documented to indicate which configuration items and relationships you will never incorporate and why. These policy statements will save countless future hours of confusion and renegotiation each time a separate project is begun. For those items that are simply deferred to a future project, include rationale statements in the span statement to indicate why you've chosen to defer them.
Documenting Span
There is no perfect format for documenting the span of your CMDB. Most projects I've participated in simply used a document that listed each boundary along with a rationale for placing that boundary in the span, and a consideration of the configuration items and associations that would cross the boundary as exceptions. For example, suppose you want to include executive workstations in your span, but not other workstations. In the span document, indicate your definition of an executive workstation and the reasons these are included while others are not. Also indicate whether there are exceptions, such as some other workstations to include, some relationships between included configuration items and general workstations, or some executive workstations to exclude. If there are no exceptions, simply state that no exceptions exist. The span document should be concise and understandable. Your organization may prefer to combine the scope and span information (along with granularity) into a single document.