Operating Model
How an organisation arranges people, process, technology and governance to deliver its capabilities, which constrains architecture as strongly as any technical factor.
The operating model determines what architectures are achievable. Designing without reference to it produces designs that are correct and undeliverable.
The dimensions that matter architecturally:
Centralised or federated delivery. A central platform team with product teams consuming a paved road produces different architecture from autonomous teams choosing their own stacks. Neither is wrong; each implies different standards, different tooling and different failure modes.
Ownership model. "You build it, you run it" produces different design decisions from a separate operations function — because the people making the design choices either do or do not feel the consequences.
Funding model. Project funding produces systems nobody owns after delivery; product funding produces sustained ownership. This is one of the strongest determinants of long-term architectural health, and it sits entirely outside engineering's control.
Decision rights. What a team may decide alone, what requires consultation, what escalates.
The practical instruction: an architecture that conflicts with the operating model will lose. Microservices with project funding and a separate operations team produce unowned services and a distributed monolith. The choice is to change the operating model or to change the architecture — and naming that choice explicitly is a large part of an architect's value.