Primary practice
Enterprise Architecture
Make the decisions stick.
Architecture is the set of decisions your organisation has already made, whether or not anyone wrote them down. The work is making those decisions visible, deciding them at the right altitude, and keeping them from being relitigated every quarter.
The problem
Architecture friction rarely shows up as a bad decision. It shows up as a decision nobody can find, made by someone who was not supposed to make it, revisited for the third time this year.
Escalation by default
Choices that a team could own arrive at a governance forum, and choices the forum should own get made quietly in a pull request.
No decision record
The rationale lives in the heads of two people. When they are unavailable, or leave, the debate restarts from zero.
Review as a queue
Architecture review is scheduled rather than conversational, so it becomes a gate teams route around instead of a service they use.
The cost is not the wrong architecture. It is the calendar — weeks of senior time spent re-deciding, and delivery waiting on a slot.
The model behind it
Technology Decision Domain ArchitectureTDDA
Most architecture friction is not caused by bad decisions. It is caused by decisions happening at the wrong altitude — enterprise-level calls made by individual teams, or team-level decisions escalated to committees with no business being involved.
- Altitude
- Enterprise / Domain / Team / Individual
- Domain
- Investment / Standards / Platform / Integration / Implementation / Security
The matrix makes authority visible, prevents unnecessary escalation, and ensures the decisions that need scrutiny actually get it. It is the fastest intervention where “who decides this?” is a recurring, expensive question.
Read the full TDDA framework →
Try this week, without booking anything
- List your top five recurring technology decisions. For each: who makes it now, and who should?
- Find one decision consistently happening at the wrong altitude — too high or too low.
The programme
The Architecture Programme
A decision system your organisation can run without you: who decides what, at which altitude, recorded in a form that survives a handover.
- Who it is for
- Enterprise, solution and domain architects; principal engineers; the VP or CTO who owns the review forum.
- How it runs
- Modules run half-day to two days. Take a single track, or sequence the core arc over a quarter.
- Catalogue
- 32 modules across 7 tracks, plus 4 facilitated sessions
Not sure where to start? The core arc is Foundations → Governance & Control → Strategy & Direction. Everything else stays available — take a single module or sequence a track.
- What Architecture IsHalf-day workshopWhat software and enterprise architecture actually is — its structure, relationships, and decisions — and what it is not. No diagrams. No jargon. Just clarity.
- Why Architecture ExistsHalf-day workshopWhy architecture exists — managing complexity, aligning technology with business, reducing risk, enabling change, and creating shared understanding across teams.
- How Architects Think1-day workshopThe cognitive toolkit of architecture — systems thinking, abstraction, balancing business and technical concerns, deciding under uncertainty, and trade-off thinking. Builds the mindset, not just the knowledge.
- Requirements, Constraints, Trade-offs & Compromise1-day workshopThe art of making the best possible architectural decision given what is required, what is constrained, and what must be sacrificed.
- Quality Attributes / -ilities1-day workshopThe non-functional characteristics that determine whether a system is truly fit for purpose — scalability, reliability, availability, performance, security, maintainability, and more.
- Architecture Decisions & ADRsHalf-day workshopHow to capture, document, and govern architecture decisions using ADRs — the lightweight mechanism that turns tribal knowledge into shared understanding.
- Solution Decomposition1.5-day workshopHow to break large, complex systems into smaller, independently manageable parts — so different teams can build, own, and change them without stepping on each other.
- Application, Integration, API, Interface, Data & Process Design2-day workshopHow the components of a solution are structured internally, how they communicate with each other, and how they connect to the data and processes they depend on.
- Technology, Infrastructure, Cloud & Security Design2-day workshopWhere abstract architecture meets physical reality — choosing the platforms, compute, networking, and security controls that make the solution work at scale.
- Common Architecture Patterns1.5-day workshopProven, reusable solutions to recurring structural problems — each with known trade-offs that make it suited to some contexts and unsuitable for others.
- Delivery, Implementation & Architecture Runway1-day workshopHow architecture supports delivery instead of blocking it — covering architecture runway, phased implementation, dependency management, keeping teams unblocked, and recovering when architecture goes wrong during delivery.
- Capability Mapping & Business Outcomes1.5-day workshopHow to build business capability maps, connect them to technology, and link capabilities to strategic outcomes — the bridge between business strategy and technical architecture.
- Current State & Target State Architecture1-day workshopHow to document what exists today, define what must exist tomorrow, and design the transition states that get you there — the discipline of architecture that connects present reality to future goals.
- Application & Technology Landscape1-day workshopHow to build, read, and use the full picture of what an organisation runs — every application, platform, integration, and technology — and how they depend on each other.
- Standards & Reference Architectures1-day workshopHow to create, govern, and operationalise architecture standards and reference architectures — the agreed patterns and structures that create consistency, reduce duplication, and accelerate delivery at scale.
- Portfolio & Dependency Thinking1-day workshopHow to see all systems, initiatives, and investments as a connected whole — understanding dependencies, shared capabilities, and how decisions in one place ripple across others.
- Architecture Governance1-day workshopHow to design, implement, and measure architecture governance — the mechanisms that ensure decisions are made consistently, applied correctly, and aligned with strategy.
- Review Forums & Decision AuthorityHalf-day workshopHow to design, run, and improve architecture review forums — the structured spaces where decisions are evaluated, challenged, approved, and communicated.
- Risk, Compliance & Control Points1-day workshopHow architecture manages technical risk and meets regulatory obligations — covering architectural risk analysis, compliance by design, privacy by design, security controls as decisions, operational risk, control points, and demonstrating compliance through architecture.
- Technical Debt & Rationalisation1-day workshopHow to understand, measure, prioritise, and reduce technical debt — the accumulated cost of shortcuts, outdated decisions, and deferred maintenance.
- Architecture Communication & Storytelling1-day workshopHow to communicate architecture decisions so they are understood, adopted, and acted on — covering audience adaptation, executive communication, architecture papers, diagrams, workshop facilitation, and influence without authority.
- Stakeholder Management & Politics1-day workshopHow to navigate organisational dynamics, manage conflicting priorities, resolve decision deadlocks, and build executive alignment — because the best architecture recommendation fails without stakeholder alignment.
- Technology Strategy & Architecture Strategy1.5-day workshopHow to distinguish technology strategy from architecture strategy, connect both to business strategy, and define a coherent direction for the organisation's technology investments.
- Investment & Prioritisation1-day workshopHow to decide which technology initiatives get funded, in what order, and why — connecting architecture to financial decisions and business outcomes.
- Build / Buy / Partner / Participate — Ecosystem Strategy1-day workshopHow to decide what to build, what to buy, what to access through partners, and what to participate in through ecosystems — covering differentiation vs commodity analysis, vendor evaluation, total cost of ownership, interoperability velocity, exit strategy, and lock-in risk.
- Operating Model Choices1-day workshopHow the structure of technology teams shapes the structure of the systems they build — covering Conway's Law, centralised vs federated models, platform teams, product operating models, team topologies, and designing the organisation that produces the architecture you want.
- Roadmaps & Transformation Sequencing1.5-day workshopHow to build multi-year transformation roadmaps that sequence architectural change realistically — accounting for dependencies, capacity, risk, and the fact that the organisation must continue operating while it transforms.
- Platform Thinking1-day workshopHow to shift from building one-off solutions to building reusable internal platforms — shared foundations that allow teams to deliver independently without solving the same problems repeatedly.
- Data & AI Direction1.5-day workshopHow data strategy and AI direction connect to architecture — covering data quality, governance, data architecture for AI, AI enablement, responsible AI, data products, data mesh, and building a data and AI roadmap.
- Automation & Agentic Systems1.5-day workshopHow AI-powered architectures that plan, act, and use tools autonomously are reshaping integration and workflow — covering agentic patterns, MCP and A2A protocols, orchestration frameworks, human-in-the-loop design, guardrails, observability, and economic risk management.
- Emerging Technology ScanningHalf-day workshopHow to monitor what is coming, filter signal from noise, and make deliberate decisions about when and how to adopt new technologies — before being forced to react.
- Future Operating Model1-day workshopHow organisations will need to restructure their technology capabilities, teams, and governance as AI, automation, and platform thinking reshape what it means to run a technology function.
Facilitated sessions
Worked on your material, not a case study
Facilitated sessions run with your own architecture and your own people, and produce an artefact you keep.
Enterprise Architecture & Technology Strategy Workshop1-2 day facilitated sessionAlign business strategy with enterprise architecture and technology roadmaps, establishing governance frameworks that reduce execution risk.You leave with: Enterprise architecture governance model, technology roadmap, ADR frameworkArchitecture Decision & Technical Clarity Workshop1-2 day facilitated sessionEliminate architectural ambiguity and technical decision bottlenecks through clear decision frameworks and accountability patterns.You leave with: ADR/ADL templates, decision backlog, prioritisation frameworkDomain-Driven Design & Strategic Design Workshop1-2 day facilitated sessionStop designing systems around databases and frameworks. Start designing around your business domains — and watch your architecture conversations change overnight.You leave with: Domain map, bounded context canvas, ubiquitous language glossary, context mapEvent Storming Workshop1 day facilitated sessionGet your developers, domain experts, and business stakeholders in the same room, speaking the same language, discovering the same system — in one day.You leave with: Event timeline, domain hotspot map, aggregate boundaries, process ownership canvas
Working under regulation
Regimes this material covers
Named in the modules below, as design constraints rather than checklists — where the control belongs in the architecture, and what evidence an auditor can actually read. This is what the curriculum addresses; it is not a certification, an audit opinion, or legal advice.
The thinking behind it
Read before you book
Decision Velocity Is Not a Leadership Problem. It Is an Architecture Problem.Decision velocity is not constrained by leadership intent but by architectural design. Governance systems built for slower eras create mechanical delay between insight and execution.10 min readYour AI Agents Are Making Architecture Decisions. Nobody Assigned Them That Role.AI agents are making micro-architecture decisions in production. No ADR recorded them. No review board approved them. No architect ever saw them. Here is the structural fix.9 min readNobody Uses ADRs as an Agentic Decision Log. They Should.Why Architectural Decision Records are the only structure most organizations already have that can govern AI agent accountability — and how to extend them into an Agentic Decision Log before the EU AI Act deadline.10 min readAI Decision Rights: Who Decides What When No Human Is Watching?Decision rights models assume human decision-makers. AI agents breach that assumption silently. Here is how to extend decision rights to cover autonomous actors before the first ungoverned decision becomes a production incident.15 min read
How it went somewhere else
Reducing Architecture Decision Time by 60%
How a SaaS scale-up introduced ADRs and a decision rights matrix to cut architecture review cycles from weeks to days.
- Client
- Series A SaaS Scale-Up (80 employees)
- Industry
- Enterprise SaaS
- Duration
- 6 weeks
Free 30-minute diagnostic
Which decisions are stuck?
Bring three decisions your organisation has revisited more than once. Thirty minutes is usually enough to see where the authority sits and where it should.
Not the right one?