Architectural Cohesion: The Metric Nobody Talks About

I’ve inherited more websites than I can count. Some were beautiful, fast, feature-packed, and ranked well. Six months later, they all seemed to arrive at roughly the same place: declining traffic, fewer leads, mounting maintenance costs, and a growing hesitation to change anything.

Routine updates became staging exercises. Adding what should have been a simple feature meant testing half a dozen plugins. Every improvement carried the possibility of breaking something seemingly unrelated.

The irony is that most of these sites weren’t built poorly. Many were assembled using what most agencies would have called best practices at the time.

They didn’t fail overnight.

They stopped evolving.

Eventually, that led me to a different question—not “Which CMS is best?” but:

Why do some platforms become increasingly difficult to maintain while others quietly disappear into the background?

I don’t think the answer has much to do with features. It has more to do with something I rarely see discussed: architectural cohesion.

We’ve become very good at measuring the wrong things

Search for “best CMS” and you’ll find the same comparisons repeated over and over:

• Number of plugins
• Number of themes
• SEO features
• Ecommerce support
• Market share
• Page-speed benchmarks

None of those are bad metrics. They’re answering a different question. Almost all of them describe how a platform behaves on launch day.

Very few describe what that same platform looks like after five years of client requests, framework updates, plugin replacements, security patches, staff turnover, and the inevitable: “Can we just add one more thing?”

That’s where the decisions beneath the surface begin to show.

Every architectural decision eventually becomes a maintenance decision

The more systems I’ve inherited, the more convinced I’ve become that every architectural decision eventually becomes a maintenance decision. Every website requires upkeep. The revealing question is when that cost arrives.

Sometimes it appears during development, when complexity surfaces earlier than expected.

Other times it doesn’t arrive for years, until a dependency is abandoned or no longer supported.

Occasionally it reveals itself in the most telling moment of all: when a feature that should have been simple turns out not to be.

The industry spends a remarkable amount of time celebrating what software makes possible and far less discussing what those possibilities require in return. We’ve become very good at comparing capabilities while growing far less comfortable comparing consequences.

Feature lists are easy to market.

Maintenance isn’t.

A thought experiment

Imagine hiring a contractor to remodel your kitchen.

One company manages the cabinets, electrical, plumbing, flooring, painting, and countertops. Different specialists, but they’re working from the same plans under the same project manager.

Now imagine hiring twelve independent contractors. Each chooses their own schedule, materials, standards, and warranty.

Individually, they may all be exceptional.

Collectively, you’ve multiplied the number of places where communication can fail.

Software isn’t much different. Every dependency introduces another boundary:

• Another update schedule
• Another set of assumptions
• Another opportunity for drift

None of that is necessarily a problem. Complex systems solve complex problems. The more useful question is whether the architecture keeps that complexity where it belongs.

Most architectural problems don’t begin with bad decisions. They begin with reasonable decisions made independently of one another. Over time, priorities shift, teams change, and those decisions no longer point in the same direction.

Cohesion isn’t about simplicity

This is where the conversation often drifts off course.

Cohesion isn’t about having fewer features, avoiding plugins, or proving one platform is objectively better than another. It asks a different question.

Instead of asking what a platform can do, ask how many independent systems are required before it feels complete.

If every project immediately reaches for separate solutions to handle forms, redirects, structured data, image optimization, caching, backups, SMTP, analytics, accessibility, and security, we’re no longer evaluating a product.

We’re evaluating an ecosystem.

There’s nothing wrong with that.

Products accumulate features; ecosystems accumulate relationships.

Those relationships create very different maintenance problems.

Popularity isn’t architecture

Popularity is often mistaken for architectural quality. The two have very little to do with one another.

A platform can become dominant because it’s approachable, affordable, familiar, or because it arrived at the right moment in history. None of those qualities tells us how gracefully it will respond to change.

Cohesion isn’t a measure of popularity. It’s an observation about how responsibilities are distributed, how boundaries are managed, and how systems continue evolving without unnecessary drift.

Why this conversation matters more than it used to

For a long time, content management systems were primarily concerned with rendering pages.

Today they’re expected to model businesses, people, organizations, services, locations, products, relationships, structured data, APIs, and AI retrieval.

For many organizations, the CMS is becoming the operational source of truth. That’s a very different responsibility.

When content, metadata, relationships, and presentation become scattered across multiple systems, maintaining consistency stops being only a technical challenge.

It becomes an architectural one.

A better place to start

Cohesion won’t tell us everything we need to know about a CMS. It won’t measure editorial experience, explain governance, or predict the health of an ecosystem.

We’ll get to those.

But I think it’s the right place to begin because so many of those conversations branch from the same observation:

Every boundary creates another place where people, systems, and assumptions have to remain in agreement.

That doesn’t make an architecture wrong. It means there’s one more relationship that has to stay healthy over time.

Maintenance becomes more expensive—not always in dollars, but often in time, confidence, or the quiet reluctance to improve a system because no one is quite sure what else might break.

Features tell us what a platform can do today.

Clear structure tells us what it will cost to keep doing it tomorrow.

I can’t help wondering how different our industry conversations would sound if we started with the second question instead of the first.