A company of 900 engineers has no enterprise architecture function and every team designs its own systems competently. Which decisions are genuinely absent, rather than simply made elsewhere?

The mechanism

A team optimises for its own delivery, and it is right to. The decisions that go missing are the ones whose costs and benefits land on different teams, because no team has the incentive or the information to make them.

Three classes, and they are the whole of the honest answer:

• Decisions where one team's convenience is another team's cost. Team A publishes an API shaped like its database because that was quickest; eleven consumers absorb the shape forever. A also chose a message format, a retry policy and an identifier scheme, and every one of those is now the estate's.
• Decisions nobody is present for. Which of the 40 internal systems can be switched off; which three teams are building the same thing; which vendor contract will constrain the architecture for six years. These need a view across teams, and in a company with no such view they are not made badly, they are not made.
• Decisions whose payback is longer than a team's horizon. Replacing a runtime that leaves support in 18 months, or paying down an integration pattern that costs everyone a little. Each team is rationally unwilling to spend a quarter on something whose benefit is mostly other people's.

The consequence people miss

The absence is not visible as a failure. Every individual system is well built, delivery is fast, and the cost shows up two or three years later as an estate where a typical feature touches five teams, four message formats and two identity systems — the point at which coordination is 40-60% of the elapsed time on ordinary work. By then the expensive part is not the decision that was missed, it is the twelve systems built on top of it. Conway observed the underlying dynamic in 1968: systems take the shape of the communication structures that produce them, so an absent cross-team view produces an estate shaped like the absence.

This is also why "we don't need enterprise architecture, our teams are good" is a category error rather than a disagreement. The function is not a check on team competence. It is an owner for decisions that have no natural owner.

Where the distinction stops mattering

Below about 50-80 engineers, or roughly 5-8 teams, the cross-team view exists informally because everyone is in the same conversations. Creating a formal function there adds a hop and removes nothing. The signal that it is time is not headcount but repetition: the third time two teams independently build the same capability, or the second time a vendor commitment surprises somebody, the information is no longer flowing on its own.

Equally, the function does not need a framework to exist. TOGAF, Zachman and the rest are vocabularies and checklists; the decisions above need an owner, a forum and a written record, not a method. Prefer the record over the method until the record is being used, because adopting a framework before there is anything to decide is the most reliable way to produce documents nobody reads.

Common weak answers

• "Standards and governance." These are mechanisms, not decisions. Naming them without saying which decisions they serve is why EA functions get a reputation for process.
• "The big picture." Unfalsifiable. Ask what it changes, and if the answer is a diagram, the function is decorative.
• "Technology selection." Mostly a team decision, and imposing it centrally is how an EA function loses its credibility on the things that actually need it.