Architecture without a vision is not neutral. It defaults to the accumulated preferences of whoever built the estate, in the order they built it. The result is an architecture that describes the past accurately and says nothing about the future. Organisations reach for enterprise architecture precisely when this becomes untenable: when the cost of change has risen to the point where every new initiative spends most of its budget navigating the consequences of decisions no one remembers making.

What makes the vision matter now, more than a decade ago, is the shift in how technology is delivered. When most capability was bought as large monolithic systems and changed on multi-year cycles, direction could be set implicitly through a handful of vendor commitments. A choice of ERP was a choice of architecture for ten years. That world is gone. Capability now arrives as a stream of platform services, composable products and third-party APIs, each acquired and changed on its own cadence, often by teams with real delegated authority and their own budgets. The pace of local decision making has increased by an order of magnitude, and the mechanisms that once held it together have not.

This is the real problem the architecture vision addresses. It is not primarily about drawing the right target state diagram. It is about creating enough shared intent that decentralised, fast-moving teams can act autonomously and still converge. A vision that lives only in a document changes nothing. A vision that shapes what people reach for by default, what they consider obviously right and obviously wrong, is worth more than any control gate. The question is not whether an organisation has an architecture. It always has one. The question is whether that architecture is the residue of a thousand disconnected choices or the expression of a direction someone chose deliberately.

An architecture vision is not a single artefact. It is a small, connected set of statements that together answer a specific question: given where the business intends to go, what must the technology landscape become, and what must be true of every decision made along the way. Four elements do the work, and they are frequently confused with one another.

The first is the target architecture: a description of the future state at a deliberately coarse grain. Its job is not precision. It is to make the destination legible enough that people can tell whether a proposal moves towards it or away from it. A good target architecture is expressed in terms of capabilities and their relationships, not products and their versions, because products change faster than the vision should. The second element is the set of architecture principles: durable statements of preference that resolve recurring trade-offs before they are argued case by case. A principle such as buy configurable capability rather than build bespoke, or integrate through published contracts rather than shared databases, does not decide any single case but it settles the direction of hundreds.

The third element is the vision statement itself: the compressed articulation of why the target looks the way it does, tied explicitly to business outcomes. This is what survives when the diagrams are out of date. The fourth is the architecture strategy: the sequenced logic of how the organisation moves from where it is to where it intends to be, including what it will deliberately not do, and in what order the dependencies must fall. A vision without a strategy is aspiration. A strategy without a vision is a project plan with no idea what it is building towards. The discipline is in keeping the four distinct and mutually consistent, because each answers a different question and each fails differently when it is missing.

The traditional model of architecture vision was episodic and centralised. A team would spend a quarter producing a target state, ratify it in a steering committee, publish it and then defend it against erosion for as long as it lasted. This worked when the environment changed slowly enough that a vision set once a year could stay roughly true. It no longer describes how leading practices operate, and the change is worth understanding because it alters what the vision is for.

The clearest shift is from target state as blueprint to direction as a durable set of constraints and intents. When the specific future cannot be predicted with confidence, fixing it in detail is not rigour, it is false precision. The more useful vision describes the invariants: the properties the landscape must preserve regardless of which specific technologies win, the boundaries that must not be crossed, the capabilities that must remain replaceable. This is a genuine intellectual move away from prediction towards optionality, and it is harder to do well because it requires distinguishing what is essential from what is merely current.

A second development is the pull of platform thinking and product operating models. As organisations reorganise delivery around long-lived product teams and internal platforms, the architecture vision has to speak to team boundaries and ownership, not only to system boundaries. Where a capability lives is now inseparable from who owns it and how they are funded. A third is the arrival of generative and agentic technology, which is forcing many organisations to revisit principles they thought were settled: how data is exposed, where decisions are automated, what remains under human control. A vision written before this shift often has a conspicuous silence at its centre, and filling that silence deliberately, rather than letting each team improvise, is now part of the work. The common thread is that the vision is becoming less a snapshot and more a living stance, revised deliberately, held with conviction, and expected to move.

A vision guides only if it is constructed to be usable at the point of decision, by people who will never read the full document. Several design principles separate a vision that shapes behaviour from one that decorates a wiki.

The first is subtractive clarity. A vision that tries to say everything says nothing that can be acted on. The most valuable statements are the ones that rule things out. If a principle cannot be violated, it is not a principle, it is an observation. Every genuine principle has a cost: it forecloses something that someone, somewhere, would otherwise reasonably choose. Naming that cost openly is what gives the principle authority. The second is the right altitude. Direction set too high becomes platitude that no decision can contradict. Set too low it becomes a design that is obsolete before it is ratified and that removes the judgement the vision was meant to inform. The skill is finding the grain at which the statement is both stable over time and consequential in practice.

The third principle is explicit traceability to business intent. Every architectural statement should be answerable to the question of which business outcome it serves, and when that link cannot be drawn the statement should be treated with suspicion. This is what protects the vision from becoming a vehicle for technical preference dressed as strategy. The fourth is designed obsolescence: the vision must carry within it the conditions under which it should change. A direction that cannot be questioned cannot be trusted, because the world it responded to will move. The strongest visions state not only what they assert but what would have to be true for the assertion to be wrong. That is what allows a vision to be held firmly and revised honestly, which is the combination the discipline actually requires.

The failure modes of architecture vision are consistent across organisations and worth naming, because most are avoidable once seen clearly.

The shelf vision. A target state is produced, approved, admired and then ignored. It fails not because it is wrong but because it never entered the flow of decisions. It was an artefact rather than an input. The tell is that no one can point to a recent decision the vision changed. The disconnected vision. The architecture direction is set without genuine engagement with business strategy, often because the two functions do not meet often enough or speak the same language. The result is technically coherent and strategically irrelevant, optimising for properties the business never asked for. The precision trap. The vision is specified in such detail that it is simultaneously always out of date and impossible to argue with, so teams route around it and the architecture function becomes a source of delay rather than direction.

The consensus vision. In an effort to gain buy-in, every stakeholder's preference is accommodated until the vision rules nothing out and therefore guides nothing. It reads well and decides nothing, because a direction that offends no one points nowhere. The frozen vision. A direction set with real conviction is then defended past the point where the assumptions behind it have changed, turning a north star into an anchor. The organisation mistakes consistency for coherence. The orphaned vision. The vision exists and is sound but has no owner with the standing to keep it current and to invoke it when decisions are being made, so it decays quietly into folklore. Underlying most of these is a single error: treating the vision as a deliverable to be completed rather than a position to be maintained. The vision is not finished when it is written. It is finished when the organisation stops making decisions, which is to say never.

Nashua treats the architecture vision as a working instrument, not a documentation exercise. The engagement begins with business strategy rather than with the technology estate, because a vision derived from the current landscape can only ever rationalise it. We work with leadership to make the strategic intent explicit and testable: not the mission statement, but the specific bets the organisation is making, the capabilities those bets depend on, and the properties the technology landscape must have to support them. Much of the early value is in surfacing strategic assumptions that were never written down, because a vision cannot be traceable to intent that no one has articulated.

From there we construct the vision as the connected set described earlier: a coarse-grained target architecture expressed in capabilities, a deliberately small body of principles each carrying its stated cost, a vision statement tied to outcomes, and an architecture strategy that sequences the movement and names what will not be done. We work in the open with the teams who will live under the vision, because a direction imposed without their engagement will be routed around regardless of how sound it is. The aim is not consensus, which dissolves direction, but comprehension: teams do not have to prefer every principle, but they must understand what it rules out and why.

Crucially, we design the vision to be operable. That means defining who owns it, how it is invoked at the moments decisions are actually made, and what evidence would trigger its revision. We help establish the light governance that keeps the vision present in decision making without turning architecture into a bottleneck, and we build the organisation's own capacity to maintain the vision rather than leaving behind a document that decays the moment we do. The measure of the work is not the quality of the diagrams. It is whether, a year later, the organisation's local decisions are visibly more coherent than they were, and whether the people making them can say what direction they are serving.

What separates a durable architecture vision from an expensive one is whether it continues to shape decisions long after the engagement ends. This is where Nashua concentrates its effort. We are not interested in leaving behind a target state that impresses in a boardroom and is forgotten in delivery. We are interested in the harder and less visible outcome: an organisation whose thousand local decisions bend towards the same direction because the people making them share a north star they understand and trust. That requires combining genuine architectural depth with an honest reading of how the organisation actually decides things, and building the vision to work with that reality rather than against it.

There is also a practical corollary that changes what the work is permitted to assume. When an engagement calls for a capability that does not yet exist, it need not wait on a procurement cycle or a vendor's roadmap. The Nashua 360 Enterprise Platform is built to accommodate almost any feature at pace, through extreme vibe coding: what is needed is described in plain language and generated quickly, but always within firm architecture principles and under stringent quality assurance, so that speed never comes at the cost of coherence, security or control. The effect is strategic rather than merely convenient. It moves the make-or-buy line, keeps optionality cheap, and lets the architecture follow the strategy rather than the strategy bending to whatever happened to be on a shelf.

Our advantage is that we hold two things at once that are usually held apart. We take the intellectual work of the vision seriously: the distinctions between target, principle, statement and strategy, the discipline of the right altitude, the traceability to business intent, the designed obsolescence that lets a direction be both firm and revisable. And we take equally seriously the unglamorous mechanics of adoption: ownership, invocation, the moment of decision, the evidence that should trigger a rethink. A vision that is intellectually excellent and operationally orphaned fails exactly as surely as one that is politically convenient and strategically empty. Nashua's practitioners have set direction across complex Dutch and international estates, and what they bring is not a template but judgement: the ability to tell, in a specific organisation, what must be fixed and what must be left open, what to rule out and what cost that will carry. That judgement, embedded in the organisation and not merely delivered to it, is where an architecture vision stops being a document and becomes the thing that keeps everything else coherent.