Understanding Operating Models for Strategic Architecture Decision Making

One of the most critical insights I’ve gained in my work as both an architect and consultant is how incredibly powerful it can be to understand an organization’s operating model—particularly the degree of business process integration and standardization across different units. This perspective, inspired by Enterprise Architecture as Strategy, directly influences how we design systems (like Salesforce), manage mergers and acquisitions, and quickly pivot when business strategies change—sometimes without warning.

In this article, I’ll explain how the concept of operating models can guide strategic architecture decisions, share real-world examples that illustrate why alignment matters, and show how this framework keeps technology in lockstep with business priorities.

What Is an Operating Model?

In broad business literature, an “operating model” can have many meanings—organizational structures, governance styles, resource management approaches, and more. In Enterprise Architecture as Strategy, however, the authors narrow the focus to two main dimensions:

1. Process Integration – The extent to which different business units share processes and data.
2. Process Standardization – The degree to which these processes are executed in a uniform way across the organization.

By assessing each dimension (low or high), we get four typical operating models: Diversification, Coordination, Replication, and Unification. This simplified view is incredibly effective because it links business strategy directly to IT and architecture decisions.

Table 1: High-Level Characteristics of Four Operating Models

Real-World Tales of Operating Models

1. Org Mergers Gone Wrong

Many years ago, I saw an IT shop pushed to merge two Salesforce orgs with the rationale of “reducing IT overhead.” On paper, this seemed practical—but the two business units in question had entirely different customers, processes, and strategic goals. In essence, they operated under a Diversification model (low integration, low standardization). Naturally, the forced merger caused friction, confusion, and a mountain of extra work. Eventually, business leadership decided to reverse the IT decision. Had they jointly considered that these units were more “diversified” than “unified,” they would have realized the merger would likely do more harm than good.

Key Lesson

A technology-centered push (e.g., “save on licensing/IT costs”) should never override the deeper question of whether business units actually need to share processes or data.

2. Unification by Acquisition

On the flip side, I encountered an organization that was aggressively acquiring businesses in the same industry. Their goal was to standardize operations and present a single face to the customer worldwide. This made it crystal clear that the company was pursuing a Unification strategy—high integration (shared data) and high standardization (uniform processes). Consolidating multiple Salesforce orgs and aligning workflows across newly acquired entities was complex and expensive – “We got about 100 people humming around this”, but it unlocked global visibility and efficiency.

Key Lesson

When a firm’s strategy is to unify its operations, the effort to integrate and standardize IT systems is essential rather than optional. Trying to keep everything separate would impede the goal of operating (and appearing) as one cohesive organization.

3. The Pivot from Centralization to Break-Up

A particularly dramatic story comes from a CIO who joined a large conglomerate expecting to centralize IT. Within months, the board decided to break up the conglomerate into independent companies. Overnight, the strategy swung from Unification (high integration, high standardization) toward a Diversification or Replication approach. Recognizing the shift, the CIO promptly stopped expensive centralization initiatives that no longer served the new business direction.

Key Lesson

Business strategies can change fast. If you keep an eye on the operating model, you’ll be more agile in adapting your architecture to the new reality—whether it’s integrating everything or carving it all apart.

Applying Operating Models to Architecture Decisions

An organization’s position on the integration and standardization scale has direct implications for how architects should design, govern, and adapt systems. For instance:

• High-integration organizations typically need robust data-sharing mechanisms and cross-unit processes, guiding them toward centralized platforms.
• Low-integration organizations can function effectively with multiple, loosely coupled systems.
• High-standardization organizations demand uniform processes and consistent configurations.
• Low-standardization organizations can tolerate local autonomy and customizations.

Table 2: Operating Models for Architecture Considerations

Salesforce Architects: Operating Models in Action

The operating model framework is especially relevant for architects working with Salesforce, a flexible and powerful enterprise platform. Below are a few specific examples:

Single vs. Multiple Orgs

Deciding to implement a single Salesforce org or multiple orgs can be one of the most consequential choices an architect makes:

• Diversification Model: Multiple Salesforce orgs often make sense. Each business unit can define its own sales process, data model, and automation without polluting or constraining others.
• Unification Model: A single Salesforce org is best to ensure uniform data definitions, shared automation, and consistent user experiences across all units.

In the scenario where an IT executive merged two Salesforce orgs purely based on IT concerns, ignoring that the underlying businesses had no overlap in customers. The clash was inevitable, and eventually, the orgs had to be separated again—wasting time, money, and stakeholder goodwill.

Data Architecture Decisions

• Coordination Model: You’ll likely need a shared data backbone—perhaps a master data management (MDM) approach—while still allowing each unit to customize local processes. MDM is never easy in my experience. So make sure to collaborate with the business side to have operation support for any technical implementation.?
• Replication Model: Standardized process templates are key, but each business unit can maintain its own data. This typically means multiple Salesforce orgs or at least separate partitions of data, all configured in an identical manner. My friends at a car manufacturer distributed packages to more than 100 orgs at regional dealerships.?

By recognizing these subtleties upfront, you can build a future-proof Salesforce architecture that matches how the business actually operates—and pivot more easily when things change.

Consulting Insights and Best Practices

From a consulting standpoint, the operating model concept is an invaluable diagnostic tool:

1. Diagnose Quickly Ask about existing systems, how many separate IT environments exist, and whether (and how) data is shared. This quickly reveals if you’re dealing with a Diversification, Coordination, Replication, or Unification model.
2. Tailor Your Solutions Avoid imposing a one-size-fits-all solution. For instance, a Unification mindset means an enterprise-wide system is vital. A Diversification mindset requires autonomy and minimal forced integration.
3. Anticipate Strategic Shifts Mergers, acquisitions, and spin-offs happen regularly. Build modularity and flexibility into your architecture so you can adapt when an organization swings from “tightly integrated” to “fully autonomous” or vice versa.
4. Push Back When Needed If you see an architecture decision that contradicts the operating model—like merging what should remain separate, or keeping separate what should be unified—raise the issue early. You’ll save your client or employer a lot of grief.

Case in Point: I once consulted for a client who had over a dozen different systems, each handling some aspects of an overall business process. It became obvious that Coordination was the real need, which needed a strong data integration strategy (with an integration platform and a standardized data model) while allowing each system to automate its part of the business process. This realization created win-win opportunities for the client and the consulting firm.

Conclusion

Understanding an organization’s operating model isn’t just a nice strategic exercise; it’s fundamental to successful architecture decision-making. By focusing on process integration and process standardization, architects and IT leaders can:

• Prevent costly missteps—like merging systems that should remain autonomous or fracturing what should be unified.
• Spot strategic opportunities—for example, when acquisitions require eventual data and workflow consolidation.
• Navigate sudden pivots—because business strategies can flip from centralization to break-up (or vice versa) practically overnight.

Whether a company is consolidating global operations, absorbing newly acquired businesses, or spinning off entire divisions, matching technology and data decisions to the right operating model sets the stage for both operational efficiency and organizational agility. With this framework in mind, architects and IT leaders transcend the role of mere technical enablers; they become indispensable strategic partners, guiding the enterprise toward lasting success.

References:

1. Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business Press.
2. MIT Center for Information Systems Research (MIT CISR) for extended research on enterprise architecture and IT governance.