« Innovation Revisited, Kinda | Main | Networking Social Behaviors »
February 23, 2009
Federation, Synchronization and Consolidation in I.T. -- a lot, but not enough.
Anyone who has done systems research or done the care and feeding of systems is familiar with the idea that a system is often made up of sub-systems -- for example the way that the human body is composed, or a good old-fashioned hi-fi stereo component hookup, or compounds made of molecules made of atoms. One of the key things to consider in managing the higher-level systems is that their sub-systems are indeed complete systems themselves and have their own internal complexities of components.
"CIs" are things that are similar to the above, in that a higher-level CI such as a "service" may be composed of other "sub"-services having, in turn, their own constituent services -- but this is why in the conversations about "CIs" in many companies, confusion develops amongst the terms "service", "system", and "component". Questions and even arguments follow this confusion, such as "when is a system a CI? Are all services CIs? Do components combine to make CIs? Do CIs combine to make other CIs?" This puts an end to the usefulness of speaking roughly.
So instead, if we take the term "Configuration Item" and break it down without regard to its actual linguistic history, we should think freshly: the term "configuration" means something on its own -- i.e., a certain arrangement of selected parts -- and the term "item" represents something involved in a configuration -- namely, a part. Any construction has a configuration, and the parts in the configuration are items. This conceptual abstraction is still easy language, and it completely covers the aspect of drilling down into one thing to find, among its parts, other things that each can likewise be decomposed. What follows below intends to apply such consistency across old terminologies as well.
For our purposes of discussion, the key construction is going to be some service that we want to have. As we'll see in the illustration here, there is an important and consistent way to discuss what is found in the drill-down on a service. Generally, we drill down onto two different kinds of resources for the service. On the one hand, sub-sections of a construction are what should be known as "components". On the other hand, the materials that are used to make up the subsection are what should be known as "elements". Like fire, earth, air and water, there are different kinds of elements; they combine to make up components that can be sub-sections of constructions, including of course constructions that have only one logical subsection: the unit whole. Logically, this is always true regardless of what particular construction is developed. But now, to address an earlier question, when is a construction a "CI"? And the answer is, a CI is not a thing; it is a management perspective on a thing. This thing might be an item or a configuration. What makes the thing a CI is management's attention to its role as an "element" of a service.
Now, when the main construction will be provided for use as a "service", and we are talking about the "components" of the service, we are referring to the configurations within the service. Remember that the essence of a "service" is in that it is something being provided for use in a given way; the type and complexity of a thing does not define it as being a service. However, logically, the components in the management view are the actual "instances" of whatever type of CI, since the instances are what the service user is actually reliant on.
Remember also that the configurations within the service are constructions themselves. What we must recognize is that for a construction seen at a "top" or "parent" level, the involved configurations have elements; but at a lower "child" level, those elements of the parent may be constructions for the child. In this way we see the drill-down through a structural hierarchy based on a recurring logic. For pragmatic reasons, organizations increasingly adopt names for the different levels, such as "Business" (parent), "IT" (child), and "Systems" (grandchild). By this logic, systems configurations become items for (i.e., elements of) IT configurations, and IT configurations become items for business configurations. Meanwhile, "services" may occur at any level, because what defines a service is how something is provided, not what something is.
What is more interesting, then, in this whole thing is not so much the parts (items) themselves but the relationships that become the structural arrangement (or actual configuration) within the construction provided as a service.
In a management scenario, relationships become important mainly because, not surprisingly, they make the configuration manageable. This intent immediately makes some relationships more important than others depending on the perspective of the particular manager. And most interestingly, it throws attention on items (parts)that are not "equipment" such as hardware and software, but instead are "instruments" such as supervisory people, or regulatory documents -- indeed, any influential entity that can be logically assigned (i.e., related) as an enabling part in the ongoing functionality of the construction.
Now, since one of management's primary concerns is to establish and maintain the appropriateness to task of whatever is being managed, then another large focus of management is configurability. To throw quality control into configurability, there is initially the aspect of design, and quickly thereafter the matter of change-control.
The design side of things calls for specifications, which basically are descriptions of the particular configuration and/or item that is intended to be realized. With design and specifications, many instances of the same type of thing should be possible to produce with sufficient similarity to make the instances interchangeable if necessary, but all of the instances would be examples of a specific and unique version of a specific and unique model.
The value of specification is in its precision, which allows managers and users to have confidence that they have their hands on exactly what they need. The specification may point out that there are characteristics of a configuration that are produced or contributed by supplier X while other characteristics are given by supplier Y.
Keeping a central library of trusted configuration descriptions is the idea that gave birth to the Configuration Management DataBase or CMDB. In a CMDB, it is usually the case that configuration characteristics are identified as parts meeting specifications called "attributes". It stands to reason that a CMDB needs to gather reliable data from multiple suppliers responsible for the attributes of any of the configurations on record. The problem of managing the CMDB itself, then, is no different from keeping any complex database in good shape. If anything, the degree of confidence that the CMDB users want in its data makes the complexity that much harder to cope with.
Centralization of the data is the easy way to describe the strategy for meeting the goal of a highly-reliable CMDB. To really appreciate what this means, it is necessary to understand "centralization" in three tactical ways that reflect and resolve the CMDB's complexity:
- federation,
- synchronization, and...
- consolidation.
Federation refers to the multiple donors of trusted information working in a co-operative manner so that they do not fail to contribute the right thing by the right time. As teammates, they need to all be on the playing field together when the play is about to be run.
Synchronization refers to the possibility that more than one party knows about the same thing, but they know it and talk about it in dissimilar ways. In this case, if one of them is more up to date in its knowledge than is the the other one, the other needs to get up to date in the terms that it uses to refer to the same thing. This paralleling, in which if A=B and B=C then A=C, calls for some mechanism that can assure the parties' two different terms (A and C) can again represent each other correctly in the same moment.
Consolidation refers to the case where multiple terms that refer to the same thing are reduced to one term which becomes the singular preferred referent, making the redundant others unnecessary.
Ideally, any configuration in a CMDB is an instance of some single type that is a successful consolidation of descriptions. Each unique type can have, theoretically, an unlimited number of instances.
In typical implementations, a CMDB may or may not be federated, since the CMDB might be held responsible for only certain types of configurations that could be confidently composed and described without multiple suppliers. Federation, always a possibility, is usually more the exception than the rule.
Synchronization is initially an issue when the first decisions are being made about which data sources are the ones that should be considered authoritative. If there are already multiple systems recording descriptions of the same thing, they probably need to be checked against each other to see how well they match, before either one is chosen over the other. This will be most useful when CIs are being initially defined for inclusion in the CMDB, since there is no point in recording a CI unless there is a trusted mechanism for keeping the record up to date.
As the above issues go, things tend to resolve in a way that there is not much discussion about federation, synchronization or consolidation (!) -- however, a different term is constantly used and rules the roost: reconciliation.
Reconciliation refers to the need to take recent validated discoveries about the characteristics of actual instances of configurations, and compare the findings to the record about those configurations as found in the CMDB. Updating the CMDB records means that the recorded versus discovered information must be checked, with mismatches resolved through a manager's decision about whether to change the CMDB record or change the actual configuration instance. Because a CMDB is not trusted unless it is known to be up-to-date in its authority, reconciliation is a critical success factor for the CMDB utilization. However, in a little recognized nuance, "reconciliation" is often mis-applied to the effort to remain up-to-date.
To appreciate this nuance, consider that two parties start out disagreeing, but they wind up agreeing with each other in the end. This would be reconciliation. However, if the two parties cannot agree with each other, and a third party is required to make the decision for both of them, then the original two parties (still disagreeing) did not have a reconciliation but instead an arbitration. An important thing to note here is that an arbitration effort can always come up with the same results that a reconciliation can, but a reconciliation effort cannot always come up with the results that an arbitration can.
It is often the case that I.T. managers rely on a mix of tools providing highly reliable feedback each in its own terms. This sets up the important necessity for arbitration to the degree that the tools do not share a common descriptive dictionary. Arbitration rules enforce "tiebreakers" and properly dispose of exceptions; this clears the way for consolidation of information within the CI record.and brings the CMDB closer to the capability that management really wants the CMDB to support -- risk avoidance in decisions, under the pressure of Quality of Service expectations.
Posted by Malcolm Ryder at February 23, 2009 4:17 PM