Bounded Architecture Decisions

The first three lessons gave you the placements: who owns a data product, what qualifies as a data product, and where decision authority sits. This lesson deals with what happens when those placements collide with each other. Mesh does not remove tension; it relocates it. Your job as an architect is to name the tension precisely, judge whether a domain can actually carry what it is being handed, and close the conversation with something narrower than a mandate but firmer than an intention.

In this lesson, you will learn to:

• Diagnose recurring operating-model tensions in a mesh proposal.
• Evaluate domain readiness through capability, capacity, and incentive.
• Facilitate an evidence-based conversation that ends in a bounded decision with owned open questions.

Three tensions recur in mesh operating models, each pitting two forces against each other. Domain autonomy versus interoperability is the most common: a domain wants freedom to define its own customer segments, while enterprise analytics needs segments that stay comparable across domains. Speed versus consistency appears whenever a domain can publish faster by skipping the shared convention.

The quieter pair is cost versus cognitive load. Pushing platform work into domains looks cheaper on the platform budget while loading each domain team with responsibilities it has no practice carrying, and that load rarely shows up in anyone's numbers until delivery slows.

Diagnosis matters because the resolution differs by tension. Autonomy against interoperability is resolved by deciding which specific attributes must be comparable, not by deciding who wins. Speed against consistency is usually resolved by scoping the first period narrowly. Cost against cognitive load is resolved by moving work, not by exhorting people to try harder. Consequently, a conversation that says only "there's a trade-off here" has not diagnosed anything. Name which two forces are in play and what each side would lose.

When a domain volunteers to own a data product, enthusiasm is not evidence. Three signal groups tell you whether accountability will actually hold. Capability asks whether the domain understands the data and knows how to publish for consumers other than itself, which are two different things. Capacity asks whether it has the people and attention available across the period in question, counting the domain lead's competing commitments honestly.

The third signal is incentive: whether anything in the domain's performance measures rewards reliability for other teams. It is usually the decisive signal and the one most often skipped. A domain measured on store sales and loyalty sign-ups will, under pressure, protect store sales and loyalty sign-ups. That is not a character flaw; it is the operating model working as designed.

In a readiness discussion, Emily, a supplier-operations lead, speaks with Marcus, the enterprise architect, about a supplier-score product.

• Emily: We know the supplier records, so we should own the score.
• Marcus: Knowledge is evidence of capability. What protects the score when the quarterly supplier-renewal work peaks?
• Emily: Renewal work will win. That is what my team is measured on.
• Marcus: Then the incentive is the finding, not a criticism. A conditional decision needs a measure that rewards reliability for the score's consumers.
• Emily: If that measure changes, we can make a realistic commitment.

Notice that Marcus did not talk Emily out of volunteering. He surfaced the incentive gap and let her convert it into a condition, which is far stronger than an assurance.

The Evidence-Based Architecture Conversation gives you six steps, in order:

1. Frame the decision: state exactly what is being decided, which is usually narrower than the room assumes.
2. Identify stakeholders and desired outcomes: name who is affected and what each actually needs.
3. Surface assumptions: make hidden beliefs explicit before anyone weighs evidence.
4. Compare evidence and trade-offs: test them against the tensions you diagnosed.
5. Record the bounded decision: make a narrow, explicitly scoped agreement, ideally conditional and testable; name the single condition whose failure reverses the recommendation.
6. Name remaining uncertainty and open questions: give each an owner.

The sixth step is what separates a decision from a stall. Unowned open questions are how bounded decisions quietly expand back into ambiguity.

The sequence turns a visible tension into a bounded decision with conditions and owners.

The takeaway for this lesson is that a good architecture conversation does not resolve a trade-off so much as make it visible, then bound it: yes, conditionally, with the conditions few, specific, and testable. Use the decision-rights map from the governance lesson and the DATSIS assessment from the product-ownership lesson as evidence when the case calls for them. Two quick checks come next to sharpen tension-spotting and the six steps, and then you'll write the conditional readiness recommendation itself, the kind a sponsor panel would either back or reject on the strength of its conditions.