TOGAF and enterprise architecture

TOGAF, from the ADM cycle to designs people build

TOGAF (The Open Group Architecture Framework) is a method for planning change across a whole organisation. This page explains how it works: the ADM (Architecture Development Method), building blocks, reuse, principles, gap analysis, governance and the ArchiMate language. It also shows how each part maps onto the designs, roadmaps and reviews of real infrastructure programmes.

ADM cycle
Building blocks
Enterprise Continuum
Principles
Gap analysis
Transition architectures
Architecture Board
ArchiMate 4

Start with the basics My related work

Live view · every phase adds requirements and draws on them

Basics

A method for change, not a pile of documents

TOGAF (The Open Group Architecture Framework) is an open standard for EA (enterprise architecture): how an organisation plans change across its business, data, applications and technology, and keeps projects pointing the same way while they deliver. It splits the enterprise into four architecture domains. A real change touches all of them.

Swipe sideways to see the whole diagram.

Animation

One change touches every domain. A goal such as getting plant data into the cloud starts as a business driver. It needs data owners and flows, new or changed applications and interfaces, and networks and hosting to carry them. Limits found lower down, such as a plant network that cannot be changed during production, flow back up and reshape the plan.

The TOGAF Standard at a glance

Part	What it holds
Publisher	The Open Group, a vendor neutral consortium. TOGAF 1.0 appeared in 1995. The TOGAF Standard, 10th Edition, was launched on 25 April 2022.
Fundamental Content	Six documents: Introduction and Core Concepts; Architecture Development Method; ADM Techniques; Applying the ADM; Architecture Content; Enterprise Architecture Capability and Governance.
Series Guides	Guidance by topic that changes faster than the core, such as business architecture, security architecture, agile architecture, the digital enterprise and microservices.
Modelling language	ArchiMate, also from The Open Group. TOGAF says what to produce; ArchiMate gives a common notation for drawing it. See ArchiMate below.
Certification	Two levels for people: TOGAF Enterprise Architecture Foundation, then TOGAF Enterprise Architecture Practitioner.

Architecture is a set of decisions

Enterprise architecture decides what an organisation changes, in what order and to which standards, so separate projects add up to one coherent estate instead of a pile of exceptions.

A method, not a template

TOGAF describes a way of working and the content it produces. It expects to be tailored. Applied whole and unchanged, it produces paperwork faster than decisions.

Where it meets my work

As a technical design authority I already set principles, write the vision and high level design, plan phased transitions and review designs. TOGAF gives those steps shared names and a shared order.

The ADM

Nine phases around one set of requirements

The ADM (Architecture Development Method) is the core of TOGAF. A Preliminary phase sets up the practice. Then phases A to H take one piece of change from vision through design, planning and delivery, and back again. Requirements Management sits in the middle, because every phase adds requirements and depends on them. Step through the cycle, then open any phase in detail.

Swipe sideways to see the whole diagram.

Step 1

The Preliminary phase prepares the organisation to do architecture at all. It agrees which parts of the enterprise are in scope, the principles that will guide designs, how TOGAF is tailored, who governs, and which tools and repository hold the work. It is revisited when the practice changes.
Phase A starts when a sponsor sends a Request for Architecture Work. I confirm goals, drivers and constraints, identify stakeholders and their concerns, assess readiness for change and sketch the baseline and target at a high level. The sponsor signs a Statement of Architecture Work before detailed design starts.
Phase B describes the business baseline and target: capabilities, value streams, organisation and processes. Gap analysis between the two shows what must change. For infrastructure work I keep it short but never skip it, because it tells me which capabilities the network must protect first.
Phase C covers data and applications, in either order. Data architecture describes the main data entities, their owners and how data moves. Application architecture describes the applications and their interfaces. For plant work this is where historians, MES (manufacturing execution systems) and cloud platforms appear.
Phase D describes the technology baseline and target: platforms, networks, hosting, cloud and the standards that govern them. Most of my design work sits here: WAN (wide area network) and campus, data centre fabrics, security zones and cloud connectivity, each traced back to the application and business needs above.
Phase E is the first view of delivery. I consolidate the gaps from B, C and D, group them into work packages, decide whether to build, buy or reuse, and define transition architectures: stable states the estate can safely stop at. The result is a first roadmap.
Phase F turns the draft roadmap into a plan the organisation can fund and staff. I agree costs, benefits, risks and dependencies with programme and portfolio owners, sequence the work packages and check that each transition delivers business value. The architecture documents are finalised here.
Phase G watches delivery. Each project signs an Architecture Contract that states what it will build and to which standards. I review designs and builds for compliance, approve dispensations with an end date, and raise change requests when delivery shows the architecture was wrong.
Phase H keeps the architecture current after delivery. I watch new business needs, technology and lifecycle dates, and assess each change request. Then I decide whether it is a simple update, a partial rework, or big enough to start a new cycle with a fresh Request for Architecture Work.
Requirements Management is not a step in the sequence. It runs alongside every phase. New and changed requirements go into one repository, and each change gets a Requirements Impact Assessment, so a late requirement in Phase G is checked against the vision, the design and the plan.

Try it: the ADM phase by phase

Choose a phase to see what goes in, what I do, what comes out, and what the same step looks like in a normal infrastructure programme.

Preliminary phase

Purpose

Set up the architecture practice before any cycle: scope, principles, the tailored framework, governance and tools.

Key inputs

Business strategy and drivers
Existing frameworks, such as ITIL for service management and PRINCE2 for projects
The current state of the architecture practice

What I do

Scope the enterprise and the organisations affected
Confirm governance and supporting frameworks
Define the team and the Architecture Board
Agree architecture principles
Tailor TOGAF and choose the tools and repository

Key outputs

Architecture principles
Tailored framework and tools
Governance and the Architecture Board

My everyday equivalent

Setting up a design authority: terms of reference, principles, templates for high and low level designs, a decision log and a review cadence.

Questions I ask

Who can say yes to a design, and who can say no?
Which existing standards and frameworks must we fit around?

Phase A: Architecture Vision

Purpose

Agree the scope, the stakeholders and the outcome the change must deliver, then win approval to do the architecture work.

Key inputs

A Request for Architecture Work from the sponsor
Business goals, drivers and constraints
Architecture principles from the Preliminary phase

What I do

Identify stakeholders, their concerns and business requirements
Confirm goals, drivers and constraints
Evaluate capabilities and readiness for change
Define the scope, value propositions and KPIs (key performance indicators)
Identify transformation risks, then secure approval

Key outputs

Statement of Architecture Work, signed
Architecture Vision
Stakeholder map and concerns

My everyday equivalent

A solution outline with a one page vision, in scope and out of scope lists, success measures and a signed scope of work.

Questions I ask

What must be true when this is done, and how will we measure it?
What is out of scope, written down?

Phase B: Business Architecture

Purpose

Describe how the business works now and how it must work: capabilities, value streams, organisation and processes.

Key inputs

The Statement of Architecture Work and the Architecture Vision
Business strategy, operating model and process maps
Capability maps, if they exist

What I do

Select reference models, viewpoints and tools
Describe the baseline business architecture
Describe the target business architecture
Perform gap analysis
Define roadmap components and resolve impacts

Key outputs

Business baseline and target
Business gaps and roadmap items
Updated requirements specification

My everyday equivalent

The business context section of a high level design: which sites, production lines and teams depend on the service, and what an outage costs each of them.

Questions I ask

Which business capability fails first if this network fails?
Who owns each process we are changing?

Phase C: Information Systems Architectures

Purpose

Describe the data and the applications the target business needs, and how they connect and exchange information.

Key inputs

The business architecture from Phase B
Application portfolio and data inventories
Integration and data standards

What I do

Select reference models, viewpoints and tools
Describe the baseline and target data and applications
Map applications to data and to business capabilities
Perform gap analysis
Define roadmap components and resolve impacts

Key outputs

Data and application baseline, target
Interface and data flow views
Application and data gaps

My everyday equivalent

The data flow and integration sections of a high level design, with every flow between zones listed by source, destination, protocol and owner.

Questions I ask

Who owns this data, and who may read it?
Which interfaces cross a trust boundary?

Phase D: Technology Architecture

Purpose

Describe the platforms, networks and hosting the applications and data need, now and in the target.

Key inputs

The data and application architecture from Phase C
Technology standards and the current estate
Vendor and product lifecycle dates

What I do

Select reference models, viewpoints and tools
Describe the baseline and target technology
Perform gap analysis
Define roadmap components
Review with stakeholders and finalise

Key outputs

Technology baseline and target
Technology standards and patterns
Technology gaps and roadmap items

My everyday equivalent

The technology sections of a high level design: topology, resilience, security zones, addressing and standards, before the low level design adds detail for each device.

Questions I ask

What is the support status of every platform in the target?
Which failure domains does each design choice create?

Phase E: Opportunities and Solutions

Purpose

Turn the gaps into work: group them into work packages, choose build, buy or reuse, and define stable steps in between.

Key inputs

Gaps and roadmap components from Phases B, C and D
Product and supplier options
Portfolio limits: budget, people and change windows

What I do

Consolidate and reconcile the gaps
Group changes into work packages
Decide whether to build, buy or reuse
Define transition architectures
Draft the roadmap and the migration plan

Key outputs

Architecture Roadmap, first version
Transition Architectures
Draft Implementation and Migration Plan

My everyday equivalent

An options analysis and a phased rollout: pilot sites, waves and the dependencies between them.

Questions I ask

What is the smallest step that delivers something real?
Which work packages depend on each other?

Phase F: Migration Planning

Purpose

Cost, prioritise and sequence the work packages with portfolio and project owners, then finalise the plan.

Key inputs

The draft roadmap and transition architectures
Costs, benefits and risks for each work package
Portfolio plans and the change calendar

What I do

Confirm how the plan meets other management frameworks
Assign business value to each work package
Estimate resources, timings and delivery vehicles
Prioritise and sequence the work
Finalise the roadmap and the plan

Key outputs

Implementation and Migration Plan
Final Architecture Roadmap
Final Architecture Definition Document

My everyday equivalent

The migration plan and business case inputs: waves, costs, resources and the change calendar, agreed with the programme and the PMO (project management office).

Questions I ask

Can we fund and staff the work in this order?
Where does each wave meet a change freeze?

Phase G: Implementation Governance

Purpose

Keep delivery true to the architecture: a contract with each project, compliance reviews and controlled dispensations.

Key inputs

The Implementation and Migration Plan
Project designs: high level, low level and build plans
Architecture standards and principles

What I do

Confirm scope and priorities with the delivery teams
Identify deployment resources and skills
Guide the development of solutions
Run architecture compliance reviews
Review after go live, then close

Key outputs

Architecture Contracts
Compliance assessments
Change requests and dispensations

My everyday equivalent

Design authority reviews at high level design, low level design and before go live, with a decision log, conditions of approval and exceptions that expire.

Questions I ask

Does the build match the approved design?
Which exceptions are still open, and when do they expire?

Phase H: Architecture Change Management

Purpose

Watch for change in the business and in technology, and decide whether to adjust the architecture or start a new cycle.

Key inputs

Change requests from projects and operations
Technology and lifecycle changes, such as end of support
Lessons from delivery

What I do

Monitor business and technology change
Assess each change request
Decide: update, rework or a new cycle
Update the architecture and the repository
Feed lessons back into the practice

Key outputs

Change requests, assessed
Updated architecture and standards
New Request for Architecture Work

My everyday equivalent

Lifecycle management: tracking end of life dates, updating standards and deciding when to start the next refresh or transformation.

Questions I ask

Is this a change to the current design, or a new design?
Which end of support dates fall in the next eighteen months?

Requirements Management

Purpose

Hold every requirement in one place and assess the impact of each change on all the phases, all the time.

Key inputs

Requirements raised in every phase
Change requests
Stakeholder concerns

What I do

Record each requirement with a source and an owner
Prioritise requirements with stakeholders
Assess the impact of each change
Update the requirements specification
Trace each requirement to the design that meets it

Key outputs

Requirements repository
Requirements Impact Assessment
Updated Requirements Specification

My everyday equivalent

A requirements catalogue of functional and non functional requirements, each traced to a design decision and a test.

Questions I ask

Which requirement does this design choice meet?
What breaks if this requirement changes?

It is a cycle, not a waterfall

Phase H can start a new cycle, and any phase can send work back to an earlier one. Most real work loops through B, C and D several times before the target settles.

Requirements never stop

A requirement found during build is still handled properly: it goes to the repository and gets an impact assessment, rather than a quiet change to one design.

Outputs are named

Each phase has defined outputs, such as the Statement of Architecture Work in Phase A or the Architecture Contract in Phase G, so everyone knows what has been agreed and where it is written down.

Iteration and scope

Scale the method to the size of the change

TOGAF expects the ADM to be repeated and tailored, never run once from start to finish. It groups the phases into four iteration cycles, describes three levels of architecture, and scopes each piece of work by breadth, depth, time and domain. Choose a cycle to see which phases it repeats.

Swipe sideways to see the whole diagram.

Architecture Capability. The Preliminary phase and Phase A, repeated when the practice itself needs to change: a new board, new principles, or a big programme that needs its own scope and sponsor. I run this loop before anything else on a new engagement.

Architecture Development. Phases B, C and D, cycled until the domains agree with each other. A technology choice in D often changes an application decision in C, so I expect two or three passes rather than one.

Transition Planning. Phases E and F, repeated as costs and dependencies become clear. Each pass refines the work packages and the transition architectures until the plan can be funded.

Architecture Governance. Phases G and H run for as long as delivery runs. Compliance reviews and change requests loop between them, and a big enough change triggers a new cycle from Phase A.

Animation

Three levels of architecture

Level	Scope	Typical horizon	Who uses it	Where my work sits
Strategic architecture	The whole enterprise	Several years	Executives and the Architecture Board	The direction my designs must fit, such as cloud first or zero trust
Segment architecture	One business area, portfolio or programme	One to three years	Programme and portfolio leads	An OT (operational technology) maturity roadmap across manufacturing sites, or a WAN refresh across a region
Capability architecture	One capability or project	Months to a year	Project teams and design authority	An AI (artificial intelligence) ready data hall, or the network and security for one migration

Horizons are indicative. TOGAF describes the three levels; the horizons depend on the organisation.

Four ways to set the scope

Breadth

Which parts of the enterprise are in scope: one site, one business unit, or the whole group, including partners and suppliers.

Depth

How much detail each domain needs. A strategy needs a page per domain; a capability architecture needs enough for a low level design to start.

Time

How far ahead the target sits, and how many transition architectures lie between today and that target.

Domains

Which of business, data, application and technology must be worked on. Infrastructure work is mostly technology, but never only technology.

Content

Deliverables, artefacts and building blocks

The content framework defines what the ADM produces. Deliverables are the formal outputs that stakeholders sign off. Artefacts are the catalogues, matrices and diagrams inside them. Building blocks are the reusable pieces the architecture is made from. Step through one building block, from a business need to a built solution.

Swipe sideways to see the whole diagram.

Step 1

A requirement arrives from the business: every manufacturing site needs secure, resilient links to the data centre and the cloud. It says what is needed, not which product to buy.
I describe the need as an ABB (architecture building block): a set of functions and qualities with no product attached. Two diverse paths, encrypted transport, central policy and direct cloud access that is still inspected.
SBBs (solution building blocks) are real products or services that could deliver the ABB. Here there are three options: two SD-WAN (software defined WAN) products and a managed MPLS (Multiprotocol Label Switching) service.
Each option is scored against the ABB, the principles and the standards: fit, cost, lifecycle, skills and supplier risk. The managed MPLS service fails the cloud access requirement. Both SD-WAN products fit; the first matches the skills the operations team already has.
The chosen SBB is specified in the low level design and built. Because the ABB came first, the decision record shows why this product won and what any replacement must still do.
Both building blocks go into the architecture repository. The next site, or the next acquisition, starts from the approved pattern instead of a fresh evaluation.

Deliverables are signed

A deliverable is formally reviewed, agreed and signed off by its stakeholders. It is a contract, so it changes through change control.

Artefacts do the explaining

Catalogues, matrices and diagrams are the parts people read. I build deliverables mostly from artefacts, which keeps the prose short.

Building blocks are reusable

A good building block has a clear boundary and interfaces, so it can be reused or replaced. ABBs say what is needed; SBBs say what delivers it.

Three kinds of artefact

Artefact type	What it is	Examples from network and infrastructure work
Catalogue	A list of things of one type	Application portfolio, technology standards, sites and circuits, principles
Matrix	The relationships between two types	Applications to data, applications to technology, stakeholders to concerns, flows to firewall zones
Diagram	A picture for one audience and purpose	Context, network zones, data flows, resilience, the migration roadmap

The main deliverables, in phase order

Deliverable	Phase	What it fixes
Request for Architecture Work	Before A	The sponsor's request: the problem, the goals and the constraints
Statement of Architecture Work	A	The agreed scope, approach, plan and sign off for the architecture work
Architecture Vision	A	A short view of the baseline and the target, and the value of getting there
Architecture Definition Document	B to D	The architecture itself: baseline, target and gaps in every domain
Architecture Requirements Specification	B to D	The requirements a solution must meet to conform to the architecture
Architecture Roadmap	E, F	The work packages and transition architectures, in order
Implementation and Migration Plan	E, F	How and when the roadmap is delivered, with costs and resources
Architecture Contract	G	The agreement between the architecture function and a delivery team
Compliance Assessment	G	The result of reviewing a project against the architecture
Change Request	H	A proposed change to the architecture, with its impact assessed
Requirements Impact Assessment	Any	What a new or changed requirement does to the work so far

Reuse

From generic patterns to our own estate

The Enterprise Continuum is a way of classifying architectures and solutions from generic to specific, so teams reuse before they build. The architecture repository is where those assets, and the decisions about them, are kept. Both only work if someone owns them.

Swipe sideways to see the whole diagram.

Animation

Reuse before you build. I look left before designing anything: is there a common pattern, an industry model or an agreed standard that already answers the question? Each organisation specific design is a specialisation of those. When a project produces something better, it moves left as a new reusable pattern.

What the architecture repository holds

Metamodel

The types of thing the practice records, such as capabilities, applications, data, platforms and requirements, and how they relate.

Architecture capability

How the practice itself runs: roles, the board, processes, templates and tools.

Architectures of the estate

Baseline, target and transition architectures, at strategic, segment and capability level.

Standards

The products, versions and patterns the enterprise has agreed to use, each with a lifecycle status, for example trial, active, deprecated or obsolete.

Reference library

Reusable patterns, templates and reference models, including industry models such as TM Forum's.

Governance records

Decisions, compliance reviews, dispensations and their expiry dates.

Requirements

Every architecture requirement, with its source, owner and the designs that meet it.

Solutions

What is actually deployed, ideally fed from the CMDB (configuration management database) and the network source of truth rather than typed in.

Where the repository lives

Tool	What it is good for
Sparx Systems Enterprise Architect	Detailed models in ArchiMate and UML (Unified Modeling Language), with a large repository
Bizzdesign, SAP LeanIX, Ardoq	Hosted EA platforms with portfolio views, surveys and roadmaps that business owners can read
Archi	A free, open source ArchiMate modelling tool. Good for small teams and for learning
ServiceNow CMDB and application portfolio management	The deployed estate and its owners, which keeps the solutions part of the repository honest
A network source of truth, such as NetBox	Sites, devices, circuits and addressing, linked to the designs that created them

Tool names are examples of what I meet in clients. The repository is a practice, not a product.

Principles

Principles that settle arguments early

Principles are the standing rules that guide every design. TOGAF gives each one four parts: a name, a statement, a rationale and its implications. A good principle is short, can be tested in a review, and has consequences someone will feel. They are agreed in the Preliminary phase and confirmed in Phase A.

Example principle

Design for failure

Statement

No single site, link, device, supplier or person can stop a critical service.

Rationale

Production lines and customer services lose money every minute they are down. Failures are certain; outages are a design choice.

Implications

Every critical site has two diverse paths and two power feeds.
Designs name their failure domains and show what happens when each one fails.
Runbooks and access do not depend on one engineer.
Costs rise, so the board agrees which services count as critical.

Principles I propose most often

Reuse, then buy, then build. A new design starts from an approved pattern. Custom work needs a written reason.
Secure by design. Zones, identities and encryption are in the first drawing, not added after a penetration test.
Standard before special. One way to build a site, a data hall or a landing zone. Exceptions are recorded and expire.
One source of truth. Sites, devices, addresses and circuits live in one system, and configuration is generated from it.
Automate repeatable change. If a change will be made more than a few times, it becomes a template or a pipeline.
Data has an owner. Every data set crossing a boundary has a named owner who decides who may read it.
Production safety comes first. On a plant, no IT (information technology) change may put people, product or equipment at risk. OT change windows win.
Supported or retiring. Every platform in a target is inside vendor support for the whole plan, or has a dated exit.

Weak and strong principles

Weak principle	Why it fails	Stronger version
"We use best of breed."	Cannot be tested, and every project can claim it.	"We choose from the approved standards list; anything else needs a dispensation."
"Security is everyone's job."	True, but implies nothing a reviewer can check.	"Every flow between zones is listed, owned and inspected."
"Use the cloud."	A preference with no reason, so it breaks at the first exception.	"Cloud first for new applications, unless latency, data residency or cost rules it out, with the reason recorded."
"Keep it simple."	No one disagrees, so it never settles an argument.	"No more than two routing protocols and one SD-WAN platform in the estate."

Few and stable

Ten to twenty principles is plenty, and they should outlast any one programme. If they change every quarter, they are really policies or standards.

They must cost something

A principle that never stops anyone doing anything is decoration. The implications line is where the cost shows.

They settle reviews

At design review I quote principles, not opinions. A designer who disagrees argues with the principle, in the open, through the board.

Gaps and transitions

From baseline to target, one stable step at a time

Gap analysis compares the baseline with the target, building block by building block. Each gap becomes work. Transition architectures are the stable states in between, and each one should be worth stopping at. Step through an illustrative network roadmap, then try the matrix.

Swipe sideways to see the whole diagram.

Step 1

The baseline is the estate as it runs today, described only as deeply as the decision needs: MPLS to every site, firewalls only in the data centre, flat plant networks and changes made by hand.
The target comes from Phases B to D: two carriers per site under SD-WAN, a cloud security service for users, zoned plant networks and changes delivered through a pipeline. I agree the target before planning the route.
Gap analysis compares the two, building block by building block. Every difference becomes a gap: something to build, change or retire. The tool below runs the same comparison.
A transition architecture is a stable state the estate can stop at safely if money or attention runs out. The first one proves the pattern: SD-WAN at pilot sites, one plant zoned and a source of truth started.
The second transition scales what worked: every site on SD-WAN, MPLS contracts ended, half the plants zoned and every site built from a template. Each transition delivers value on its own.
The last step reaches the target. Phase H then watches for the next change, because by the time a target is reached the business has usually moved on.

Try it: a gap analysis matrix

TOGAF's gap analysis puts baseline building blocks in rows and target building blocks in columns. A baseline block can be kept, enhanced, replaced or eliminated. Any target block that nothing in the baseline turns into is new. Change what happens to each block and watch the gaps, and the warnings, change.

MPLS WAN to every site

Firewalls in the data centre only

Flat plant networks

Configuration by hand

Branch routers

Monitoring by SNMP (Simple Network Management Protocol) polling

Baseline	SD-WAN	Cloud security	Zoned plants	Automation	Telemetry	Kept or enhanced	Eliminated
MPLS WAN	Replaced
Data centre firewalls		Replaced
Flat plant networks			Replaced
Manual configuration				Replaced
Branch routers							Eliminated
SNMP monitoring						Enhanced
New					New

Each replaced, enhanced, eliminated or new block is a gap, and each gap becomes part of a work package in Phase E.

7 gaps to plan. 4 replaced, 1 enhanced, 1 eliminated and 1 new. Check every eliminated block: something may still depend on it.

MPLS WAN to every site: replaced by SD-WAN over two carriers. Build the new block, migrate, then retire the old one.
Firewalls in the data centre only: replaced by A cloud security service for users. Build the new block, migrate, then retire the old one.
Flat plant networks: replaced by zoned plant networks with an industrial DMZ (demilitarised zone). Build the new block, migrate, then retire the old one.
Configuration by hand: replaced by A source of truth and automation. Build the new block, migrate, then retire the old one.
Branch routers: eliminated. Retire it only after checking nothing still depends on it.
Monitoring by SNMP (Simple Network Management Protocol) polling: enhanced in place. Upgrade or extend it where it stands.
Streaming telemetry: new. Nothing in the baseline does this today, so it is built from scratch.

Eliminated is where gaps hide

TOGAF tells the architect to check every eliminated block: was it removed on purpose, or was a function simply forgotten? Retired branch routers might still be the only place a site's voice gateway or its DHCP (Dynamic Host Configuration Protocol) relay runs.

Transitions must stand alone

Funding stops, priorities change and suppliers slip. Each transition architecture must be safe, supportable and worth having if the programme pauses there.

Gaps are not only technology

Every gap has people, process and supplier sides: new skills, new support contracts, changed runbooks. I list them with the technical work so they are costed too.

Stakeholders and views

One architecture, a view for each audience

Every stakeholder has concerns. TOGAF, and the international standard for architecture description, ISO/IEC/IEEE 42010, handle them with viewpoints and views: a viewpoint says how to show something to one audience, and a view applies it to this architecture. Choose an audience to see the same design drawn for them.

Swipe sideways to see the whole diagram.

Sponsor view. The CFO (chief financial officer) and the business sponsor care about cost, value, risk and the order of work. They get one page: the outcome, the transitions, what each one costs and what could stop production.

Security view. The CISO (chief information security officer) cares about zones, trust and every flow between them. The same design is drawn as zones, with each permitted flow listed and inspected, and plant traffic leaving only through the industrial DMZ.

Operations view. Operations care about who owns what, what is monitored, which alerts fire and what the runbook says. The same design gains a monitoring path from every site and an owner for every part.

Engineering view. Engineers need interfaces, protocols and numbers: routing, VLANs (virtual local area networks), address ranges and private links. This view leads straight into the low level design.

Animation

Who needs what

Stakeholder	Main concerns	What I give them
Sponsor and finance	Cost, value, risk, timing	A one page vision and a costed roadmap
Chief information security officer	Zones, identity, data protection, compliance	Zone diagrams, a flow matrix and the risk register
Plant and site managers	Production safety, downtime, change windows	Site impact, outage plans and the change calendar
Operations and the service desk	Ownership, monitoring, support, runbooks	Support model, monitoring design and runbooks
Engineers and suppliers	Interfaces, standards, configuration	High and low level designs, standards and templates
Architecture Board	Fit with principles and standards, reuse	The design, the decisions and any dispensations requested

A stakeholder map

TOGAF's stakeholder management technique sorts people by their power over the work and their interest in it. I redraw the map at the start of each phase, because both change.

Keep satisfiedHigh power, lower interest. Short, regular updates; no surprises.Finance, the CIO (chief information officer)

Manage closelyHigh power, high interest. Involved in every decision that affects them.Sponsor, CISO, plant directors

MonitorLower power, lower interest. Informed through normal channels.Wider staff, some suppliers

Keep informedLower power, high interest. Regular detail, and a way to raise concerns.Engineers, service desk, site IT

Governance

An Architecture Board that helps projects land

Phase G and the governance part of the standard describe how architecture stays real during delivery: an Architecture Board, Architecture Contracts, compliance reviews and dispensations. TOGAF also defines how closely an implementation can follow its specification, from irrelevant to fully conformant.

Swipe sideways to see the whole diagram.

Step 1

The project submits its design with a compliance checklist: which principles, standards and requirements it meets, and where it departs from them. I ask for this before the low level design is finished, while change is still cheap.
The Architecture Board, or a design authority acting for it, reviews the design. Questions go back and forth. The board checks fit with principles, standards, the target architecture and other projects.
A compliant design proceeds. The project and the architecture function sign an Architecture Contract: what will be built, to which standards, and how compliance will be checked again before go live.
A justified exception gets a dispensation: approved, but with conditions, a named owner and an end date. A supplier lead time or a legacy dependency is a fair reason; preference is not.
A non conformant design goes back with written findings. Most rework is small when the review is early. Late reviews are where governance gets its bad name.
Every decision, condition and dispensation goes into the governance log. Phase H reviews dispensations as they expire, so exceptions do not quietly become the standard.

How closely a project follows the architecture

Level	What it means
Irrelevant	The implementation has nothing in common with the architecture specification, so conformance does not arise.
Consistent	Some features in common, built as specified. But some specified features are missing, and there are extra features the specification does not cover.
Compliant	Some specified features are missing, but everything built is covered by the specification and built as specified.
Conformant	Every specified feature is built as specified, but some extra features are built that do not follow the specification.
Fully conformant	A full match: every specified feature is built as specified, and nothing extra.
Non conformant	Any of the above where some specified feature is built in a way that does not follow the specification.

The six compliance levels described in TOGAF's architecture compliance guidance, in my words.

Who sits on the board

Senior architects for each domain, security, operations and a business representative, with a chair who can say no. A board that cannot refuse is a mailing list.

Review early and often

I review at high level design, at low level design and before go live. An early review costs a conversation; a late one costs a rebuild.

Dispensations expire

Every exception has an owner, a reason, a compensating control and a date. Open dispensations past their date are reported to the board each month.

My own design authority method, with decision records, factory builds and supplier reviews, is on the design authority page. This section is the TOGAF view of the same job.

Architecture governance meets project governance at the stage gates on my PRINCE2 page.

ArchiMate

ArchiMate, the language for drawing it

TOGAF says what to produce. ArchiMate, also from The Open Group, is a modelling language for drawing it consistently, with defined elements and relationships across motivation, strategy, business, applications, technology and change. Choose a domain to see one small model built up.

Swipe sideways to see the whole diagram.

Motivation. Drivers, goals, outcomes, principles and requirements explain why the architecture exists. Here a driver, plant data that nobody can see, influences a goal of live plant data, and a requirement that OT stays isolated helps realise it.

Strategy and business. A capability, production insight, is realised by a process: reviewing line output. A business actor, the plant manager, is assigned to that process. Strategy elements such as capabilities and value streams sit above the business domain.

Application. An application component, the data platform, serves the business process and accesses a data object, line telemetry. In ArchiMate 4, behaviour such as process, function, service and event comes from one common set of elements, used in every domain.

Technology. A technology node, the edge gateway, serves the data platform, and a communication network, the plant network, connects it to the line. This is where my network designs meet the rest of the model.

Implementation and migration. A work package, the plant pilot, realises the change to the data platform and reaches a plateau: a stable state, which matches a TOGAF transition architecture.

Animation

The domains and their elements

Domain	Main elements in ArchiMate 4
Common	Role, collaboration and path; service, process, function and event; grouping and location
Motivation	Stakeholder, driver, assessment, goal, outcome, principle, requirement, meaning and value
Strategy	Resource, capability, value stream and course of action
Business	Business actor, business interface, business object and product
Application	Application component, application interface and data object
Technology	Node, device, system software, technology interface, communication network, distribution network, equipment, facility, artifact and material
Implementation and migration	Work package, deliverable and plateau

From the ArchiMate 4 Specification pocket guide, published by The Open Group in April 2026. Element names are ArchiMate's own.

How elements relate

Group	Relationships	Example
Structural	Composition, aggregation, assignment, realisation	A work package realises a plateau
Dependency	Serving, access, influence, association	A data platform serves a business process
Dynamic	Triggering, flow	A line alarm triggers a maintenance process
Other	Specialisation, junctions and multiplicity	An edge gateway is a specialisation of a node

One notation, many views

Because every element has a defined meaning, the sponsor's one page view and the engineer's detail can come from the same model and stay consistent.

Versions matter

ArchiMate 3.2 was published in October 2022. ArchiMate 4 followed in April 2026, keeping the core ideas while reorganising the language into domains with a common set of elements. Tools and models move across at different speeds, so I agree the version up front.

Tools I meet

Archi is free and open source. Sparx Systems Enterprise Architect, Bizzdesign and similar platforms add repositories, collaboration and reporting.

In practice

Where TOGAF meets designs, sprints and cloud

Most infrastructure work happens at programme and project level, where the documents are high and low level designs, migration plans and design approvals. TOGAF's names map neatly onto them. The method also has to live alongside agile teams and cloud platforms with frameworks of their own.

Swipe sideways to see the whole diagram.

Animation

Just enough, just in time. TOGAF has a Series Guide on agile architecture. In practice the vision, target and principles change slowly, while the runway of approved patterns grows a little ahead of the teams. Decisions are short written records, and what sprints learn flows back into them.

TOGAF names and everyday names

TOGAF name	What I usually call it	Where it lives
Request for Architecture Work	A demand or project brief	The portfolio or demand tool
Statement of Architecture Work	The scope of work for the design	Signed off by the sponsor
Architecture Vision	A solution outline: the one page vision	The design repository
Architecture Definition Document	The HLD (high level design)	The design repository, reviewed by the board
Architecture Requirements Specification	The requirements catalogue, with NFRs (non functional requirements)	An appendix to the HLD, or a requirements tool
Below TOGAF's level of detail	The LLD (low level design) and build sheets	The engineering repository, generated from the source of truth where possible
Architecture Roadmap and Implementation and Migration Plan	The migration plan, in waves	The programme plan
Architecture Contract	Design approval with conditions	The decision log
Change Request	A design change request	The change process

HLD and LLD

Most of my documents are high and low level designs. The HLD carries the architecture: context, principles, target, gaps and decisions. The LLD turns one solution building block into something an engineer can build.

Cloud

Cloud providers publish adoption frameworks, such as the Microsoft Cloud Adoption Framework for Azure and the Cloud Adoption Framework from AWS (Amazon Web Services). They cover one platform in depth; TOGAF sits above them and decides where each platform fits.

Agile

Agile teams still need a target, principles and guardrails. I keep those short and stable, and let detailed design happen in the teams, close to the work.

Try it: how much TOGAF does this need?

TOGAF expects tailoring. Choose the size of the change, the delivery style and how regulated the organisation is, and see how I would scale the method.

Size of the change

Delivery style

Regulation

A programme, agile, heavy regulation.

Phases I lean on: A, then B to D at segment level, E and F to plan the waves, and G for as long as delivery runs.
What I produce: A vision, high level designs for each domain, a roadmap with transition architectures, a migration plan and Architecture Contracts.
Governance rhythm: Board review at each stage gate, and a design authority every week or two.
How I work: Architecture runway items sit in the backlog, decisions are short records, and reviews happen at demos as well as on documents. Every requirement traces to a design decision and a test, evidence is kept for auditors, and dispensations are formally risk accepted.
What I leave out: Enterprise wide modelling and a full metamodel. I model only what the programme needs.

When it goes wrong

When architecture stops being used

Enterprise architecture fails in familiar ways, and almost never because the framework was wrong. Choose a symptom to see where in the cycle it usually starts, what I see, and what I change. My general method for finding faults, technical or not, is on the troubleshooting page.

Swipe sideways to see the whole diagram.

Documents nobody reads. The architecture was written to satisfy the framework, not the people who must act on it. I cut it to a one page vision, a view for each audience and decision records, and I test each document by asking a stakeholder what it told them.

Projects route around the board. Governance is slow or late, so teams avoid it. I move reviews to the high level design, commit to a turnaround, publish approved patterns that need no review, and make the board the fastest route to a yes.

Endless current state work. The baseline became the project. I time box it, describe only what a decision depends on, and agree the target early so the baseline work has a purpose.

A target with no route. The architecture stopped at Phase D. Without Phases E and F nobody can fund it. I group the gaps into work packages and transition architectures, cost them with the programme, and make each transition useful on its own.

Exceptions that never expire. Dispensations were granted without an end date or an owner. Each one now has both, with a compensating control, and the board sees every expired dispensation each month until it is closed or renewed on purpose.

A repository nobody trusts. It was filled once by hand and never maintained. I give each area an owner, feed deployed facts from the CMDB and the network source of truth, and remove what nobody uses.

Framework for its own sake. TOGAF was adopted whole, so the team produces artefacts instead of decisions. I tailor it in the Preliminary phase: start from the decisions the organisation must make, and produce only what those decisions need.

Nobody agrees what success is. Phase A was skipped. I go back to it: confirm the goals, the measures, what is out of scope and who decides, and get the Statement of Architecture Work signed before more design.

Animation

Signals I watch

Signal	What it tells me	Healthy, indicative
Review turnaround	Whether governance helps or blocks	Most reviews answered within ten working days
Reviews before build	Whether projects use governance at all	Nearly every in scope project reviewed at high level design
Expired dispensations	Whether exceptions are controlled	None open past their date without a decision
Pattern reuse	Whether the repository is useful	Most new designs start from an approved pattern
Requirements traced	Whether designs answer real needs	Every target building block traces to a requirement or driver
Stakeholder feedback	Whether documents help anyone	Sponsors can state the target and the next transition

Targets are indicative. I agree real ones with the board in the Preliminary phase.

Engagement

How I run an architecture engagement, from request to a living roadmap

Architecture work starts with a request from a sponsor. If it goes well, it ends with a roadmap that projects follow and a practice that keeps it current. I follow the same path whether the scope is one capability or a whole segment: agree the outcome, find out what really exists, design the target, plan the transitions and govern delivery.

Swipe sideways to see the whole diagram.

Step 1

I start with the sponsor's request and turn it into a signed Statement of Architecture Work: the problem, the outcome, what is in and out of scope, and the measures of success. I map the stakeholders and record who decides in a RACI (responsible, accountable, consulted, informed) chart.
I turn drivers and goals into requirements: what the target must do, and how well, with a number wherever one can be agreed. Principles come from the Preliminary phase or are agreed now. Each requirement has a source and an owner, and goes into one repository with an impact process for changes.
I describe the baseline only as deeply as the decisions need. I pull inventories from the CMDB, the application portfolio, cloud accounts and the network source of truth, then check them with the owners in workshops. Capability and maturity assessments show where the real gaps are.
I design the target across business, data, applications and technology, with security in each, and compare it with the baseline building block by building block. Options are scored against the principles and requirements. The result is an Architecture Definition Document and a high level design the board can approve.
I group the gaps into work packages and define transition architectures, each a stable state worth stopping at. With the programme and finance I cost, sequence and fund them. The roadmap and the migration plan become the programme's own plan, not a separate architecture document.
During delivery each project signs an Architecture Contract and is reviewed at high level design, low level design and before go live. Dispensations get an owner and an end date. Decisions go into the governance log, so later teams can see what was agreed and why.
After delivery I keep the architecture current. I assess change requests, track product end of life dates and new business needs, and update the standards and the repository. When a change is big enough, it becomes a new Request for Architecture Work and the cycle starts again.

Functional requirements

What the architecture engagement must deliver.

Give the sponsor an agreed vision, scope and measures of success before detailed design starts.
Describe baseline and target architectures for every domain in scope, with security in each.
Trace every target building block to a driver, a principle or a requirement.
Turn the gaps into costed work packages and transition architectures.
Govern delivery with Architecture Contracts, compliance reviews and controlled dispensations.
Keep the repository and the standards current after delivery.

Non functional requirements

How well it must do it, with a number wherever one can be agreed.

Timeliness: Design reviews answered within ten working days (typical).
Traceability: Every target building block traced to a requirement, a principle or a driver.
Coverage: Every project above an agreed size reviewed before build starts.
Currency: Repository content for live systems reviewed at least every six months (typical).
Reuse: Most new designs start from an approved pattern, with exceptions recorded (typical target).
Clarity: A one page vision for sponsors, and a view for each stakeholder group.
Control: No dispensation left open past its expiry without a board decision.

Numbers are typical starting points. I agree real ones with the sponsor and the board.

Who I talk to

Business sponsors and capability owners, who set the outcome
Application and data owners, who know what the systems really do
Infrastructure, network and cloud teams, who run the estate
Security and risk, who set the constraints
Suppliers and outsourcers, who hold the contracts and lifecycle dates

How I find out

Stakeholder conversations and workshops, mapped to concerns
Capability mapping and maturity assessment
Inventory from the CMDB, the application portfolio and cloud accounts
Review of designs, standards and support contracts
Site visits to plants and data centres, because drawings drift

Discovery tools

Tool or source	What it tells me
SAP LeanIX or Ardoq	The application portfolio: owners, lifecycle and costs
ServiceNow CMDB and application portfolio management	Deployed services, dependencies and support groups
Sparx Systems Enterprise Architect, Bizzdesign or Archi	Models in ArchiMate: capabilities, applications, technology and the links between them
NetBox or another network source of truth	Sites, devices, circuits and addressing
Azure Resource Graph and AWS Config	What actually runs in each cloud account
Capability and maturity questionnaires	Where the business sees its biggest gaps

When an architecture engagement goes off track, the cause is usually missing agreement, not a missing artefact. I work through it in order.

My approach

Scope. Is the Statement of Architecture Work still true? Has the sponsor, the goal or the budget changed?
Stakeholders. Who is missing from decisions, and whose concerns have no view?
Requirements. Are requirements traced and owned, or are designs arguing about unwritten goals?
Gaps. Has every gap become a work package with an owner and a cost?
Governance. Are reviews early enough, and fast enough, that projects choose to use them?
Fix and record. Change one thing, record the decision, and check the effect at the next review.

Problems I see most

No signed scope, so everything is in scope
A target with no transitions or costs
Reviews held after the build has started
Dispensations with no expiry date
A repository filled once and never updated
Principles nobody can test

Layer by layer

Layer	What I check
Business	Capabilities and outcomes agreed with their owners, with a measure for each.
Data	An owner for every data set that crosses a boundary, and its classification applied.
Application	An accurate portfolio, every interface listed, and lifecycle dates known.
Technology	Current standards, platforms in support, and failure domains understood.
Security	Zones, identity and flows drawn in every domain, not added at the end.
Governance	Decisions logged, contracts signed, and dispensations dated and owned.

My general method for finding faults is on the troubleshooting page, and my design authority method is on the design authority page.

Projects

Related work behind this page

These are the projects closest to this page. They use the skills TOGAF describes: agreeing principles and standards, writing the vision and the high level design, planning change as phased transitions, and governing delivery as a design authority.

AVEVA · 2020 to 2021

Design authority standards for every region Related

Led network and security transformation through AVEVA's reverse merger, modernising every site worldwide. Set the design authority standards adopted by every regional delivery team, and planned the rollout as a phased, site by site transformation roadmap.

XIDA · 2025 to now

An OT maturity assessment and a phased roadmap Related

For Dyson, assessed OT maturity across manufacturing sites, identified capability gaps and shaped a phased IT/OT transformation roadmap covering Purdue Model zoning, OT cybersecurity and a UNS (Unified Namespace) for plant data.

XIDA · 2021 to 2024, 2025 to now

High level designs with TM Forum frameworks Related

Produced high level designs for Virgin Media O2 across RAN (radio access network), core, transport, and OSS and BSS (operations and business support systems), using TM Forum frameworks. The work fed architecture into its autonomous network and service orchestration roadmap. More on the TM Forum page.

Vodafone · 2024

Discovery, due diligence and architecture Related

As Digital Transformation Architect and Technical Design Authority, led discovery, due diligence and architecture for network infrastructure automation aligned to TM Forum and MEF (formerly the Metro Ethernet Forum) standards, in support of Vodafone's digital customer platforms.

BNY Mellon · 2018 to 2019

From audit to designs and governance Related

Delivered the EMEA (Europe, the Middle East and Africa) Network Refresh programme: audit, HLD and LLD design and implementation of LAN (local area network), WAN, SD-WAN and data centre infrastructure. Advised on change governance and architecture standards, and kept the estate compliant with MiFID II (the Markets in Financial Instruments Directive) throughout.

XIDA · 2021 to 2024

Lead architect from discovery to handover Related

Lead architect on network, cloud and data centre modernisation programmes from discovery to operational handover across several client environments, including Weetabix, Dyson, Virgin Media O2 and Network Rail.

Related credentials: TM Forum Architecture, PRINCE2 Practitioner, and ITIL v3 and v4. See all credentials

Explore

More areas I design and deliver

Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.