Engineering alignment is an architecture concern

System boundaries fail when ownership, language, incentives, and decisions are unclear—even when the diagram is technically sound.

Most expensive architecture failures begin as human misalignment that the system later makes concrete.

A diagram can hide organizational ambiguity

Two boxes connected by an arrow may look simple. In delivery, the arrow can represent an undocumented contract, two competing definitions, an approval queue, a privacy boundary, or a dependency owned by nobody. Technical clarity requires human clarity at the same boundary.

This is why architecture cannot be produced only from a requirements document. The architect has to discover who makes the decision, who operates the component, who carries the risk, and what happens when assumptions differ.

System design: how a boundary earns clarity

Alignment is not a single meeting. It is a sequence a boundary has to pass through before implementation hardens around it.

• Ambiguous boundary — an arrow exists on the diagram before anyone has agreed what it means operationally.
• Named owner — a specific person or team owns the producer side and the consumer side.
• Written decision — the choice, its alternatives, and its consequences are recorded, not just remembered.
• Operational agreement — both sides agree how change, incidents, and deprecation will be handled.
• Reversibility check — the process applied matches how hard the choice will be to undo.

Write decisions, not just requirements

Requirements describe desired behavior. Decisions record why a path was selected under specific constraints. Without the second artifact, teams repeat old debates and future maintainers cannot distinguish a deliberate trade-off from an accident.

A useful decision record stays short, but it always answers the same six questions.

• Context — the constraint or pressure that made a decision necessary
• Choice — the path that was actually taken
• Alternatives — what else was considered and why it was set aside
• Consequences — the cost accepted in exchange for the benefit gained
• Owner — the person accountable for the decision holding up
• Review trigger — the evidence that would be enough to revisit it

Its purpose is not ceremony. Its purpose is to keep the system's reasoning available after the meeting has disappeared.

Make ownership visible at boundaries

Every important interface needs an owner on both sides and an operational agreement between them. That agreement includes schema changes, incident handling, service objectives, security responsibilities, and deprecation. Ownership is incomplete if it covers delivery but not operation.

• Name the producer and consumer of every critical contract
• Document who approves change and who responds to failure
• Keep one shared definition for business-critical terms
• Record which upstream data each boundary depends on, and who is allowed to change it
• Escalate unresolved ownership before implementation hardens it

Prefer reversible decisions under uncertainty

Not every choice deserves the same process. A reversible experiment should move quickly with a clear measurement. A difficult-to-reverse choice—identity model, data ownership, public contract, or compliance boundary—deserves broader review.

Teams become faster when they agree on this distinction. They spend less energy seeking certainty for small choices and more attention on decisions that can trap the product for years.

From production: the arrow that had two owners

On StreetSenseAI, the arrow between the source adapters and the canonical model looked like a single technical translation step on the diagram. In practice, three independent public data sources changed their export formats on different schedules, with no shared release calendar between them. Nobody owned the contract the canonical model actually depended on — each adapter team assumed the model would absorb whatever shape arrived. The fix was not a smarter parser. It was naming one internal owner for the canonical model's contract and requiring every source adapter to fail loudly against that contract instead of silently reshaping bad data downstream — the trade-off already recorded for that decision: normalization needs deliberate mapping work, but it is what makes downstream logic testable at all.

On the Enterprise MCP Gateway, the decision to keep the user's identity attached to every downstream call was a five-minute agreement in a design review and an eight-week integration effort once SAP's session model and Salesforce's connected-app scopes turned out to disagree about what "the same user" meant. Writing that decision down — the alternative of a shared service identity was faster to ship, the consequence was harder token propagation in exchange for real least-privilege and auditability, and who owned getting it right — is what let two separate integration teams debug the same failure without re-litigating why the harder path had been chosen in the first place.

What to carry forward

• Treat ownership as part of the system boundary
• Preserve the reason behind important decisions
• Use one vocabulary across product and engineering
• Match decision process to reversibility
• Treat a repeated escalation as a missing decision record, not a training gap

Applied in the portfolio

• StreetSenseAI — An open-data intelligence system for understanding roadworks, disruption, and operational risk across UK streets.
• Mauri — A phenotype-led guidance and recovery-tracking experience for women navigating PCOS, endometriosis, and hormonal health.
• Enterprise MCP Gateway — A governed integration layer that turns enterprise APIs into safe, versioned tools for production AI agents.