You are here: | ||
<<< Previous | Home | Next >>> |
The TOGAF Architecture Development Method (ADM) is intended to be used as a model to support the definition and implementation of architecture at multiple levels within an enterprise. As discussed in Part V, 40. Architecture Partitioning , it is not possible to develop a single architecture that addresses all the needs of all stakeholders. Therefore, the enterprise must be partitioned into different areas, each of which can be supported by architectures. As discussed in Part V, enterprise architectures are typically partitioned according to Subject Matter, Time Period, and Level of Detail, as illustrated in Summary Classification Model for Architecture Landscapes .
This chapter discusses the types of engagement that architects may be required to perform and how the ADM can be used to co-ordinate the activities of various teams of architects, working at different levels of the enterprise.
An architecture function or services organization may be called on to assist an enterprise in a number of different contexts, as architects range from summary to detail, broad to narrow coverage, and current state to future state. Typically, there are three areas of engagement for architects:
Classes of Enterprise Architecture Engagement and the following table show the classes of enterprise architecture engagement.
Each of these architecture engagement types is described in the table below.
Area of |
Architecture |
|
---|---|---|
Engagement |
Engagement |
Description |
Definition of Change |
Architectural Definition of Foundational Change Initiatives |
Foundational change initiatives are change efforts that have a known objective, but are not strictly scoped or bounded by a shared vision or requirements. In foundational change initiatives, the initial priority is to understand the nature of the problem and to bring structure to the definition of the problem. Once the problem is more effectively understood, it is possible to define appropriate solutions and to align stakeholders around a common vision and purpose. |
|
_ |
_ |
|
Architectural Definition of Bounded Change Initiatives |
Bounded change initiatives are change efforts that typically arise as the outcome of a prior architectural strategy, evaluation, or vision. In bounded change initiatives, the desired outcome is already understood and agreed upon. The focus of architectural effort in this class of engagement is to effectively elaborate a baseline solution that addresses the identified requirements, issues, drivers, and constraints. |
Implementation Change |
Architectural Governance of Change Implementation |
Once an architectural solution model has been defined, it provides a basis for design and implementation. In order to ensure that the objectives and value of the defined architecture are appropriately realized, it is necessary for continuing architecture governance of the implementation process to support design review, architecture refinement, and issue escalation. |
Different classes of architecture engagement at different levels of the enterprise will require focus in specific areas, as shown below.
Engagement Type |
Focus Iteration Cycles |
Scope Focus |
---|---|---|
Supporting Business Strategy |
Architecture Context Architecture Definition |
Broad, shallow consideration given to the Architecture Landscape in order to address a specific strategic question and define terms for more detailed architecture efforts to address strategy realization. |
Architectural Portfolio Management of the Landscape |
Architecture Context Architecture Definition |
Focus on physical assessment of baseline applications and technology infrastructure to identify improvement opportunities, typically within the constraints of maintaining business as usual. |
Architectural Portfolio Management of Projects |
Transition Planning Architecture Deployment |
Focus on projects, project dependencies, and landscape impacts to align project sequencing in a way that is architecturally optimized. |
Architectural Definition of Foundational Change Initiatives |
Architecture Context Architecture Definition Transition Planning |
Focus on elaborating a vision through definition of baseline and identifying what needs to change to transition the baseline to the target. |
Architectural Definition of Bounded Change Initiatives |
Architecture Definition Transition Planning |
Focus on elaborating the target to meet a previously defined and agreed vision, scope, or set of constraints. Use the target as a basis for analysis to avoid perpetuation of baseline, sub-optimal architectures. |
Architectural Governance of Change Implementation |
Architecture Deployment |
Use the Architecture Vision, constraints, principles, requirements, Target Architecture definition, and transition roadmap to ensure that projects realize their intended benefit, are aligned with each other, and are aligned with wider business need. |
The previous sections have identified that different types of architecture are required to address different stakeholder needs at different levels of the organization. Each architecture typically does not exist in isolation and must therefore sit within a governance hierarchy. Broad, summary architectures set the direction for narrow and detailed architectures.
A number of techniques can be employed to use the ADM as a process that supports such hierarchies of architectures. Essentially there are two strategies that can be applied:
At the extreme ends of the scale, either of these two options can be fully adopted. In practice, an architect is likely to need to blend elements of each to fit the exact requirements of their Request for Architecture Work.
Each of these approaches is described in the sections below.
In situations where a single architecture team is tasked with defining architectures at many levels within the enterprise, it is possible to use iterations within a single ADM cycle to create all required architectures.
Using this approach, the Architecture Vision phase can be used to develop a strategic view of the architecture. Phases B, C, and D then provide a more detailed and formal architectural view of the landscape for different segments or time periods. Phases E and F then develop a detailed Migration Plan, which may include even more detailed and specific Capability Architectures.
A summary of the approach is shown in Iterations within a Single ADM Cycle Example .
The key benefits of this approach are:
The key limitations of this approach are:
Generally speaking, this approach should be used when a number of architectures are being developed within a similar time period by a single team.
In cases where larger-scale architectures need to be developed by a number of different architecture teams, a more hierarchical application of the ADM may be used. This approach to the ADM uses the Migration Planning phase of one ADM cycle to initiate new projects, which will also develop architectures. This approach is illustrated in A Hierarchy of ADM Processes Example .
The key benefits of this approach are:
The key limitations of this approach are:
Generally speaking, this approach should be used when architectures are being developed over different timelines by different
teams.
return to top of page
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.