Architectural Cohesion

I have inherited websites that looked finished and performed well, yet became difficult to change within a few years. Routine updates required increasingly elaborate checks in a separate testing environment. Adding a feature meant testing several other features that appeared unrelated. Testing was necessary; the growing reach of each change was the concern. Eventually, the cost of an improvement was determined less by the work itself than by the number of places it could cause trouble.

That pattern is easy to miss during a platform comparison. Feature lists describe what a system can do. Market share describes how widely it is used. Benchmarks describe performance under selected conditions. None of them tells us how much coordination an ordinary change will require after years of updates, replacements, staff turnover, and new requests.

Architectural cohesion offers a different measure. It asks whether the parts of a system have clear responsibilities, dependable connections, and a manageable way to change together. The issue is not how many parts exist. It is how a change in one part affects the others, and how much checking is needed before the result can be trusted.

A Boundary That Outlived Its Purpose

GOV.UK provides a useful example because its team documented both the reason for an architectural decision and the reason it was later removed.

The public website is served by eight applications. When GOV.UK was being built in 2011, a separate application called Static, together with a tool called Slimmer, gave pages from those applications a common header and footer. Static later carried shared styles, scripts, and site-wide features such as emergency banners. The arrangement reduced duplication and helped separate applications present one consistent website.

It was a reasonable solution to a real problem. It also became part of every public page.

Over time, Static and Slimmer stopped working like the rest of GOV.UK’s code. Developers had to understand and maintain a special path for assembling pages, even as newer shared components took over much of its original role. By 2026, the Government Digital Service reported that retiring the application had removed complexity, reduced what new developers needed to learn, and made future improvements easier.

Removing it was not a quick cleanup. GOV.UK had already begun moving shared interface elements into a component library in 2017. The team later moved error pages and banners to places with clearer responsibility. It tested the final change first on one of the smallest, least-visited applications, then repeated the work across the remaining seven.

That rollout had to account for nearly 200 page types, their variations, mobile and desktop layouts, and supported browsers. Some styles that Static and the applications had compiled separately needed to be combined for the first time. In other words, the obsolete boundary was expensive to remove precisely because it had once been useful and had accumulated responsibilities.

Visitors were not supposed to notice the result. The pages looked and behaved as before. The benefit appeared in maintenance: one less application to operate, one less exceptional assembly process to understand, and a clearer path for changing shared parts of the site.

What the Case Shows

The lesson is not that fewer applications produce better architecture. GOV.UK still uses eight applications to serve public pages, and its shared components remain separate from application-specific work. The change clarified those boundaries rather than erasing them.

A shared component belongs in the common library when more than one application needs it. Application-specific behavior stays with the application that owns it. This is a practical definition of cohesion: responsibilities are grouped according to the work they perform, the connections between them follow consistent rules.

DORA’s research provides a useful guardrail here. It associates strong software delivery with systems that teams can test, deploy, and change independently. Separation can therefore improve maintainability. The deciding question is whether a boundary gives a part genuine independence or merely adds another layer that everyone must coordinate around.

Static no longer provided useful independence. It sat in the delivery path of every page while operating differently from the applications around it. Its responsibility had narrowed, but its coordination cost remained.

Test the Change Not the Feature List

The same question can make a content management system (CMS) comparison more concrete. Choose a change the organization expects to make repeatedly, then trace it through the proposed system.

Consider adding a new service. The service may need a page, a place in navigation, structured data for search engines, an option on an inquiry form, a directory listing, and availability in an internal or public search tool. A feature comparison may confirm that every required capability exists. It does not show whether information about the service is entered once and reused, or entered six times and kept consistent by memory.

That distinction makes the maintenance burden visible. If the CMSholds the main service record and the other tools draw their information from it, the organization can change one fact and inspect where it appears. If each capability maintains its own version, every update becomes a small reconciliation project.

The same service may also need a form, but that does not mean the form must live in the CMS. Security, delivery, or retention requirements may justify keeping it in a separate system. The question is whether that separation preserves the relationship to the service being offered. Can the form use the same service record, or a consistent reference to it, and can it be tested or replaced without rewriting unrelated templates? If so, the boundary contains complexity. If each template must carry its own instructions for connecting the two, the boundary has only moved that complexity elsewhere.

A Better Comparison

Architectural cohesion will not identify the best CMS in the abstract. It can reveal how a particular system is likely to age inside a particular organization.

For each representative change, ask:

• Where is the underlying information entered and maintained?
• Which other components must change, and which should update automatically?
• Can each separate service be tested or replaced without rebuilding the rest?
• Who is responsible for confirming the result?
• What evidence confirms that the change reached every required destination?

The answers do not automatically favor an all-in-one platform or a collection of connected tools. They show whether the division of work makes sense and whether the people maintaining it can continue to understand it as the organization changes.

GOV.UK’s visitors saw essentially the same pages after Static was retired. Its maintainers saw a system with one fewer exception and clearer ownership of shared work.

Features tell us what a platform can do today. Architectural cohesion tells us how much of the system must be understood, coordinated, and retested to keep doing it tomorrow.

Sources

• Government Digital Service, How we retired a web application to make GOV.UK simpler to run (2026).
• GOV.UK Developer Documentation, Architecture overview of GOV.UK applications (accessed 2026).
• Google Cloud and DORA, Re-architecting to cloud native.