Decision Altitude.

The most expensive architecture mistake is often not the technology. It is building the right capability in the wrong layer.

An application team creates an event pipeline to solve an immediate product problem. Another team adds caching rules inside its service. Several groups each implement a version of the same data transformation.

Every implementation may be thoughtful and technically sound. The system is still expensive because a capability with shared consequences is owned at a local altitude.

I call this decision altitude: the technical and organizational layer at which a capability, policy, or tradeoff is owned.

Possible altitudes include:

• one code path;
• one service;
• one product;
• a shared platform; or
• the organization itself.

The important question is not “Should we centralize this?”

It is:

At which layer does ownership minimize the total cost of change?

That wording matters because centralization is not automatically leverage. Sometimes moving a problem into a platform merely turns a local decision into a queue.

The altitude is part of the architecture

Architecture diagrams show components, dependencies, and data flows. They rarely show who owns a decision, how many teams inherit it, or what coordinated work becomes necessary when it changes.

Those omissions can hide the most consequential part of the design.

A local implementation optimizes for immediate learning and autonomy. A platform capability optimizes for consistent guarantees and lower change cost across many consumers. An organizational policy optimizes for risks or constraints that no individual team should own alone.

None is inherently superior. Each is appropriate under different conditions.

The mistake is allowing the consequences of a decision to expand while its ownership remains at the original layer.

Three tests for the correct altitude

1. The duplication test

How many teams repeatedly make the same underlying decision?

One implementation is usually an experiment. Two similar implementations are an invitation to compare constraints. Three or more teams solving substantially the same problem may indicate a shared capability.

Count repeated decisions, not repeated syntax.

Two services may contain similar code while serving genuinely different product constraints. Conversely, two systems may use different technologies while making the same decision about identity, durability, ordering, or access.

The question is not “Can we reuse this code?” It is “Are several teams paying to rediscover and maintain the same guarantee?”

2. The change-amplification test

When the implementation changes, how many repositories, roadmaps, and teams must coordinate?

Suppose a storage or messaging migration requires dozens of consumers to change their code. That usually means the contract exposed the engine rather than the capability.

Compare these two contracts:

Technology contract

Publish to this Kafka topic using this schema and client.

Capability contract

Emit a durable customer-state change. Delivery, ordering, retention, and implementation are handled behind this boundary.

The first makes consumers depend on how the system works. The second lets them depend on what it guarantees.

Technologies will change. A durable capability contract gives the owning team room to change them without turning each migration into an organizational program.

3. The decision-horizon test

Which changes faster: the consumer need or the implementation behind it?

• When consumer needs are still changing rapidly, keep the decision close to the product and continue learning.
• When many consumers share a stable need but the implementation evolves frequently, put the implementation behind a platform boundary.
• When a decision represents company-wide risk, policy, or consistency, its correct altitude may be organizational rather than merely technical.

This is why “build the platform first” is often poor advice. A stable abstraction cannot be designed from an unstable understanding of the problem.

Let local teams learn until the shared need becomes visible. Then move ownership before the cost of coordination becomes permanent.

The Decision Altitude matrix

Place the capability on two axes:

• Horizontal — number of consumers: one → many
• Vertical — cost of coordinated change: low → high

The lower-left quadrant rewards autonomy. There is little value in creating shared ownership for a cheap, local decision.

The upper-left quadrant is different: even one consumer can justify a strong boundary when the underlying dependency is risky or costly to change.

The lower-right quadrant may need standards, templates, or conventions—but not necessarily a central service. Lightweight coordination can be enough.

The upper-right quadrant is where a platform capability can create the most leverage. Many consumers share the need, and coordinated change is expensive.

There is one additional condition:

A team must be willing to own the capability as a product.

Without product ownership, centralizing the code creates an orphan—not a platform.

The symmetrical failure

Premature platformization is the opposite altitude error.

A central team notices two similar requirements and standardizes them before learning why they differ. The resulting service reflects neither product’s real constraints. Consumers route around it. The organization gains another dependency without reducing cognitive load.

Common symptoms include:

• a growing request queue around the platform team;
• product teams maintaining private alternatives;
• exceptions becoming more common than the standard path;
• adoption measured by mandates rather than repeat use; and
• an architecture diagram that looks cleaner while delivery becomes slower.

Shared code is not automatically a platform. A platform is a commitment to provide a capability, evolve its implementation, support its consumers, and reduce their total cost of change.

Move a capability only when shared ownership reduces that cost, not when centralization merely makes the architecture diagram cleaner.

A practical architecture-review exercise

Choose the capability causing the most repeated coordination in your organization.

Ask:

1. Duplication: How many teams independently make the same underlying decision?
2. Change amplification: How many consumers, repositories, or roadmaps must coordinate when it changes?
3. Decision horizon: Which changes faster—the consumer need or the implementation?
4. Product ownership: Is a team prepared to own the capability, its contract, adoption, and evolution?

Then place it on the matrix.

You may discover that the implementation is fine. The altitude is what makes it expensive.