Building Blocks and the ADM

Building Blocks and the Architecture Development Method

Principles Specification Process Levels of Modelling

Basic Principles

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

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 an information system.

The various building blocks in an architecture specify the services required in an organization specific system.

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

An architecture need only contain building blocks to implement those services that it requires.
Building blocks may implement one, more than one, or only part of a service identified in the architectural framework.
Building blocks should conform to standards relevant to the services they implement.

Building Block Design

The process of identifying building blocks includes looking for collections of functions which require integration to draw them together or make 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 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 reusability.

Building Block Specification Process in the ADM

The process of building block definition takes place gradually as the Architecture Development Method is followed, mainly in steps A, B and C. 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 architectural building blocks (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 Solution Building Blocks (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 1.

Figure 1: Key Phases / Steps of ADM at which Building Blocks are Evolved / Specified

In Phases A and B the earliest building block definitions start as relatively abstract.

Phase A Initiation and Framework produces:
- A first list of candidate building blocks, from the business process view.
- A model of these candidate building blocks showing the relationships between them
Phase B Baseline Description produces:
- A second, additional list of candidate building blocks, from the analysis of the baseline.

Both of these are lists of potentially reusable Architecture Building Blocks from the existing system.

Phase C Target Architecture Development takes these lists and model as inputs, and evolves them iteratively during a number of steps into a definition of the target architecture, specified in terms of architectural building blocks.

Phase C, Step 3, produces:
- a high level description and broad model of the target system in terms of Architectural Building Blocks.
- a rationale for each building block decision
Phase C, Step 4, produces:
- for each Architectural Building Block, a service description portfolio, built up as a set of non-conflicting services. The set of services must be tested to ensure that the functionality provided meets application requirements.
Phase C, Step 5, produces:
- a confirmation of the merit and completeness of the model and service description portfolio, and a description of how the emerging target architecture meets the objectives of the architecture development
Phase C, Step 7, produces:
- A target architecture, fully specified in terms of Architectural Building Blocks
- a fully defined (by service) list of all the standards that make up the target architecture, and all the Architectural building blocks that will be used to implement it.
- a diagrammatic depiction of the building blocks at the levels needed to describe the strategic and implementation aspects of the architecture.

The minimum content of an Architectural Building Block specification is described under Introduction to Building Blocks.

Finally in Phase D "Opportunities and Solutions" the building blocks become more implementation specific as Solution Building Blocks, and their interfaces become the detailed architecture specification.

The output of Phase D is:
- The building block architecture, both in Architectural (i.e. functionally defined) and Solution (i.e. product-specific) Building Block forms.

The minimum content of a Solution Building Block specification is described under Introduction to Building Blocks.

Levels of Modelling

Defining and developing the context for a set of building blocks takes place at two levels:

The business process level (colored green in the diagrams in this section). This deals only at the highest level with what has to happen for a business process to be carried out.

The technical functionality and constraints level (colored blue in the diagrams). This level deals with the component activities that form part of the business process and whether they can be supported or not.

Defining and developing an actual set of building blocks also takes place at two levels:

The architectural model level (colored red in the diagrams). This level identifies the systems and components that will implement the technical functionality and expresses the relationships between them. This level introduces the idea of a notation to describe the architectural elements and relationships.

The solution model level (colored black in the diagrams). This is the level where the individual products and/or product components that will implement the architecture are identified.

Working through the four levels is an iterative process. Figure 2 shows how considerations at any level can result in change at any or all of the other levels.

Figure 2: Iteration between the Four Levels of Modeling

Mapping the Modelling Levels to the ADM

The business process level of definition takes place in Phase A of the ADM.

The technical functionality and constraints level work happens in Phase B, once the characteristics of the current system have been established. At that stage it is possible to identify the constraints imposed on new architecture work by the legacy of the old system.

The architectural model and solution model levels consist of work done in Phase C, the Target Architecture phase of the ADM, and Phase D, Opportunity Identification. The architectural model work is mostly done in Phase C-2, when taking different views of the architecture, and the solution model work in Phase D, where selection of products and projects takes place.

To show how building block definition happens in practice, the remainder of this appendix consists of a fictional worked example. In this fictional example much detail has been left out in order to emphasise the process.