This is the fifth posting in a series on TOGAF’s ADM. Following the ADM, we have so far prepared the organization for doing architecture work, defined an architecture vision and modeled baseline- and target architecture. In this post we zoom in on phase E: Opportunities and Solutions in which we find the delivery vehicles for implementing the architecture. As before, we briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Objectives, steps, inputs and outputs

The primary objectives for this phase are to (a) consolidate the gap analysis for the three domains, (b) to find groups of building blocks to address the capabilities that address the missing capabilities. To understand what happens in this phase, a solid understanding of the building block concept is necessary.

Sidebar: building blocks

Simply put, a building block (BB) is a cohesive unit of functionality and can be either a business capability, (part of) an information system, a piece of infrastructure or a combination thereof. BB’s are loosely coupled and can generally be realized independent of other BB’s, often in more ways than one. Note that a distinction between architecture building blocks (ABB) and solution building blocks (SBB) are made. The former capture architecture requirements from the relevant domains, whereas the latter specify what components will implement these requirements. More details can be found in section 37 of the TOGAF 9 specification.

The inputs to this phase are numerous: all the architectural artefacts developed so far are used and analyzed to form a coherent view of the exact capabilities that are to be delivered. Heavy use is being made of the architecture repository in this phase: specifications of BB’s are used in conjunction with case studies, vendor information, implementation strategies and so forth.

The TOGAF standard proposes to use a tabular form for gap analysis, where the vertical axis lists the baseline BB’s and the horizontal axis lists target BB’s. Analyzing rows and columns effectively means comparing baseline and target architectures. The following diagram illustrates how this works:

Gaps between baseline and target may result from each of the three domains:

• Business – missing skills, process inefficiencies, missing information etc.
• Data – data placement, data quality, missing functionality etc.
• Applications – to be implemented, updated or removed
• Technologies – to be implemented, updated or removed

In performing the gap analysis, constraints (budget, time), dependencies, and readiness for change must be taken into account. After defining a high-level implementation strategy, major areas of work are translated into transition architectures.

The outputs of this phase are numerous and partly consist of updated version of artefacts produced so far such as the architecture definition document and architecture requirements specification. Other outputs include a report on the readiness for change of the organization, and the transition architecture which includes the consolidated gaps, dependencies, risks etcetera.

Best practices

Performing gap analysis is complex and time consuming. It is often underestimated with terrible consequences. Two main issues seem to cause this in practice:

• Dependencies are missed
• The readiness for change is too optimistic

In many cases, the latter is reinforced by the former as people tend to miss dependencies, push for a “favored solution” and suggest that implementing this favored solution is relatively easy. For example, we have seen cases where a “small change to a table and a form” turned out to result in a 4 month project with changes to at least a dozen systems and processes.

Building up an architecture repository with detailed knowledge about the organization is a key capability that helps organizations deal with gap analysis and impact assessment. It generally takes a while to gather this knowledge and storing and managing this information centrally will increasingly make life easier. In previous posts we already advocated the use of ArchiMate as a language and proposed to use a repository-based tool (such as BiZZdesign Architect).

Using a tool makes it relatively easy to find out which components / building blocks are relevant for impact assessment. Obviously, the segment under consideration may have changed, meaning that the architect must always confirm the validity of the models. A typical scenario would be to start with one building block (i.e., an IT system) and ask the tool to generate views that show which other building blocks are ‘attached’ to it. By also considering baseline and target plateaus, the below view can be arrived at

We have seen in practice that these diagrams work well for both validation (i.e., note that the customer file service is not realized by any infrastructure component presently, a clear omission by the architect!) and project planning.

Outlook

If you’d like to know more, please contact the author directly at This e-mail address is being protected from spambots. You need JavaScript enabled to view it , or leave a comment. The next post in this series entitled “Translating opportunities to a well-defined project plan” is scheduled to be posted on the 31^st of October.