Enterprise Architecture

Architecture that helps an organisation make better decisions — and keeps doing so as conditions change.

On this page
  1. Top of page
  2. The shape of the work
  3. Common questions from clients
  4. What you walk away with
  5. Patterns we design our practice to avoid
  6. Evidence & references
  7. What to read next

§ 01 ·

When it stops being useful, it usually stops being architecture and starts being a diagram.

The work is at the boundary between strategy and delivery: the place where decisions move from intent to implementation, and where most large programmes quietly succeed or quietly fail. The four phases the firm uses to do this work are on the How we work page.

§ 02 ·

The shape of the work

Numbers from the firm's own engagements over the last several years. Every number has a basis: `engagement data` (measured from real engagements), `design heuristic` (a working target the firm uses to plan), or `target` (a posture the practice is designed to maintain).

12–18
months is the typical horizon for a target architecture to become operational
basis: engagement data
4–7
forums with architectural authority is what a well-designed governance loop contains
basis: design heuristic
≥1
live, tested interface contract per service boundary in the target architecture
basis: design heuristic
0
decisions routed through the central forum that should be made by delivery teams
basis: target

§ 03 ·

Common questions from clients

The questions we hear most often, in the order they tend to come up.

A capability map describes what the organisation needs to be able to do, expressed independently of how it is done today. It is stable across reorganisations, leadership changes, and platform decisions.

A target architecture describes how those capabilities will be delivered: the platforms, patterns, and ownership boundaries that will carry them. It is specific, dated to the version of the system it describes, and revisable when the evidence changes.

In practice the map comes first and constrains the target. A target architecture written against a fuzzy capability list becomes a guess about which platforms serve which outcomes.

Most architecture engagements run between six and eighteen months. The framing phase (the capability map) is six to twelve weeks; the target architecture and governance-loop work is the bulk of the early engagement; the migration is sized to the number of moves; the operating-model work is ongoing. The total horizon is set in the framing session.

Engagements are priced against the capability map produced in the framing phase. The cost depends on the breadth of the architecture, the depth of the target, the size of the migration, and the operating model the work needs. A typical range for a multi-phase engagement sits in the low-to-mid six figures; the final figure is set in the scoping call after the framing phase.

The first 30 days are the framing phase: interviews with leadership and front-line practitioners, an inventory of the capabilities the organisation actually has, and the production of the capability map organised by business outcome. By the end of the first 30 days, the client has a few pages that scopes the rest of the engagement.

By making the easy path the right path. Our governance is a set of lightweight forums with narrow authority that review significant decisions, not routine ones. Most decisions are handled by paved roads, golden templates, and default patterns: the architecture practice does the hard work up front so delivery teams do not have to revisit the same questions.

A forum that sees every decision is a symptom of unclear contracts, not a solution to them.

§ 04 ·

What each phase produces in an architecture context is on the How we work page.

What you walk away with

A flat list of the artefacts an enterprise architecture engagement produces. The full shape of the engagement is on the [How we work](/services/methodology/) page.

A capability map organised by business outcome

A stable capability taxonomy, a maturity rating per capability, and an investment-prioritisation lens that distinguishes core, supporting, and generic capabilities. The artefact is small: a few pages. The conversations behind it are where the value is created.

A target architecture as a reference model

Names the integration patterns, the ownership boundaries, the data contracts, and the small set of platform decisions settled at the enterprise level. Deliberately does not specify every component.

A migration plan as a sequence of moves

Each move has an entry criterion, an exit condition, a rollback path, and an explicit dependency on the previous move. The plan is complete when the prior system is decommissioned and the contracts are stable.

Operating-model documents

A review cadence, a decision-record template, a paved-road pattern library, and clear escalation paths. Names what the operating model explicitly does not do.

A decision record per significant architectural decision

A short, durable document that records the decision, the assumption that proved correct, and the conditions under which the decision will be revisited. The decision record is what lets the architecture be revised cleanly when the evidence changes.

§ 06 ·

Patterns we design our practice to avoid

Six failure modes we have seen repeatedly, across architecture engagements of every size. Each one motivates a specific choice in how we work.

The map is a means of conversation, not an end. If leadership cannot make a faster decision because the map exists, it has become a poster.

Without a stable capability taxonomy, every platform decision becomes a guess about which outcome it serves. The guess is corrected, and the architecture is reworked.

A list implies parallelism. Architecture migrations are sequential by nature: each move depends on the previous one. A project list lets a portfolio schedule work in parallel that cannot actually run in parallel.

The architectural equivalent of code review for every commit. The forum becomes a bottleneck, loses credibility, and is eventually routed around.

An unverifiable contract is a wish. Without conformance tests, the contract drifts the first time the implementation hits a deadline.

The dangerous period is the parallel run. Until the prior system is decommissioned and the contracts are stable, the migration is not complete — and pressure will push users back to the old system.

The best architecture work I have seen looks boring from the outside. The capability map fits on a page. The migration plan is a sequence with explicit dependencies. The governance forum is small. The contracts are tested. Nothing about it is exciting. And that is how you know it is working.

Client CTO, after an eighteen-month architecture engagement

§ 08 ·

Evidence & references

Public frameworks and writing that inform the firm's practice.

Domain-Driven Design
Eric Evans, Addison-Wesley, 2003

The capability map is, in practice, a bounded-context map. The strategic classification — core, supporting, generic — is the investment-prioritisation lens we use.

Building Evolutionary Architectures
Neal Ford, Rebecca Parsons & Patrick Kua, O'Reilly, 2017

The architectural fitness functions concept (automatic, continuous tests of architectural properties) is the reference for the firm's work on contracts that survive contact with delivery.

Team Topologies
Matthew Skelton & Manuel Pais, IT Revolution Press, 2019

The four team types and three interaction modes map cleanly onto our governance-loop design. We treat it as the operating-model sibling of the architecture work.

Data Mesh
Zhamak Dehghani, O'Reilly, 2022

Domain ownership, data as a product, self-serve platform, and federated governance: the data-architecture reference we lean on most often.

§ 09 ·

What to read next

The shape of the engagement, and the services the architecture work most often sits next to.

Want to talk architecture?

If you are weighing a major platform decision, navigating an organisational change that will reshape ownership, or strengthening an existing architecture practice, the firm is useful at that boundary. A short conversation is the right next step.

Start a conversation
© NOETRONIQ Contact