Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the eight posting in a series on TOGAF’s ADM which covers phase H – Architecture Change Management. Phase H is not really a phase, but more a continuous activity of monitoring change as well as establishing procedures for managing this change.
Objectives, steps, inputs and outputs
The adage “the only constant is change” most certainly holds for many businesses. It is therefore extremely important to make sure that the designed architectures continue to stay aligned to business goals and direction. The formal objectives of this phase are: make sure that the architecture continues to be fit for purpose, assess changes to the framework and principles set up in the previous phases, to establish a change management process for the new (baseline) architecture that is achieved with the completion of phase G, and to operate the governance framework.
The drivers for change will vary from organization to organization but may originate from e.g. a strategy change, resolving key issues in the current operation or experience from previous (architecture) projects.
Changes are managed by means of a Request for Change (RFC) form. Changes can be classified as either simplification changes (which can normally be handled via regular change management techniques), an incremental change, or a re-architecting change (which requires the organization to go through a whole new ADM cycle). To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:
1. Registration of all events that may impact the architecture 2. Resource allocation and management for architecture tasks 3. The process or role responsible for architecture resources has to make assessment of what should be done 4. Evaluation of impacts
Typical inputs for this phase are all the architecture deliverables from the previous phases (including e.g. the Organizational Model for EA, the Architecture Repository and the Architecture Definition Document) as well as formal change requests. Typical outputs are architecture updates, changes to the framework, new requests for architecture work (spinning off a new ADM cycle) as well as compliance assessments and (updated) architecture contracts.
Based on experiences at several organizations over the last few years we have learned that the key to being successful in the area of architecture change management lies in two things: communication and participation. To operationalize this, the organization should have an effective architecture board.
The Architecture Board “should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture”. If the key players with respect to architecture join forces in the board and meet frequently (bi-weekly tends to be a good rhythm) then changes as well as issues in projects can be dealt with early and effectively.
Note that the board should be used for (a) discussing new trends, and (b) making decisions. The board should delegate detailed (impact) analysis to the architecture team whenever possible to make the best use of its time.
If you’d like to know more, please leave a comment. The final post in this series entitled “Covering the basics: keep track of requirements” is scheduled to be posted on Monday the 12th of December.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: