For two decades the constraining factor in enterprise technology was delivery. Building systems was slow, expensive and risky, so the organisations that could execute reliably held an advantage. That constraint has largely dissolved. Cloud platforms, managed services, low-code tooling and a mature software-as-a-service market mean that almost any capability can be stood up quickly by almost any team with a budget. Delivery is no longer the bottleneck. Coherence is.

The consequence is an IT landscape that grows faster than anyone's ability to reason about it. Business units procure their own platforms, integration accumulates as a web of point-to-point connections, and the same customer or product data is mastered in four places with four subtly different definitions. Each individual decision was defensible. The aggregate is an organisation that cannot say with confidence what it owns, what those systems cost to run, or whether the whole is moving toward its stated ambitions or away from them.

This is why IT strategy and architecture has moved from a back-office planning function to a board-level concern. Regulatory regimes now expect institutions to demonstrate control over their technology landscape and their operational resilience. Investment cases increasingly hinge on whether a proposed change fits a coherent direction or adds another exception to an already tangled landscape. The scarce resource is no longer the ability to build. It is a credible, shared answer to the question of what should be built, what should be retired, and in what order. Setting that direction, and defending it against the constant pressure of local optimisation, is the work.

The foundational move in this discipline is to separate what the business does from how it currently does it. A business capability is a stable, technology-neutral statement of an ability the organisation must possess: settle a claim, onboard a customer, forecast demand, reconcile a ledger. Capabilities change slowly because they describe the essence of the enterprise. The applications, processes and infrastructure that realise them change constantly. Anchoring planning to capabilities rather than systems gives strategy a coordinate system that survives reorganisations, vendor changes and technology cycles.

A capability model is deliberately hierarchical and deliberately boring. At the top sit a few dozen level-one capabilities that any peer in the sector would recognise. Beneath them, two or three further levels of decomposition reach the granularity at which investment and ownership decisions are actually made. The value of the model is not the taxonomy itself but what can be layered onto it. Each capability can be assessed for business importance, for the health and cost of the systems that support it, and for the strategic ambition attached to it. The result is a heat map that turns an unmanageable landscape into a small number of prioritised conversations.

This reframing changes the questions leadership asks. Instead of debating whether to renew a particular platform, the discussion becomes which capabilities are strategically differentiating and therefore deserve bespoke investment, which are necessary but undifferentiated and therefore candidates for standard packages, and which are declining and should be starved. Build versus buy stops being a procurement reflex and becomes a consequence of where a capability sits on that spectrum. Roadmaps stop being lists of projects and become sequenced movements of named capabilities from a current state to a target state. The capability is what lets strategy and architecture speak the same language, and it is what keeps both tethered to the business rather than to the technology of the moment.

The discipline is being reshaped by several forces at once, and it is worth separating durable shifts from fashion. The most consequential is the move from architecture as documentation to architecture as a living model. For years the target architecture lived in slide decks and static repositories that were obsolete the day they were signed off. Modern practice treats the architecture as data: capabilities, applications, data flows, technologies and their relationships held in a queryable model that can be kept current and interrogated. This is what makes it possible to answer, in an afternoon rather than a quarter, which systems would be affected by retiring a platform or which capabilities depend on a technology reaching end of support.

The second shift is the erosion of the boundary between strategy and continuous delivery. When technology was released annually, a multi-year plan and an annual review were adequate. When teams deploy continuously, a static three-year plan is a liability. The contemporary answer is not to abandon direction but to hold a stable target lightly and revise the path to it frequently. Direction is set for years; the roadmap toward it is revisited every quarter against what has actually shipped and what the IT landscape now looks like.

The third force is the pressure that machine learning and generative systems place on planning. There is genuine substance here, but it arrives wrapped in noise. The disciplined response is to treat these as capabilities to be located in the model like any other, with honest assessment of which are differentiating and which are commodity, rather than as a mandate to rebuild everything. Alongside this, sovereignty, data residency and resilience requirements are pulling some organisations back toward deliberate hybrid and on-premise choices after a decade of unconditional cloud migration. The mature posture is not cloud-first or cloud-only but placement decided per capability against cost, control and regulatory constraints. In each of these trends the constant is the same: the organisations that cope are those with a model to reason against, and those without one lurch from vendor pitch to vendor pitch.

A target architecture is only useful if it is built to survive contact with reality. The first principle is explicit separation of concerns across layers. Business capabilities, the applications that realise them, the data those applications steward, and the technology they run on should be modelled distinctly and connected by clear relationships. When these layers are conflated, a change in one propagates unpredictably into the others, and no one can trace the blast radius of a decision. Kept distinct, the architecture becomes navigable: one can move from a strategic capability down to the specific technology that constrains it.

The second principle is that architecture principles must be few, specific and consequential. A principle such as buy for undifferentiated capabilities, build only where we differentiate is useful because it decides real cases and rules things out. A principle such as we will be agile and customer-centric decides nothing. Good principles are written with a rationale and, crucially, with their implications spelled out, so that when a project proposes an exception the cost of that exception is visible. Principles that cannot be violated are not principles; they are aspirations. The discipline lies in naming the trade-off each one imposes.

The third principle is designing for replaceability rather than permanence. No component in the IT landscape is forever, so the architecture should minimise the cost of removing any one of them. This favours well-defined interfaces over deep integration, standard data definitions over system-specific ones, and loose coupling at the seams where organisational or vendor boundaries fall. Reference models earn their place here: a shared reference architecture for integration, for data, or for a common domain gives teams a sanctioned pattern to follow, which reduces the number of bespoke decisions and therefore the number of future liabilities. The aim is not a perfect end state, which never arrives, but an IT landscape whose parts can be exchanged without each swap becoming an excavation.

The failure modes in this discipline are consistent enough to name. The ivory tower. An architecture function withdraws to produce elegant target-state models that delivery teams neither understand nor obey. The documents are internally coherent and practically inert. The remedy is not better diagrams but embedding architects in the flow of real decisions, where their models are tested against actual projects and kept current by that friction.

ize

Strategy and landscape drift apart. A direction is set with conviction, then the organisation stops checking whether the IT landscape is actually moving toward it. Projects deliver, exceptions accumulate, and three years later the real landscape bears little resemblance to the target no one revisited. This is the most common and most corrosive failure, because each individual deviation was reasonable. Preventing it requires a governance rhythm that compares intent to reality on a fixed cadence and treats the delta as the primary management signal.

Build-versus-buy by reflex. Decisions default to whatever the organisation culturally prefers, building everything because it can, or buying everything to avoid engineering, rather than deciding case by case against where the capability sits strategically. The result is bespoke systems for commodity functions or packaged constraints on the very capabilities that should differentiate. Roadmaps as project lists. A roadmap that enumerates funded projects rather than sequenced capability movements optimises for what is already approved and loses the thread of where the organisation is trying to arrive. Boiling the ocean. An attempt to model the entire landscape to uniform depth before deciding anything, which produces an enormous artefact and no decisions. The discipline is to model to the depth a decision requires and no further, then move. Each of these failures shares a root: the connective tissue between business intent and technical reality is allowed to snap.

Nashua treats IT strategy and architecture as a continuous practice rather than a one-off engagement that ends with a deliverable. The work usually begins by establishing the coordinate system: a capability model that reflects how this organisation actually operates, assessed for business importance, system health and cost. That assessment is deliberately evidence-led. Rather than accept an idealised org chart, Nashua examines the real IT landscape: what applications exist, what they cost, how they integrate, and which capabilities they genuinely support. The heat map that emerges is usually uncomfortable and always clarifying, because it makes the gap between intent and reality visible for the first time.

From that baseline the direction is set as a target architecture expressed in the same capability language, accompanied by a small set of architecture principles written with their trade-offs made explicit. Nashua's preference is for principles that decide cases and reference models that give teams sanctioned patterns, so that the architecture reduces the number of open questions rather than adding a layer of review. Build-versus-buy and cloud-versus-on-premise decisions are framed per capability, against its strategic weight and its regulatory and cost constraints, not as blanket policy.

The roadmap that follows is sequenced as capability movements from current to target state, with the dependencies and the retirements made as visible as the new investments, because the systems an organisation switches off matter as much as the ones it builds. Crucially, Nashua institutes the governance rhythm that keeps strategy and landscape from drifting: a regular comparison of where the IT landscape actually is against where the target says it should be, with the delta treated as the signal that drives the next decisions. This is unglamorous and it is the part most often skipped, which is precisely why it is where the value accumulates. Nashua's role is to hold the direction steady while the path to it is revised against what the organisation has actually delivered.

The difference Nashua brings is less any single artefact and more the discipline of keeping intent and reality connected over time. Many firms can produce a target architecture; far fewer will still be governing against it two years later, when the pressure of local optimisation has had time to work. Nashua's practitioners have sat on both sides of the table, setting strategy and then living with the IT landscape that results, and that experience shows in advice that is specific rather than generic and in principles that survive the first difficult project rather than the first quiet week. The measure of the work is not the elegance of the model but whether, years on, the organisation can still say with confidence where it is going and how far along it is.

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.

What ties it together is a refusal to let the discipline become theatre. Strategy and architecture only earn their keep when they change what gets built, what gets bought, and what gets switched off, and when they keep doing so as the business and its technology move underneath them. Nashua's contribution is to make that connection durable: a shared statement of direction, expressed in capabilities the business recognises, kept honest against the real IT landscape on a cadence that does not lapse. That is what stops a technology landscape from drifting away from the organisation it is supposed to serve, and it is where a considered partner is worth more than any diagram.