This chapter explains the concept of building blocks.

37.1 Overview

This section is intended to explain and illustrate the concept of building blocks in architecture.

Following this overview, there are two main parts:

• Introduction to Building Blocks (see 37.2 Introduction to Building Blocks), discusses the general concepts of building blocks, and explains the differences between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).
• Building Blocks and the ADM (see 37.3 Building Blocks and the ADM), summarizes the stages at which building block design and specification occurs within the TOGAF Architecture Development Method (ADM).

37.2 Introduction to Building Blocks

This section is an introduction to the concept of building blocks.

37.2.1 Overview

This section describes the characteristics of building blocks. The use of building blocks in the ADM is described separately in 37.3 Building Blocks and the ADM.

37.2.2 Generic Characteristics

Building blocks have generic characteristics as follows:

• A building block is a package of functionality defined to meet the business needs across an organization.
• A building block has a type that corresponds to the TOGAF content metamodel (such as actor, business service, application, or data entity)
• A building block has a defined boundary and is generally recognizable as "a thing" by domain experts.
• A building block may interoperate with other, inter-dependent, building blocks.
• A good building block has the following characteristics:
  • It considers implementation and usage, and evolves to exploit technology and standards.
  • It may be assembled from other building blocks.
  • It may be a subassembly of other building blocks.
  • Ideally a building block is re-usable and replaceable, and well specified.

A building block's boundary and specification should be loosely coupled to its implementation; i.e., it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block. The way in which assets and capabilities are assembled into building blocks will vary widely between individual architectures. Every organization must decide for itself what arrangement of building blocks works best for it. A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.

Systems are built up from collections of building blocks, so most building blocks have to interoperate with other building blocks. Wherever that is true, it is important that the interfaces to a building block are published and reasonably stable.

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 accompanied by a full specification.

The level of detail to which a building block should be specified is dependent on the objectives of the architecture and, in some cases, less detail may be of greater value (for example, when presenting the capabilities of an enterprise, a single clear and concise picture has more value than a dense 100-page specification).

The OMG have developed a standard for Re-usable Asset Specification (RAS),¹ which provides a good example of how building blocks can be formally described and managed.

37.2.3 Architecture Building Blocks

Architecture Building Blocks (ABBs) relate to the Architecture Continuum (see Part V, 39.4.1 Architecture Continuum), and are defined or selected as a result of the application of the ADM.

37.2.3.1 Characteristics

ABBs:

• Capture architecture requirements; e.g., business, data, application, and technology requirements
• Direct and guide the development of SBBs

37.2.3.2 Specification Content

ABB specifications include the following as a minimum:

• Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability
• Interfaces: chosen set, supplied
• Interoperability and relationship with other building blocks
• Dependent building blocks with required functionality and named user interfaces
• Map to business/organizational entities and policies

37.2.4 Solution Building Blocks

Solution Building Blocks (SBBs) relate to the Solutions Continuum (see Part V, 39.4.2 Solutions Continuum), and may be either procured or developed.

37.2.4.1 Characteristics

SBBs:

• Define what products and components will implement the functionality
• Define the implementation
• Fulfil business requirements
• Are product or vendor-aware

37.2.4.2 Specification Content

SBB specifications include the following as a minimum:

• Specific functionality and attributes
• Interfaces; the implemented set
• Required SBBs used with required functionality and names of the interfaces used
• Mapping from the SBBs to the IT topology and operational policies
• Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability
• Performance, configurability
• Design drivers and constraints, including the physical architecture
• Relationships between SBBs and ABBs

37.3 Building Blocks and the ADM

37.3.1 Basic Principles

This section focuses on the use of building blocks in the ADM. General considerations and characteristics of building blocks are described in 37.2 Introduction to Building Blocks.

37.3.1.1 Building Blocks in Architecture Design

An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of the business.

The various building blocks in an architecture specify the scope and approach that will be used to address a specific business problem.

There are some general principles underlying the use of building blocks in the design of specific architectures:

• An architecture need only contain building blocks that are relevant to the business problem that the architecture is attempting to address.
• Building blocks may have complex relationships to one another. One building block may support multiple building blocks or may partially support a single building block (for example, the business service of "complaint handling" would be supported by many data entities and possibly multiple application components).
• Building blocks should conform to standards relevant to their type, the principles of the enterprise, and the standards of the enterprise.

37.3.1.2 Building Block Design

The process of identifying building blocks includes looking for collections of capabilities or assets that interact with one another and then drawing them together or making them different:

• Consider three classes of building blocks:
  • Re-usable building blocks, such as legacy items
  • Building blocks to be the subject of development, such as new applications
  • Building blocks to be the subject of purchase; i.e., Commercial Off-The-Shelf (COTS) applications
• Use the desired level of integration to bind or combine functions into building blocks. For instance, legacy elements could be treated as large building blocks to avoid breaking them apart.

In the early stages and during views of the highest-level enterprise, the building blocks are often kept at a broad integration definition. It is during these exercises that the services definitions can often be best viewed. As implementation considerations are addressed, more detailed views of building blocks can often be used to address implementation decisions, focus on the critical strategic decisions, or aid in assessing the value and future impact of commonality and re-usability.

37.3.2 Building Block Specification Process in the ADM

The process of building block definition takes place gradually as the ADM is followed, mainly in Phases A, B, C, and D. It is an iterative process because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of products may affect the choice and the content of building blocks.

The key parts of the ADM at which building blocks are designed and specified are summarized below.

The major work in these steps consists of identifying the ABBs required to meet the business goals and objectives. The selected set of ABBs is then refined in an iterative process to arrive at a set of SBBs which can either be bought off-the-shelf or custom developed.

The specification of building blocks using the ADM is an evolutionary and iterative process. The key phases and steps of the ADM at which building blocks are evolved and specified are summarized below, and illustrated in Figure 37-1.

Footnotes

1. Refer to www.omg.org/spec/RAS.

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part of the TOGAF document or go direct to a chapter within the document.
  
• Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or select Home to return to the welcome page.
  

Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G116.