Running TOGAF without bureaucracy

TOGAF is often blamed for bureaucracy when the real causes are implementation choices that the standard does not require and explicitly advises against through its tailoring guidance. Five sources account for most bureaucratic architecture behaviour.

1. Unclear decision rights. If nobody knows what architecture is allowed to decide, every review becomes a negotiation. The Architecture Board reviews everything because it trusts nothing to be handled elsewhere. The solution is not more governance but clearer governance: a decision rights matrix that specifies which decisions need board review, which the domain architect can decide, and which belong to the delivery team.
2. Over-centralised review. All decisions flow through one forum regardless of their consequence level. Minor choices queue alongside major ones, creating bottlenecks that affect sprint cadence and delivery morale. The solution is tiered governance: different weights for different decisions, with escalation reserved for decisions that genuinely cross the board threshold.
3. Artefact production without decision purpose. Templates exist because the content framework mentions them, not because someone needs them for a decision or handoff. Documents multiply without anyone asking whether they change a delivery choice. The solution is the purpose test: every artefact should serve an identified decision or handoff. If it does not, it should not be produced.
4. Fear-driven governance. The architecture function reviews everything because past failures have created a culture of defensive oversight. The response to a governance gap is always more governance, never smarter governance. The solution is to address the specific failure that caused the fear with a specific control, not to add blanket oversight.
5. No tailoring discipline. The enterprise keeps every activity from the largest possible interpretation of the ADM, even when the problem does not justify that weight. This is the source the opening story illustrates: the architecture team treated the content framework as a mandatory checklist rather than a menu. The solution is explicit tailoring using the G20F patterns.

None of these causes is inherent to TOGAF. All of them are implementation choices that the standard explicitly advises against. C220 Part 3 states that the ADM is intended to be used flexibly and tailored. The permission to tailor is built into the method. The enterprise must exercise that permission deliberately.

A lightweight TOGAF implementation is still good if the enterprise can answer four questions positively. These questions test whether the essential architecture value survives the tailoring. If all four answers are positive, the implementation is proportionate. If any answer is negative, the tailoring has removed too much.

1. Can the enterprise explain its architecture decisions to a sceptical stakeholder? This tests whether decision traceability survives. If nobody can explain why a target state was chosen, the architecture has no explanatory power. The minimum requirement is a decision log that records significant decisions, their rationale, and their status.
2. Can it control material exceptions with visibility and follow-on discipline? This tests whether the waiver process from Module 54 works. If deviations accumulate invisibly with no expiry conditions and no compensating controls, the architecture is fictional. The minimum requirement is an exception register with the six waiver elements.
3. Can it hold a cross-domain picture of change that delivery teams recognise as useful? This tests whether the repository serves delivery. If delivery teams do not use architecture outputs, the cross-domain picture exists only for the architecture team. The minimum requirement is a target-state view that delivery teams reference when making design decisions.
4. Can the repository answer a real question faster than asking a senior architect from memory? This tests whether the repository is operational. If the fastest way to get architecture information is to find a specific person, the repository is decorative. The minimum requirement is that a delivery lead can find the rationale behind a specific constraint within five minutes using the repository alone.

If those four abilities survive the tailoring, the implementation is proportionate. If they disappear, the enterprise has stripped the method past the point of usefulness. Conversely, if the enterprise has all four abilities plus significant additional process that does not improve any of them, the additional process is bureaucracy.

Even the lightest TOGAF implementation should retain five control points that protect architecture value. These five controls are the floor, not the ceiling. A regulated enterprise like London will need more. A small product team might need only these. The point is that removing any of them erodes the architecture's ability to explain and govern itself.

1. Scope statement. A clear, short description of the enterprise problem, architecture boundary, and decision horizon. Without this, nobody can judge whether the architecture is relevant or whether a specific decision falls inside or outside its scope. The scope statement should be one page, not a document.
2. Active principles. A small set of architecture principles (typically 8 to 15) that are specific enough to constrain real decisions and reviewed regularly enough to stay current. Principles that cannot be used to settle a design disagreement are too vague. Principles that have not been reviewed in over a year are likely stale.
3. Decision log. A record of significant architecture decisions, their rationale, and their status. The log does not need to be elaborate. It needs to be findable and maintained. The test is whether a delivery lead who was not in the room can understand why a constraint exists.
4. Exception register. A record of active deviations, their compensating controls, and their expiry conditions. This is what prevents architecture debt from accumulating invisibly. Without it, the enterprise has no mechanism to distinguish between governed exceptions and ungoverned drift.
5. Lightweight review path. A defined way for material exceptions to reach a decision forum, even if that forum is a weekly 30-minute architecture review rather than a formal board. The review path should have a defined threshold (what triggers escalation) and a defined response time (how quickly the forum will decide).

G20F provides TOGAF-endorsed patterns for tailoring the ADM to different enterprise contexts. The guide recognises that one-size-fits-all application of the full ADM creates the exact overhead problems described in the opening story. G20F offers four tailoring strategies, each of which can be applied independently or in combination.

Iteration and levels

G20F supports iterating through ADM phases at different levels of detail. A strategic-level pass may touch all phases lightly to establish direction. A segment-level pass may focus on specific domains in depth. A capability-level pass may address a single bounded problem within an existing target architecture. Each level adjusts the depth of analysis and the weight of governance without abandoning the method's structure. The enterprise chooses the level that matches the problem, not the level that matches a standard operating procedure.

Phase selection

Not every initiative requires every ADM phase. A narrow change within an existing target architecture may start at Phase E (migration planning) rather than repeating Phases A through D. An initiative that affects only the technology domain may focus on Phase D without revisiting the business or information systems architecture. G20F makes this explicit: the enterprise should enter the ADM at the point that matches the problem.

Artefact selection

G20F supports producing only those artefacts that serve a decision or handoff purpose. The content framework is a menu, not a mandatory checklist. If an artefact does not change a delivery decision or feed a governance review, it should not be produced. This single principle eliminates more unnecessary weight than any other tailoring choice. The 47-template problem from the opening story is a direct consequence of treating the content framework as mandatory.

Governance scaling

G20F supports scaling governance from a full Architecture Board with formal compliance reviews to a lightweight review and escalation path, depending on enterprise risk and scope. A large, regulated enterprise may need full board governance for cross-domain decisions and lighter governance for bounded changes. A small enterprise may need only a weekly review meeting with an escalation path for material exceptions.

G210 (Applying the TOGAF ADM using Agile Sprints) addresses the common objection that TOGAF is incompatible with agile delivery. Module 49 covered the G210 sprint integration model in the context of delivery cadence. Here the focus is on how G210 supports proportionate governance by changing the cadence of architecture work without weakening its substance.

Architecture runway

Architecture work runs ahead of delivery sprints, producing just-enough architecture to guide the next sprint cycle. The architecture team maintains a runway of decisions and views that delivery teams can consume. The runway prevents the waterfall trap (define everything before delivery starts) without creating the divergence trap (sprint into territory with no architectural guidance).

Sprint-aligned reviews

Architecture reviews happen at sprint boundaries rather than in separate governance cycles. This integrates architecture into delivery cadence rather than creating a parallel process that adds calendar time. The review at each sprint boundary asks: did the sprint stay within guardrails, and has the sprint produced any learning that should update the architecture?

Decision-point governance

Rather than reviewing every sprint output, governance focuses on decisions that cross the board-level threshold. Sprint-level decisions that stay within published guardrails do not need board review. Decisions that affect cross-domain boundaries, change the target state, or introduce a material deviation do need review. This is proportionate governance in action: weight where it matters, lightness where it does not.

G210 does not dilute TOGAF. It adapts the cadence while preserving the method's core value: decision traceability, cross-domain coherence, and governed exceptions. The architecture function stays relevant because it operates at delivery speed rather than at its own separate speed.

London is a relatively strong-fit TOGAF case because the change is wide, regulated, and dependent on good governance. Even here, proportion matters. London should not attempt maximum TOGAF everywhere. The discipline lies in assigning the right weight to the right decision, not in applying maximum weight everywhere or minimum weight everywhere.

Tier 1: Full governance weight

Applies to cross-domain decisions, target-state changes, major exceptions, and regulatory milestones. These earn the cost of formal board review, documented architecture contracts, and structured G21H compliance assessment. Examples in London include:

• Changes to the OT/IT boundary architecture that affect operational safety.
• Changes to the information authority model that affect regulatory publication.
• New cross-domain integration patterns that affect multiple work packages.
• Material exceptions to architecture principles with regulatory consequence.

Tier 2: Lighter governance

Applies to domain-specific design choices within the approved target state, technology configuration within approved platforms, and sprint-level decisions that stay within published guardrails. These need domain architect review and recording in the decision log, but not formal board review. Examples in London include:

• Internal design of a connection-offer calculation service within the approved integration pattern.
• Configuration changes to the publication pipeline within approved data standards.
• Local workflow optimisation within an operational area that does not change cross-domain boundaries.

Tier 3: Minimal governance

Applies to operational fixes, minor cosmetic changes, and decisions entirely within one bounded service that do not affect cross-domain boundaries, data authority, or regulatory compliance. These need only standard change management, not architecture review. Examples in London include:

• Bug fixes within a single service that do not change the data model or integration pattern.
• User interface refinements that do not change the underlying business process or data authority rules.
• Performance tuning within an approved technology platform.

The four-question test applied to London

• Decision traceability: Can the Architecture Board explain to Ofgem why a specific technology choice was made? If yes, the decision log is working.
• Exception visibility: Are all waivers (such as the API gateway waiver from Module 54) recorded with expiry dates and compensating controls? If yes, the exception register is working.
• Cross-domain picture: Do delivery teams reference the target-state views when making design decisions? If yes, the repository serves delivery.
• Repository operationality: Can a delivery lead find the rationale behind the OT/IT boundary constraint without asking the chief architect? If yes, the repository is operational.