Owning architecture across teams

The hard design problems now sit between teams: ownership boundaries, build versus buy, reliability and debt. Decide them in writing.

Also called ownership boundaries

What: Clear lines saying which team owns each service, database and API, who may change it, and who gets paged when it breaks.
Why: Cross-team designs fail on ownership more often than on technology. Shared databases with no owner become the hardest systems to change.

Watch out

Letting several services write to the same tables, so no team can change the schema safely.

Also called inverse Conway manoeuvre

What: The observation that systems tend to mirror the communication structure of the organisation that builds them.
Why: Architecture and team structure must be designed together. Some organisations change team shape first to get the architecture they want.
Example: Three teams building one product often end up with three services and awkward integration points exactly where the teams rarely talk.

What: Deciding whether to build a capability in house, use open source you operate, or pay for a managed product, based on total cost, differentiation, risk and lock-in.
Why: Building non-differentiating software burns engineering time for years. Buying core capabilities can leave you stuck with a vendor.

Watch out

Comparing a vendor's price with only the build cost, ignoring years of maintenance, on-call and upgrades.

Also called innovation tokens

What: The idea that an organisation can afford only a few new, unproven technologies at once, so most choices should use well-understood tools it already runs.
Why: Every new technology adds operating cost, hiring needs and unknown failure modes. Spending novelty only where it solves a real problem keeps systems operable.

Also called ADR, architecture decision record, decision record

What: Architecture decisions written as ADRs or design docs and stored in one searchable, well-known place, with status, context, options and consequences.
Why: At this level decisions affect teams who were not in the meeting. If they cannot find the reasoning, they reopen the debate or work around it.

Watch out

Recording decisions in a chat thread or one team's private folder.

Also called blast radius, failure mode

What: The ways a system can fail, such as dependency outages, overload, retry storms or bad deploys, and how much of the product each failure takes down.
Why: Reviewing designs for failure modes, then limiting blast radius with timeouts, isolation and gradual rollouts, prevents one team's bug becoming everyone's outage.

Also called SLO, SLI, SLA, service level objective, error budget

What: An SLO is a reliability target for a measured indicator, such as 99.9 percent of requests succeeding over 30 days. The error budget is the failure the target still allows.
Why: They turn reliability into a shared, numeric agreement. When the budget is spent, teams prioritise reliability over features without a political argument.

Watch out

Setting 100 percent or many nines by default, which is costly and blocks all change.

Also called technical debt, tech debt

What: Managing debt like investments: listing the main items, estimating the ongoing cost of each and the cost to fix, and paying down the ones with the best return.
Why: Leaders cannot fix all debt. A portfolio view lets you explain priorities to product and leadership in terms of cost and risk.
Example: A flaky deploy pipeline costing every team hours a week ranks above an ugly but stable module nobody touches.

Go deeper