The defining condition of the modern enterprise landscape is that no single person can describe it accurately. A decade ago the boundary of IT was reasonably firm: procurement, a data centre, a licence agreement and a project methodology together kept most technology inside a knowable perimeter. That perimeter has dissolved. Software as a service can be adopted on a corporate card without any central approval. Cloud platforms let a single engineer stand up infrastructure in minutes. Business units, under pressure to move quickly, buy capability directly from vendors who are only too happy to sell around the IT function. Each of these decisions is locally rational. In aggregate they produce sprawl.

The consequences are measurable and they compound. Overlapping systems duplicate licence spend and support effort. Integration surface area grows faster than the value being integrated, because every new tool must be wired to the systems of record. Data fragments across instances that no longer agree with one another, so reporting becomes an exercise in reconciliation rather than insight. Security and compliance exposure widens with every unmanaged endpoint and every forgotten administrator account. And the human cost is real: skilled people spend their time maintaining variety instead of building capability.

What makes this matter now, rather than as a perennial complaint, is the changed economics of technology. When the majority of spend was capital, sprawl was slow and visible on a balance sheet. When spend is consumption based and subscription based, sprawl is fast, continuous and easy to miss. A dormant cloud environment still bills. A rarely used application still renews. The IT landscape no longer waits for a budget cycle to grow, which means governance can no longer operate on a budget cycle either. It has to become a continuous function, and consolidation has to become an ongoing programme rather than a one off tidy up.

The first principle of governance is unglamorous but decisive: governance is not primarily about technology, it is about who gets to decide what, and on what basis. Before an organisation can rationalise its IT landscape, it has to be honest about how choices are actually made. In most firms the real decision rights are implicit, contested and inconsistent. One category of spend is tightly controlled while another, larger one flows freely. A central architecture group has authority on paper that it cannot exercise in practice. Making these rights explicit is the foundational act of governance, and it is worth more than any tooling.

A workable model distinguishes a small number of decision types and assigns each to a clear owner. Principles and standards, the durable rules that shape everything else, belong to a central authority with senior sponsorship. Investment decisions, which capabilities to fund and which to starve, belong to a portfolio body that can see across the whole landscape rather than one project at a time. Design decisions within an approved standard belong to the delivery teams closest to the work, because pushing them upward only creates bottlenecks. The art lies in drawing these lines so that the centre governs the few things that must be consistent and delegates the many that need not be.

Portfolio management is the instrument that turns decision rights into outcomes. Rather than treating each system as an isolated asset, portfolio thinking asks a comparative question across the whole landscape: what does this capability cost, what value does it deliver, what risk does it carry, and how does it overlap with everything else that does something similar. From that view a lifecycle disposition follows for every application. Invest, because it is strategic and healthy. Tolerate, because it works and replacement is not yet justified. Migrate, because a better standard exists. Or retire, because it is redundant, obsolete or unsupported. Governance that cannot produce this disposition for its IT landscape is not yet governance. It is administration.

Governance has a reputation, often deserved, for being a bureaucratic residue: steering committees, architecture review boards and lengthy documents that delivery teams learn to route around. The significant development of recent years is that the discipline has been reshaped by the operating models that surround it, and the best practice now looks materially different from the classical picture.

The most important shift is the move from project funding to product funding. When technology was funded as projects, governance was episodic: a business case was scrutinised at the start, then the initiative disappeared into delivery and reappeared only when it overran. Persistent product teams, funded to own a capability over its life, change the governance question from should we approve this project to is this product still earning its place in the portfolio. That is a far more useful question for consolidation, because it forces a continuous judgement about relevance rather than a one time approval that no one revisits.

Alongside this, cost transparency has become a formal practice. Technology business management and the FinOps movement have given organisations a shared vocabulary for attributing technology cost to business services, so that a conversation about consolidation can be grounded in numbers rather than assertion. The rise of platform engineering matters too: internal platform teams that offer paved, self-service paths make it easier for delivery teams to do the standard thing than to invent their own, which is the only sustainable way to enforce standards at scale. And the regulatory backdrop, from data protection to operational resilience obligations, has raised the price of an unmanaged landscape, turning governance from a discretionary good into an accountable duty. The common thread is that governance is increasingly embedded in how work flows, rather than layered on top of it as an inspection.

The architecture of good governance rests on a single distinction: the difference between a guardrail and a gate. A gate stops work until someone approves it, and gates accumulate until delivery slows to the speed of the slowest committee. A guardrail constrains the shape of a decision while letting the decision itself proceed without waiting. Governance that scales is built almost entirely from guardrails, with gates reserved for the genuinely irreversible or high consequence choices. The design goal is not to review more, it is to make the right choice the path of least resistance and the wrong choice visibly effortful.

This is achieved through a small, deliberately curated set of standards rather than an exhaustive catalogue. A reference architecture describes the approved patterns for common problems, so that teams compose from known good building blocks instead of designing from first principles every time. A technology standard names the preferred products in each category and, just as importantly, names those that are being retired, so that the direction of travel is unambiguous. Golden paths, the paved self-service routes provided by platform teams, embed these standards in tooling so that following the standard is the fastest way to ship. Standards held only in documents are aspirations. Standards embedded in the path of delivery are governance.

Consolidation applies the same design thinking to reduction. A rationalisation follows a disciplined sequence. First, discover the IT landscape as it truly is, because you cannot consolidate what you cannot see, and shadow systems are exactly the ones that discovery must surface. Second, assess each application against a consistent frame of business value, technical health and total cost, so that comparisons are fair. Third, decide a target state: which system in each overlapping cluster survives, and what the others migrate to. Fourth, and this is the step organisations most often omit, actually decommission, which means migrating data, redirecting integrations, revoking access, cancelling licences and confirming that nothing depends on what has been switched off. Retirement is where the savings live, and it is the hardest, least celebrated part of the work.

Governance and consolidation fail in recognisable ways, and naming the patterns is the first defence against them.

Governance as obstruction. The most common failure is the review board that adds latency without improving decisions. When every change queues for a committee that meets fortnightly, teams learn to avoid governance entirely, and the IT landscape they build unsupervised is precisely the one governance existed to prevent. Governance that is felt as friction will be routed around, and a bypassed control is worse than no control because it creates a false sense of oversight.

Standards without adoption. A reference architecture that no team follows is not a standard, it is a wish. This happens whenever standards are written by a central group in isolation from delivery, imposed rather than paved, and never made easier to follow than to ignore. The remedy is not enforcement but attraction: the standard has to be the more convenient option.

Rationalisation that stops at analysis. Many consolidation programmes produce an elegant application inventory, a heat map of redundancy and a target state deck, and then stall. The systems marked for retirement keep running because decommissioning is genuinely difficult and rarely funded. Analysis without decommissioning delivers no saving at all. It merely documents the problem.

The undead application. Related to the above, systems are switched off nominally but never truly retired: the server stays up in case someone needs it, the licence renews by default, the integration remains live. The IT landscape carries the cost of the old and the new at once. Real retirement requires the discipline to confirm nothing depends on a system and then remove it decisively.

Consolidating to a worse standard. Sometimes the surviving system in a rationalisation is chosen for political rather than technical reasons, and the organisation spends heavily to migrate onto a platform that is not actually the best of the set. Consolidation reduces count but degrades capability. The decision of which system survives deserves as much rigour as the decision to consolidate at all.

Governing everything equally. When the same heavyweight process applies to a trivial change and a strategic one, the trivial changes overwhelm the process and the strategic ones get too little attention. Proportionality, matching the weight of governance to the consequence of the decision, is what keeps a governance function credible and fast.

Nashua treats governance and consolidation as an operating capability to be built, not a report to be delivered. The engagement begins with an honest picture of the IT landscape and the way decisions are actually made within it, because both are usually less orderly than the official version suggests. We combine automated discovery of applications, infrastructure and spend with structured conversations across IT and the business, so that the shadow landscape and the informal decision rights come into view alongside the documented ones. The output is not merely an inventory. It is a portfolio view in which every significant application carries a value, a cost, a risk and a clear disposition.

From there the work is deliberately sequenced so that value arrives early and the organisation is not asked to swallow a multi year programme on faith. We identify the overlapping clusters where consolidation pays back quickly, and we establish the governance mechanisms in parallel: the decision rights model, the small set of standards that will hold, and the lightweight forums that make proportional decisions at the speed delivery needs. Crucially, we design governance as guardrails embedded in how teams already work, so that it enables delivery rather than queuing in front of it. We plan retirement as a first class activity, with the data migration, integration rework and licence exit treated as funded work rather than an afterthought, because that is where the promised savings are actually realised.

Throughout, Nashua works as a practitioner alongside the client's own people rather than as a detached adviser. Standards that the organisation's teams have helped shape are standards they will adopt. A portfolio the organisation can maintain after we leave is worth more than a perfect snapshot it cannot keep current. Our aim is to leave behind a governance function that is proportionate, a portfolio that is live, and an IT landscape that is measurably smaller and more coherent than the one we found.

The difference Nashua makes is the transition from a single consolidation exercise to a durable capability that keeps sprawl from returning. Any competent firm can produce an application rationalisation once. The harder and more valuable outcome is an organisation that governs its own decisions well enough that the IT landscape stays coherent, that retires systems as a matter of routine rather than as a rare campaign, and that experiences governance as an accelerant rather than a tax. That is the outcome we build towards, and it depends as much on the operating model and the people as on any assessment.

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 this together is Nashua's stance as an enterprise technology and consulting firm that stays engaged through delivery and beyond. We are not interested in a governance framework that looks impressive in a document and dies on contact with the pace of real delivery, nor in a consolidation plan whose savings never leave the spreadsheet. We measure our success in the concrete terms that matter to the business: fewer redundant systems, lower recurring cost, reduced integration and security surface, faster and clearer decisions, and a portfolio the organisation can steer for itself long after the engagement ends. Deciding well about technology and taming the sprawl that poor decisions create is not a project with an end date. It is a capability, and helping our clients own it is where Nashua makes the difference.