Part I of II: Enterprise Architecture as a Strategy for Business Execution

Enterprise Architecture is most valuable when it helps leadership make durable choices: what must be standardized, what must be integrated, and where autonomy is a feature—not a flaw.

This post introduces a practical framework from Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Jeanne W. Ross, Peter Weill, David C. Robertson). The goal is not academic Enterprise Architecture. The goal is a shared language between business and IT leadership – plus an approch and a small set of artifacts that help you avoid “initiative churn” and invest in the right foundations.

By the end of Part I you will be able to:

• classify an organization’s operating model using two simple dimensions
• use that classification to guide standardization vs. differentiation decisions
• understand why a one-page enterprise architecture view is a strategic tool, not documentation theater

Part II builds on this foundation and moves into execution: organizing delivery and operations, and how platform thinking (cloud/edge) supports the chosen operating model.

The problem: Business and IT often optimize different things

In many organizations, strategy, forecasting, and operating priorities evolve on the business side while IT decisions follow a different rhythm—driven by lifecycle constraints, architectural debt, vendor contracts, security posture, and operational reliability.

The result is familiar:

• initiatives that are “important” but not consequential
• stalled transformations where the back office cannot support the front office
• consolidation or outsourcing projects that consume attention while market needs shift
• a persistent gap between “strategy” and “execution”

If you carry responsibility for long-term decisions—either as an executive, chief architect, or trusted advisor—you already know the hardest part: alignment. Not agreement in a meeting, but real alignment across leaders, managers, and delivery teams who will execute the strategy over years.

Why alignment is the highest-leverage investment

John Kotter’s work on change management is useful here, especially three stages that are consistently underestimated:

1. Create a sense of urgency
2. Build a guiding coalition
3. Anchor new approaches in the culture

In practical terms: investing early in a cross-functional leadership coalition and a shared model of the business is not overhead—it is the fastest path to speed later. If this alignment effort fails, that is signal too: you have likely surfaced a deeper structural issue that must be addressed before any transformation will stick.

The core idea: Classify the operating model before you standardize anything

Ross, Weill, and Robertson propose a simple but powerful move: Step back from current priorities and classify the organization’s operating model using two dimensions:

• Process integration: how much do business units need to share data and coordinate end-to-end processes?
• Process standardization: how consistently are processes executed across products, regions, or business units?

Figure 1 (Operating Model): A 2×2 model with Integration (low→high) and Standardization (low→high).

What to look for: Where your organization sits today—and where leadership believes it should sit.

These two dimensions yield four archetypes. Naming varies by source, but the common mapping is:

• Diversification (low integration, low standardization)
• Coordination (high integration, low standardization)
• Replication (low integration, high standardization)
• Unification (high integration, high standardization)

This is not about labeling. It is about consequences: each quadrant implies different economics of scale, different change dynamics, and different “right” levels of shared platforms and shared processes.

Why this matters in M&A and growth strategies

The operating model is especially predictive in mergers and acquisitions.

Table 1 (Growth strategies by operating model)

What to look for: which combinations require tight integration vs. allow coexistence.

A simple rule of thumb on how to make use of the table:

• In Diversification, coexistence is common; synergy is limited; integration pressure is lower.
• In Unification, integration is the strategy; synergy expectations are high; “rip and replace” becomes likely.

A useful checkpoint for leaders and advisors:
If you’ve experienced “half-baked” M&A integration, the operating model mismatch is often a root cause.

The key artifact: A one-page enterprise architecture

The 2×2 operating model gives orientation, but it’s not enough to execute. The authors therefore recommend creating a one-page architecture overview of the business.

This is where many EA efforts go wrong, so a few constraints matter:

• Do not delegate this to staff: leadership must do the work together
• Keep it to one page: poster-level clarity beats document depth
• It is not IT architecture: it is the architecture of value streams, core capabilities, policies, and information flows
• Control granularity: detail is the enemy; this is a shared mental model

Example 1: Unification model (high standardization + high integration)

Caption: A unified operating model: standard processes and integrated systems that optimize shared assets and end-to-end execution.

Figure 2 (One page architecture) Unified example of Delta Airlines

What makes this valuable is not the visual style—it’s the conversation it enables:

• what the business optimizes (e.g., asset utilization, operational efficiency)
• where events and feedback loops sit (“nervous system”)
• how changes in one area propagate across operations and customer experience

Example 2: Diversification model (autonomy with selective shared services)

Figure 3 (One page architecture) Generic Diversification example

The draft shows a business architecture with independent business units that build shared foundations (e.g., identity, integration standards, common tooling) where it creates leverage as a to deep level of standardisation their core business processes is often counterproductive.

The strategic decision: Standardize enough to scale, not so much that you suffocate the business

Standardization creates leverage—up to a point. Beyond that point it increases coordination cost, slows local optimization, and damages time-to-value. You called this the “corset” effect; the underlying mechanism is: over-standardization reduces organizational agility while raising friction.

The question is not “standardize or not.” The question is:

• what must be standardized to enable the operating model, and
• what should remain flexible to preserve differentiation and speed

Deriving the right level of standardization (enterprise architecture → IT architecture)

Once the operating model and one-page business architecture are aligned, you can map them to where standardization belongs:

Figure 4 (Mapping operational model to level of standardisation)

What to look for: how standardization guidance shifts depending on the operating model.

A practical mapping often looks like this:

• Unification: standardize business processes, policies, data, and applications broadly; IT follows.
• Coordination: standardize shared data and integration mechanisms; allow process variation where it matters.
• Diversification: standardize foundational IT (security baseline, identity, networking, shared tooling); keep business systems largely autonomous.
• Replication: standardize a repeatable business process “template” and platform; replicate units quickly with minimal integration.

This step is where the framework becomes operational: it prevents the common failure mode of standardizing everything “because it feels efficient,” or standardizing nothing “because autonomy feels faster.”

What to expect in Part II

Part I establishes the strategic foundation: operating model → one-page business architecture → standardization boundaries.

In Part II, I will move into execution:

• how to organize delivery and operations to support the chosen operating model
• how platform thinking (cloud and edge) can reduce friction while preserving the right autonomy
• how to avoid common pitfalls when turning strategy into a buildable, supportable architecture

Closing thought

A final disclaimer that I strongly agree with: frameworks are powerful, but they must be adapted to your constraints. As Alistair Cockburn put it: “You need to know your own swamp.” The same applies here. Use the model to drive alignment—and then tailor the resulting decisions to your context.