9 min read
I’ve been trying to write something on TOGAF and programme governance for a couple of years now. I kept it in the bag until I actually had the recognitions to back it up – Foundation, Practitioner, and Applied Practitioner, all three now done. So here’s the first piece built on it, and it happens to land squarely on AI: the argument, and the actual repository underneath it.
I’ve delivered more than twenty-five enterprise Business Applications and Power Platform programmes over sixteen-plus years – several of them recoveries, brought in after something had already gone wrong – and that’s enough to recognise a pattern before it fully arrives. AI programmes are hitting the exact same wall every major wave of enterprise technology has hit before it: the technology performs, the pilot impresses, and then six months later nobody can explain how the third use case connects to the first, who owns the risk when the system gets something wrong, or why the data platform can’t support the thing the business actually asked for next.
That’s not a technology failure. It’s an architecture failure, and it isn’t new. I’ve watched the same thing happen with CRM rollouts and with Power Platform citizen-development sprawl – every “this changes everything” technology that arrived before the organisation underneath it was ready to carry it. AI is just the newest version of the same problem, moving faster. It’s the reason I’ve spent the past few months building – and now publishing – a framework I’m calling Architecture-Led AI Enterprise. The open-source TOGAF 10 template set is available on GitHub.
In this piece:
- What I mean by “Architecture-Led AI Enterprise.”
- This isn’t an “architects only” conversation.
- TOGAF 10 fits AI programme delivery better than a bespoke framework would.
- Here’s what’s actually in the repo.
- One folder in the repo isn’t a phase at all, and that’s deliberate.
- Here’s the worked example nobody wants to think about.
- The connective thread: same discipline, different scale.
- Start using it this week.
What I mean by “Architecture-Led AI Enterprise.”
An Architecture-Led AI Enterprise is an organisation that establishes its enterprise architecture – covering business capability, governance, data, people, and technology – as the deliberate foundation before scaling AI programmes, ensuring that AI delivery is purposeful, governed, and aligned to measurable business outcomes.
I should say upfront – I made this term up. It isn’t Gartner’s, it isn’t McKinsey’s, it’s mine, because the existing vocabulary didn’t have a name for the thing I kept seeing missing.
The dominant industry narrative right now is “AI-first” – technology leads, everything else catches up. I think that narrative has it backwards.
Architecture leads. AI follows.
Not because architecture is more important than the technology, but because architecture is what turns a portfolio of disconnected pilots into a programme that actually compounds.
McKinsey’s most recent research backs this up in a way I found genuinely sobering: only 7% of companies have fully scaled AI across their organisation. PwC’s 2026 AI Performance study puts a number on the gap from a different angle – nearly three-quarters of AI’s measurable economic value is being captured by just one-fifth of companies, while the majority remain stuck in pilot mode, unable to convert activity into returns. Access to capable foundation models is becoming less of a differentiator than the operating model around them. The gap is whether there’s a structure underneath the AI capable of carrying its weight.
This isn’t an “architects only” conversation.
I want to head off the obvious misreading early: this is not a pitch for enterprise architects to reclaim territory from data science teams. If this reads as a framework for architects to feel important about, I’ve failed to make the actual point.
Architecture-led thinking is a leadership and governance posture, not a technology choice. The questions it forces are business questions: What capability are we actually trying to build? Who is accountable when an AI system gets a consequential decision wrong? What’s our appetite for risk on this specific use case versus that one? Is the data this depends on fit to be depended on? Those aren’t questions a data science team can answer alone, and they’re not questions that get answered by picking a better model. They get answered – or they don’t – by whoever is setting direction for the organisation.
Too many AI programmes defer this conversation entirely. They jump straight from ambition to build, because build feels like progress and the honest “are we actually ready for this” conversation doesn’t. TOGAF 10’s Architecture Development Method has a phase for exactly this moment – the Preliminary Phase, before Phase A even starts – and in practice, it’s often compressed, deferred, or treated as optional. It shouldn’t be. It’s where an AI Governance Framework gets defined, where an honest maturity assessment happens, and where Legal, Risk, Compliance, and the business actually get into the same room before a single line of code gets written. Skip it, and you’re not moving faster. You’re deferring the conversation to a point where it’s far more expensive to have.
TOGAF 10 fits AI programme delivery better than a bespoke framework would.
Every consultancy has its own AI maturity model at this point. Most of them are marketing collateral with a veneer of rigour – a quadrant, a five-stage ladder, a logo. I didn’t want to build another one of those, and I didn’t need to: TOGAF 10 already solved this problem, just not with AI specifically in mind.
TOGAF 10 is The Open Group’s current edition, released in 2022. TOGAF as a standard has been adopted by over 80% of the world’s leading enterprises by The Open Group’s own count. Unlike TOGAF 9.x, the 10th Edition specifically is explicitly modular and lightweight, built to integrate with agile and digital product delivery rather than sit above it as a governance tax. Its Architecture Development Method gives AI programmes a repeatable, iterative structure: Preliminary, Phases A through H, and Requirements Management running underneath all of them as a cross-cutting discipline, not a phase in the sequence itself (more on that below). It carries an initiative from “we should probably look into this” to a governed, production-grade capability, without reinventing the approach for every new use case.
Three properties map directly onto what AI programmes actually need: a holistic view that integrates business, data, application, and technology layers instead of leaving AI stranded in a data science silo; modularity that adapts to AI’s fast-moving nature (cloud, MLOps, agents) without a full re-architecture every eighteen months; and governance that carries compliance, auditability, and scalability across the whole programme lifecycle, not just the pilot.
To be clear about what TOGAF itself does and doesn’t give you: it doesn’t prescribe a complete AI operating model – it never claimed to. This repo is my own AI-specific tailoring of the ADM: using its structure to force the decisions, controls, and evidence that AI programmes actually need, phase by phase.
Here’s what’s actually in the repo.
The repository maps every ADM phase to a specific AI programme concern, with a working template for each one:
Available now: AI Maturity Assessment, AI Capability Model, Business Scenario Template, Transition Architecture Definitions, and Business Value Register – several also as ready-to-fill Word and Excel versions, not just markdown.
In progress: the remaining templates across every phase, shipping incrementally, in the open, so anyone can watch it fill in rather than wait for a finished product.
One folder in the repo isn’t a phase at all, and that’s deliberate.
Here’s a detail that only matters once you’re actually running a programme against this: the repo has an unnumbered requirements-management/ folder sitting outside the sequential 01-10 structure. That’s deliberate, not an oversight.
In TOGAF’s own ADM, Requirements Management isn’t a phase you pass through once – it’s the hub at the centre of the cycle. Every phase feeds it new or changed requirements, and every phase draws requirements back out of it as the programme evolves. An AI programme’s requirements change more than most: a new regulatory reading, a model update, a stakeholder who finally understands what “explainability” needs to mean for their use case. If requirements management were just another sequential step, that constant churn would have nowhere sane to live. Giving it no number and its own folder is a small structural choice that keeps the whole thing honest.
Here’s the worked example nobody wants to think about.
A council builds an AI assistant for its homelessness duty team – not an autonomous eligibility engine, but a decision-support tool that triages applications, surfaces vulnerability signals a caseworker might miss, and drafts the initial assessment for a human to review and sign off. That decision-support/autonomous-determination line is exactly why this is a high-stakes architecture problem before it’s a technology problem: the EU AI Act’s Annex III classifies AI evaluating eligibility for essential public benefits as high-risk, and Article 22 UK GDPR gives citizens a right not to be subject to a solely-automated decision with a significant effect on them. The same shape shows up well outside government, too – during a major 2026 acquisition, one company’s legal team used contract-intelligence software to review 360 contracts in minutes rather than days, but the tool surfaced information for lawyers to act on; it didn’t make the deal decisions itself.
AI compresses the grunt work. A human keeps the judgement call.
Skip that governance work and the cost isn’t hypothetical. Reporting by Tortoise Media found a UK government department’s housing-benefit fraud algorithm had wrongly flagged roughly 200,000 legitimate claims since 2019, with around £4.4 million spent on the resulting investigations – and a subsequent fairness assessment found statistically significant referral disparities by age, nationality, disability, and marital status. I don’t have visibility into exactly why that algorithm went wrong, or whether a TOGAF Preliminary Phase specifically would have caught it – these are inherently multi-causal failures. What the pattern does suggest is a recurring shape: weak governance, poor problem framing, and unclear accountability – exactly what a serious Preliminary Phase is designed to surface before a system reaches production, not any one sector or any one algorithm.
The connective thread: same discipline, different scale.
This is the same discipline I wrote about in “Think first, then use AI”, just scaled up. That piece argued for forming your own view before opening the AI chat window, using AI to pressure-test rather than originate, and delivering the synthesis as your judgement, augmented – not AI output with your name on it.
Architecture-Led AI Enterprise is that same sequence at the level of an organisation: understand your capability, governance, and actual maturity first – think first – before you scale AI across any of it. Organisations that invert this sequence – that reach for the AI capability before doing the architecture work – end up exactly like the examples above: fast out of the gate, and then very publicly wrong. The repo below is what “think first” looks like when the thinking has to hold up across an entire programme, not just one person’s judgement.
Start using it this week.
The repo is designed to be picked up mid-programme, not just at the start of a greenfield build – most teams land here because something’s already gone sideways, and that’s fine, the templates don’t assume a clean slate.
- Start with the AI Maturity Assessment – you can’t plan honestly until you know which of the five maturity levels you’re actually at.
- Work the ADM phases in order for a new programme, or jump straight to whichever phase is currently the problem.
- Every template’s header states its inputs and outputs, so you can see exactly how it chains into the next phase.
- Use whichever format fits your workflow – markdown pasted into Confluence or Notion, or the fillable Word/Excel versions directly. No proprietary tooling required either way.
It’s vendor-neutral by design. I work deepest in Microsoft’s stack – Copilot Studio, Dataverse, Fabric, Azure AI – so where the repo needs a concrete worked example, that’s the one I reach for. But the architecture discipline underneath it doesn’t care whether you’re running AWS Bedrock, GCP Vertex AI, LangGraph, or something built in-house. Swap the stack, keep the sequence.
It’s also not a finished, perfect worked example – it’s a set of templates meant to get you moving in the right direction on your own programme, not a case study to copy wholesale. Some phases are fully built out; others currently ship as structured stubs, filling in incrementally as I keep building it in the open.
Think of it as scaffolding you can start using now, not a finished monument.
The full repository is open, MIT-licensed, and free to use or fork: architecture-led-ai-enterprise on GitHub.