Two-Speed IT Is a Symptom, Not a Strategy

Almost every enterprise architecture group we work with has, at some point, drawn the same picture: a slow-moving core of ERP, billing, and record systems on one side, and a fast-moving layer of digital channels, apps, and experiments on the other. Two-speed IT. It works — for about eighteen months. Then the fast lane accumulates its own integrations, its own undocumented data flows, its own retiring champions, and you discover you have not solved the agility problem. You have franchised it. The uncomfortable truth is that two-speed IT is a diagnostic finding, not an operating model. It tells you exactly where your architecture is unable to absorb change. The job of enterprise architecture is to close that gap, not to institutionalise it.

Agility Is a Property of Coupling, Not of Teams

Leaders often respond to slow delivery by changing team topology: new squads, new product owners, new funding model. Useful, but insufficient. If a pricing change requires coordinated releases across a commerce front end, an order management layer, and a monolithic ERP with embedded pricing logic, no amount of ceremony will make that change fast. The constraint is architectural coupling, and it is measurable.

Practical diagnostics we use on assessment engagements:

• Change blast radius: for the ten most frequent business change requests of the last year, how many deployable units had to change together?
• Decision latency: how long from "we want to try this" to "it is live for a real customer segment"? Separate the approval time from the build time — they have different cures.
• Data ownership clarity: for each core entity (customer, product, price, order), is there exactly one authoritative system, or three plausible candidates?
• Reversibility: what fraction of changes can be turned off without a release? Feature flags and configuration are agility infrastructure, not developer conveniences.

These four numbers say more about your agility ceiling than any maturity model score.

As-Is Maps That People Actually Use

Most as-is landscapes fail because they are drawn for auditors rather than for decisions. A 400-box diagram nobody can read is not documentation; it is expensive wallpaper. The as-is artefact worth investing in is deliberately lossy: it captures capabilities, the systems that realise them, the integration style between them, and — critically — a health verdict per system.

We recommend classifying every application against two axes: business differentiation and technical fitness. That produces four honest verdicts — invest, tolerate, migrate, eliminate. Executives can debate those four words. They cannot debate a topology diagram. And because differentiation is a business judgement, it forces the conversation out of IT and into strategy, which is where architecture earns its budget.

To-Be Roadmaps in Increments That Deliver Value Alone

The failure pattern in to-be architecture is the three-year end-state that only pays off in year three. Business conditions change, sponsors rotate, and the programme is cancelled at 60% completion — leaving both the old and new estate running. That is how two-speed IT becomes permanent.

A better structure is a sequence of transitional architectures, each of which is defensible as a stopping point:

• Strangle before you replace: put an API or event boundary in front of the legacy capability first. That single step decouples consumers and buys optionality even if the replacement never happens.
• Extract the data before the logic: establishing an authoritative product or customer view usually unlocks more agility, faster, than re-platforming the application that owns it.
• Cap the old estate: a hard rule that no new functionality is added to a system marked migrate does more for the roadmap than any migration plan.
• Fund the boundary, not just the feature: integration and contract work needs its own line item, or it will be silently descoped by delivery teams under pressure.

In SAP Commerce and broader CX estates specifically, this is the difference between a composable ambition and a composable outcome: teams that first stabilise product, pricing, and order contracts can swap front ends and add channels routinely. Teams that start with the front end rebuild it again in two years.

Governance That Speeds Things Up

Architecture governance loses credibility when it functions as a review gate. Invert it. Publish a small set of standards — approved integration patterns, identity approach, data ownership rules, observability baseline — and pre-approve anything that conforms. Reserve human review for the genuine exceptions. Teams get faster because the default path is paved; architects get leverage because they spend their time on the decisions that actually carry risk.

Then measure the fast lane's exit. Every capability built in the fast lane should have a documented destination: either it graduates into the standard estate with proper ownership, or it is deliberately retired. Without that clause, the second speed never merges back.

The Goal Is One Speed, Variable Gearing

Mature estates do not run two speeds; they run one delivery model with different risk gearing per domain. A pricing experiment ships daily because the architecture makes it cheap and reversible. A general ledger change ships quarterly because that is genuinely appropriate. The difference is intent, not capability gap. Over the next few years, as AI-driven features push more decision logic closer to the customer, the enterprises that win will be those whose core data and integration contracts were designed to be extended — not those with the largest fast lane. Architecture's contribution is to make change cheap enough that agility stops being a programme and becomes a default.