Fake Boundaries

"Customer Engagement" has a roadmap and a budget but no coherent system boundary. Governance invents boundaries for portfolio legibility. Engineering invents different ones for architecture. Both are chosen for representational convenience.

On a slide in a portfolio review, a box appears labelled “Customer Engagement.”

The box has a roadmap, a Jira board, quarterly OKRs, a budget, and an executive sponsor. The board likes it. Finance likes it because money can be allocated to it. Customer Engagement does not exist as a coherent system.

The notification logic lives in a legacy monolith. The customer profile data lives somewhere else. The personalisation features are prototypes in an experimental repository. The recommendation engine is a third-party service owned by yet another team. The organisation has grouped these fragments under one label because the board needs to review a portfolio, and portfolios prefer nouns.

The label comes first. The boundary comes never.

In a real product, the boundary corresponds to something operationally meaningful: a team can deploy it, measure it, change it, and answer for its behaviour. In a fake product, the boundary exists for governance convenience. Someone has to maintain the roadmap, reconcile the budgets, and sit in meetings where one executive means “personalisation,” another means “notification service,” and a third means “customer response times.” The work is real. The product is not.

The fake product also becomes a power base. If three of the strategic products on the board slide turn out to be labels rather than systems, somebody’s portfolio shrinks and somebody’s strategic importance shrinks with it. The fiction persists because important careers are attached to it.

The boundary question: does the product exist in the system?

Fake autonomy

The same mistake appears lower down the stack. Imagine a bus: one driver, one route, thirty passengers. Now imagine someone decides each passenger should have their own car, except nobody split the passengers by destination. Each car carries one-thirtieth of everyone’s luggage. Every trip requires all thirty cars to coordinate.

A great many microservices programmes reproduced exactly that failure. The organisation heard “independent deployment” and split the software without splitting the work. Forty services, one shared database. A dozen services to complete one customer journey. Every change that crosses an unsplit boundary must be negotiated through the coordination machinery the architecture was supposed to eliminate.

Fake products and microservices graveyards are the same failure at two altitudes. The board invents boundaries that make the portfolio legible. Engineering invents boundaries that make the architecture legible. In both cases, the boundary is chosen for representational convenience rather than operational truth.

The busy-work organisation keeps asking, “How do we improve alignment across these boundaries?” The better question is, “Why do these boundaries exist?”

The bus analogy is memorable. The question it should leave is not “how do we coordinate the thirty cars?” but “why did we split the passengers before we split the destinations?” The boundary question is not an architecture question. It is a governance question wearing an architecture costume.

← The Strategy Deck That Ate the Company The Meeting That Replaced the Work →