Operating Model Design FAQ for Architects

Practical answers to the questions practitioners ask when designing, implementing, and evolving operating models

This FAQ addresses the real questions business architects and enterprise architects encounter when working with operating models. It assumes you understand the basics of business architecture and are looking for practical guidance on design decisions, governance challenges, and evolution strategies.

Operating Model Fundamentals

What's the difference between an operating model and an organizational structure?: An operating model defines how capabilities are organized, governed, and coordinated to execute strategy, while organizational structure shows reporting relationships and hierarchy. Your operating model might specify that customer onboarding capabilities are centralized with shared services delivery, but your org chart shows whether those people report to Operations, Customer Experience, or Business Units. The operating model drives organizational design decisions, not the other way around. We see organizations get this backwards and end up with operating models that just document existing silos rather than designing for strategic outcomes.
How do I know if our current operating model is actually working?: Look for evidence in your value stream performance metrics and cross-capability coordination patterns. If you're seeing consistent delays at capability handoffs, duplicated investments across business units, or inability to respond quickly to strategic initiatives, your operating model likely needs attention. Heat map your capabilities against strategic priorities and assess whether your current organizing principles support or hinder those priorities. The most telling sign is when simple customer journeys require coordination across multiple disconnected organizational boundaries with different governance models.
Should we design our operating model around customer journeys or internal capabilities?: Start with customer value streams but organize around capabilities that can be combined flexibly across multiple journeys. A customer-journey-only approach leads to siloed, redundant capabilities that can't adapt to new market demands. Instead, identify the core capabilities needed across your key value streams, then design your operating model to optimize those capabilities for reuse and coordination. For example, 'Customer Identity Verification' should be designed as a shared capability that supports onboarding, lending, and servicing journeys rather than building separate verification processes for each.
What's the relationship between operating models and business capabilities?: Operating models define how capabilities are organized, governed, and orchestrated to deliver business outcomes. Capabilities are the building blocks; the operating model is the blueprint for how those blocks fit together. Your capability map shows what your organization does, while your operating model shows how those capabilities are structured, funded, and coordinated. When we design operating models, we're making decisions about capability ownership, shared services, centers of excellence, and governance models that directly impact how effectively those capabilities can be developed and deployed.
How detailed should an operating model be?: Detail it to the level needed for governance and investment decisions, typically to Level 2 or 3 capabilities with clear ownership and coordination mechanisms. Going deeper leads to process documentation; staying too high-level provides no actionable guidance. Your operating model should specify which capabilities are shared services, which are embedded in business units, how they're funded, and how they coordinate, but it shouldn't prescribe specific workflows or technology implementations. Think of it as the governance layer that enables detailed design decisions rather than making them.
Can one organization have multiple operating models?: Yes, and large enterprises often do, but they need explicit coordination mechanisms and clear boundaries. You might have different operating models for different business units, geographies, or product lines, especially in holding company structures or post-merger environments. The key is ensuring your operating models don't create conflicting governance or duplicated investments where you need coordination. We recommend mapping the interfaces between operating models and establishing clear protocols for shared capabilities, data, and customer touchpoints.

Operating Model Archetypes and Design Patterns

Which operating model archetype should we choose for our organization?: Choose based on your strategic priorities, organizational maturity, and coordination requirements rather than following industry trends. Centralized models work well for cost optimization and consistency but can limit agility. Federated models balance local responsiveness with shared standards but require strong governance. Platform models enable rapid innovation but need significant technology investment and cultural change. Most enterprises end up with hybrid models where different capability domains use different archetypes based on their strategic importance and coordination needs.
How do shared services fit into operating model design?: Shared services are a delivery mechanism within your operating model, not the operating model itself. Design shared services for capabilities where standardization and scale provide clear value, typically support functions like HR, Finance, or IT Infrastructure. But avoid the common mistake of automatically centralizing everything for cost savings. Customer-facing capabilities often need to remain close to business units for responsiveness. Your operating model should specify which capabilities become shared services, how they're governed, funded, and how they coordinate with embedded capabilities.
What's the difference between centers of excellence and shared services?: Centers of excellence provide standards, expertise, and guidance while shared services provide standardized delivery of capabilities. A Center of Excellence for Data Analytics might establish data standards, provide training, and share best practices across business units, while a shared data analytics service would actually perform analytics work for business units. Both can coexist in your operating model: the CoE ensures consistency and capability development while shared services provide efficient delivery. The key is clarity about whether you're standardizing expertise or standardizing delivery.