From Enterprise Architecture as a Strategy to Business Infrastructure as a Platform – Part II of II

April 19, 2021
Tags: , , , , , ,

It is still about you: 
We want to expand our view from the discussed question in Part I on:
How you can ensure that you establish a good, long term strategy for your business
to:
how to build a solid foundation that matches your individual business model, providing just the right level of standardisation & Freedom in implementing business processes and IT.

Now, In part II We’ll Extend and finalise the framework, that intends to help you how a Business-IT Platform could look like with focus to to adjust your individual investments in that area to the optimal level.

InPart II of II: From Operating Model to Platform and Execution

In Part I, we used Ross/Weill/Robertson’s operating model to create a shared language between business and IT leadership. We also introduced two leadership-grade artifacts that prevent “initiative churn”:

  • a clear classification of the operating model (integration vs. standardization)
  • a one-page enterprise architecture view that explains how the business executes

In Part II, we extend that strategic foundation into execution. The aim is to connect four concerns that are often discussed separately:

  1. Strategy and operating model (what the business must optimize)
  2. Enterprise architecture layers (what needs to be standardized vs. flexible)
  3. How teams collaborate (how change is delivered sustainably)
  4. A platform model (how you reduce friction and increase reliability at scale)

Recap: The strategy-to-execution bridge

The operating model is not just a categorization tool—it is a decision aid. It helps leadership choose the right boundaries for standardization and integration so that IT investment matches the business model.

Figure 1 (Strategy to execution framework)

What to look for: the left side (strategy/operating model/architecture layers) drives choices on the right side (team setup and platform capabilities).

The core message from Part I still holds:

  • Leadership must own the thinking (do not delegate it to “sherpas”).
  • Alignment is a prerequisite for durable change (Kotter’s urgency + guiding coalition + culture).

Extending the framework: Execution requires teams and platforms

To turn strategy into results, we need an operating system for delivery and operations.

The extended framework links:

  • Grand strategy → operating model → foundation for execution
  • Enterprise architecture layers (business architecture, information/data, applications, technical infrastructure)
  • Interdisciplinary teams (how we coordinate scope, work, and competencies)
  • Platform capabilities (how we enable consistent delivery and reliable operations)

A key assumption runs through this model: optimize the overall system, not local silos.

Walk-through scenario: A Unification operating model (standardization at scale)

To make the mechanics concrete, let’s use a simplified scenario in the Unification quadrant (high integration + high standardization). This is the quadrant where platform thinking is often the highest-leverage move—because reuse and consistency create compounding returns.

Reconsider the Delta airline one-page architecture from Part I:

Figure 2 (One-page enterprise architecture (airline example)

What to look for: tightly coupled value streams and operations, where reliability and end-to-end coordination are strategic.

Airlines are a useful metaphor because they combine:

  • complex operations (fleet, routes, crew, maintenance)
  • high safety and compliance constraints
  • deep integration with external ecosystems (airports, border control, baggage systems, travel security)
  • frequent change (new destinations, partnerships, shifting demand)

Now imagine the airline launches a new destination on another continent. That triggers a repeatable chain of work:

  • extend infrastructure capacity and network connectivity
  • deploy the operational runtime and supporting services
  • roll out and integrate core business systems in that region
  • test, train, and operate with high reliability

In parallel, product teams continue evolving the architecture and business capabilities. This is where many organizations discover a hard truth: delivery speed depends on operations maturity, and operations maturity depends on standardized, automated, self-service foundations.

From “Operations” to a Platform Team

In many enterprises, operations begins as a service desk and a set of runbooks. Over time—especially in unification models—it must evolve into a product-like organization that delivers reusable capabilities.

Figure 3 (Evolution from operations to platform team)

What to look for: a shift from ticket-driven work to productized capabilities consumed by “internal customers.”

In the scenario, operations expands its mission and forms a platform team, staffed with a blend of SRE/ops, architects, security specialists, and experienced engineers from business IT.

Platform intent

The platform team treats business IT teams as customers and focuses on:

  • standardizing and automating repeatable work
  • reducing lead time from idea to production
  • improving reliability and security through shared mechanisms
  • enabling global rollout with consistent controls

Platform vision

Make the deployment and operation of complex business systems feel as consumable as provisioning compute—without losing governance, compliance, or resilience.

How the platform is built (the realistic path)

  • start with pilot teams and real workloads
  • generalize what works into reusable templates/guardrails
  • measure incidents, lead time, change failure rate, and service health
  • iterate continuously with feedback loops

The critical practice here is not “more governance.” It is better mechanisms:

  • paved roads (golden paths) instead of gatekeeping
  • automation instead of manual approvals
  • observability and policy-as-code instead of opaque control

Positive effects when the platform approach works

When the platform becomes credible, you typically see compounding effects:

  • Higher reliability with fewer heroics (automation replaces tribal knowledge)
  • Faster delivery because environments and controls are self-service
  • Better security posture because standards are implemented as defaults
  • Improved staff mobility (teams can swap specialists because the toolchain is consistent)
  • More trust between leadership, delivery, and operations (transparent metrics and shared ownership)

This is where your “human-centric, business-driven” point is important—but it needs to be expressed as an operating principle, not a motivational passage:

  • Humans scale complex systems; design for learning, not blame.
  • Strategy sets direction; teams need autonomy within clear boundaries.
  • Platforms reduce cognitive load; they don’t eliminate accountability.

“Manage with scientific methods”: What it means in practice

You reference the “manage with scientific methods” idea (commonly associated with Lean thinking). For this audience, it helps to anchor it to an actionable loop:


Figure 4 (Manage with scientific methods)

What to look for: feedback loops that treat work as hypotheses and improve decisions over time.

In practice:

  • treat major backlog items as hypotheses
  • make work visible and measurable
  • run disciplined reviews and retrospectives
  • use data to improve architecture, processes, and platform capabilities

This is the management counterpart to engineering iteration: controlled change, fast learning, and steady improvement—at enterprise scale.

Three management artifacts to orchestrate scope, work, and competencies

1) An enterprise backlog (portfolio-level visibility)

Collect and prioritize requirements derived from strategy and architecture into a single enterprise backlog. This is not “one Jira board”; it is a governance view that lets leadership see trade-offs, dependencies, and sequencing.

A simple user story template is fine, as long as it connects to outcomes:

  • As a… I want… so that…
  • include constraints: Compliance, resilience, cost, data locality, SLAs, etc.

Key principle: cross-functional leaders jointly assess business value, risk, effort, and dependencies so teams work on the highest-value items at the time.

2) Amplified learning (feedback that improves decisions)

Backlog priorities and designs are based on assumptions. Only delivery and operation validate them. Create a regular cadence of:

  • reviews (did we deliver the intended outcome?)
  • retrospectives (what did we learn about the system and our process?)
  • incident learning (what did failure teach us about architecture and controls?)

Over time, this reduces misalignment and improves estimation, sequencing, and architectural coherence.

3) Standardize what does not differentiate

This is the strategic payoff from Part I:

Use the operating model and one-page architecture to decide what is:

  • commodity (standardize, automate, platformize)
  • differentiating (keep flexibility, optimize locally, iterate faster)

Apply this consistently across:

  • organizational architecture (policies/decision rights)
  • IT business architecture (process/data/app patterns)
  • technical architecture (runtime/platform/toolchain/security controls)

A note on hyper scalers: Don’t copy the outcome – copy the mechanism

The airline scenario makes one thing clear: hyperscalers didn’t win primarily because they bought more hardware. They won because they built platforms and operating models that made change cheap and safe at scale.

For IT leadership, the real strategic question is:

  • Does your business model fit naturally into a hyperscaler ecosystem (services + constraints + shared responsibility)?
  • Or do you need flexible compute/storage/network capacity while retaining tighter control – often in a hybrid posture?

A pragmatic pattern many enterprises adopt:

  • standardize on portable layers (e.g., Kubernetes)
  • use common storage and integration patterns where appropriate (e.g., S3-compatible APIs in some contexts)
  • build a consistent delivery and ops toolchain across environments
  • treat the platform as the unit of standardization, not individual projects

Closing

Part I gave the strategic lens: operating model → one-page enterprise architecture → standardization boundaries.
Part II completes the execution view: interdisciplinary teams + platform capabilities + feedback loops that keep change sustainable.

The result is a practical progression:
Enterprise Architecture as Strategy → Foundation for Execution → Platform as a Product → Faster, safer change at scale.