CIs and BBs: ITIL meets TOGAF

I have had some recent discussions about tool that I produced which is meant to allow projects to be assessed based on their architectural reuse of a set of core building blocks (BB). The proposed value of this would be to allow architecture development within a project to demonstrate architecture building block (ABB) reuse through a BB-Requirements matrix, where each project requirement would be mapped to a standard set of core ABBs. The matrix would theoretically show that the more BB-Requirement intersection, the less risk of unnecessary and non-compliant components being introduced by that project’s proposed architecture. This tool has been sent out to a few people and interestingly, one of the first questions that has come back has been related to IT management. Essentially, the question was this:

What is the difference between a TOGAF building block and an ITIL CMDB Configuration Item?

Since we are in the process of implementing an ITIL-compliant ITSM system, people’s attention towards topics like CMDB and CIs are definitely heightened, but the more I consider the question, the more I am drawn into this topic: Truly, what is the difference? Or, are there any differences at all?

A Configuration Management Database (CMDB) according to ITIL v3 is:

A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

A Configuration Item (CI) according to ITIL v3 is:

Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained through its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software buildings, people, and formal documentation such as Process documentation and SLAs.

A Building Block (BB) according to TOGAF v9:

Represents a (potentially reusable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanies by a full specification. Building blocks can relate to “architectures” or “solutions.”

Without claiming to be an expert in ITIL or TOGAF, I have attempted to outline similarities and differences that I believe exist at first glance. There are definitely several ways to look at the nature of the data and metadata which populate an ITIL CMDB or a TOGAF Meta Model-based Architecture Repository, but since I’m still learning to apply both knowledge areas, I’ll leave my assessment at only the surface level. Feel free to comment with additional thoughts or opposing views.

Similarities

• Components: CIs and BBs are both discrete components – hardware, software, locations, roles, services, etc. – each with a unique set of attributes.
• Relationships: Both are expressed not only in terms of their own attributes, but are most valuable when relationally modeled in respect to other components.
• Abstractions: Both make use of abstraction, composition, and decomposition to express “low level” components and their relationship to “high level” components.
  
• States: Some Configuration Management Systems (CMS) are able to manage transitional states between the current state and previous transitions or even proposed future states. This is similar in concept to the transitioning of a BB from a current to future state. Though, the implementation of this is dependent on the ITSM and CMS, CIs definitely support the idea of states.
  

Differences

• Single vs. Multiple Perspectives
  

  One of the biggest differences between a CI and a BB is the framework that manages them. Since ITIL is primarily a Service Management framework, CIs are typically represented in a service model. Because of this, I would imagine that almost never is there a CMDB dedicated to managing the relationships between organizational goals and a process, nor is data typically modeled in a CMDB at all. Therefore, I believe you could consider ITIL’s service models to be a single Service Management view of the broader set of views required to model EA. This means that only the CIs required to model this view are housed in the CMDB.

• Operational vs. Strategic Functions
  

  Since the CMBD typically only manages CIs related to service management, it is particularly helpful to those performing day-to-day service management activities. Consider a strategy map dashboard which shows strategic goals, their relationship to one another, and rolls up health information for each goal. This would be another operational view, supported by EA modeling which would not fit into a typical CMBD and therefore is not a candidate CI.

• Service Management vs. Enterprise Architecture Context
  

  In summary, I think the biggest difference between CIs and BBs are their context. The systems which attempt to support this context do not take into account other uses. While the CIs in a CMBD are relegated to only those required to model the service management view, this does not have to be the case. Nor is it true that there shouldn’t be some collaboration between CMDB and EA repository vendors to support a dual purpose system, where BBs are able to be made into CIs in support of the IT service management view.

 

Advertisement