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 within it. 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. Two options: 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

Business Factors (Business-Focused Rules): The operating principles and constraints governing how the organisation needs to work in relation to IT. Principles, policies, conceptual data models, direction statements. Broad, stable, long-lived. Established collaboratively by business leaders and architects during Strategic Alignment.

Business Visions (Business-Focused Structures): The desired long-term direction and intended future configuration of the organisation's business capabilities and IT estate. Business Capability Models, Roadmaps, Target States. The primary input translating business strategy into an investment direction.

Business Outlines (Business-Focused Changes): High-level, business-intelligible descriptions of specific proposed IT initiatives — their purpose, scope, conceptual solution, business value, and indicative cost. The investment cases through which initiatives are funded. Temporary: produced for each initiative, retired after funding decisions are made.

IT Standards (IT-Focused Rules): Technical rules that IT solutions should follow — Technology Reference Models, Guidelines, Patterns, IT Principles. Established and maintained by architects. Promote reuse, consistency, and technical quality across the IT landscape.

IT Landscapes (IT-Focused Structures): Factual documentation of the current IT estate — Landscape Diagrams, Application Inventories, Enterprise System Portfolios. The factual basis for every other planning decision. Updated continuously as the landscape changes.

IT Designs (IT-Focused Changes): Detailed technical specifications telling project teams exactly how to build approved IT solutions — application architecture, data models, integration specifications, security designs. Temporary: produced per initiative, retired after delivery.

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.

D-E-A: the three-step pattern that makes architecture artefacts legitimate (Discuss, Elaborate, Align) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 6 of 20

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.

Next article: the three Alignment Processes that constitute an EA practice, starting with Strategic Alignment.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PART III: THE THREE ALIGNMENT PROCESSES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

──────────────────────────────────────────────────

Strategic Alignment (Translating business direction into an IT investment portfolio) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 7 of 20

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 are the operating rules. They answer: how does this organisation need to work in relation to IT? The most important type is Principles — substantive statements about the organisation's IT approach that genuinely shape planning decisions. A useful Principle has the following structure: a Statement (what we do), a Rationale (why we do it), and Implications (what this means for specific decisions). "We prefer standard platforms over custom builds" followed by a rationale about maintenance cost and a list of specific types of custom build that require explicit justification is a useful Principle. "We will use appropriate technology" is not a Principle. It is a sentence.

The test for a useful Principle is simple: can a reasonable organisation argue against it? If no reasonable organisation would argue against it, it contains no real decision, and it is trivial. Trivial Principles are worse than useless — they give the illusion of direction while providing none.

Business Visions are the directional plans. They 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 of IT initiatives: 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.

Strategic Alignment is structurally different from the other two Alignment Processes in AMBIT. It is continuous and largely unstructured. You cannot schedule it into quarterly sessions and expect it to work. It happens in conversations, in informal check-ins with the CFO about technology cost trends, in observations about which Business Visions are being invalidated by market shifts. Enterprise architects who practise Strategic Alignment well do not spend most of their time at their desks. They spend it in conversations.

This also means that Strategic Alignment is the hardest process to establish and the last to mature in most organisations. It requires senior business executives who genuinely trust the architects enough to have those conversations. That trust is earned through Initiative Alignment first — through architects demonstrating, project by project, that they add real value and can be relied upon to give honest advice. The sequence matters.

Two things to measure that tell you whether Strategic Alignment is working. First: when IT investment decisions are being made, is the Roadmap in the room? Not as a historical reference — as an active input. Second: 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 aren't, no volume of architecture artefacts will compensate for that gap.

Next article: Initiative Alignment — from funded project to delivered IT solution.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Initiative Alignment (How good IT solutions actually get designed) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 8 of 20

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. Step one is Initiation. Step two is Realisation. They are separated by a funding gate.

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 document called 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 are: business context, current state, proposed solution concept, future state, business benefits, indicative cost and timeline, risks, strategic alignment (which Principles and Roadmap entries does this serve?), technical concept, and sourcing recommendation (buy, build, or outsource?).

The over-specification failure mode for Solution Overviews is worth naming explicitly: producing a document too detailed for an investment decision. If a Solution Overview contains detailed requirements, it has over-specified. If it contains a system architecture diagram with integration patterns, it has over-specified. The test is simple: does this section help the Investment Forum decide whether to fund? If not, remove it.

Once the Solution Overview is approved and funding is committed, Realisation begins. This step answers the question: exactly how will we build this?

The output of Realisation is an IT Design — a Solution Design. This is the document the project team actually builds from. It covers: application architecture, data model and data flows, integration specifications, infrastructure requirements, security architecture, and for complex solutions, a migration or cutover plan.

The key principle for IT Designs is what I call the boundary rule. Specify every decision that, if made incorrectly, creates a costly landscape consequence — an integration pattern that locks in a vendor, a data model that conflicts with the enterprise data standard, a security approach that introduces regulatory risk. Delegate every decision that has no landscape consequence — internal code structure, UI component choices, configuration details within an approved platform.

IT Designs that over-specify become obstacles. Project teams route around them. Architects waste time enforcing decisions that don't matter while the decisions that do matter get made informally. IT Designs that under-specify leave the architecture to chance — every project reinvents the wheel, inconsistencies multiply, and the landscape gradually becomes incoherent.

Getting this calibration right is one of the most important skills an architect can develop.

One final point on Initiative Alignment that most process descriptions miss. Not all initiatives are strategic. AMBIT identifies five initiative types: Fundamental (major transformations), Strategic (from the Roadmap), Local (business-unit-initiated), Urgent (reactive), and Technical (IT-internal, e.g. infrastructure refresh or architecture debt remediation). Initiative Alignment handles all five — not just the strategic ones.

A portfolio dominated by Urgent and Technical initiatives is a diagnostic signal. It means Strategic Alignment is not working. Business needs are arriving as fire-fighting rather than planned investment, and IT is spending most of its budget on maintenance rather than capability development. No amount of better Initiative Alignment process fixes a Strategic Alignment problem. But better Initiative Alignment process, consistently applied, builds the track record that makes Strategic Alignment possible.

Next article: Technology Alignment — keeping the IT landscape coherent over time.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Technology Alignment (The process that prevents landscape decay) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 9 of 20

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.

It has three inputs. First, IT Landscapes: the factual documentation of what currently exists. Second, IT Standards: the picture of what should exist — which technologies are strategic, which are retiring, which are prohibited. Third, 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.

The outputs feed in two directions. They inform the IT investment portfolio, generating Technical initiatives (infrastructure refresh, platform consolidation, legacy decommission) that need to be funded alongside strategic business initiatives. And 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. It is an entirely IT-internal process. This makes it easy to defer, underfund, and gradually stop doing — especially when the IT budget is under pressure and business stakeholders are asking why money is being spent on things that don't deliver new capability.

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. Each new project requires more effort to navigate the existing complexity. Each technical shortcut taken to meet a delivery deadline adds to the mountain of debt that constrains the next initiative. The organisations that defer Technology Alignment save money in the short term and pay significantly more in the long term.

The architecture debt concept is Technology Alignment's most important 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. Architecture debt is not inherently bad. Sometimes taking on debt for a valid business reason is the right decision. The problem is unacknowledged debt: deviations that are not formally recorded, not estimated for remediation cost, and not tracked against a remediation plan. Unacknowledged debt compounds silently. It becomes structural constraint.

Good Technology Alignment practice requires a simple discipline: record every deviation. Put it in an Architecture Debt Register. Estimate what it will cost to fix. Give it a target remediation date. Review the register quarterly. Let it inform portfolio decisions.

A register of twenty architecture debts with remediation costs and target dates is a mature, honest account of a landscape's condition. A register with three entries in an organisation with hundreds of systems is either a perfect landscape — which is unlikely — or an architecture team that isn't looking.

Next article: the four governance forums that make all three processes accountable.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

The four governance forums (How architecture decisions get formally authorised) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 10 of 20

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 deserved, 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. The forum's role is to create an official, auditable record that the organisation has collectively committed to this direction.

If a governance forum meeting is producing significant new arguments, strong objections, or substantive revisions to the artefact being reviewed, the pre-meeting process failed. The fix is not a longer governance meeting. It is better preparation.

With that framing established, here are the four governance forums in AMBIT.

The Strategy Forum is business-focused and strategic. It approves Business Factors and Business Visions. It is chaired by the CIO, attended by senior business executives and enterprise architects, and meets quarterly. This is the forum where the organisation's strategic IT direction is formally ratified.

The Technology Forum is IT-focused and strategic. It approves IT Standards and the strategic dimensions of IT Landscapes. It is chaired by the Chief Architect or Architecture Manager, attended by Domain Architects and senior IT leaders, and meets monthly. This is the forum that defines the technical playing field.

The Investment Forum is business-focused and tactical. It approves Business Outlines — specifically, Solution Overviews — and makes funding decisions. It is chaired by the CIO, attended by business executives, architects, and a finance representative, and meets monthly. This is the investment gate: nothing moves into implementation without passing through here.

The Design Forum is IT-focused and tactical. It approves IT Designs. It is chaired by the relevant Domain Architect or lead architect, attended by Solution Architects and technical specialists, and meets on a per-initiative basis rather than on a fixed schedule. This is the quality gate: implementation begins only after the Design has been reviewed for landscape fit and Standards compliance.

Four forums, covering all four combinations of business/IT and strategic/tactical.

In small organisations all four functions can be handled by a single committee that invites different participants for different agenda items. In medium organisations, two committees typically cover the four types: a Business Committee (Strategy + Investment) and an IT Committee (Technology + Design). In large organisations, four separate forums make sense. The governance function must be fulfilled regardless of how it is structured.

Two practical principles for effective forums.

First: pre-read discipline. Every artefact being reviewed must be distributed to forum members before the meeting — forty-eight hours at minimum. A forum that reviews documents for the first time in the meeting is not governing; it is reacting. Reactions produce poor decisions.

Second: decision logging. Every endorsement, rejection, exemption, and escalation must be formally recorded with 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. That commitment is what gives architects the organisational authority to hold delivery teams accountable to architectural direction.

Next article: architecture debt — what it is, why it matters, and how to manage it.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Architecture debt (Every deviation from good architecture has a future cost — do you know yours?) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 11 of 20

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.

The term is borrowed from technical debt in software engineering, and the borrowing is apt. 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 discipline of architecture debt management is simple. When a governance forum approves a deviation — grants an exemption because the business case is strong enough — the deviation is documented. It goes into an Architecture Debt Register with five fields: a description of the deviation, which IT Standards or architectural direction it departs from, the estimated future cost to remediate, the planned remediation date, and a severity classification (minor, medium, or major based on the 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.

The register serves three purposes.

First, it makes the true cost of IT decisions visible. When an Investment Forum is evaluating whether to approve a tactical solution that deviates from the strategic direction, the architecture debt estimate is part of the total cost calculation. A solution that costs £500k to build but carries £400k of architecture debt has a total cost of £900k. Present it that way. Many urgency-driven decisions look different when the deferred cost is made explicit.

Second, it drives Technology Alignment. The Architecture Debt Register is one of the primary inputs to Technology Alignment — the process of analysing the landscape and identifying rationalisation opportunities. Debts with remediation dates become planned Technical initiatives. The register is not a historical record of regrettable decisions; it is a planning tool.

Third, it enables governance escalation. Many organisations establish debt thresholds that trigger higher-level governance. 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 — "significant deviations require senior authority" — into an auditable decision rule.

What the Architecture Debt Register reveals about an organisation is telling. An organisation with a comprehensive register, realistic cost estimates, and active remediation plans has a mature, honest practice. An organisation with an empty register and a chaotic landscape has an architecture function that either isn't looking or isn't recording what it sees.

The register is not a report of failure. It is evidence of honesty. Every architecture team, in every organisation, managing a real IT landscape, has debts. The ones who pretend otherwise are not managing their debt; they are just not measuring it.

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

Next article: Business Factors and Business Visions — the strategic layer of the Alignment Matrix.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PART IV: THE ARTEFACTS IN DEPTH ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

──────────────────────────────────────────────────

Business Factors and Business Visions (The strategic layer that most architecture practices build last — if at all) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 12 of 20

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 are the operating rules for IT planning. The most important type is Principles.

A Principles document should contain statements that actually shape decisions. The test for a useful Principle is whether it could be violated. If following the Principle 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.

The Statement-Rationale-Implications structure makes Principles useful. The Statement says what. The Rationale says why. The Implications list the specific decisions that follow from it. An architect reviewing a proposed IT Design can take a Principle, read its Implications, and determine whether the Design complies or deviates. That traceability is what connects strategic intent to delivery decisions.

Business Visions are the directional plans. The Business Capability Model is the foundation.

A Business Capability Model is 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" are capabilities that persist through organisational restructuring and system replacements. This stability is what makes them useful as a planning reference. An IT investment portfolio organised by capability is comprehensible to business leaders in a way that an IT investment portfolio organised by system or technology is not.

The Roadmap translates capability priorities into an IT investment sequence. Which capabilities need investment now? Which in the next two years? Which are on the radar but not yet defined enough to plan? 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" is a Roadmap entry. It shapes the portfolio without constraining delivery.

The connection between Business Visions and the Investment Forum is the mechanism through which Strategic Alignment actually influences investment decisions. When a new initiative proposal arrives at the Investment Forum, the first question should be: where does it appear in the Roadmap, and which Business Capability does it strengthen? If it doesn't appear in the Roadmap and doesn't clearly strengthen a priority capability, it needs an explicit justification for why it should displace something that does.

This sounds simple. In organisations without Strategic Alignment, the Investment Forum evaluates each proposal on its individual merits without a shared strategic context. Every department makes the best case it can for its own initiative. The portfolio that results is the sum of individually defensible decisions rather than a coherent strategic programme. Business Factors and Business Visions are what change that.

Next article: Business Outlines — the investment case artefact that bridges strategy and delivery.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Business Outlines (The investment case document most organisations get wrong) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 13 of 20

Most IT investment proposals I have reviewed 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). It is produced during the Initiation step of Initiative Alignment 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 (what will this deliver, and is it worth the cost?) and technical feasibility (is the proposed approach credible, and are the cost and timeline estimates reasonable?). The Solution Overview needs to answer both dimensions in a way that is credible to the business executives who will approve it — which means it needs to be written in business language, not technical language.

The ten sections of a useful Solution Overview:

Business context — why does this need doing now? What business problem or opportunity does it address?

Current state — what does the current landscape look like in the relevant area? This is IT Landscape content translated into business terms, not a technical diagram.

Proposed solution — what will be built, at a conceptual level accessible to non-technical readers? Not "we will implement a microservices architecture"; rather, "we will replace the current manual claims processing workflow with an automated platform that integrates with the customer portal."

Future state — what will the business environment look like after this is delivered? Before/after framing, in business terms.

Business benefits — what specific outcomes will the organisation achieve? Cost reduction, revenue uplift, risk reduction, compliance, customer experience improvement. Quantified where possible.

Cost and timeline — indicative, not committed. Enough precision to support a funding decision, not a project plan.

Risks — the top three to five risks, stated clearly with their mitigating factors.

Strategic alignment — which Principles does this comply with? Which Roadmap entries does it address? Which Business Capabilities does it strengthen?

Technical concept — a brief explanation of the proposed solution approach for a technically literate reader. One page maximum.

Sourcing recommendation — buy, build, or outsource, with rationale.

The over-specification failure mode deserves its own emphasis. When a Solution Overview contains integration architecture diagrams, API specifications, or detailed user stories, the architect has over-specified. They have produced design work that belongs in an IT Design — work that should only be done after funding is approved, because it is too expensive to invest in before knowing whether the initiative will proceed.

The under-specification failure mode is less common but equally damaging. A Solution Overview with no technical concept, unrealistic cost estimates, or a strategic alignment section that simply says "aligns with digital transformation strategy" has not done enough work to support a good investment decision.

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

Options Assessments are a related artefact type — used when multiple credible solution approaches exist and the organisation needs to evaluate them explicitly before committing to one. An Options Assessment compares typically two to four options against a common set of criteria: business fit, technical risk, cost range, time to value, and strategic alignment. It produces a recommendation with reasoning.

Initiative Proposals are lighter still — a brief statement of a proposed initiative for early-stage portfolio consideration, before enough analysis has been done to produce a full Solution Overview.

The sequence in most cases is Proposal → Options Assessment (if needed) → Solution Overview → IT Design.

Next article: IT Standards and IT Landscapes — the technical infrastructure of a coherent IT estate.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

IT Standards and IT Landscapes (The technical infrastructure of a coherent IT estate) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 14 of 20

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 define the technical playing field. They answer the question: given the full range of available technologies and approaches, which ones does this organisation adopt as its norm?

The most important IT Standard type is the Technology Reference Model — a structured classification of every significant technology in an organisation's ecosystem, mapped against a lifecycle status:

Strategic: actively invest and adopt. This is the direction we are heading. Current: continue using, maintain, but don't actively expand. Emerging: evaluate and pilot. Not yet approved for production use. Retiring: plan to replace. Approved for existing uses but not new ones. Prohibited: do not use. Regulatory, security, or strategic incompatibility.

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 needs to evaluate each technology choice from scratch. They check it against the Reference Model. "Azure Functions are classified as Strategic for serverless workloads. The proposed use of AWS Lambda for this integration is a deviation. It needs an exemption or a justification for why the architectural direction should change."

Guidelines are the implementation instructions that 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.

The over-constraint failure mode for IT Standards deserves attention. Standards that are so rigid that project teams cannot comply without unacceptable delivery cost don't reduce deviation — they just make the deviation undisclosed. If every project is requesting exemptions, or worse, simply ignoring the Standards, the Standards are miscalibrated. The right level of constraint is the one where competent project teams can comply with reasonable effort, and genuine deviations are identifiable exceptions rather than standard practice.

IT Landscapes document reality. They answer the question: what does the IT estate actually look like right now?

The most essential type is the Landscape Diagram — a visual map of the IT landscape at a defined scope and granularity. For strategic planning conversations, a high-level Landscape Diagram showing major application clusters and their relationships is appropriate. For initiative planning, a more detailed view of the relevant domain is needed.

Application Inventories are the structured data underlying the diagrams — a list of every application, with its owner, its technologies, its business capabilities served, its hosting environment, and its strategic status. This is the factual basis for Technology Alignment analysis.

Enterprise System Portfolios bridge IT Landscapes and Business Visions — they map the IT estate against the Business Capability Model, showing which systems support which capabilities, identifying capability gaps (capabilities with no IT support) and redundancy (capabilities with multiple competing systems).

The maintenance discipline for IT Landscapes is straightforward but requires deliberate commitment: update them. Every time a project delivers new functionality, the Landscape is updated to reflect it. Every time a system is decommissioned, it is removed. Every time a technology is changed, the Inventory entry is updated. Landscapes that are updated quarterly at best and never in response to project delivery 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.

Next article: the two hats every architect wears — and why both are essential.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PART V: THE ARCHITECTS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

──────────────────────────────────────────────────

The two hats every architect wears (Technology Expert and Change Agent) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 15 of 20

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 on this point. Every architect who delivers sustained value wears two hats simultaneously. The first is the Technology Expert hat. The second is the Change Agent hat. Neither can be delegated.

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

The Change Agent hat is the facilitator mode. 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 is what makes architecture artefacts legitimate — produced through genuine collective agreement rather than technical authority.

The key insight is that neither hat is sufficient alone.

A pure Technology Expert — brilliant on the technical side, impatient with organisational dynamics, preferring to solve problems at the desk rather than in conversations — produces technically excellent work that doesn't get implemented. Their solutions are overridden by political decisions they didn't anticipate because they weren't in the room. Their Standards are ignored because the project teams find them impractical without the negotiation work that would have surfaced the compromises. Their Designs are deviated from because the business stakeholders don't feel ownership of them.

A pure Change Agent — excellent with people, skilled at facilitation, deeply trusted by business leaders — produces consensus without technical substance. Their planning decisions are politically viable but technically flawed. Their enthusiasm for collaboration isn't matched by the technical depth needed to evaluate what they're agreeing to. They over-rely on junior colleagues for the technical input that should inform their own judgement.

Effective architects use both hats. 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, navigating competing departmental priorities, making the investment case legible to non-technical decision-makers) simultaneously. These are not sequential activities. They happen in the same conversations.

This has a direct implication for how architects are hired and developed. Organisations that hire for technical depth alone consistently find they have architects who cannot engage senior business leaders effectively. Organisations that hire for communication skills alone find they have architects who lack the credibility to challenge technically poor decisions. 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.

One practical note for architects early in their careers: the Technology Expert hat comes first, not because it is more important, but because technical credibility is the prerequisite for the Change Agent hat to work. Business leaders trust architects who clearly know what they're talking about. That trust is the precondition for the conversations through which alignment is actually achieved. Build technical depth first. The organisational skills follow more naturally from a position of credibility than from a position of enthusiasm.

Next article: the five architect archetypes and where each one operates.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Five architect archetypes (Who does what in a mature architecture function) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 16 of 20

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.

Solution Architects work at the initiative level. They own the design and delivery governance of individual IT projects. They are present through Initiative Alignment — from Solution Overview development through IT Design to delivery review. Their primary stakeholders are project managers, business analysts, and the technical specialists building the system. They use the Technology Expert hat heavily during design, the Change Agent hat heavily when navigating the competing interests of project teams, business stakeholders, and the landscape constraints that Domain Architects impose. Solution Architects are the most numerous archetype in most organisations. They are also the entry point for most architects — Initiative Alignment is where architecture begins.

Domain Architects work at the technical landscape level. They own a specific EA domain — applications, data, integration, infrastructure, security, cloud — and are responsible for the IT Standards and IT Landscapes in that domain. Their primary stakeholders are solution architects (whose designs they review for domain compliance) and senior IT specialists (whose expertise they synthesise into standards). Domain Architects are the Technology Alignment process's primary operators.

Business Area Architects work at the business unit level. They own end-to-end IT planning for a specific business area — a line of business, a major function, a geography. They run both Strategic Alignment and Initiative Alignment for their area, and they must be as credible in a conversation with a business unit director as in a discussion about integration architecture. This is the archetype that requires the most balanced combination of both hats.

Enterprise Architects work at the organisation-wide level. They are responsible for the cross-cutting, organisation-wide planning that transcends any individual domain or business area. They own the organisation's Business Capability Model, the overarching Roadmap, the top-level Business Factors, and the cross-domain elements of IT Standards. Their primary stakeholders are the C-suite. They are typically the most senior architects in the function, and they operate the Change Agent hat at its highest intensity — the ability to maintain trusted advisory relationships with senior business executives is their primary value.

Architecture Managers are not primarily architects. They manage other architects, organise the architecture function's operations, and ensure the practice is improving over time. They are responsible for the governance forums running effectively, artefact quality being reviewed periodically, and architectural capability being developed in the team. In small organisations this role may be combined with Enterprise Architect. In large ones it is usually separate.

Two supporting roles that sit adjacent to the archetypes are worth naming. Engagement Managers, used in some organisations, 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.

The practical implication for building an architecture function: start with Solution Architects. Stage One maturity — which covers Initiative Alignment — is built with Solution Architects and nothing else. As the practice grows into Stage Two (adding Technology Alignment), Domain Architects are added. As it grows into Stage Three (adding Strategic Alignment), Enterprise Architects and Business Area Architects become necessary. The progression is driven by what the practice needs to do next, not by an ideal org chart.

One observation that the evidence strongly supports: the architecture function should grow incrementally, each role added when the organisation is ready to support what that role does. An Enterprise Architect in an organisation with no Strategic Alignment practice is not doing Enterprise Architecture. They are doing something else — often quite usefully, but not Enterprise Architecture. Hire for the capability you can use now.

Next article: governance forums in practice — what good looks like and what bad looks like.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Governance forums in practice (What they look like when they work — and when they don't) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 17 of 20

I described the four governance forums conceptually a few articles ago. 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.

A governance forum that works has five characteristics.

Decisions are not new to anyone. The participants have been engaged through the D-E-A process. The artefact being reviewed has been through Discuss and Elaborate. Every stakeholder with a significant interest has been consulted, and their concerns have been addressed or explicitly acknowledged and explained. By the time the forum meeting happens, the review is confirming what everyone already knows, not discovering it.

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 I have attended, it is not the norm.

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. A Design Forum reviews design quality. It does not reopen the strategic case for the initiative. 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.

Decisions are documented the same day. Who attended. What was reviewed. What was decided. What conditions or obligations attach to the decision. If this isn't done before participants leave the building — or at minimum before twenty-four hours have passed — detail fades and commitments blur. Decision logs are not bureaucracy; they are memory.

Architects are advisors, not decision-makers. Architects have no managerial authority over investment decisions or project commitments. Their role in governance forums is to provide analysis, advocate architectural positions, and ensure that the technical consequences of decisions are understood. The decision belongs to the business executives and IT leaders who constitute the forum. An architect who attempts to behave as though they have veto authority over investment decisions will rapidly lose access to the conversations they need to do their job.

Now the failure modes.

Forum as discovery session. Artefacts arrive with participants for the first time in the meeting. Genuine new concerns surface. Decisions are deferred. The forum spends its time exploring rather than deciding. This is not a governance problem — it is a preparation problem. The forum is compensating for D-E-A work that didn't happen.

Forum as rubber stamp. The D-E-A process has been so thorough — or so politically managed — that the forum endorses everything without scrutiny. Over time, participants disengage because attendance has no consequence. The forum becomes a ritual without function.

Forum as battleground. Unresolved organisational conflicts play out in the governance meeting. Competing departments use the forum to relitigate investment priorities. Architects find themselves mediating political disputes rather than providing architectural guidance. This is a symptom of inadequate Strategic Alignment — when there is no agreed strategic direction, every investment decision becomes a contest.

Forum as technical theatre. The meetings produce rigorous, detailed review of architecture artefacts — and are attended only by architects and IT specialists. Business stakeholders stopped coming because the meetings felt irrelevant to their concerns. The forum is technically excellent and organisationally isolated.

Each failure mode has a different root cause and a different fix. Forum as discovery: invest in D-E-A. Forum as rubber stamp: re-examine whether the right concerns are being surfaced. Forum as battleground: address the Strategic Alignment deficit. Forum as technical theatre: rewrite the agenda and reinvite business executives.

What forum your organisation has tells you more about the state of its architecture practice than what artefacts it produces.

Next article: establishing an architecture practice — where to start and what order to build in.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PART VI: MATURITY AND LIFECYCLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

──────────────────────────────────────────────────

Establishing an architecture practice (Why you can't switch one on — and what you can do instead) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 18 of 20

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. It requires business stakeholders who engage with it. It requires governance structures that function as described rather than as written. It requires 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 architecture practices understand one thing clearly: you introduce the practice incrementally, one element at a time, and you don't add the next element until the current one is genuinely working.

There are two paths to establishing a practice.

The historical path, followed by most large organisations that have had EA in some form for decades, goes in this order: start with IT Standards and IT Landscapes (Technology Alignment begins), then add Solution Overviews and IT Designs (Initiative Alignment formalises), then finally 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 of the historical path is that Strategic Alignment emerges last — if it emerges at all. Many organisations have mature Initiative Alignment and Technology Alignment practices but thin Strategic Alignment. Their IT portfolios are well-governed but not well-directed. Business executives receive competent technical delivery without strategic leadership. This is valuable, but it is not the full potential of an architecture practice.

The deliberate path, available to organisations starting fresh with the benefit of accumulated knowledge, starts from the most acute business problem. Not from the technically natural starting point.

If the most urgent problem is that business leaders don't understand where IT budget is going, start with Business Outlines and the Investment Forum. If the most urgent problem is that IT projects are technically inconsistent and expensive to integrate, start with IT Standards and the Design Forum. If the most urgent problem is that 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.

Regardless of which path is taken, six conditions must be met to institutionalise any new artefact type. Executive mandate: a named senior leader has committed to this. A designated lead architect: individual accountability. Active stakeholder involvement: the right people are participating, not just consulted. An accessible repository: anyone who should be able to find the artefact can. A defined maintenance process: who updates it, when, and in response to what triggers. Defined usage: in which decisions will this artefact be referenced?

Without all six, the artefact type may be produced but will not be institutionalised. It will be used for a cycle or two and then gradually abandoned as the architects who built it move on.

One practical note on sequencing. The practice should not be introduced organisation-wide all at once. Pilot in one business area or one domain. Demonstrate value. Refine the approach. Then propagate. Organisations that attempt to launch organisation-wide practices simultaneously usually find that inconsistent quality in early artefacts and patchy stakeholder engagement undermine confidence before the approach has had a fair trial.

The practice takes time. In medium-sized organisations, three to five years to reach full Strategic Alignment maturity is typical. In large organisations, longer. Any consultant or methodology that promises faster transformation should be viewed with scepticism proportional to the confidence with which the promise is made.

Next article: the maturity test — what a mature practice looks like and how to assess where you are.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

The maturity test (Five questions that tell you whether your architecture practice is working) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 19 of 20

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, the coverage of the technology reference model. 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.

The first layer is structural: which of the three Alignment Processes are genuinely institutionalised?

Stage Zero is no architecture. No architects, no artefacts, no governance. The starting point.

Stage One is Initiative Alignment. Business Outlines and IT Designs are produced for significant initiatives. The Investment Forum and Design Forum are meeting. Project delivery quality has measurably improved. Strategic Alignment and Technology Alignment are absent or rudimentary.

Stage Two adds Technology Alignment. IT Standards are established and maintained. IT Landscapes are current and trusted. The Technology Forum is meeting. The IT landscape is being actively managed, not just documented. Architecture debt is being recorded and addressed. Strategic Alignment may exist in nascent form but is not yet reliable.

Stage Three adds Strategic Alignment. Business Factors and Business Visions are established and maintained. The Strategy Forum is meeting with genuine business executive participation. IT investment decisions are shaped by explicitly agreed capability priorities. The investment portfolio reflects strategic intent rather than accumulated bottom-up demand.

Most organisations in large industry sectors sit somewhere between Stage One and Stage Two. The transition from Stage Two to Stage Three — the addition of genuine Strategic Alignment — is the most culturally demanding step, because it requires business executives to engage deeply with IT planning in a way that most have not done before. It cannot be mandated into existence. It has to be earned.

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

Do you understand what IT is doing?

Do you understand how IT contributes to the achievement of your business goals?

Do you understand where and on what particular initiatives your IT budget is being spent?

Do you understand how IT is transforming your business?

Do you understand what business value IT is delivering to your organisation?

If these questions receive consistent positive answers from the executive-level business audience, the architecture practice is fulfilling its purpose. It is creating the shared understanding between business and IT that reduces misalignment and improves investment quality.

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. The practice is not working.

This test is uncomfortable to apply honestly. Most architecture teams that I encounter have not asked these questions — or have asked them and not acted on the answers. There is a natural incentive to measure what looks good: artefact production, governance completeness, technical standards coverage. These things are within the architecture team's control. Business executive understanding is not within their direct control — it depends on relationships, on communication quality, on the track record of delivery, on organisational culture. It is harder to influence and harder to measure. It is also the only measurement that matters.

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

Final article: where AMBIT is going — and what an evolving, evidence-based framework looks like.

JD Garing | HighGrain EA Consultants | jd@highgrain.co AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research

──────────────────────────────────────────────────

Where AMBIT goes from here (On building a framework that stays honest about what it doesn't know) ────────────────────────────────────────────────── Series: Enterprise Architecting | Part 20 of 20

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.

This is what it actually means to take an empirical basis seriously. Not citing the research once to establish credibility and then treating the framework as settled. Staying in genuine relationship with it.

There are things 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. These are real challenges in real organisations, and the current framework's answers to them are incomplete.

I also want to name the limits of what a framework can 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.

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.

AMBIT Version 3.0 · A practitioner interpretation of Kotusev's empirical EA research Grounded in: Kotusev (2019) The Practice of Enterprise Architecture; Kotusev (2023) Enterprise Architects: The Agents of Digital Transformation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PUBLISHING NOTES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Suggested cadence: one article per week (20-week programme) Suggested hashtags per article: #EnterpriseArchitecture #AMBIT #CIO #ITStrategy Series hashtag to include every article: #EnterpriseArchitecting

Cross-references: each article closes with "Next article:" — this can optionally be replaced with a live link once subsequent articles are published.

Kotusev attribution: named explicitly in Article 3 (the AMBIT reveal); thereafter referred to as "the research" or "the empirical evidence" per the editorial strategy. Never more than once per article.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF SERIES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━