I have inherited websites that looked finished and performed well, yet became difficult to change within a few years. Routine updates required a staging environment and a checklist. Adding a feature meant testing several other features that appeared unrelated. 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 share clear responsibilities, stable relationships, and a manageable way to change together. The issue is not how many parts exist. It is how many boundaries a change must cross 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, and their interfaces follow conventions the rest of the system understands.
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 makes every change coordinate through another layer.
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 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, a form destination, 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 the service is represented once and reused, or entered six times and kept consistent by memory.
That distinction makes the maintenance burden visible. If the CMS owns the service record and the other parts consume it through defined relationships, 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 draw on the same service record or identifier, 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 owns the result when several systems participate?
- What evidence confirms that the change reached every required destination?
The answers will not reward a monolith or an ecosystem by default. They show whether the proposed divisions correspond to real responsibilities and whether those divisions can remain understandable 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.