February 6, 2013

Figuring out the baseline architecture and target architecture

This is the fourth post in a series on TOGAF’s ADM. In this posting we zoom in on Phases B, C, and D, covering business architecture, information systems architecture, and technology/infrastructure architecture. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Introduction

The ADM’s phases B, C, and D cover what was traditionally thought of as “doing architecture”: modeling the architecture of an organization at some point in time. As such, these phases cover what was traditionally believed to be the main job of an architect: make architecture models (several years of consulting in the field of architecture have taught me that many clients still expect this of their architects). Given the fact that goals and steps for these three phases are so similar, I decided to cover them in one posting.

Objectives, steps, inputs and outputs.

The main objective of each of the B, C, and D phases is to develop baseline architecture and target architectures for each domain, and to perform a gap analysis between these two. Based on selected viewpoints, baseline and target architectures are documented in a way that the concerns of relevant stakeholders are addressed.

Even though it is acknowledged that a good architecture effort starts with a solid understanding of business architecture, it should be noted that the TOGAF standard is fairly IT-centric. Business architecture could be interpreted as “all things that are non-IT, but are relevant to IT”. In practice, though, we see more and more organizations to broaden the scope of business architecture.

The list of inputs for this phase is rather long. Key inputs are the organizational model for EA (explaining the organization of the architecture function), as well as the outputs of the previous phases, most notably the request/statement of architecture work and the architecture vision (a high-level, aspirational view of the end architecture product).

The steps that are conducted for each of the domains are relatively straight forward. Based on the architecture vision, a baseline and target architecture are developed and documented using relevant viewpoints. In many cases, reference models can be used in this activity (i.e., in telecom industry the eTOM, TAM, and SID standards are frequently used). A gap analysis for each individual domain is performed (optional), impact of the rest of the organization is analyzed, after which a formal stakeholder review is conducted. Approval is necessary to proceed with the next step.
The results of these phases are documented in the architecture definition document (ADD), possibly complemented by the architecture requirements specification (ARS). The main distinction between these two lies in the fact that the ADD has a focus on functional aspects whereas the ARS has a focus on non-functional / quality aspects. Both documents span all architectural domains.

Best practices

The phases under consideration rely heavily on TOGAF’s content meta-model which prescribes the concepts that can be used to model building blocks of the architecture:

Even though the core entities and some relations between them are defined, we noticed that in practice a more formal language improves communication drastically. This particularly holds for ArchiMate, another standard maintained by the Open Group. The core concepts of the ArchiMate language map well on the concepts prescribed by the TOGAF standard. An illustration of (part of the) meta model is given below:

The advantages of using a formal modeling language such as ArchiMate are manifold:

·         Both concepts and relations between concepts are formally defined:
o   Models are more easily interpreted
o   It is easier to bring new architects on board
·         The further development of the ArchiMate language is aimed at making sure the language covers all phases of TOGAF. This includes extensions for requirements, motivation, and project management
·          Tool support – such as BiZZdesign Architect – is available:
o   Automatically verify correct use (syntax) of the language
o   Store architectural models as well as views for future reuse
o   Reuse architectural knowledge across architectural teams using a repository
o    Generate and manage different views on the same model for different stakeholders (isn’t this worth a separate bullet?)

We end this blog post with an ArchiMate diagram that shows the result of a gap analysis in the information systems domain, showing several applications which are to be phased out, as well as new functions being added to another system.


Outlook

Many best practices are to be mentioned for these phases, such as the merging the ADD and ARS documents, and the use of conceptual/ logical/ physical architectures. They will be covered in separate blog postings, not in this series. If you have thoughts or suggestions in this respect, please let us know!
If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment. 
Post a Comment