Operating Models and Decision Ownership

The logistics group had four country units, and for twenty years each had run its own everything: its own transport management system, its own cloud accounts, its own data team, its own security baseline. After an audit finding, the new group CIO centralized. One IT organization, one standard stack, every purchase and every production change through group. Fourteen months later the country heads escalated to the board: a warehouse integration that had taken the Polish unit three weeks now took four months, and two units had quietly kept their old systems running. The CIO reversed. Decisions would be federated. Each country would decide for itself within group guardrails, and a monthly architecture council with representatives from every unit and every central function would settle what was shared. Two years on, the council had thirty members, met for three hours a month, and had decided almost nothing, because nobody had ever written down which decisions were the council’s and which were the countries’. Every question was global if someone in the room said it was. The Polish integration was still waiting, this time for the council.

This fictional group changed its reporting structure without resolving the decisions that caused delay. It needed to establish which processes and data required common treatment, then assign authority with attention to risk, legal obligations, resources, and local expertise. Evan Bottcher’s account of enterprise platforms similarly connects platform work to organizational arrangements. An operating model supplies business requirements for this design; it does not automatically place every decision. Team boundaries, decision rights, and support and control mechanisms need to be worked out together and tested against actual work.

Start with the business requirements for shared work

MIT CISR uses operating model for the integration and standardization requirements of core business processes. Standardization concerns common ways of working; integration concerns connected work and shared data. Its four models emphasize different combinations: unification combines both, coordination emphasizes integration, replication emphasizes standardization, and diversification permits greater independence across distinct businesses. These are useful descriptions of business requirements, not a complete delegation policy or a requirement to classify every part of a group identically.

The logistics group chooses common warehouse and transport steps where a review finds that consistency will support training and shared maintenance. It retains country-specific regulatory steps, carrier interfaces, and approved variations. Multinational accounts also need compatible customer and shipment information. This resembles replication with a coordination requirement in the shared-account scope. The choice requires business leadership and local expertise, but naming it does not settle who can change a standard, fund an interface, or approve an exception. Eighty Diagrams and No Answer connects these requirements to target architecture; Forty-Seven Initiatives and No Strategy examines investment choices. Here the task is to turn those requirements into workable decision rights.

Allocate authority for each class of decision

Authority may be central, jointly governed across units, or delegated locally. Who Decides What compares these arrangements for data governance. Central review can create queues, an unclear federation can leave disputes unresolved, and independent choices can fragment shared work; these are risks to manage, not inevitable outcomes. Common standards can be agreed jointly and implemented locally. Shared data can use agreed interfaces without one central owner of every definition. In federated computational governance, automation supports common rules alongside scoped domain authority; judgment, exceptions, and risk-based review still require people.

Business requirement	One possible authority arrangement	What still needs an explicit decision
Common end-to-end processes and data	A group process owner with delegated local execution	Which changes need group approval, what local variations remain, and who funds implementation
Shared data across distinct processes	Participating owners agree interface and meaning contracts	Scope, compatibility, dispute resolution, and any centrally imposed obligations
Similar processes across largely independent units	A common standard governed centrally or jointly, with local configuration rights	Whether implementations must be shared, configuration limits, support, and exceptions
Distinct businesses with limited common work	Broad local authority with identified group obligations	Which shared services are optional, which controls are mandatory, and who owns each obligation

The table gives possible arrangements, not a mapping prescribed by the four model names. A federation may have many legitimate shared decisions; the test is whether authority, response time, escalation, and execution capacity fit the work. Delegate repeatable decisions where appropriate and record how a deadlock ends. The foundation for execution supplies reusable business and IT capabilities, but reuse does not require all funding or authority to sit centrally.

Platform teams and domain teams

Authority and team design affect one another. Conway’s law describes how communication relationships constrain system design, not a guarantee that an org chart will reproduce a desired architecture. Inspect the information and decisions needed for a change. Team Topologies offers a vocabulary: a stream-aligned team owns outcomes along a flow of work; a platform team provides supporting internal products; an enabling team helps develop skills; and a complicated-subsystem team concentrates specialist expertise. Its interaction modes distinguish time-bounded collaboration, ordinary service consumption, and facilitation. Use them to clarify work relationships. Service consumption can reduce routine coordination without removing decisions about scope, funding, risk, or the roadmap. Governance and working relationships have different jobs.

In this example, country teams own local delivery flows. Business process owners define the agreed process, data owners govern shared meaning, and the platform team provides selected components and interfaces under an operating agreement. The Load Has to Land Somewhere explains how to specify that boundary. The CNCF white paper emphasizes a thin, composable platform matched to user needs; the thinnest viable platform principle asks what support is sufficient for the intended work. A process standard does not by itself mandate one implementation. A required platform route needs an authorized rationale, fit for the affected workloads, support, and an exception process; security or legal obligations can also justify constraints. Operate the platform as a product, with a platform product manager developing priorities within the agreed mandate. A Mandate Is a Measurement separates mandated use from evidence of user value.

Bottcher describes specialist teams optimizing their own work while end-to-end delivery suffered, and identifies self-service as an important platform property. The useful distinction is between consuming a managed capability and waiting for another team to perform each routine change. Both create dependencies, but the first can remove substantial operational and specialist effort. Assess cognitive load, support demand, delays, failure handling, and ongoing effort for provider and consumer teams. A dependency count alone cannot establish whether the platform reduced their burden.

Ownership means decision rights, not names

Decision rights state which role can decide which questions, within what scope and limits. Effective ownership also needs resources and routes for obtaining decisions outside those limits. The distinction between responsibility and accountability can sit with different roles: doing the work, answering for the outcome, and approving a particular risk need not belong to one person. A service owner coordinates commitments across a service’s life; data governance separates the duties of owner, steward, and custodian. Domain ownership in Who Is This Table For? likewise requires a usable mandate. A team can own outcomes while still needing budget, security, or cross-service approval. Judge whether it can obtain and carry through the required decisions, not whether it can approve everything alone.

Decision class	Who decides, in the logistics group’s replication-with-coordination model	Scope of the right	Where it was before
The common warehouse process	Group business process owner, with country representatives and specialist advice; implementation assigned separately	Common steps across four units; local legal requirements and permitted variants documented	Previously left to the council without a clear mandate
Configuration of the standard within stated limits	Each country’s stream-aligned team	Its unit; limits published by the process owner	The council, one request at a time
Shared-account shipment and customer definitions	The participating data owners under a written joint decision rule	Shared products and interfaces; named escalation authority and response target for unresolved disagreements	Four definitions with no compatibility agreement
Carriers, partners, and local systems outside mandatory common components	The unit within procurement authority, security requirements, and architecture principle	Its unit; changes affecting shared contracts or required components follow the specified approval route	Group review of each request
Security baseline and technology requirements	Security and architecture authorities with country legal and operating input	Defined systems and jurisdictions; automated checks where suitable, with review and exception responsibilities	Central authority existed, but control coverage and evidence were inadequate
Platform priorities	Platform product manager with the team and sponsors, within delegated budget and obligations	Roadmap informed by user outcomes, risk, maintenance, and capacity; unresolved trade-offs escalated	An agenda dominated by individual requests

The six rows define where routine decisions go. The remaining governance body has a written mandate for approvals, cross-unit conflicts, and exceptions that exceed delegated authority, with a response target and a route beyond it. Necessary review does not disappear. Record consequential allocations and their rationale using the discipline in Architecture Decisions, so a later reorganization can examine why the boundaries exist. Not every operational decision needs an enterprise architecture record.

Support and control are different instruments

Support helps teams achieve an outcome; control limits or verifies what they may do. One review can contribute to both, but routing every request through the same body can create avoidable delay. DORA describes risks from remote standard-setting, ticket-driven platform work, and rigid paths that fail to serve different teams. The CNCF white paper similarly emphasizes user needs and the limits of mandates as an adoption strategy. Choose service, training, automated checks, and human review according to the task rather than assuming one instrument can cover all of them.

Job	Instrument	Where it belongs	Fails as
Support a repeatable delivery journey	A golden path in the internal developer platform, consumed as a service	Workloads for which the path meets requirements; approved alternatives where needed	A rigid path that ignores different needs or necessary exceptions
Transfer a skill a team lacks	An enabling team in facilitation mode, for a defined period	Units adopting a new capability for the first time	A permanent dependency, if the enabling team never leaves
Apply repeatable controls	Policy as code evaluates explicit rules; enforcement points act on decisions and expose evidence	Automatable parts of security, classification handling, and shared rules; human judgment for meaning and risk	Uncovered routes, stale policies, wrong inputs, or untested enforcement
Resolve judgment and exceptions beyond delegated authority	A governance body with a written mandate and recorded reasoning	Decisions whose scope, risk, or conflicts require that authority	Delay or ambiguity when boundaries, response times, and escalation are missing
Set limits that make teams faster	Enabling constraints: an architecture principle with a rationale and an exception route	Choices that would otherwise be made forty times	A standard with no rationale, which is a preference with a badge

Automated controls can reduce repeated manual work. They still cost time to design, integrate, test, deploy, observe, and maintain; users may also bear remediation and exception costs. Human review remains appropriate for judgment, evidence assessment, and risks the checks do not cover. For the logistics group’s access-control finding, the response needs an inventory of relevant accounts and access paths, correction of existing permissions, coverage of bypass routes, policy version tracking, and tests of allowed and denied access. Closing the finding requires evidence accepted through the audit process, not merely installing a policy engine.

Judging an operating model

Assess the model against a defined set of decisions and services over a stated period. Check whether common requirements and permitted variation are understood, whether disputed questions have an authorized decision and escalation route, and whether teams have the resources to act. Measure decision delay, rework, incidents, control failures, and provider and consumer effort alongside service outcomes. Meeting counts and self-service or automated-control percentages need denominators and workload context; fewer meetings or a rising percentage is not always improvement. Review collaboration arrangements when their purpose changes. A target delegation can be designed while legacy systems remain, but distinguish the authority granted now, technical limitations on its exercise, and the funded transition needed to remove those limitations. An architecture maturity model is not a universal eligibility test for assigning decision rights.

What a reviewer should ask

1. How much process standardization and how much data integration does the business require between its units, who decided that, and is the answer written down?
2. For each decision class, what shared requirements, obligations, risks, expertise, and resources justify its allocation?
3. Which decision classes does each standing body hold, and what did it decide in the last year?
4. Which team responsibilities and working relationships support the flow, and where do blocking handoffs or necessary reviews remain?
5. What does the platform provide, where is a specific route mandatory, who authorized that requirement, and what alternatives or exceptions exist?
6. What may each owner decide directly, which approvals must they obtain, and how can they resolve a delay?
7. Which controls are automated or reviewed by people, what does each actually verify, and how is coverage and effectiveness tested?
8. Can a unit identify its authority, limits, and escalation route, and use them to obtain decisions in time?

In the group’s third attempt, business and technology leaders agree the common process steps, approved country variations, and shared-account data contracts. They use the six-row mandate to delegate local integration work while retaining specified security, procurement, and cross-unit approvals. The platform team provides selected components as services; business and data owners retain their respective responsibilities. Product priorities reflect user evidence, operating obligations, risk, and capacity. The access-control remediation covers existing permissions and all identified access paths, and the audit function accepts the test and operating evidence before closing the finding. During the following year the governance body handles four escalations, and the Polish integration completes in five weeks after satisfying its delegated scope and required checks. These illustrative counts do not establish success by themselves: the group still compares delay, effort, failures, and service results for comparable work. What changed is that the participants can say who decides, what evidence is needed, and where an unresolved question goes.

References:

• MIT CISR, Classic Topics: Enterprise Architecture
• MIT CISR, CISR Glossary: Enterprise Architecture
• MIT CISR, 50th—50 Facts: Operating Models and Enterprise Architecture
• Team Topologies, Team Topologies, Key Concepts
• Team Topologies, What is a Thinnest Viable Platform (TVP)?
• CNCF TAG App Delivery, Platforms White Paper.
• DORA, Platform engineering (capability guide).
• Evan Bottcher, What I Talk About When I Talk About Platforms, martinfowler.com, 2018.