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:
·
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.
No comments:
Post a Comment