Tailoring TOGAF by size, speed, and risk

TOGAF expects tailoring. That is not a weakness or a concession. It is a design principle built into the standard. The ADM is deliberately broad enough to cover complex, multi-year, regulated enterprise change. It is also deliberately designed to be adapted for lighter contexts. Part 3 of the TOGAF Standard specifically addresses iteration and levels of architecture. The G186 Series Guide provides a practitioner's approach to proportionate ADM application.

Tailoring does not mean casual trimming. It means deciding what architecture work the enterprise genuinely needs, what can be lighter, what must stay explicit, and how the whole operating pattern should behave. The best tailoring decisions preserve the reasons for doing architecture in the first place. They keep architecture useful to the enterprise rather than faithful to an imaginary maximum form of the framework.

What tailoring protects

Good tailoring protects three things: decision memory (why was this choice made?), traceability (how do decisions connect to one another?), and exception governance (what happens when somebody needs to deviate from the architecture?). These are the capabilities that future teams, auditors, and regulators will need. They are also the capabilities that disappear first when tailoring is done carelessly.

What tailoring can vary

Almost everything else can vary: artefact depth, modelling formality, governance cadence, repository tooling, review frequency, and the number of ADM phases that receive explicit treatment. The standard provides the full method. The enterprise decides how much of it to use.

Even in the lightest TOGAF implementation, certain controls should remain visible. These are not bureaucratic additions. They are the controls that let future teams understand why decisions were made and whether those decisions still hold.

• A clear statement of the enterprise problem, scope, and change boundary. Without this, nobody can tell what the architecture is trying to achieve or where it stops. This comes from the Architecture Vision and the Statement of Architecture Work.
• Some way of recording the architecture decisions that matter and the reasons behind them. A decision log does not need to be a formal document. It needs to be findable and traceable. Without it, decisions become institutional folklore.
• A minimum useful artefact set that supports current design and future reuse. The repository should contain enough to answer real questions. It does not need to contain everything the framework mentions.
• A governance or review path for material exceptions. Even if the path is lightweight (a weekly review with an escalation route), it needs to exist. Without it, exceptions are handled informally and create untracked technical debt.
• Traceable movement from current problems toward target or transition decisions when change spans time. If the change has meaningful duration, the architecture should explain not just the target but the path. Without this, roadmap logic is invisible.

Artefact depth

A small fast-moving initiative may need concise architecture notes: a one-page scope statement, a simple dependency diagram, and a decision log. A regulated multi-year change programme may need richer artefacts: a full Architecture Definition Document, detailed domain architectures, transition-state models, and a governedrepository. The depth should be proportionate to the decision complexity, not to an abstract idea of what TOGAF "should" look like.

Governance cadence

Some contexts need formal Architecture Board checkpoints with documented decisions, compliance reviews, and exception protocols. Others need a small weekly architecture review with a clear escalation route. The cadence should match the decision rhythm of the enterprise, not the rhythm of an imaginary maximum-governance model.

Modelling formality

Some teams need simple explanatory views that stakeholders can read without training. Others benefit from more formal modelling (using ArchiMate, for example) because scale, cross-domain dependency, and traceability justify the investment. The choice depends on stakeholder audience, repository size, and analytical needs.

Repository tooling

A lightweight effort may use a disciplined folder structure, a decision log in a shared document, and a simple diagram tool. A broader capability may need a richer repository with version control, access management, and stronger stewardship rules. The tooling should serve the practice, not define it.

ADM phase treatment

Not every ADM phase needs explicit treatment in every engagement. A small change may collapse Phase B, Phase C, and Phase D into a single lightweight architecture assessment. A complex change may need each phase handled with full rigour. The ADM is a cycle, not a checklist. Phases can be combined, abbreviated, or given different levels of attention depending on the problem.

These four profiles are not rigid categories. They are reference points that help practitioners calibrate their tailoring decisions against recognisable enterprise contexts.

Profile 1: Small, low-risk, single-team change

Context. One team, one bounded system, limited cross-domain consequence, low regulatory exposure, short duration.

Tailoring. Use a minimal scope statement (one page), one or two architecture views, a clear decision log, and a lightweight exception path. Do not stage-manage a full Architecture Board process for a small bounded problem. Phases B through D may be collapsed into a single lightweight assessment. Phase E and F may be a simple priority list rather than a formal roadmap.

Risk. The risk of under-tailoring (too heavy) is higher than the risk of under-governing (too light).

Profile 2: Medium cross-team platform change

Context. Multiple teams, shared platform or integration, moderate cross-domain consequence, some regulatory or compliance consideration, medium duration.

Tailoring. Keep explicit domain interfaces, a small repository, defined review points, and a roadmap with dependencies. Architecture effort should rise because integration and reuse matter more. Each ADM phase gets some attention, but artefact depth is still proportionate. Governance operates through regular review meetings rather than a formal board structure.

Risk. Both under-tailoring and under-governing are real risks at this level. The calibration needs care.

Profile 3: High-risk or regulated enterprise change

Context. Cross-domain, regulated, multi-year, high consequence of failure, multiple stakeholder groups, external reporting obligations.

Tailoring. Increase evidence quality, governance clarity,transition-state logic, exception handling, and traceability across therepository. Each ADM phase gets explicit treatment. The Architecture Board operates formally. Architecture contracts bind delivery to architecture decisions.Compliance reviews are documented. This is where a fuller TOGAF operating pattern earns its cost.

Risk. The risk of under-governing is higher than the risk of over-tailoring. The enterprise cannot afford invisible architecture at this level.

Profile 4: Fast delivery with strategic consequence

Context. Fast delivery cadence (sprints, continuous deployment), but the decisions have strategic consequence: platform selection, API design, data architecture, or integration patterns that will be hard to change later.

Tailoring. Keep the architecture thin but fast: shorter cycles, fewer artefacts, tighter decision logs, and explicit release conditions. The G210 Series Guide on applying the ADM with agile sprints is directly relevant here. Architecture decisions are embedded in the delivery process rather than sitting outside it. Speed does not remove the need for architecture. It changes the cadence.

Risk. The risk is that speed becomes an excuse for invisible architecture. Strategic decisions made in sprints without architecture visibility accumulate into technical debt that is expensive to reverse.

The TOGAF Series Guide G20F provides patterns for tailoring the ADM to different enterprise contexts. These patterns are relevant because they represent The Open Group's own guidance on how to adapt the method proportionately.

The key principle from G20F is that tailoring should be a deliberate design decision, not an ad hoc reduction. Practitioners should be able to explain why each tailoring choice was made and what it preserves or sacrifices. A tailoring decision that cannot be explained is a tailoring decision that was not really made.

A practical tailoring sequence

1. Define the enterprise problem and the real consequence of getting it wrong. This sets the risk level. A problem with high consequence of failure justifies more architecture depth than one with low consequence.
2. Judge how broad the architecture boundary is. Does the problem span business, information, applications, technology, and governance? Or is it bounded within one or two domains? Broader boundaries justify more method depth.
3. Set the minimum artefacts and decisions needed to keep change defensible. Use the minimum visible controls from section 63.2 as a floor. Add artefacts only where they improve real decisions or handoffs.
4. Choose the lightest governance cadence that still protects enterprise coherence. A weekly review with escalation may be enough. A formal Architecture Board with documented decisions may be needed. Match the cadence to the decision rhythm.
5. Review the tailoring choice after early delivery evidence. Do not treat the initial tailoring as fixed forever. Early delivery experience may reveal that the tailoring was too heavy or too light. Adjust based on evidence.

A practical way to test whether your tailoring has gone too far is to ask five questions. If any answer is "no," the tailoring may have removed something that earns its keep.

1. New-joiner test. Can a new team member understand why the enterprise is changing and what constraints apply? If the architecture is invisible to new joiners, it exists only in the heads of current team members and will be lost when they move on.
2. Decision-trace test. Can a reviewer trace a key decision back to its architectural rationale? If the answer is "you would have to ask the architect who was here two years ago," the decision memory has been lost.
3. Exception test. Can the governance path handle a material exception without improvising? If exceptions are handled informally every time, the governance is not functioning. This does not mean the governance needs to be heavy. It means it needs to exist.
4. Roadmap test. Can the roadmap explain not just the target but the sequencing logic? If the roadmap says "do A, then B, then C" but cannot explain why that order rather than another, the transition logic is missing.
5. Repository test. Can the repository answer a real question faster than asking a senior architect from memory? If the repository is slower or less reliable than asking somebody, it is not earning its maintenance cost.

These five tests are practical, not theoretical. They can be applied at any point during an engagement to check whether the tailoring is working or whether it has cut too deep.

The London case sits toward the heavier end of the tailoring spectrum because it combines regulatory exposure, cross-domain interdependence, long-lived transition states, and visible governance obligations. In terms of the four profiles, London is primarily Profile 3 (high-risk, regulated enterprise change) with elements of Profile 4 (fast delivery with strategic consequence) in its digital transformation workstreams.

How London's tailoring maps to the profiles

• Regulatory and compliance architecture. Profile 3 treatment. Full governance visibility, documented decisions, compliance evidence, and formal exception handling.
• Network and OT/IT architecture. Profile 3 treatment. Cross-domain, safety-relevant, long-lived assets, and strong traceability requirements.
• Digital service and data publication. Profile 4 treatment. Faster delivery cadence, but strategic decisions about data standards, API design, and integration patterns need architecture visibility.
• Internal tooling changes. Profile 1 or 2 treatment. Bounded scope, limited cross-domain consequence, and proportionately lighter architecture effort.

That makes London a useful upper reference point, not a universal template. A lighter enterprise or a narrower change could retain the same core logic with fewer artefacts, fewer checkpoints, and less formality.

• London shows what fuller TOGAF tailoring looks like when enterprise risk and coordination needs are high.
• The learning point is proportionality, not imitation. Your enterprise should design its own tailoring based on its own risk profile, coordination needs, and delivery rhythm.