Architecture Building Blocks

An Architecture Building Block is defined as a package of functionality which is defined to meet the needs of a business.

How the functionality, custom developments and products inside a building block are packaged varies between architectures.

Each business or organisation should decide what arrangement of building blocks works best as a good choice of selecting building blocks can lead to:

  • Interoperability when creating a new system or application
  • Flexibility when creating a new system or application
  • Improvements in legacy system integration

The characteristics of Building Blocks

Generic Building Blocks should have the following generic characteristics:

  • A package of functionality which is defined to meet the needs of the business across an organisation
  • A building block has interfaces associated with it to provide access to functionality
  • The building block may inter-operate with other, interdependent building blocks

A good Building Block should have the following characteristics:

  • The building block considers the implementation and usage and then evolves to exploit standards and technology
  • The building block may be a sub-assembly of other building blocks
  • The building block is both replaceable and reusable and well specified
  • The building block may be implemented multiple times but in association with difference interdependent building blocks

The two types of Building Blocks – ABBs and SBBs

There are two types of Building Blocks:

  • Architecture Building Blocks (ABBs)
  • Solution Building Blocks (SBBs)

Architecture Building Blocks

Architecture Building Blocks (ABBs) relate to the Architecture Continuum and are defined or selected based on the result of the application of the Architecture Development Method (Generally during ADM Phases A, B,C and D).

The main characteristics of Architecture Building Blocks are:

  • Technology-aware
  • Provide direction and guidance for the development of Solution Building Blocks
  • Capture technical and business requirements
  • Define the functionality to be implemented

Solution Building Blocks

Solution Building Blocks (SBBs) relate to the Solutions Continuum and are either developed or procured.

The main characteristics of Solution Building Blocks are:

  • A SBB will define what components and products will implement the required functionality
  • They will define the actual implementation
  • A SBB will ensure that it fulfills the requirements of the business
  • SBBs are vendor or product aware

An easy way to differentiate between the two types of building blocks is to understand the following:

“Architecture Building Blocks are more closely aligned with the design and specification whilst the a Solution Building Block is essentially the implementation of the Architecture Building Block”

The Gap Analysis

The technique known as Gap Analysis is used throughout the TOGAF Architecture Development Method to validate an architecture under development. The main step to understand when undertaking a gap analysis is to consider any facets which may have been forgotten.

The purpose of a gap analysts is to show any shortcomings between the Baseline Architecture and the Target Architecture meaning any items which may have been accidentally or deliberately left out or not yet defined.

Crucial source of gaps which should be actively considered are any concerns of the stakeholders which may have not been addresses in prior architectural work.

A gap analysis occurs during phases B, C, D and E of the architectural development method.

How to perform a gap analysis

The first step is to draw a matrix with a list of all the Target Architecture Building Blocks (ABBs) across the top.

Next, create a new column listing all the Baseline Architecture Building Blocks (ABBs vertically)

At the end of the last horizontal row create a new column and call this column Eliminated.

Create a new row at the very bottom of the matrix and call this row New.

When an ABB appears in both the horizontal row at the top and the first column indicating that the ABB appears in both the target and baseline architectures, mark the cell as Included.

When an ABB in the baseline architecture is not included in the target architecture the ABB should be reviewed. In the scenario where the ABB is correctly eliminated mark it as Intentionally Eliminated in the associated cell in the Eliminated column.

When an ABB was found to be accidentally eliminated and must be addressed by reinstating it during the next iteration of the architecture design mark the ABB as Unintentionally Eliminated in the associated cell in the Eliminated column.

When an ABB from the target architecture is not included mark it as a gap which needs to be developed in the row marked New.

The Enterprise Operating Model

The Enterprise Operating Model is a technique that is used in phases A through to E in the TOGAF Architecture Development Method.

The main ingredient to establishing interoperability is to determine the Corporate Operating Model.

The Corporate Operating Model will determine what type of interoperability approach will be appropriate.

The Operating Model is the necessary level of business process integration and standardisation for delivering services and goods to customers. The Operating Model will describe how a company wants to grow by providing a more actionable and stable view of the company.

There are four operating models each based on the level of business process, standardisation and integration. It is using these models that architects are able to decide the level of detail and complexity of solution and architecture building blocks.

The four operating models are:

  1. Coordination
  2. Unification
  3. Diversification
  4. Replication