A team says a choice is "an enterprise architecture concern, not ours". What actually distinguishes an enterprise-level decision from a team-level one?

The mechanism

Architecture scope follows the reach of the consequence, not the size of the thing. A team that chooses its own test framework affects itself; if the choice is wrong they change it, and nobody else pays. A team that picks a new message broker adds a system every other team's on-call may be paged about, that the platform must back up, patch and monitor, and that the next team will reasonably cite as precedent.

The first is a team decision however large. The second is an enterprise decision however small it looked in the ticket.

The practical test, in three questions

1. Who pays if this is wrong? If the answer includes people outside the team, it is not a team decision.
2. How long does it outlive the team that made it? Data models, wire formats and identifiers outlive reorganisations; frameworks usually do not.
3. What does it cost to reverse? A choice reversible in a sprint can be made locally even if it is consequential, because the mistake is cheap. As a rough line: if reversal takes under 5 days of one team's time, choose local.

Why the other options fail

• "Involves more than one system." Most changes touch more than one system. A team owning four services integrates them all day and none of it is an enterprise concern, because the consequence stays inside the team.
• "Costs more than a budget threshold." Money is a poor proxy: a \(2,000 SaaS subscription holding customer data has wider reach than a \)200,000 hardware purchase inside one team's boundary. Thresholds are convenient for finance and produce the wrong architecture reviews.
• "Technically difficult." Difficulty is a reason to ask for help, not a reason to move the decision rights. Conflating the two is how architecture functions become consultancies that teams must queue for.

What this rules in and out

It rules in: new datastores and languages entering the estate, anything touching shared identity or regulated data, integration contracts between domains, identifiers that appear in other systems.

It rules out: internal structure, libraries, test strategy, deployment tooling inside a paved road, and most of what architecture boards spend their time on.

When this test is the wrong one

In a very small organisation, nearly everything binds everyone, so the distinction is academic and the whole company is the review. In a very large one, "enterprise" splits into domains, and most cross-team decisions should be settled inside a domain rather than centrally. The line is drawn where the blast radius of a mistake stops, and that moves as the organisation grows. In practice fewer than 10% of changes clear the bar in a healthy estate; if yours is higher, the test is being applied too widely.