Building Blocks

Building Block Characteristics

Building blocks have generic characteristics as follows:

• A building block is a package of functionality defined to meet the business needs across an organisation
• A building block normally has a type that corresponds to the metamodel (such as actor, business service, application, or data entity)
• A building block has a defined boundary and is generally recognisable 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 realise 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 organisation 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 Object Management Group® (OMG® has developed a standard for Re-usable Asset Specification (RAS),¹ which provides a good example of how building blocks can be formally described and managed.

Building Blocks and the ADM

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

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; ie., 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.

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 evolutionary and 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 phases and steps of the ADM at which building blocks are evolved and specified are summarised in Figure 5-1. 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.