This chapter is from the book
This chapter is from the book
This chapter is from the book
CIs as the CMDB “DNA”
We can propose a simple analogy to highlight the power of CI reuse and federation from the CMDB. Our example is DNA, the basic building block of all organic life forms (at least those on Earth!) and how the basic genetic elements are abstracted to eventually form complex organisms.
Every living organism is built from the same four building blocks. Geneticists call these nucleotides and represent them by their letters: A (adenine), T (thymine), C (cytosine), and G (guanine). The reason each plant or animal is different is because these nucleotides are assembled differently. Arrange them one way, you get a Bengal tiger; arrange them another way, and you get Tiger Woods.
If we consider the genetic CMDB to contain only four CIs, being the four nucleotides, we can turn this raw data into extremely sophisticated organisms using abstraction models known as codons, genes, chromosomes, and organisms. Everything uses the exact same CIs. The secret to each unique finished organism lies in the abstractions.
Abstractions are themselves CIs with their own special attributes, so we need a CMDB mechanism to store and retrieve them. It is best to store the abstractions in separate CMDBs from the one containing the four nucleotides. This is where federation brings value to the overall CMDB structure. As we explain later and in Chapter 4, the federated model allows flexible references to the CMDB data to produce actionable information. In this case, the abstractions point to the nucleotide CMDB to obtain the correct low-level details, and all of this is assembled in a usable form based on the structure defined in the codon, gene, chromosome, and organism CMDBs.
Figure 2.7 depicts the genetic hierarchy followed as we navigate from the top-level organism all the way down to the nucleotides. Obviously, genetics is a far more complex field than is shown in this example, but it does illustrate how the various abstractions interact and relate. Note how each abstraction layer uses its own CMDB to hold the models that define the structure of the abstraction and the references to the layers below. An organism model defines the right mix of chromosomes, each chromosome model defines the right mix of genes, each gene model defines the right mix of what geneticists call codons, and each of the 64 codon combinations is built from a unique structure of nucleotides. If there was a need to further deconstruct the nucleotides, one could break down each nucleotide to its molecules, atoms, and subatomic particles through the use of additional abstraction layers.
)
Figure 2.7 Genetics example of federated CIs
It would be wasteful to replicate copies of data from each lower level of this structure. By the time we get to the chromosome level, the number of nucleotide combinations is astronomical. The use of abstraction tiers greatly simplifies this situation. For example, the chromosome level only needs to reference models of individual gene strands, not the entire structure of each. The raw data remains accurate and up to date, and we have the flexibility of creating new abstractions merely by rearranging the most practical model. Everything below that model remains unchanged.
Every good CMDB follows a similar pattern of hierarchical references as the models and data are navigated for a particular use case. The idea is similar to database normalization, where the goal is to optimize flexible data construction with a minimum of data replication and maximum performance. Object federation in a CMDB structure differs from database normalization in that it can link a wider variety of data sources in many physical places (if needed). Object models can also contain behavioral information such as rules. Good object models go far beyond mere structural information.
Data from the level below is not duplicated in each model. This would cause severe data overload and synchronization issues, especially at the higher levels. Each abstraction merely references the appropriate elements of the layer below. For example, there is no need to define the molecular structure of every codon when simply referring to the A, T, C, and G nucleotides and their assemblies are sufficient. A behavioral aspect of the genetic CMDB that can be encoded in the model further simplifies the nucleotide references. Because the only possible nucleotide combinations in the genetic code can be A to T and C to G, there are not four possibilities, but only two (an A-T pair and a C-G pair—or a one and a zero, if you wish).
It is ironic that life forms can be deconstructed down to the same binary code used in computer science! This is one reason we chose the genetic example. Clearly the genetic code is hideously complex, but building the layered models greatly simplifies the navigation of the system and optimizes performance, data reuse, and reliability. IT services are no different. If a federated model can allow us to tackle something as convoluted as the genome, IT services should be much easier. Nobody can credibly state that a federated CMDB is easy, but we often overcomplicate an already complex mission by our failure to leverage best practices and novel solutions. CMDB federation is such a novel solution, and ITIL (or similar process models) can offer the best practices.