Enterprise architecture exists because a recurring pattern of failure resists every straightforward solution. An organisation hires excellent project managers. It improves its requirements process. It adds governance layers and steering committees and business analysts embedded in delivery teams. The alignment between business intent and IT delivery improves at the margin, but the structural gap persists.

Understanding why requires understanding what kind of problem misalignment actually is. It is not a process problem. It is not a communication problem in the ordinary sense — not the kind that better documentation or more frequent meetings can fix. It is a structural problem produced by four characteristics that are intrinsic to large organisations and their IT estates.

Four structural causes

Organisational diversity

Every significant organisation contains multiple business units, functions, and geographies with different priorities, vocabularies, and definitions of value. No individual holds enough knowledge of all of them to make consistently optimal IT planning decisions across all of them. This is not a management failure — it is a scale property. The organisation has grown beyond the cognitive span of any one person or team, however competent.

IT complexity

Modern IT landscapes are genuinely, irreducibly complex. Hundreds of applications. Thousands of integrations. Multiple hosting environments accumulating over decades. Legacy systems carrying business logic that no living person fully understands. No individual can hold the full picture in mind. An IT estate is not a project to be designed from scratch — it is an organism that has grown continuously, one decision at a time, for years.

Mismatched planning horizons

Business strategy operates on a three-to-five-year horizon. IT projects operate on a six-to-eighteen-month horizon. The gap between them is where most misalignment lives. Strategic decisions get made by people who do not understand the technical consequences. Technical decisions get made by people who do not understand the strategic context. Both sets of people are doing their jobs competently within their respective time horizons. The gap is structural, not individual.

No shared language

Business leaders speak in capabilities, outcomes, and risks. IT specialists speak in systems, integrations, and architectures. These vocabularies do not map naturally onto each other. When both sides attempt to communicate directly about complex planning decisions, they often reach apparent agreement on something they have not actually agreed on — discovering the divergence only when delivery is underway.

Why process improvements don't reach the root cause

The standard responses to alignment failure — better requirements processes, more detailed governance, embedded business analysts — address symptoms rather than causes. They operate at the project level, improving execution within individual initiatives. But the structural gap exists above the project level, in the planning processes that determine which initiatives are funded, in what order, to serve which strategic ends.

A project that delivers exactly what was specified can still represent a misalignment of IT investment with business direction. The specification was correct. The strategic framing was wrong. Improving specification quality does not improve strategic framing quality — those are different problems requiring different solutions at different levels of abstraction.

What a structural solution looks like

A structural problem requires a structural solution. The solution AMBIT provides is not a better project process — it is a set of continuously operating planning processes that work at the level where the structural gap actually lives: between business strategy and IT investment, between the current IT estate and the organisation's strategic direction, between individual initiatives and the landscape they cumulatively produce.

These processes produce specific types of planning documents — artefacts — that serve as durable, shared reference points across the organisational, cognitive, and vocabulary boundaries that structural complexity creates. They are not project documents. They are organisational planning instruments: maintained continuously, accessible to all relevant stakeholders, and used in every significant IT planning decision.

The Alignment Matrix — the taxonomy of six artefact types that forms AMBIT's backbone — is the subject of the next three articles. But the starting point is this: the alignment problem cannot be solved at the level at which it usually gets attacked. Addressing it requires acknowledging that it is structural, which means the solution must be structural too.

The most consequential misunderstanding about enterprise architecture is that its primary output is documents. Architecture diagrams. Standards frameworks. Repository entries. Governance artefacts. This misunderstanding is so common that it has become the default mental model — and it explains most EA failures.

The primary output of an architecture practice is alignment. The documents are instruments for producing it.

What communication means in practice

An architecture practice creates shared understanding across the four structural boundaries described in the previous article — organisational diversity, IT complexity, mismatched planning horizons, and absent shared vocabulary. It does this through artefacts that make complex planning decisions legible to diverse stakeholders, through processes that ensure the right people are involved at the right moments, and through governance that makes decisions official and auditable.

Every element serves this communicative function or it serves nothing. An architecture diagram that nobody reads has not contributed to alignment. A Standards document that project teams are unaware of has not improved technical coherence. A governance committee that endorses documents without genuine review has not created legitimate organisational commitment.

The development process is more valuable than the document

This is one of the most important empirical findings about how successful EA practices actually work. The conversations that produce a Business Vision or a Business Outline are where alignment is achieved. The finished artefact documents agreement already reached — it is not the mechanism through which the agreement is formed.

An architect who works alone, produces a technically excellent document, and presents it to stakeholders for approval is not practising architecture in any meaningful sense. They are producing a personal view of what the architecture should be. The stakeholders may endorse it — under time pressure, with incomplete understanding, without genuine ownership. The document will then sit in a repository and be ignored during actual decision-making, because nobody except the architect who wrote it feels accountable for it.

Genuine architecture artefacts emerge from the D-E-A process: conversations first, document second, formal endorsement last. The D-E-A pattern is described in Article 6. Its significance here is that it positions communication — not documentation — as the primary activity of architecture work.

Implications for how practices are organised and evaluated

If architecture is fundamentally a communication practice, several things follow that contradict how most architecture teams are structured.

The most valuable thing an architecture function can do is cultivate trusted relationships with senior business leaders. Not produce architecture artefacts. Not maintain the repository. Not enforce governance compliance. Relationships — because relationships are what make the conversations possible through which alignment is actually achieved.

The most important skill an architect can develop is the ability to translate between business thinking and technical thinking in both directions simultaneously. Not technical depth alone, and not interpersonal skill alone. Both, simultaneously, in the same conversations. This is developed in Article 15's treatment of the two hats every architect wears.

Maturity is measured not by artefact coverage or governance completeness but by whether business leaders understand what IT is doing and why. This is the subject of Article 19's five-question maturity test.

What this means for AMBIT

Every element of AMBIT is designed with this communicative purpose in mind. The Alignment Matrix classifies artefacts by their audience and the type of understanding they are meant to produce. The three Alignment Processes are structured around the conversations through which different types of decisions get made. The governance forums exist not to make decisions but to make decisions official — because genuine decisions already made through conversation need organisational authority to be binding.

The framework does not succeed when an organisation has produced all six artefact types and established all four governance forums. It succeeds when business leaders and IT professionals understand each other — when IT investment consistently reflects business direction and business leadership understands how IT is transforming their organisation. Artefacts and governance are the means. That mutual understanding is the end.

AMBIT — Architecture Methodology for Business and IT — is HighGrain's practice framework for establishing, running, and improving enterprise architecture practices. It is grounded in empirical research: systematic study of what organisations that achieve sustained business-IT alignment actually do, as opposed to what frameworks designed from first principles say they should do.

The distinction matters. Most enterprise architecture frameworks were designed by committees, consultancies, or individuals reasoning from first principles about what EA should look like. AMBIT's conceptual basis is different: it reflects what demonstrably works in real organisations, observed empirically across many cases over many years.¹

This grounding is not incidental. It is the reason AMBIT makes the claims it makes. Every structural choice — the six artefact types, the three processes, the four governance forums, the maturity stages — reflects what the evidence shows about how successful EA practices are organised.

Research describes. AMBIT prescribes.

The empirical research that informs AMBIT is descriptive: it documents what successful practices have in common. AMBIT is prescriptive: it translates that evidence into structured, actionable guidance for practitioners who need to know how to build and run a practice — not just what the literature reveals.

These are distinct contributions. An organisation that reads the research knows what a successful practice looks like. An organisation that implements AMBIT knows how to build one. AMBIT is the bridge between evidence and execution.

The six Ambits

AMBIT organises the full scope of an EA practice into six domains. Each domain is called an Ambit — from the Latin ambitus, meaning the circuit or compass of something. Together they go all the way around the subject.

What AMBIT is not

AMBIT is not a certification programme. There is no AMBIT examination or designation. Architectural competence develops through practice, not through passing tests.

AMBIT does not mandate specific artefact formats, specific tooling, or specific governance structures. Real EA practices are highly context-specific. The framework provides the models and patterns that successful practices share — which organisations adapt to their own context rather than implement literally.

AMBIT is not a static framework. Because it is grounded in empirical evidence rather than committee consensus, it updates when the evidence updates. As new research emerges and as practice surfaces patterns the current framework does not fully capture, AMBIT evolves. The commitment is to the evidence, not to preserving a version.

How this series is organised

The remaining seventeen articles cover the six Ambits in sequence, deepening from framework overview to operational detail. Parts II and III cover the Alignment Matrix and the three Alignment Processes — the core working machinery of AMBIT. Part IV covers the six artefact types individually. Parts V and VI cover the architects who run the practice and the lifecycle through which it matures.

Readers working with a specific element of AMBIT can go directly to the relevant article. Readers building a new practice from scratch will benefit most from reading in sequence through Part III before specialising.

The Alignment Matrix is AMBIT’s taxonomy for classifying every planning document in an EA practice. It organises artefacts along two independent dimensions, and the intersection of those dimensions produces six distinct types. The classification is not decorative — it immediately tells you who needs to be involved in producing the artefact, which governance body should endorse it, and what failure modes to watch for.

Two dimensions

The first dimension is what the artefact describes. Three options exist along this axis: Rules — general operating principles and constraints that govern the whole organisation or a major domain. Structures — high-level pictures of the organisation’s business capabilities or IT estate. Changes — descriptions of specific proposed IT initiatives or solutions.

The second dimension is how it is described: Business-Focused (accessible, brief, technology-neutral; primary audience is business leaders and architects jointly) or IT-Focused (technical, formal, detailed; primary audience is architects and IT specialists).

The six types

What the classification tells you

The position on the horizontal axis (Rules / Structures / Changes) determines the lifecycle. Rules and Structures artefacts are permanent — they exist continuously and are updated rather than replaced. Changes artefacts are temporary — produced specifically for each initiative and retired when it concludes.

The position on the vertical axis (Business-Focused / IT-Focused) determines the stakeholder set. Business-Focused artefacts require active senior business executive participation to produce legitimately. IT-Focused artefacts require deep technical expertise. This determines not only who to involve but which hat the architect must wear most heavily — the Change Agent hat for business-facing artefacts, the Technology Expert hat for IT-facing ones.

The matrix is a coordinate plane, not a rigid grid. Artefacts sit anywhere along the axes. A Principles document in a highly technical organisation will be more IT-focused than one in a services business. A solution architecture for a simple application will be less detailed than one for a core banking replacement. The classification gives orientation, not a template.

Within the six artefact types of the Alignment Matrix, one distinction cuts across the entire grid and determines everything about how artefacts are produced, who can update them, and what governance process they require. This is the distinction between Action Artefacts and Reality Artefacts.

Reality artefacts: documenting what is

Reality Artefacts document objective facts about the current IT estate. The primary example is IT Landscapes: landscape diagrams showing which systems exist and how they relate, application inventories recording system metadata, enterprise system portfolios mapping IT assets against business capabilities.

The content of a Reality Artefact is either accurate or inaccurate. There is no planning decision being represented. An individual architect, working with appropriate data sources, can produce and update a Reality Artefact without requiring collective agreement. The governance question for Reality Artefacts is quality control: is this correct and current? The key risk is staleness.

Action artefacts: representing planning decisions

Action Artefacts represent planning decisions — choices about what the organisation should do, how it should work, what it should build, or what technical standards it should follow. Business Factors contain decisions about operating principles. Business Visions contain decisions about strategic direction. Business Outlines contain decisions about which initiatives to fund. IT Designs contain decisions about how solutions will be built. IT Standards contain decisions about which technologies are acceptable.

Planning decisions are not true or false — they are agreed or contested. They can only be legitimately made through collective agreement among the people who will act on them and live with their consequences. The governance question for Action Artefacts is legitimacy: has this been genuinely agreed by the right stakeholders? The key risk is illegitimacy — a document that represents one architect's preferred direction, not an organisational commitment.

A subtlety in IT Landscapes

IT Landscapes are primarily Reality Artefacts, but they contain elements that function as planning decisions: lifecycle classifications (marking a technology as strategic or to be decommissioned), portfolio assessments, and rationalisation recommendations. Those elements are Action Artefact content within a Reality Artefact container, and they require Forum endorsement accordingly.

Factual updates — adding a new system delivered last month, updating a version number — do not require governance. Strategic classifications — marking a system for decommission, elevating a technology to strategic status — do. Architecture teams that apply Forum governance to all Landscape updates create bureaucracy without value. Teams that apply no governance to Landscape updates allow strategic decisions to enter the record without organisational commitment.

The practical implication

Before beginning any artefact development activity, identify whether the output is primarily a Reality Artefact or an Action Artefact. This determines the development process: individual technical work for Reality Artefacts, D-E-A stakeholder engagement for Action Artefacts. It determines who to involve, how long to allow, and which governance body will endorse the result.

Treating planning decisions as if they were facts — producing Standards and Designs unilaterally and expecting compliance — is the most common failure mode in IT-focused architecture functions. Treating facts as if they required collective agreement — running every Landscape update through a committee — is the most common source of EA bureaucracy that consumes time without adding value.

Most architects know how to write an architecture document. Fewer know how to produce one that will actually be used.

The difference between these two things is almost entirely about process, not content. An architecturally excellent document produced through the wrong process will be resisted, ignored, or bypassed. A simpler document produced through the right process will shape decisions for years.

The right process for Action Artefacts — the planning documents that represent collective decisions — is a three-step pattern called D-E-A: Discuss, Elaborate, Align.

Step One: Discuss.

Before any draft is written, the architect has conversations. Not meetings. Not workshops. Conversations — informal, one-on-one, without an agenda or expected outputs.

The goal of the Discuss step is to understand. What does this stakeholder actually need? What are they worried about? What constraints do they face that they haven't articulated formally? What does success look like from their perspective? What history exists around this decision that a newcomer wouldn't know?

No artefact is produced in the Discuss step. This is important. The temptation is to arrive with a draft and ask people to react to it. Resist this. A draft constrains the conversation. It signals that the thinking is already done and what's needed is validation. You get polite agreement rather than genuine input. The Discuss step is the stage at which you don't know what the answer is yet, and you should look like it.

Step Two: Elaborate.

Now you write something. But not a finished document — a straw-man. A deliberately rough, incomplete, openly provisional sketch. The purpose of a straw-man is not to be correct; it is to be concrete enough that stakeholders can react to it.

People engage differently with a sketch than with a blank page. A blank page is overwhelming. A sketch is a provocation. "Here is one way this could go — what's wrong with it?" is a far more productive question than "what should the future look like?"

The Elaborate step is iterative. The straw-man goes out, reactions come in, the draft improves, the next version goes out. This cycle continues until all the principal planning decisions have been made — genuinely, through conversation — and documented in a near-final draft. The document that comes out of Elaborate is not perfect. But every important decision in it is already owned by someone.

Step Three: Align.

The completed artefact goes through formal endorsement: first by the direct stakeholders who participated in its development, then peer review by senior architects, then approval by the appropriate governance forum.

Here is the key principle of the Align step: nothing in the artefact should be new or surprising to anyone in the room. Genuine alignment was achieved in Discuss and Elaborate. The Align step is not for making decisions — it is for making them official.

If a governance committee meeting produces significant disagreement or surprise, the D-E-A process failed in the earlier steps. The appropriate response is not a longer or more formal governance meeting. It is better Discuss and Elaborate work before the next artefact reaches the table.

This matters because governance committees are expensive. They require senior people to set aside time, prepare, attend, and follow up. Using that time to make decisions that should have been made in one-on-one conversations is waste. The right governance meeting ratifies what everyone already knows and formally commits the organisation to acting on it.

D-E-A is not a formal methodology. It is a pattern that reflects how good architects actually work. The Discuss conversations happen in corridors and coffee meetings. The Elaborate cycles happen through email and informal workshops and bilateral sessions. The Align step happens in the committee room. The pattern works because it respects how organisations actually make decisions: informally first, formally last, with the informal work doing the real thing.

Most organisations have a business strategy. Most organisations have an IT department. Most organisations find that the two do not reliably produce the same view of what IT should be doing.

Strategic Alignment is the process that bridges this gap. It translates the organisation’s strategic direction — its goals, its operating model, its sense of how the competitive environment is changing — into a concrete picture of where IT capability needs to go and what investments will take it there.

Let me be clear about what Strategic Alignment is not. It is not a planning exercise that produces a five-year IT strategy document that sits in a drawer. It is not a once-a-year board presentation on technology trends. It is not a CIO writing up their view of the technology landscape and presenting it to executives for endorsement.

Strategic Alignment is a continuous, ongoing conversation between senior business executives and enterprise architects, conducted informally but structured by shared artefacts, that produces two types of output: Business Factors and Business Visions.

Business Factors: the operating rules

Business Factors answer: how does this organisation need to work in relation to IT? The most important type is Principles — substantive statements that genuinely shape planning decisions. A useful Principle has three parts:

Business Visions: the directional plans

Business Visions answer: where is this organisation going and what IT capabilities does it need to get there? The most essential is the Business Capability Model — a structured view of what the organisation can do, not how it does it, heatmapped to show where investment is most urgent. From the Business Capability Model flows a Roadmap: what to build, in what sequence, with what priority.

The Roadmap is not a project plan. It is a direction-setting document. Roadmap entries do not have detailed requirements or confirmed budgets. They have enough information to answer the question “should we fund an initiative in this area?” — and that is all they need.

How to know if it is working

Strategic Alignment is structurally different from the other two Alignment Processes. It is continuous and largely unstructured. You cannot schedule it into quarterly sessions and expect it to work. Enterprise architects who practise it well spend most of their time in conversations, not at their desks. That trust is earned through Initiative Alignment first — through architects demonstrating, project by project, that they add real value.

Two things to measure:

1. When IT investment decisions are being made, is the Roadmap in the room? Not as a historical reference — as an active input.
2. Ask senior business executives whether they understand what IT is doing and why. If the answers are consistently positive, Strategic Alignment is working. If they are not, no volume of architecture artefacts will compensate.

Every IT initiative — whether it came from a carefully maintained Roadmap or landed on a Monday morning as a board-level urgent request — eventually needs to be designed, funded, and built. Initiative Alignment is the process that handles this.

It has two inherent steps, separated by a funding gate.

Step One: Initiation

Initiation answers the question: what are we going to build, roughly how, and why is it worth funding? It produces a Business Outline — specifically, a Solution Overview.

A Solution Overview is not a requirements document. It is not a technical architecture document. It is an investment case. It needs to be intelligible to the senior business executives who will decide whether to fund it, and it needs to give architects and technical leads enough information to assess feasibility. Both things. In one document. Typically fifteen to thirty pages.

The ten sections of a useful Solution Overview:

1. Business context — why does this need doing now?
2. Current state — what does the current landscape look like in the relevant area, in business terms?
3. Proposed solution — what will be built, at a conceptual level accessible to non-technical readers?
4. Future state — what will the business environment look like after delivery?
5. Business benefits — what specific outcomes will the organisation achieve? Quantified where possible.
6. Cost and timeline — indicative, not committed. Enough precision to support a funding decision.
7. Risks — the top three to five risks, with mitigating factors.
8. Strategic alignment — which Principles does this comply with? Which Roadmap entries does it address?
9. Technical concept — a brief explanation of the proposed approach for a technically literate reader. One page maximum.
10. Sourcing recommendation — buy, build, or outsource, with rationale.

Step Two: Realisation

Once the Solution Overview is approved and funding is committed, Realisation begins. It answers: exactly how will we build this? The output is an IT Design — the document the project team actually builds from. It covers application architecture, data model and data flows, integration specifications, infrastructure requirements, and security architecture.

The key principle for IT Designs is the boundary rule: specify every decision that, if made incorrectly, creates a costly landscape consequence. Delegate every decision that has no landscape consequence. IT Designs that over-specify become obstacles. IT Designs that under-specify leave the architecture to chance.

The five initiative types

Not all initiatives are strategic. AMBIT identifies five types:

• Fundamental — major transformations that reshape the organisation’s capability landscape.
• Strategic — initiatives drawn from the Roadmap, implementing agreed Business Visions.
• Local — business-unit-initiated initiatives serving a specific area’s needs.
• Urgent — reactive initiatives responding to immediate business problems or compliance requirements.
• Technical — IT-internal initiatives: infrastructure refresh, platform consolidation, architecture debt remediation.

There is a version of enterprise architecture that does Initiative Alignment well and Strategic Alignment adequately and never thinks about Technology Alignment at all.

These organisations deliver well-designed solutions, project by project. Each one is technically coherent. Each one passes architecture review. And yet, five years later, they have an IT landscape that nobody can explain clearly, that costs a fortune to maintain, and that is full of systems doing overlapping things in incompatible ways.

This is what Technology Alignment is for.

Technology Alignment is the continuous process of analysing the IT landscape — the full picture of what systems exist, what technologies they use, how they relate to each other — and identifying the rationalisation opportunities that keep it coherent, efficient, and capable of supporting the organisation’s strategic direction.

Three inputs

1. IT Landscapes — the factual documentation of what currently exists.
2. IT Standards — the picture of what should exist: which technologies are strategic, which are retiring, which are prohibited.
3. Business Visions — the direction the organisation is heading, which tells you which parts of the landscape need to improve and which need to be retired.

The analysis maps current state against ideal state. Where systems deviate from IT Standards, the deviation needs to be understood and either corrected or formally accepted as architecture debt. Where capability gaps exist relative to Business Visions, technical initiatives need to be added to the portfolio. Where redundancy exists — multiple systems serving the same capability — rationalisation opportunities need to be evaluated.

Two outputs

1. They inform the IT investment portfolio, generating Technical initiatives (infrastructure refresh, platform consolidation, legacy decommission) that need to be funded alongside strategic business initiatives.
2. They update IT Landscapes and IT Standards themselves — as Technology Alignment reveals new patterns or invalidates old ones, the artefacts reflecting those patterns need to change.

Technology Alignment is the least visible of the three processes to business stakeholders. It involves no business executive participation and produces no business-facing documents. This makes it easy to defer, underfund, and gradually stop doing — especially when the IT budget is under pressure. This is exactly backwards. Technology Alignment is what makes sustainable capability delivery possible. An IT landscape that is not actively maintained becomes progressively more expensive to change.

Architecture debt as Technology Alignment’s primary instrument

Every time a project deviates from IT Standards — uses a deprecated technology, introduces an integration pattern that conflicts with the target architecture, adds a system that duplicates existing capability — that deviation is a debt. The problem is not the debt itself; it is unacknowledged debt that compounds silently and becomes structural constraint.

Governance has a bad reputation in most organisations. It means slow decisions, bureaucratic overhead, and approval processes that add delay without adding value. I want to take this reputation seriously rather than dismiss it, because it is often deserved — and when it is, it is usually because the governance has been designed around the wrong purpose.

Governance forums in an architecture practice exist for one reason: to make planning decisions official. Not to make them. To make them official.

The actual decisions are made through D-E-A — through the informal conversations, iterative development, and bilateral alignment that happen before any governance meeting. By the time an artefact arrives at a governance forum for formal endorsement, everyone in the room should already know what it contains and broadly agree with it. If a governance forum meeting is producing significant new arguments or substantive revisions, the pre-meeting process failed. The fix is not a longer governance meeting. It is better preparation.

The four forums

How forums scale with organisation size

• Small organisations: A single committee handles all four functions, inviting different participants for different agenda items.
• Medium organisations: Two committees — a Business Committee (Strategy + Investment) and an IT Committee (Technology + Design).
• Large organisations: Four separate forums. The governance function must be fulfilled regardless of how it is structured.

Two practical principles

1. Pre-read discipline. Every artefact being reviewed must be distributed to forum members at least forty-eight hours before the meeting. A forum that reviews documents for the first time in the meeting is not governing; it is reacting. Reactions produce poor decisions.
2. Decision logging. Every endorsement, rejection, exemption, and escalation must be formally recorded: the artefact version reviewed, the participants present, and any conditions or obligations attached. Decision logs are the institutional memory of an architecture practice and the audit trail for architecture debt. Without them, the commitments made in governance forums evaporate.

The most important thing governance forums do is not endorse good plans. It is create the shared, explicit, documented commitment that makes plans binding — the organisational authority that gives architects the standing to hold delivery teams accountable to architectural direction.

Every organisation that has been running IT for more than a few years has architecture debt. Most of them don’t know how much.

Architecture debt is the accumulated cost of past shortcuts. Every time a project used a deprecated technology because it was faster. Every time a system was built outside approved integration patterns because the approved approach would have taken too long. Every time a solution was approved with known deviations from IT Standards because the business need was urgent. Every one of those decisions was a debt. It will cost more to fix later than it would have cost to do right in the first place.

Like financial debt, architecture debt is not inherently wrong. Sometimes borrowing is the rational choice — implementing a tactical solution now to meet an urgent business need, while planning to invest in the strategic solution later. The problem is not the debt; it is undisclosed debt.

Undisclosed architecture debt accumulates silently. Future initiatives consume more effort because the landscape they have to work with is messier than it should be. Integration projects take longer because the data models don’t align cleanly. Security improvements are harder because the authentication patterns are inconsistent. The total cost of the portfolio quietly rises, and nobody quite understands why.

The Architecture Debt Register

When a governance forum approves a deviation — grants an exemption because the business case is strong enough — the deviation is documented in an Architecture Debt Register. Five fields:

1. A description of the deviation.
2. Which IT Standards or architectural direction it departs from.
3. The estimated future cost to remediate.
4. The planned remediation date.
5. A severity classification: minor, medium, or major, based on landscape impact.

That’s it. A spreadsheet or a simple database. Not a sophisticated tool. The sophistication is in the discipline of actually maintaining it.

Three purposes the register serves

1. Makes the true cost of IT decisions visible. A solution that costs £500k to build but carries £400k of architecture debt has a total cost of £900k. Many urgency-driven decisions look different when the deferred cost is made explicit.
2. Drives Technology Alignment. Debts with remediation dates become planned Technical initiatives. The register is not a historical record of regrettable decisions; it is a planning tool.
3. Enables governance escalation. Deviations creating minor debt can be approved by the Design Forum. Deviations creating major debt require escalation to the Technology Forum or Strategy Forum. This translates the abstract governance principle into an auditable decision rule.

The question is not whether you have architecture debt. The question is whether you know what it is.

The two business-focused artefact types at the top of the Alignment Matrix are the hardest to develop, the most dependent on executive trust, and the last to mature in most organisations. They are also, ultimately, the ones that determine whether an EA practice is delivering genuine strategic value or merely providing technically competent delivery governance.

Business Factors and Business Visions are the strategic layer. They translate what an organisation is trying to do into what its IT capabilities need to become. Without them, the IT investment portfolio is driven by bottom-up demand — local business requests, urgent problems, technology replacements — rather than strategic intention. The portfolio may be well-managed. It is not necessarily well-directed.

Business Factors: operating rules for IT planning

The most important type is Principles — statements that actually shape decisions. The test: could this Principle be violated? If following it is always the obvious choice and no one would ever consider violating it, it contains no real decision and is worthless as a planning constraint.

“We support business agility” is not a Principle. “We prefer buying standard software over building custom, and any custom development requires explicit justification at Investment Forum level” is a Principle. The first could appear in any organisation’s documentation without meaning anything. The second will actually be argued about, and that argument is precisely what makes it valuable.

What makes a Principle operational is the Statement-Rationale-Implications structure:

Business Visions: directional plans

The Business Capability Model is the foundation — a structured map of what an organisation can do, not how it does it, not who does it, not what systems support it. Capabilities are stable: “claims processing”, “customer onboarding”, “product pricing” persist through organisational restructuring and system replacements. That stability makes them a reliable planning reference.

The Roadmap translates capability priorities into an IT investment sequence. A Roadmap entry is not a project plan — it is a direction commitment. “We will invest in improving our claims processing capability over the next 18 months” shapes the portfolio without constraining delivery.

Most IT investment proposals have the same problem. They are either too thin to support a good funding decision, or they contain so much detail that they are effectively doing the architecture work that should come after funding is approved, not before.

Business Outlines — specifically Solution Overviews — are the AMBIT answer to this problem. Getting them right is one of the most practically impactful skills an architect can develop.

A Solution Overview is the investment case document for an IT initiative. It sits between the strategic direction (Business Visions) and the detailed design (IT Designs). Produced during Initiation and approved by the Investment Forum, its purpose is to answer one question: is this initiative worth funding? That question has two dimensions: business value and technical feasibility. The document needs to answer both in business language, not technical language.

The ten sections

1. Business context — why does this need doing now? What business problem or opportunity does it address?
2. Current state — what does the current landscape look like in the relevant area? IT Landscape content translated into business terms, not a technical diagram.
3. Proposed solution — what will be built, at a conceptual level accessible to non-technical readers?
4. Future state — what will the business environment look like after delivery? Before/after framing, in business terms.
5. Business benefits — what specific outcomes will the organisation achieve? Quantified where possible.
6. Cost and timeline — indicative, not committed. Enough precision to support a funding decision, not a project plan.
7. Risks — the top three to five risks, stated clearly with their mitigating factors.
8. Strategic alignment — which Principles does this comply with? Which Roadmap entries does it address? Which Business Capabilities does it strengthen?
9. Technical concept — a brief explanation of the proposed solution approach for a technically literate reader. One page maximum.
10. Sourcing recommendation — buy, build, or outsource, with rationale.

The calibration question is: does this section help the Investment Forum decide whether to fund? If yes, it belongs. If no, it doesn’t.

Related artefact types

Not every initiative begins with a full Solution Overview. The typical sequence is:

1. Initiative Proposal — a brief statement of a proposed initiative for early-stage portfolio consideration, before enough analysis has been done.
2. Options Assessment — used when multiple credible solution approaches exist and the organisation needs to evaluate them explicitly before committing to one. Compares typically two to four options against business fit, technical risk, cost range, time to value, and strategic alignment.
3. Solution Overview — the full investment case, once the approach is selected.
4. IT Design — the detailed specification, once funding is approved.

The two IT-focused artefact types in the Rules and Structures columns of the Alignment Matrix — IT Standards and IT Landscapes — are the technical infrastructure that makes everything else in an architecture practice coherent.

They are also, in many organisations, either absent or present but not used. Understanding why requires understanding what they are actually for.

IT Standards: defining the technical playing field

IT Standards answer: given the full range of available technologies and approaches, which ones does this organisation adopt as its norm? The most important type is the Technology Reference Model — a structured classification of every significant technology in the ecosystem, mapped against one of five lifecycle statuses:

A Technology Reference Model with these five statuses turns hundreds of individual technology decisions into a coherent framework. An architect reviewing a proposed IT Design no longer evaluates each technology choice from scratch — they check it against the Reference Model and either confirm compliance or surface a deviation.

Guidelines accompany the Reference Model. A Reference Model says which technologies; Guidelines say how to use them. Security Guidelines define approved authentication patterns. Integration Guidelines define approved messaging formats and API styles. Data Guidelines define how shared data entities should be modelled.

IT Landscapes: documenting reality

IT Landscapes answer: what does the IT estate actually look like right now? Three types:

The maintenance discipline for IT Landscapes is straightforward but requires deliberate commitment: update them. Every time a project delivers, every time a system is decommissioned, every time a technology changes. Landscapes that are updated quarterly at best become historical artefacts that nobody trusts. An architecture team that has stopped trusting its own Landscape documentation has lost the factual basis for every other planning decision it makes.

There is a persistent myth in architecture that you can separate the technical work from the organisational work. That the architect’s job is to produce technically excellent designs, and then someone else — a project manager, a business analyst, a change manager — facilitates the conversations needed to make those designs happen.

This is wrong, and organisations that operate on this assumption consistently fail to get value from their architecture investment.

The research on how effective architects actually work is clear: every architect who delivers sustained value wears two hats simultaneously. Neither can be delegated.

The Technology Expert hat

Deep, current, authoritative knowledge of IT domains, technologies, vendor products, architecture patterns, and the specific technical landscape of the organisation. This hat produces technically sound solutions — IT Designs that actually work, IT Standards that reflect current best practice, IT Landscapes that accurately describe reality. Without it, an architect has no credibility with the project teams and technical specialists they need to influence.

The Change Agent hat

The ability to engage stakeholders — to understand what they actually need rather than what they say they need, to navigate conflicting interests without losing relationships, to translate between business language and technical language in both directions, to achieve the consensus needed to move a planning decision forward. This hat makes architecture artefacts legitimate: produced through genuine collective agreement rather than technical authority.

Neither hat is sufficient alone

Effective architects use both hats in the same conversations. Producing a Business Outline requires Technology Expert work (assessing technical feasibility, estimating cost, evaluating sourcing options) and Change Agent work (understanding the business sponsor’s actual goals, making the investment case legible to non-technical decision-makers) simultaneously. These are not sequential activities.

This has a direct implication for how architects are hired and developed. The population of people who combine deep technical competence with genuine organisational effectiveness is small. Finding it, or developing it in existing people, is the central talent challenge of an architecture function.

An architecture function is not a homogeneous group of generalists all doing the same thing. The most effective ones have differentiated roles — architects operating at different levels of abstraction, with different stakeholder sets, and with different balances of the two hats.

Five archetypes recur consistently across mature architecture practices.

Two supporting roles

• Engagement Managers — handle the stakeholder identification and relationship management work that precedes the D-E-A process, opening the conversations that architects then have.
• Technical Designers — handle the detailed implementation specifications that sit below the level of IT Designs — system internals, detailed data models, infrastructure configurations — delegating that work from architects to specialists.

Building the function incrementally

The practical implication for building an architecture function: start with what the practice needs to do now, not with an ideal org chart.

1. Stage One (Initiative Alignment): Solution Architects only.
2. Stage Two (adding Technology Alignment): Domain Architects are added.
3. Stage Three (adding Strategic Alignment): Enterprise Architects and Business Area Architects become necessary.

I described the four governance forums conceptually in Article 10. Here I want to be practical about what they look like when they work and when they don’t — because the failure modes are instructive.

Five characteristics of a governance forum that works

1. Decisions are not new to anyone. The participants have been engaged through the D-E-A process. Every stakeholder with a significant interest has been consulted, and their concerns addressed or explicitly acknowledged. By the time the forum meeting happens, the review is confirming what everyone already knows, not discovering it.
2. Pre-reads are distributed and read. Artefacts arrive with participants at least forty-eight hours before the meeting. Participants arrive having read them. The meeting begins with shared understanding rather than simultaneous first reading. This sounds elementary. In most governance forums it is not the norm.
3. The agenda matches the forum type. A Strategy Forum discusses strategic direction. It does not spend forty-five minutes on a detailed technical issue that belongs in a Technology Forum. Agenda drift is a symptom of unclear forum mandates, and it compounds over time until the forum is doing everything poorly rather than one thing well.
4. Decisions are documented the same day. Who attended. What was reviewed. What was decided. What conditions or obligations attach. If this isn’t done before participants leave the building, detail fades and commitments blur. Decision logs are not bureaucracy; they are memory.
5. Architects are advisors, not decision-makers. Architects have no managerial authority over investment decisions or project commitments. Their role is to provide analysis, advocate architectural positions, and ensure that the technical consequences of decisions are understood. An architect who attempts to behave as though they have veto authority will rapidly lose access to the conversations they need.

Four failure modes

The most common reason EA initiatives fail is not bad process design. It is unrealistic expectations about how quickly a practice can be established.

An architecture practice is a complex organisational system. It requires skilled architects, business stakeholders who engage with it, governance structures that function as described rather than as written, and artefacts that people actually use. Most importantly, it requires trust — the accumulated experience of architects delivering value and business leaders experiencing that value directly. Trust takes time to build and cannot be accelerated by process design.

The organisations that establish successful practices understand one thing clearly: introduce the practice incrementally, one element at a time, and don’t add the next element until the current one is genuinely working.

Two paths to establishing a practice

The historical path

Followed by most large organisations that have had EA in some form for decades. The sequence:

1. Start with IT Standards and IT Landscapes — Technology Alignment begins.
2. Add Solution Overviews and IT Designs — Initiative Alignment formalises.
3. Add Business Factors and Business Visions — Strategic Alignment emerges.

This sequence reflects the natural evolution of IT departments: from technical concerns outward, toward strategy. The risk is that Strategic Alignment emerges last — if it emerges at all. Many organisations have mature Initiative and Technology Alignment practices but thin Strategic Alignment. Their IT portfolios are well-governed but not well-directed.

The deliberate path

Available to organisations starting fresh. Start from the most acute business problem, not from the technically natural starting point:

• If business leaders don’t understand where IT budget is going — start with Business Outlines and the Investment Forum.
• If IT projects are technically inconsistent and expensive to integrate — start with IT Standards and the Design Forum.
• If the IT investment portfolio is disconnected from business strategy — start with Business Capability Models and the Strategy Forum.

Starting from business problems rather than artefact checklists is the defining discipline of the deliberate path. It requires an experienced architect who can diagnose the problem correctly before prescribing the solution.

Six conditions required to institutionalise any new artefact type

Regardless of which path is taken, these six conditions must all be met:

1. Executive mandate — a named senior leader has committed to this.
2. A designated lead architect — individual accountability.
3. Active stakeholder involvement — the right people are participating, not just consulted.
4. An accessible repository — anyone who should be able to find the artefact can.
5. A defined maintenance process — who updates it, when, and in response to what triggers.
6. Defined usage — in which decisions will this artefact be referenced?

One practical note on sequencing: do not introduce the practice organisation-wide all at once. Pilot in one business area or one domain. Demonstrate value. Refine the approach. Then propagate. The practice takes time. In medium-sized organisations, three to five years to reach full Strategic Alignment maturity is typical. Any consultant or methodology that promises faster transformation should be viewed with scepticism proportional to the confidence with which the promise is made.

Maturity models for enterprise architecture are everywhere. Most of them measure the wrong things.

They count the number of artefact types in use, the percentage of projects going through architecture review, the completeness of the governance documentation. These things can all be measured, which is presumably why they appear in maturity models. But they can all be present in a failing practice and absent from a successful one. They measure form, not function.

AMBIT’s maturity model has two layers.

Layer one: which Alignment Processes are genuinely institutionalised?

Layer two: the five-question test

The ultimate test bypasses all measurement entirely. Find your senior business executives — the CFO, the COO, the business unit heads — and ask them five questions:

1. Do you understand what IT is doing, and how it contributes to the achievement of your business goals?
2. Do you understand where and on what particular initiatives your IT budget is being spent?
3. Do you understand how IT is transforming your business?
4. Do you understand what business value IT is delivering to your organisation?
5. Do you feel that IT investment decisions reflect your strategic priorities?

If these questions receive consistent positive answers from the executive-level business audience, the architecture practice is fulfilling its purpose. If the answers are negative — if senior business executives are confused about what IT is doing, uncertain about whether the budget is well-spent, or disconnected from the transformation agenda — the practice is not working. It does not matter how many artefacts have been produced, how rigorous the governance process is, or how impressive the architecture repository looks.

One question for reflection: when did you last ask a senior business executive those five questions? And if you did, what did they say?

Twenty articles. One framework. One discipline.

I want to close with something that is less about AMBIT and more about the kind of framework I am trying to build.

Most EA frameworks are frozen. They are written, published, certified, and then periodically revised in ways that reflect commercial considerations as much as new evidence. The version you implement today is essentially the same framework someone implemented years ago, regardless of what the discipline has learned in the interim.

AMBIT is grounded in empirical research — in what organisations that genuinely achieve business-IT alignment actually do. That grounding creates an obligation that a theoretically constructed framework does not have: the obligation to update when the evidence updates.

As Svyatoslav Kotusev’s research develops, as other researchers contribute to the empirical body of knowledge on EA practice, as my own work with organisations surfaces patterns that the current framework does not fully capture, AMBIT changes. Not arbitrarily — every change needs justification from the evidence or from observed practice. But the commitment is to the evidence, not to preserving a version.

What AMBIT does not yet handle well

• The interaction between EA practices and platform engineering organisations, where the traditional boundary between architecture and engineering is dissolving.
• The implications of AI-assisted architecture for which decisions still need human judgement and which can be delegated to tools.
• The governance of technology investment in highly federated organisations, where the concept of an organisation-wide IT landscape is more aspirational than real.

What a framework cannot do

AMBIT describes the shape of a mature EA practice. It does not — cannot — tell you how to build the trust with your CFO that makes Strategic Alignment possible. It does not tell you how to navigate the political dynamics of an organisation where IT and business have a history of adversarial relationships. It does not tell you how to demonstrate value quickly enough to survive the first funding cycle.

• How to build trust with senior executives who have been disappointed by IT before.
• How to navigate organisational politics when competing departments have conflicting investment priorities.
• How to demonstrate value quickly enough to survive the first budget cycle.

These are human problems. They require human judgement, contextual reading, and the kind of practical wisdom that accumulates through experience rather than through reading frameworks. AMBIT gives you a map. It does not give you the navigational skill to use it in every terrain.

What it does give you, I hope, is a coherent picture of what you are building toward — a mature practice in which business and IT leaders genuinely understand each other, in which IT investment reflects strategic intent, in which the IT landscape is being actively maintained rather than passively accumulated, and in which architects are trusted partners in organisational decision-making rather than technical reviewers attached to delivery projects.

That is the ambition. The scope, range, and sphere of operation that gives the framework its name.