10.4 The Four Purposes of Architecture
Key Takeaways
- The four purposes of architecture are Architecture to Support Strategy, Portfolio, Project, and Solution Delivery.
- Architecture to Support Strategy provides an end-to-end Target Architecture and develops roadmaps of change over a three- to ten-year period.
- Architecture to Support Portfolio supports cross-functional, multi-phase, and multi-project change initiatives.
- Architecture to Support Project supports the enterprise's project delivery method, and Architecture to Support Solution Delivery supports solution deployment.
- An Architecture Capability is established specifically to support one or more purposes, which frame the planning horizon, breadth, and depth of architecture work.
10.4 The Four Purposes of Architecture
The Foundation syllabus asks you to list the four purposes that help to frame the planning horizon and breadth and depth of the Architecture Project. The TOGAF Standard, 10th Edition recognizes that Enterprise Architecture is not done for one reason: an Architecture Capability is established specifically to support one or more purposes, and each purpose shapes how far ahead the architecture looks, how wide it goes, and how much detail it needs.
The Four Purposes
| Purpose | Description |
|---|---|
| Architecture to Support Strategy | Provide an end-to-end Target Architecture and develop roadmaps of change over a three- to ten-year period |
| Architecture to Support Portfolio | Support cross-functional, multi-phase, and multi-project change initiatives |
| Architecture to Support Project | Support the enterprise's project delivery method |
| Architecture to Support Solution Delivery | Enterprise Architecture used to support the solution deployment |
The Series Guide A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM describes how the ADM is configured for each purpose.
How Purpose Frames Horizon, Breadth, and Depth
| Purpose | Planning horizon | Breadth | Depth |
|---|---|---|---|
| Strategy | Longest — three to ten years | Widest: the whole enterprise or a large part of it | Least detailed; summary target and roadmap |
| Portfolio | Medium — the span of a portfolio of change initiatives | Cross-functional: several projects or programs | More detailed: enough to coordinate dependencies and priorities |
| Project | The project's delivery timescale | The project's scope | Detailed enough to guide the project |
| Solution Delivery | Shortest — the deployment of a solution | Narrowest: the solution being delivered | Most detailed: specific enough to guide implementation |
This is why purpose connects so closely to scoping (Section 4.3): breadth, depth, time period, and domains follow from what the architecture is for.
Purposes and Landscape Levels
The purposes map naturally, though not rigidly, to the landscape levels:
- Architecture to Support Strategy typically produces Strategic Architecture
- Architecture to Support Portfolio typically produces Segment Architecture
- Architecture to Support Project and Solution Delivery typically produce Capability Architecture and solution-level detail
How Each Purpose Feeds the Next
The Series Guide A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM describes a configured journey through the ADM for each purpose, and shows how the output of one purpose sets the boundaries for the next:
| Purpose | What the architecture typically does | What it hands on |
|---|---|---|
| Strategy | Clarifies the Target Architecture and a roadmap of change over three to ten years, identifying change initiatives | Direction and boundaries for portfolios and programs, and a basis for governing strategy execution |
| Portfolio | Focuses on a single portfolio, deriving its boundaries and purpose from the strategic architecture above it, and groups work into coherent themes within budget | The projects that make up the portfolio and terms of reference for each project |
| Project | Focuses on a single project, deriving its boundaries from the portfolio architecture, and identifies the discrete gaps and work packages that deliver measurable value on the roadmap | Scope and budget confirmed, and preparation for solution delivery governance, including Architecture Contracts |
| Solution Delivery | Supports the teams deploying the solution | Architecture-compliant solutions and feedback to higher-level architectures |
This "superior architecture sets the boundaries" pattern is the same one seen in the Architecture Landscape levels (Section 10.2) and in hierarchies of concurrent ADM cycles (Section 10.1).
Why the Purposes Matter
- Right-sizing effort: a strategy engagement that tries to specify every interface wastes effort; a solution delivery engagement that stays at summary level gives teams nothing to build against.
- Choosing stakeholders: executives care most about strategy; portfolio and program managers about portfolio; project managers about projects; delivery teams about solution delivery.
- Designing the capability: an EA practice set up mainly to support projects needs different skills, tools, and governance than one set up to support strategy.
- Supporting agility: solution delivery and project purposes can move at the pace of Agile teams, within the direction set by strategy and portfolio architecture (Section 7.3).
Worked Example: One Organization, Four Purposes
| Purpose | Example engagement in a retail bank |
|---|---|
| Strategy | Define a target architecture and a seven-year roadmap for moving from branch-centric to digital-first banking |
| Portfolio | Coordinate the lending, cards, and payments programs so shared customer and identity services are sequenced correctly |
| Project | Provide architecture for the new mortgage origination project, fitting the bank's project delivery method |
| Solution Delivery | Guide the delivery team deploying the mortgage decisioning solution, resolving design questions as they arise |
Common Exam Pitfalls
- Confusing purposes with phases. The four purposes are reasons for doing architecture, not ADM phases.
- Confusing purposes with levels or domains. Strategy, Portfolio, Project, and Solution Delivery are purposes; Strategic, Segment, and Capability are levels; Business, Data, Application, and Technology are domains.
- Forgetting the strategy horizon. Architecture to Support Strategy develops roadmaps over a three- to ten-year period.
- Assuming one purpose per enterprise. An Architecture Capability can support one or more purposes.
Which list gives the four purposes of architecture in the TOGAF Standard, 10th Edition?
Which purpose of architecture provides an end-to-end Target Architecture and develops roadmaps of change over a three- to ten-year period?
An architecture team coordinates dependencies across several programs and projects that together deliver a cross-functional change initiative. Which purpose is being served?
How do the four purposes relate to scoping an Architecture Project?