2.4 Applying the ADM: The TOGAF Library, Purpose-Based Architecture Projects & the Digital Enterprise

2.4 Applying the ADM: The TOGAF Library, Purpose-Based Architecture Projects & the Digital Enterprise

Section 2.3 covered how much ADM to run — tailoring, iteration cycles, and architecture levels. This section covers the question that comes immediately before it: what is this piece of architecture work actually for? TOGAF's answer is more precise than "to produce an architecture," and getting it right is what stops an architecture team from producing beautifully modelled documents that nobody uses.

---

Purpose-Based Architecture Projects

The TOGAF Standard identifies four distinct purposes that an architecture project can serve. They are not maturity stages and they are not sequential — a healthy architecture practice runs all four concurrently for different parts of the enterprise.

Three consequences follow, and each is worth internalizing:

1. The purpose determines the deliverable set, not the other way round. An Architecture Definition Document produced for Solution Delivery and one produced for Strategy should not look alike. Strategy work that descends to interface specifications has failed; Solution Delivery work that stops at capability maps has also failed.
2. The purpose determines the appropriate architecture level. Strategy work produces Strategic Architecture; Portfolio work produces Segment Architecture; Project and Solution Delivery work produce Capability Architecture and solution-level detail. This is the practical bridge between the abstract three-level landscape of Section 2.3 and a real engagement.
3. The purpose determines who governs it. Strategy and Portfolio architectures are governed by the Architecture Board directly; Project and Solution Delivery architectures are usually governed through Architecture Contracts and compliance reviews (Sections 6.1 and 6.4).

A common failure mode: an architecture team is asked for "an enterprise architecture," produces a Strategy-purpose artifact, and is then criticized by delivery teams for being abstract and by executives for being slow. The team never asked which purpose it was serving. Ask first.

---

Using the TOGAF Library to Configure the Framework

The ADM is deliberately generic. The TOGAF Library is where the specifics live: Series Guides, reference models, templates, patterns, and worked material published by The Open Group to help you configure the framework for a context. Applying the standard well means reaching for the Library rather than re-deriving guidance from first principles.

Material you adopt from the Library is normally copied into the Reference Library class of your Architecture Repository (Section 10.1), where it sits alongside your own in-house patterns. Note the boundary carefully: adopting Library material does not by itself make it binding on your projects. Reference material informs practice; it is your Standards Information Base that binds compliance, so anything you intend to enforce has to be promoted into the SIB and governed. Be precise about the Library's status, too — it is the store that holds the TOGAF documentation set, and the Series Guides inside it are part of the TOGAF Standard (Section 1.2). What is advisory is the reference material you draw from it, not the standard itself.

---

Applying the ADM to Support the Digital Enterprise

"Digital enterprise" is not a slogan in the standard; it names a specific set of pressures that change how the ADM is executed:

• Change is continuous, not episodic. The enterprise is never between architectures. Phase H stops being an occasional review and becomes a standing function that continuously triggers new Architecture Capability and Architecture Development iterations.
• The unit of change is smaller. Instead of one multi-year transformation, the enterprise runs many small changes concurrently. That pushes work toward Capability Architecture and Solution Delivery purposes, with Strategic Architecture providing guardrails rather than blueprints.
• Decisions must be made with less certainty. Architecture alternatives and trade-offs move to the foreground: the architect's job becomes framing options and their consequences for stakeholders, not declaring a single answer.

---

Architecture in an Agile Enterprise

Applying the ADM alongside agile software delivery is an explicit Foundation-level topic, and the reconciliation is simpler than the debate around it suggests:

1. Just enough architecture, just in time. Produce the architecture needed for the next increment at the level of detail that increment requires. Architecture work is itself iterative — that is what the four iteration cycles are for.
2. Feed an architecture runway. Architecture Building Blocks defined ahead of delivery (shared identity services, event backbones, data contracts) let delivery squads move fast without each inventing its own foundation.
3. Govern by contract, not by gate-keeping. An Architecture Contract that states the constraints a squad must respect scales far better across many concurrent teams than a review board approving every design.
4. Keep the Requirements Repository authoritative. Agile backlogs churn; architecture requirements need a stable home so traceability survives re-prioritization.

The failure mode to avoid is treating "agile" as a licence to skip architecture entirely. The result is a fast accumulation of technical debt that the enterprise pays for over the following decade — exactly the outcome enterprise architecture exists to prevent.

---

Exam Focus

The Introduction to Applying the ADM syllabus area is worth 4 of the 40 questions on OGEA-101. Across that area and Section 2.3, be able to state: how to apply the standard (via the Library and Series Guides), how iteration works, the three levels of the Architecture Landscape, why partitioning is used, the four purposes of architecture projects, and how the standard supports the digital enterprise.