Objectives, steps, inputs
and outputs
The
objective of this phase is simple: come up with a migration plan that is
aligned with other management and governance frameworks in the organization
(i.e. project management approaches such as Prince2). This entails two things:
(1) to make sure that work packages – based on the transition architectures
from phase E – are defined and prioritized, and (2) to co-ordinate with the
project management office so that the projects can be kicked off when
necessary.
The inputs
of this phase are numerous in the full TOGAF spec, and mostly cover the outputs
of all the previous phases such as the architecture vision, statement of
architecture work, architecture definition document, (preliminary) architecture
requirements specification and a set of (preliminary) transition architectures.
Many of these documents will be
finalized in the current phase.
Following
the TOGAF standard, the steps in this phase include confirming that other
management and governance frameworks are aligned (i.e., project management,
operations) to avoid surprises down the road; do a cost/benefit analysis based
on expected business value of each of the transition architectures; prioritize;
generate a time-lined roadmap and migration plan; and to establish the
architecture evolution cycle as well as lessons learned. In this phase, close
co-operation, buy-in, and direction from management are key in generating the
desired migration plan.
The key
deliverables of this phase are the implementation plan and architecture
contracts for each of the proposed implementation projects. Such contract is a
“joint agreements between development partners and sponsors on the
deliverables, quality, and fitness-for-purpose of an architecture”. This
deliverable closely resembles DYA’s “Project Start Architecture” (PSA). This
document will be used in the next phase as a basis for governing and overseeing
the implementation project.
Best practices
In several
projects at clients, we have found that maintaining a close relation between
the enterprise architecture team and a project management office is a key
aspect of being successful with architecture.
Traditionally
when someone in the business has a great idea, a first step in achieving it is
a project lead who manages the concretization of the idea into a solid
implementation plan and its delivery. When adopting TOGAF’s ADM, a large part
of this work is delegated to the architecture team. In order to structurally
manage the relation, roles, responsibilities between the two bodies in an
organization it is useful to create an architecture board. In the architecture
board, key players from the business side (executive sponsors), architects,
project managers and other stakeholders meet to jointly prioritize work
packages. Usually such a board only approves (or calls for amendments of) plans
that are prepared by the architecture team, but in some cases (i.e., large
programs and key projects under high pressure), a workshop-based approach may
be called for.
A second
best practice in this respect pertains to document management. The TOGAF
standard proposes to use an architecture repository to track and manage
artefacts produced during/ used by the architecture team. However, since
projects need a formal basis, in our experience it is best to let the project
management office (PMO) handle management of documents that are formally signed
off. The contract can then be managed together with documents and deliverables
that are used by the project methodology of the organization.
Firstly, it
shows that planning & prioritization is a joint activity between different
roles, and is part of Phase E of TOGAFs ADM. This phase is modeled as a process
step. Furthermore, the diagram also shows that the management of formal project
documentation is a function that is used in phase E. (Execution of) this
function is assigned to the project manager.
Outlook
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