7.3 Supporting Agile Software Development with the ADM
Key Takeaways
- TOGAF supports enterprise agility through partitions, which split work into multiple architecture initiatives, and levels, which develop architecture at different granularity and detail.
- In an Agile enterprise, Segment Architecture can provide just enough architecture to identify features and requirements that become backlog items for Agile teams.
- Capability Architecture is the solution specification that Agile teams construct and deploy while following architecture guidelines, metrics, and compliance considerations.
- TOGAF treats enterprise agility as broader than Agile software development based on the Manifesto for Agile Software Development.
- The TOGAF Standard, 10th Edition lists Minimum Viable Architectures among the Design Support Services that help funded projects, whether waterfall or Agile.
7.3 Supporting Agile Software Development with the ADM
The final "Introduction to the ADM" learning outcome asks you to explain how developing architecture for different purposes, or levels of detail, can be applied to support Agile software development. The key idea: TOGAF does not require a big design up front. Architecture can be developed at the level of detail and for the purpose that each decision needs, so Agile teams get just enough architecture at the right time.
Enterprise Agility and the TOGAF Framework
The TOGAF Standard, 10th Edition notes that "enterprise agility" is defined differently by different practitioners, but it matters because it enables an enterprise to better react to change by being more customer and product-centric, more efficient, and better able to ensure regulatory compliance. The term "agile" is often associated with the Manifesto for Agile Software Development; those principles and techniques can be applied to adapt the TOGAF framework, but enterprise agility is broader than Agile software development.
Enterprise Architecture provides a framework for change, linked to strategic direction and business value, with a sufficient view of the organization to manage complexity, support continuous change, and manage the risk of unanticipated consequences.
TOGAF responds to the need for timely delivery through three concepts:
| Concept | What it does for agility |
|---|---|
| Partitions | Define how the work is broken down into multiple architecture initiatives, which can proceed in parallel |
| Levels | Define how the overall architecture can be developed at different levels of granularity and detail |
| Iteration | Allows the ADM to be applied repeatedly and concurrently, within and between phases |
The ADM does not mandate a waterfall method or a fixed phase sequence (Section 4.1), so it can be run in short cycles.
Levels of Detail Supporting Agile Delivery
The TOGAF Series Guide Enabling Enterprise Agility describes how architecture at each level of the Architecture Landscape supports an Agile enterprise:
| Level | Role in an Agile enterprise | Agile connection |
|---|---|---|
| Strategic Architecture | A high-level iteration, supported mainly by Phase A, that sets strategic direction and provides context for lower-level architectures | Guides portfolio themes and priorities |
| Segment Architecture | Typically the specification of a product or business solution — just enough architecture to identify features and functional and non-functional requirements | Outputs become backlog items that Agile teams can work on |
| Capability Architecture | The solution specification that Agile teams construct and deploy, following architecture guidelines, metrics, and compliance considerations | Delivered through sprints and releases |
Because higher levels establish direction and constraints, lower-level architecture can be produced incrementally and just in time, alongside the teams that build the solution.
Purposes of Architecture Supporting Agile Delivery
The 10th Edition also frames architecture by purpose (Section 10.4). Each purpose works at a different pace and depth:
| Purpose | Contribution to Agile software development |
|---|---|
| Architecture to Support Strategy | End-to-end target and roadmaps over a three- to ten-year period, giving Agile programs direction |
| Architecture to Support Portfolio | Supports cross-functional, multi-phase, multi-project change initiatives — for example, coordinating dependencies between several Agile product teams |
| Architecture to Support Project | Supports the enterprise's project delivery method, which may be Agile |
| Architecture to Support Solution Delivery | Used to support solution deployment, working alongside teams as they build |
Architecture developed for solution delivery can be light and fast, while architecture for strategy is broader and longer-term. Matching the purpose and level of detail to the decision at hand is how TOGAF avoids either no architecture or excessive up-front documentation.
Minimum Viable Architecture
The 10th Edition lists Minimum Viable Architectures (MVAs) among the Design Support Services an EA practice can offer after a project has been funded, whether the project is waterfall or Agile. An MVA provides just enough architecture for teams to start building safely, with more detail added as understanding grows.
Where to Find More Guidance
- TOGAF Series Guide: Enabling Enterprise Agility — how to adapt and use the TOGAF framework to support an Agile enterprise
- TOGAF Series Guide: Applying the ADM Using Agile Sprints — using the ADM in sprint-based delivery
- The Open Agile Architecture™ Standard — a separate standard of The Open Group, referenced by the TOGAF Standard as a source of guidance for Agile enterprises
Scenario: A Digital Bank's Product Teams
A digital bank runs a Strategic Architecture iteration to set a three-year direction: mobile-first customer journeys and a shared payments platform. A Segment Architecture for "retail payments" defines just enough architecture — key features, interfaces, security requirements — to create backlog items. Product teams then deliver the Capability Architecture for instant payments in two-week sprints, following the bank's principles and standards and checked through lightweight compliance reviews. When a sprint reveals a new regulatory constraint, the change is recorded through Requirements Management and the Segment Architecture is updated — iteration keeps the architecture current without stopping delivery.
Common Exam Pitfalls
- Assuming TOGAF requires a waterfall approach. The ADM does not mandate a waterfall method or a fixed phase sequence.
- Equating enterprise agility with Agile software development. TOGAF treats enterprise agility as broader.
- Producing all architecture detail up front. Levels and purposes allow just enough architecture at the right time.
- Confusing partitions with levels. Partitions break work into multiple initiatives; levels set granularity and detail.
Which two TOGAF concepts help the framework respond to the needs of an Agile enterprise in a timely manner, alongside iteration?
How can Segment Architecture support Agile software development according to TOGAF guidance on enterprise agility?
What does the TOGAF Standard say about enterprise agility compared with Agile software development?
Which architecture purpose is described as EA used to support solution deployment, working at the pace of teams building the solution?