Software systems become harder to change as they grow.

This is not controversial. What remains disputed is why.

The conventional explanations are familiar: technical debt, increasing dependency count, larger teams, institutional memory, distributed ownership, aging infrastructure, regulatory constraints, and the gradual accumulation of decisions made by people who have since moved to Colorado to make artisanal furniture.

All of these probably contribute.

But they do not fully explain an observation familiar to anyone who has worked on a sufficiently mature system: at some point, the difficulty of making a change begins increasing faster than the apparent complexity of the change itself.

Adding a field to a response object may require three teams. Renaming a service may require a migration plan. Changing a timeout may result in an architecture review whose attendees include people who are not entirely certain what times out.

This phenomenon has generally been classified as organizational overhead.

Recent work suggests we may have been looking at it incorrectly.

A small but increasingly confident group of researchers believes software architecture possesses mass.

Not metaphorical mass.

Architectural mass.

The distinction is important.

Early Observations

The Architectural Mass Hypothesis emerged from an attempt to model change propagation in long-lived enterprise systems.

Researchers studying several large distributed platforms noticed that certain architectural decisions appeared to exert influence over components with which they had no direct runtime relationship.

A service adopting a particular event format, for example, increased the probability that unrelated services would later adopt the same format. A gateway introduced to solve a local routing problem was eventually cited as justification for placing gateways in front of systems that had no corresponding routing problem.

These effects persisted even after the engineers responsible for the original decision had left the organization.

Initially this was attributed to documentation.

That explanation became difficult to sustain when researchers discovered that nobody had read the documentation.

The current model proposes that architectural components generate a field proportional to their accumulated organizational significance. Once established, sufficiently massive structures begin bending nearby technical decisions toward themselves.

A database is merely a database.

An enterprise database platform has mass.

A message queue is infrastructure.

The Strategic Asynchronous Event Fabric has considerably more mass, particularly after someone presents it at an all-hands meeting.

The effect is measurable.

Architectural Mass

Architectural mass should not be confused with system size.

A small component can possess enormous architectural mass if enough diagrams contain it.

Conversely, a large and heavily used component may exhibit surprisingly little mass if it was built quietly by three engineers six years ago and has never appeared in a strategy presentation.

The simplest proposed approximation is:

Mₐ = C × A × R

Where:

Mₐ is architectural mass,
C is conceptual complexity,
A is organizational attention, and
R is the number of times the component has appeared on a roadmap.

This remains an incomplete formulation.

Subsequent experiments found that architecture decks produce nonlinear effects, requiring the addition of a presentation coefficient.

Researchers currently disagree about the correct value of this coefficient, largely because nobody has found an ethical way to expose a control group to forty-seven slides of platform strategy.

Even without a complete model, several empirical patterns have emerged.

Systems with high architectural mass resist local deviation.

They attract abstractions.

They accumulate governance.

Most importantly, they alter the path of nearby engineering work.

A team attempting to solve a simple problem near a sufficiently massive architecture will often discover that the shortest path between two technical points is no longer a straight line.

It curves toward the platform.

Decision Curvature

This is perhaps the most interesting prediction of the theory.

Consider a team that needs to move a small quantity of data from System A to System B.

In an environment with low architectural mass, the team may evaluate several options: an HTTP call, a queue, a shared datastore, a scheduled job, or whatever else fits the actual requirements.

Near a large enterprise event platform, however, the solution space changes.

The team may still believe it is evaluating alternatives.

But researchers have repeatedly observed engineering discussions bending toward the nearby architectural object.

Questions such as:

“Do we need asynchronous delivery?”

gradually become:

“How should we publish the event?”

This transition is usually subtle.

Nobody announces that a decision has been made.

Instead, the vocabulary changes first.

Once the vocabulary has crossed the boundary, the architecture generally follows.

This effect has been reproduced in architecture reviews with remarkable consistency.

One experiment presented engineers with a hypothetical inventory synchronization problem. Participants were divided into two groups. The first received a neutral description of the problem. The second received the same description accompanied by a diagram containing Kafka.

The second group produced 63% more topics.

The authors caution that the sample size was small and several participants worked in fintech.

Architectural Gravity

If architectural mass exists, then sufficiently large architectures should exert gravitational effects.

This prediction appears to be supported by field observations.

Engineers report that once an organization invests heavily in a particular platform, new workloads increasingly migrate toward it even when the original reason for adopting the platform does not apply.

This is typically explained economically.

“We already have it.”

Operationally:

“We know how to run it.”

Organizationally:

“It is the standard.”

These are rational arguments.

Architectural gravity does not require irrationality.

In fact, the theory predicts the opposite.

Each individual decision may be perfectly sensible while the aggregate trajectory becomes increasingly difficult to explain.

This is consistent with gravitational systems elsewhere in nature, where individual objects do not need bad judgment to fall into a star.

The analogy becomes especially useful in organizations with strong platform strategies.

The platform becomes easier to adopt because tooling, support, documentation, compliance, monitoring, and deployment pipelines have been constructed around it.

This increases adoption.

Increased adoption justifies further investment.

Further investment increases architectural mass.

Eventually the platform is no longer selected because it is the best fit.

It is selected because escaping it requires energy.

Researchers call this the architectural escape velocity.

Most engineering teams call it Tuesday.

Time Dilation

One of the stranger consequences of the Architectural Mass Hypothesis is its prediction that time behaves differently near complex architectures.

This sounds implausible until examined against ordinary project planning.

A change estimated by the engineer performing the work as “about two days” may require six weeks to complete once introduced into a sufficiently massive architectural environment.

Importantly, the engineer is not necessarily wrong.

The code may still require two days.

The remaining time occurs elsewhere.

Security review.

Platform review.

Architecture review.

Dependency coordination.

Change management.

Observability requirements.

A discussion regarding whether the service belongs in the existing domain model.

A second discussion clarifying the outcome of the first discussion.

An ADR documenting why everyone eventually agreed to do what the engineer proposed five weeks earlier.

From the engineer’s local frame of reference, two days of implementation have occurred.

From the organization’s frame of reference, nearly two months have passed.

This is architectural time dilation.

The effect becomes more pronounced near systems of exceptional mass.

Researchers have documented environments where engineers experience only several hours of productive work while entire quarters pass outside.

Long-term exposure may explain why senior engineers occasionally emerge from infrastructure modernization programs looking significantly older than their LinkedIn profiles.

The Schwarzschild Architecture Radius

The theory becomes more controversial here.

Several researchers have proposed that architectural mass has an upper limit beyond which a system becomes effectively impossible to simplify.

They refer to this boundary as the Schwarzschild Architecture Radius.

Inside this radius, all attempted simplifications are converted into additional abstraction.

Removing a service requires a migration service.

Eliminating a data model requires a compatibility model.

Decommissioning an API requires an API that informs consumers that the original API is being decommissioned.

Attempts to reduce governance result in the creation of a governance working group.

No architecture can escape.

Even deletion becomes additive.

The earliest documented example involved a company attempting to retire an internal platform that had accumulated twelve years of integrations.

The decommissioning program introduced two orchestration services, an abstraction layer, a migration framework, eleven new dashboards, a compatibility proxy, and a central program office.

After eighteen months, the system scheduled for retirement contained fewer lines of code than the infrastructure designed to remove it.

At this point, researchers concluded that the system had crossed the radius.

Information could still enter.

Nothing, including the platform, could leave.

Detecting Collapse

There are several warning signs that an architecture is approaching gravitational collapse.

One is the appearance of recursive diagrams.

A normal architecture diagram describes a system.

A high-mass architecture diagram increasingly describes other architecture diagrams.

Boxes labeled “platform services” point toward boxes labeled “shared capabilities,” which connect to “enterprise services,” which eventually route back through “platform services.”

Engineers inspecting these diagrams often report a sensation of familiarity without understanding.

Another indicator is language compression.

Specific technical nouns disappear.

Databases, queues, APIs, jobs, and caches become “capabilities.”

Capabilities become “platform primitives.”

Platform primitives become “strategic enablers.”

Eventually it becomes possible to attend an architecture meeting in which no physical computing resource is mentioned for more than forty minutes.

At extreme mass, architectural terminology becomes almost entirely self-referential.

The platform enables the capability.

The capability supports the strategy.

The strategy validates the platform.

Nothing has happened, but everything is aligned.

Conservation Laws

The Architectural Mass Hypothesis also appears to explain a persistent mystery in enterprise modernization.

Why does complexity so rarely disappear?

Organizations routinely launch programs intended to simplify systems.

Applications are consolidated.

Platforms are standardized.

Services are retired.

Dependencies are removed.

And yet the total difficulty of changing the organization remains remarkably stable.

This has led some researchers to propose the Conservation of Architectural Complexity:

Architectural complexity cannot be destroyed. It can only be transferred to a different team.

A database may disappear, but its behavior moves into an abstraction layer.

A deployment process may be simplified for application developers while becoming dramatically more complicated for the platform team.

A service mesh may remove networking concerns from individual applications while creating an entirely new class of networking concerns that require people with different LinkedIn titles.

From the perspective of the local team, complexity has been eliminated.

From the perspective of the entire system, it has changed address.

This distinction matters.

Many architecture programs measure local simplification and infer global simplification.

That is roughly equivalent to cleaning your garage by putting everything in your neighbor’s garage and publishing a case study about storage optimization.

Implications

If the hypothesis is correct, several common architectural practices deserve reconsideration.

The first is the assumption that adding a shared platform reduces complexity simply because fewer teams must solve the same problem independently.

Sometimes it does.

But shared solutions accumulate mass.

The more important the platform becomes, the more expensive deviations become, and the more problems are eventually reframed to fit the platform.

This does not make platforms bad.

Gravity is not bad either.

It is merely worth knowing that you are standing near something heavy.

The second implication concerns architectural review.

Review processes are usually justified as mechanisms for preventing expensive mistakes.

They can do that.

But they also increase the organizational attention surrounding approved designs, which increases architectural mass, which increases the probability that those designs will be reused.

A successful architecture therefore becomes more likely to be applied outside the conditions that made it successful.

This may explain why organizations periodically discover that every technical problem somehow resembles the last technical problem they spent several million dollars solving.

The third implication is more uncomfortable.

Some complexity may be impossible to remove centrally.

The attempt to simplify an entire organization may itself require enough coordination, standardization, migration infrastructure, governance, and tooling to create a new massive object.

In other words, the program designed to reduce architectural gravity may become the largest source of gravity in the system.

There are early reports of this phenomenon.

They are mostly PowerPoint.

Further Research

The Architectural Mass Hypothesis remains controversial.

Critics argue that the observed effects can already be explained through incentives, path dependence, sunk costs, organizational structure, and ordinary human preference for familiar tools.

This is probably true.

Researchers supporting the theory respond that “architectural mass” provides a more convenient unit.

A proposal is currently being considered to define one Fowler as the minimum quantity of architectural influence required to cause an engineer to create an interface with exactly one implementation.

Larger units may be necessary for enterprise systems.

Preliminary candidates include the mega-Fowler, the governance ton, and the strategic kiloyak.

Standardization discussions are ongoing.

Naturally, they have formed a committee.

For now, the practical conclusion is modest.

Software architecture appears to become heavier over time.

Some of that weight is useful. Some of it represents accumulated knowledge, operational maturity, working infrastructure, and expensive lessons nobody particularly wants to relearn.

But mass has consequences.

Large systems bend decisions around themselves. Mature platforms become easier to enter than leave. Simplification requires energy. Time behaves strangely. And somewhere beyond a certain point, every attempt to remove architecture produces more architecture.

The next time someone proposes a small additional abstraction, it may therefore be worth asking not only whether the abstraction is useful.

Ask how much it weighs.

Because eventually somebody has to lift the thing.