The Operating Model Is the Architecture of How Work Gets Done

Strategy can be clear at the level of intention and still fail in operation.

Leadership may decide that the enterprise should provide one customer experience, integrate an acquisition, reduce cost to serve, accelerate product delivery, or become more responsive to local markets. Those ambitions can be legitimate and specific enough to guide investment. They still do not answer the questions that determine how the work will actually happen.

Who owns decisions that cross business-unit boundaries? Which capabilities should be shared, and which should remain close to the market? What information needs a common definition? How will competing demand for scarce expertise be resolved? Which activities require enterprise consistency, and where is variation useful? Who funds the capabilities that everyone depends on? What happens when local performance and enterprise performance point in different directions?

Those are operating model questions.

They are not secondary implementation details. They are the choices that determine whether the enterprise can behave in the way its strategy requires.

Business architecture is valuable in this work because it provides a stable view of the enterprise beneath the current organization chart. Capabilities, value streams, information, stakeholders, organization, policies, initiatives, and measures allow leaders to examine the consequences of an operating choice before they embed it in a reorganization, platform program, outsourcing agreement, or multiyear transformation.

Strategy Is Not an Operating Instruction

A strategy establishes direction and priorities. It identifies where the enterprise intends to compete, which outcomes it values, and what it is prepared to emphasize or decline.

It does not automatically specify the arrangements needed to carry those choices through the organization.

A declaration such as “operate as one company” may imply common customer information, shared commercial policies, integrated planning, coordinated investment, or a unified technology platform. It may also imply none of those things if leadership has not decided how much integration is actually required.

“Empower the regions” may mean faster local decisions, greater authority over customer exceptions, local control of staffing, or freedom to adapt products. It can also become a vague justification for duplication, incompatible information, and fragmented accountability.

“Build enterprise capabilities” may sound decisive, but it does not answer who owns those capabilities, how they are funded, how demand is prioritized, what service other units should expect, or how enterprise standards will be enforced.

The operating model converts strategic direction into durable institutional commitments. It determines how responsibility, coordination, authority, information, capacity, and performance management will be arranged so that the organization can act consistently over time.

An Operating Model Is a System of Commitments

A useful working definition is:

An operating model is the set of durable arrangements through which an enterprise assigns responsibility, coordinates work, makes decisions, uses information, deploys capacity, and manages performance.

The important word is durable. An operating model is not whatever people happen to do during a well-run meeting. It is the pattern the organization can sustain when priorities compete, leaders change, budgets tighten, demand increases, and exceptional cases test the boundaries.

An operating model is therefore more than an organization chart.

An organization chart shows formal reporting relationships. It does not necessarily show who controls investment, who defines policy, who owns shared information, who can approve exceptions, or how work moves across organizational boundaries.

An operating model is also more than a process map. A process can describe the sequence of work without resolving who has authority when two functions disagree, who funds a shared activity, or whether the process should be common across business units.

It is more than a technology blueprint. A common platform can support coordination, but the platform does not decide whose priorities take precedence, which data definitions are authoritative, how service levels are established, or what local variation is allowed.

It is more than a target-state presentation. A future-state picture may be attractive while remaining silent about capacity, incentives, transition costs, and the governance needed to keep the model coherent.

An operating model becomes real when the organization has made choices that can survive contact with ordinary institutional pressure.

Why the Organization Chart Is a Poor Starting Point

Operating model work often begins with boxes and reporting lines because structure is visible and familiar. It is also politically salient. Leaders understand that changing the chart can expand or reduce formal authority, headcount, budget, and status.

That visibility can make the organization chart a misleading starting point.

Beginning with the current structure tends to preserve inherited boundaries before anyone has asked whether those boundaries support the desired outcome. Beginning with a proposed structure encourages participants to debate reporting relationships before clarifying which capabilities, decisions, information flows, and accountabilities the structure is supposed to support.

A better sequence starts with the outcome, then examines the work and capabilities required to produce it. Structure should follow from those choices rather than silently determine them.

This does not mean that organizational history is irrelevant. Existing structures often preserve accumulated expertise, legitimate authority, regulatory accountability, customer relationships, and practical knowledge about how work gets done. A sound design identifies what those arrangements currently accomplish before changing them.

The goal is not to treat the organization chart as disposable. It is to avoid treating it as the enterprise itself.

What Business Architecture Contributes

Business architecture does not decide that a capability should be centralized, that a process should be standardized, or that a business unit should surrender authority. Those are leadership decisions.

Business architecture improves the quality of those decisions by making their implications visible.

A capability view shows what the enterprise must be able to do regardless of current reporting lines. It helps leaders distinguish a capability that should be shared from an activity that happens to be performed in several places.

A value stream view shows how an outcome is produced from the stakeholder’s perspective. It reveals where functional boundaries interrupt end-to-end delivery and where a local optimization imposes cost elsewhere.

An information view identifies the concepts that must be consistently understood, maintained, and exchanged. It exposes situations in which a proposed operating model depends on integrated information that the enterprise does not yet possess.

An organization view shows where capacity, accountability, authority, and expertise currently reside. It also helps identify the institutional disruption involved in moving them.

Strategy and initiative mappings connect the proposed model to investments and change activity. They show whether the portfolio is actually building the capabilities and dependencies that the target model assumes.

Measures and stakeholder mappings help test whether the proposed model aligns incentives with the outcomes leadership says it wants.

The architecture does not replace judgment. It gives judgment a coherent body of evidence.

Operating Model Design Is a Choice About Boundaries

Most operating model debates are, at their core, debates about boundaries.

Where should common rules end and local discretion begin? Which work should cross organizational lines, and which work should remain contained within them? Which information should be enterprise-wide? Which decisions should be made close to the customer? What belongs inside the enterprise, and what can be performed by a partner? Which capabilities should be managed as common assets, and which should remain embedded in a business unit?

These choices create tradeoffs.

Greater consistency can improve reliability, interoperability, compliance, and customer recognition. It can also reduce responsiveness and force different markets into arrangements that do not fit.

Greater local authority can preserve expertise and speed. It can also create duplication, incompatible practices, and difficulty managing an enterprise customer or product.

Shared capabilities can reduce redundant investment and improve quality. They also create dependencies, queues, prioritization conflicts, and the need for service management.

Centralized decisions can protect enterprise interests. They can also move authority away from the information needed to make a good decision.

External providers can offer scale and specialized expertise. They can also weaken institutional knowledge and create new governance, integration, and contingency requirements.

A credible operating model does not eliminate these tensions. It makes deliberate choices about where they will be managed.

A Seven-Question Business Architecture Method

Operating model work becomes more manageable when it is anchored to a defined decision rather than a broad request to “design the future state.” The following sequence is intended as a practical method, not a universal framework.

1. What Outcome Is the Enterprise Trying to Improve?

Begin with the result that must change.

The relevant outcome may concern a customer, employee, regulator, supplier, shareholder, or internal stakeholder. It may involve growth, responsiveness, reliability, cost, risk, speed, quality, or consistency.

The outcome should be concrete enough to expose the operating tension. “Improve collaboration” is usually too vague. “Provide a consistent resolution experience for customers whose accounts span multiple business units while preserving local authority over market-specific exceptions” is much more useful.

The business architect should identify the affected stakeholders, value streams, stages, measures, and pain points. This establishes why the operating model is being examined and prevents structure from becoming the objective.

2. At What Level Is the Decision Being Made?

An enterprise can have operating arrangements at several levels.

A corporate-level decision may establish how major business units share information, investment, platforms, or policy. A domain-level decision may govern how finance, technology, commercial management, or operations works across the enterprise. A value-stream decision may focus on the coordination required to produce a particular stakeholder outcome. A regional or product-level decision may define the boundaries of local authority.

Confusion arises when participants are solving different problems at different levels.

A centralized capability may make sense at the enterprise level while still requiring distributed execution. A common policy may be appropriate across business units while local processes remain different. A value-stream owner may need authority over priorities without directly managing every participating team.

The scope must therefore identify the organizational boundary, the decision makers, the affected capabilities, and the degree of change under consideration.

3. Which Capabilities Must Work Differently?

The next question is not which departments should move. It is what the enterprise must be able to do differently to produce the desired outcome.

For each relevant capability, examine:

Its importance to the strategy and stakeholder outcome
Its current performance and capacity
Whether it depends on scarce expertise or common infrastructure
Whether consistency creates value
Whether local variation creates value
Whether the capability differentiates the enterprise
Which information, technology, policy, and supplier dependencies it carries
Whether the organization can realistically operate and improve it in the proposed location

A capability may be governed centrally but performed locally. It may use a shared platform while retaining local service decisions. It may be designed once and replicated, or it may need meaningful variation by market.

The operating choice should describe these distinctions rather than force every capability into a simple centralized-or-decentralized label.

4. What Has to Cross Organizational Boundaries?

Operating models fail when they assume that coordination will occur without specifying what must move across boundaries.

The required flow may involve customer information, product definitions, work requests, demand forecasts, risk decisions, capacity commitments, funding, policy, service cases, or performance data.

For each critical flow, determine:

What must be exchanged
Why it is needed
When it is needed
Who is responsible for its quality
Which definition is authoritative
What happens when the information is incomplete or disputed
Which systems and handoffs support the exchange

This analysis often reveals that the apparent operating problem is not primarily structural. A company may not need one centralized service organization. It may need a common customer identity, consistent case information, clear escalation rules, and a reliable mechanism for transferring work.

The solution should address the actual dependency rather than defaulting to a reorganization.

5. Where Should Authority Sit?

Naming an owner is not enough. Meaningful ownership consists of specific decision rights.

For each major capability or decision domain, clarify who can:

Establish policy and standards
Set priorities
Approve investment
Allocate capacity
Design the capability
Operate the capability
Approve exceptions
Resolve cross-unit conflict
Measure performance
Change the operating arrangement

These rights may be distributed. Enterprise leadership may define policy and investment priorities, while business units retain authority over execution within agreed boundaries. A shared capability leader may manage design and capacity, while a value-stream leader sets outcome priorities. Local leaders may approve routine exceptions, while material exceptions require enterprise review.

The model is not finished until participants understand which decisions belong where and how unresolved disputes reach a legitimate decision maker.

“Everyone collaborates” is not a decision-rights model.

6. How Will the Model Be Resourced and Measured?

A strategically attractive operating model can still be operationally impossible.

A shared team may not have enough people to absorb enterprise demand. A newly centralized capability may inherit accountability without budget. A value-stream owner may be held responsible for an outcome while every participating function is measured on local efficiency. A common platform may become a bottleneck because no one has defined how demand will be prioritized.

The design should therefore identify:

The capacity required to perform and improve the capability
The funding model
The source of specialist skills
The mechanism for prioritizing demand
The service expectations between providers and users
The measures that indicate whether the outcome is improving
The incentives that may reinforce or undermine the model
The forums in which performance and conflict will be reviewed

Formal structure matters, but measures and resource allocation often reveal the organization’s real operating model.

If leaders say that an end-to-end customer outcome is the priority while funding and rewarding every function independently, the functional model will continue to dominate.

7. How Will the Enterprise Move From Current to Target?

Operating models are rarely replaced in a single event.

Information may need to be integrated before work can be transferred. A shared capability may need additional capacity before local teams can release responsibility. New decision rights may require changes to policy, governance forums, budgets, roles, and measures. Technology may lag behind organizational changes. Some duplication may be necessary during transition.

A credible transition should identify:

Which decisions must occur first
Which capabilities are prerequisites
What can be piloted
What must remain temporarily duplicated
Which responsibilities move at each stage
How service continuity will be protected
What evidence will justify the next step
Which assumptions must be tested
What conditions would pause, revise, or reverse the change

The target model describes the intended arrangement. The transition model describes how the organization will become capable of sustaining it.

Without that transition logic, the target is an aspiration rather than an operating design.

Test the Model With Real Decisions

An operating model can appear coherent in abstract language and fail immediately when applied to a concrete situation.

Scenario testing is one of the best ways to expose hidden ambiguity.

Consider what happens when:

Two business units want conflicting changes to a shared capability
A local market requests an exception to an enterprise standard
A customer issue crosses product and regional boundaries
Demand exceeds the capacity of a shared team
A supplier misses a critical commitment
A regulatory change affects only one jurisdiction
Enterprise and local performance measures recommend different priorities
A new product requires information the common model does not yet support

For each scenario, ask who decides, what information is required, which capability performs the work, how the issue is escalated, who bears the cost, and how the outcome is measured.

A model that cannot answer ordinary conflict is not yet an operating model. It is a statement of intent.

A Practical Example: One Customer Experience Without One Monolithic Organization

Consider an enterprise with several regional business units. Leadership wants customers to receive a consistent experience regardless of which region serves them.

The first proposal is to centralize customer service.

A business architecture assessment shows that customers do need several common elements. They need a single identity across regions, consistent service commitments, transferable case information, comparable measures, and a clear escalation path. These needs justify enterprise coordination and common enabling capabilities.

The assessment also shows that staffing, scheduling, regulatory interpretation, relationship management, and some customer exceptions depend heavily on local conditions. Moving all authority to a central organization would separate decisions from market knowledge and could slow resolution.

A more coherent operating model might therefore:

Establish an authoritative customer identity and common service information
Define enterprise service commitments and escalation rules
Use a shared case platform with consistent minimum information requirements
Place platform governance and capability design at the enterprise level
Retain regional authority for staffing, scheduling, and defined categories of exception
Create a cross-regional forum with explicit authority over investment priorities and unresolved conflicts
Measure both the end-to-end customer outcome and the operating conditions faced by each region
Review exceptions to determine whether they represent legitimate variation or recurring design failure

This arrangement is not fully centralized or fully decentralized. It separates the things that require enterprise coherence from the things that benefit from local judgment.

That is the point of operating model design. The objective is not to place the organization into a fashionable category. It is to create an arrangement that can deliver the intended outcome under real conditions.

Common Failure Modes

Operating model work tends to fail in recognizable ways.

A Reorganization Masquerades as an Operating Model

The enterprise changes reporting lines but leaves policy, funding, information ownership, measures, and decision rights untouched. The visible structure changes while the underlying behavior remains the same.

Shared Services Are Created Without Service Management

A capability is declared shared, but no one defines demand intake, prioritization, service expectations, capacity planning, funding, or escalation. The result is usually a queue, local workarounds, and declining confidence in the shared model.

Enterprise Standards Have No Exception Logic

Leadership mandates consistency without defining when variation is legitimate or who can approve it. Local teams either ignore the standard or escalate routine matters until governance becomes a bottleneck.

Governance Forums Exist Without Decision Rights

A committee meets, discusses, and recommends, but no participant has recognized authority to resolve conflict. The organization creates another coordination cost without creating a decision mechanism.

End-to-End Accountability Is Added to Functional Measures

A leader is made responsible for a value-stream outcome, but participating functions continue to be funded and measured only on their local results. The new accountability remains ceremonial.

“Federated” Becomes a Substitute for Design

The word federated is used to avoid choosing what is common, what is local, and who decides. A real federated model requires more precise boundaries and governance, not less.

Capacity Is Assumed Rather Than Designed

A centralized or shared capability is given additional demand without the staff, skills, funding, or technology needed to absorb it. Strategic desirability is confused with operational feasibility.

The Target State Has No Transition

Leadership approves an attractive future model without confronting temporary duplication, knowledge transfer, system dependencies, policy changes, and the loss of local control required to reach it.

The Model Attempts to Resolve Everything

The design expands until it includes every organizational problem. Scope becomes unmanageable, decisions are postponed, and the work produces a comprehensive picture without a usable commitment.

The remedy is to return to the specific outcome and operating decision that justified the work.

The Minimum Useful Operating Model Work Product

An operating model engagement does not need to begin with a large document or an exhaustive collection of diagrams.

A useful initial work product can be a concise operating model decision brief containing:

The decision and its boundary
The outcome, organizational scope, participating leaders, and the choice that must be made.
The current operating constraints
The capability gaps, information problems, structural dependencies, capacity limits, incentives, and inherited arrangements that shape the decision.
The target operating choices
What will be common, what will remain local, what will be shared, what will be transferred, and what will be performed externally.
The capability implications
Which capabilities must improve, where they will be governed, where they will be performed, and what dependencies they require.
The critical flows across boundaries
The information, work, funding, policy, and decisions that must move reliably between organizational elements.
Decision rights and accountability
Who establishes policy, sets priorities, allocates resources, approves exceptions, resolves conflict, and changes the model.
Capacity, funding, and measures
How the model will be resourced, how demand will be managed, and how leaders will know whether it is producing the intended outcome.
Scenario tests
A small set of realistic conflicts or exceptions used to test whether the arrangement is complete.
Transition and review points
The sequence of change, prerequisites, pilots, interim arrangements, evidence thresholds, and conditions for revising the design.

This is enough to support a consequential leadership discussion. Additional detail should be developed where the decision requires it, not merely because another artifact could be produced.

The Business Architect’s Role

The business architect should not act as though the operating model is a diagram that can be designed in isolation and handed to the organization.

The work is to help leaders make a coherent set of choices.

That requires translating strategy into operating implications, identifying what the current arrangement already accomplishes, exposing contradictions, clarifying decision rights, testing the design against real scenarios, and connecting the target model to the initiatives and capability improvements needed to make it feasible.

It also requires institutional realism.

Formal authority may differ from informal power. A shared capability may be resisted because local leaders expect poorer service or loss of control. A proposed owner may lack budget or staff. A common standard may fail because the information required to enforce it does not exist. A governance body may be legitimate on paper but unable to settle disputes among senior leaders.

These are not reasons to abandon the design. They are conditions the design must address.

A business architect adds value by showing not only what is strategically desirable, but also what the enterprise would have to believe, fund, govern, measure, and change for that model to work.

Business Architecture Belongs in the Operating Model Conversation

An operating model is where strategic ambition meets institutional reality.

It determines how the enterprise will coordinate across boundaries, where authority will reside, what must be common, where variation will be protected, how shared capabilities will be managed, and how performance will be judged.

Business architecture gives leaders a way to examine those choices without reducing the enterprise to the current organization chart or the next technology platform.

Capabilities show what the enterprise must be able to do. Value streams show how outcomes are produced. Information shows what must be consistently understood and exchanged. Organization shows where authority and capacity reside. Strategy and initiatives show whether investment is building the required future. Measures show whether the model reinforces the outcome or quietly rewards something else.

The contribution is not a universal template. It is a disciplined way to make the operating choices explicit, understand their consequences, and create an organization capable of sustaining them.

Strategy describes what the enterprise intends to accomplish.

The operating model determines how the enterprise will repeatedly act on that intention when the work becomes difficult.

The Business Architecture Cookbook provides practical recipes, work products, and starting points for business architects who need to translate architecture into decisions an organization can understand, govern, and implement.