4.3 Governing EA, Scoping the Architecture & Alternatives
Key Takeaways
- The TOGAF ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.
- TOGAF says well-defined, effective governance controls all architecturally significant activity within a single framework.
- The four dimensions used to scope an architecture are Breadth, Depth, Time Period, and Architecture Domains.
- Architecture scope is normally directed by the team's organizational authority, the objectives and stakeholder concerns, and the availability of people, finance, and resources.
- The architecture alternatives method selects criteria, identifies alternatives, and then selects one or combines features, with the architect facilitating the stakeholders' trade-off decision.
4.3 Governing EA, Scoping the Architecture & Architecture Alternatives
This section covers three more "Introduction to the ADM" learning outcomes: explain the need to govern the creation, development, and maintenance of Enterprise Architecture; briefly explain how to scope an architecture; and briefly explain the reasons for considering architecture alternatives, including understanding concerns and trade-offs.
Why Enterprise Architecture Must Be Governed
The ADM does more than design architectures. The TOGAF Standard says the ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures. Governance is needed across that whole lifecycle for several reasons that run through the standard:
| Need | How TOGAF addresses it |
|---|---|
| Control architecturally significant activity | Central to operating an ongoing architecture is well-defined and effective governance, whereby all architecturally significant activity is controlled and aligned within a single framework |
| Decide what enters the repository | The criteria for including source materials in an organization's Architecture Repository typically form part of the EA governance process, which decides when general resources can be adapted and when specific solutions can be generalized for wider re-use |
| Make sure only agreed architecture steers change | Deliverables are formally reviewed, approved, and signed off; approved targets, not candidate designs, govern change |
| Keep implementation faithful to the architecture | Phase G provides architectural oversight of implementation using Architecture Contracts and compliance reviews; the Content Framework's realization models include binding statements used to steer and govern implementation |
| Manage risk and exceptions openly | The architect may identify and mitigate risks, but risks are accepted and managed within the governance framework; non-conforming work is handled through dispensations |
| Keep the architecture current | Phase H establishes procedures for managing change to the architecture, and Requirements Management handles changing requirements through appropriate governance processes |
The benefits TOGAF claims for architecture governance include increased transparency of accountability, proactive risk and opportunity management, protection of the existing asset base through re-use, and value creation through monitoring, measuring, evaluation, and feedback (Chapter 11). Governance is set up early: the Preliminary Phase includes the step Confirm Governance and Support Frameworks and produces an Architecture Governance Framework.
Scoping an Architecture
There are many reasons to constrain the scope of architecture work, and TOGAF says the scope chosen is normally directed by:
- The organizational authority of the team producing the architecture
- The objectives and stakeholder concerns to be addressed
- The availability of people, finance, and other resources
The scope of an architecture activity is expressed through four dimensions:
| Dimension | Question it answers | Example decision |
|---|---|---|
| Breadth | What is the full extent of the enterprise, and how much of it should the architecting effort focus on? | Retail banking division only; exclude insurance subsidiary |
| Depth | To what level of detail should the architecting effort go? | Capability and service level, not detailed physical design |
| Time Period | What is the architecture horizon, and does it make sense to develop Transition Architectures? | Three-year target with two Transition Architectures |
| Architecture Domains | Which domains are covered? | Business and Data in detail; Technology treated as a constraint |
A complete Enterprise Architecture description should contain all four architecture domains, but resource and time constraints often mean a given cycle focuses on some of them. These are the same decisions the ADM key points say must be taken afresh for every iteration: breadth, level of detail, time period, and assets to leverage.
Scope and Architecture Levels
Scope also connects to the Architecture Landscape. A broad, shallow scope over a long horizon typically produces a Strategic Architecture; a scope covering an area of the enterprise at program or portfolio level produces a Segment Architecture; a narrow, detailed scope focused on particular abilities produces a Capability Architecture.
Architecture Alternatives and Trade-Offs
Why Consider Alternatives?
Stakeholders have different, often conflicting concerns — cost, speed, security, flexibility, regulatory exposure. There is usually more than one way to meet a set of requirements, and each way favors some concerns over others. TOGAF therefore describes part of the architect's role as showing the trade-offs made in reconciling potentially conflicting stakeholder concerns. Considering alternatives:
- Makes the consequences of choices visible before commitment
- Lets stakeholders decide explicitly rather than inheriting an architect's or vendor's assumption
- Surfaces options that combine strengths of more than one approach
- Supports re-use, because existing assets are compared with new build options
A trade-off is characterized as "a balance achieved between two desirable but incompatible features; a compromise."
The Architecture Alternatives Method
The ADM Techniques document describes a simple method:
- Select criteria — use the vision, principles, requirements, and other information to select sets of criteria fitting for different alternatives.
- Identify alternatives — define alternatives based on the criteria and build understanding of each.
- Choose — either select one of the alternatives or combine features from more than one to create the proposed alternative, then define it in detail.
Hints from the standard: perform the activities in just enough detail; the method can be used in any phase at any level of architecture; and the practitioner's role is to facilitate the stakeholders' trade-off decision, because complex trade-offs require compromises between stakeholders' preferences such as priority, cost, and value.
Worked Example
| Criterion (from principles and requirements) | Alternative 1: Extend legacy core | Alternative 2: SaaS platform | Alternative 3: Hybrid |
|---|---|---|---|
| Time to first value | Fast | Medium | Fast |
| Fit with "Common Use Applications" principle | Low | High | Medium |
| Data residency concern (risk officer) | Met | Uncertain | Met |
| Five-year cost | High | Medium | Medium |
Stakeholders choose the hybrid, combining the fast start of Alternative 1 with the shared-platform direction of Alternative 2 — exactly the "combine features" option the method allows.
Common Exam Pitfalls
- Forgetting a scope dimension. The four are Breadth, Depth, Time Period, and Architecture Domains.
- Thinking alternatives are only for technology choices. The method can be applied in any phase at any level.
- Assuming the architect makes the trade-off decision alone. The architect facilitates the stakeholders' decision.
- Treating governance as something that starts in Phase G. Governance frameworks are confirmed in the Preliminary Phase and apply to creation, development, and maintenance of the architecture.
Which four dimensions does TOGAF use to express the scope of an architecture activity?
According to TOGAF, what is a trade-off?
In the architecture alternatives method, what is the practitioner's role in the final decision?
Which factors does TOGAF say normally direct the scope chosen for an architecture activity?