Every organization that has run enterprise systems for more than a decade eventually arrives at the same uncomfortable truth: the systems that run the business well are the systems that must not change quickly, and the systems that win customers are the ones that must. Around 2010 this tension acquired a name and a shape. Two-speed IT — later popularised as bimodal IT — proposed running the enterprise technology estate at two different tempos. A stable, heavily governed core for finance, inventory and the general ledger. A fast, loosely governed edge for customer-facing applications, mobile experiences and experimentation. It was the right diagnosis. Whether it was the right prescription is a question organizations are still arguing about, and the AI wave has made the argument urgent again.
Why the Split Happened
The pressure came from both directions at once. On the core side, ERP had become genuinely load-bearing. A change to the general ledger structure touches statutory reporting, audit trails, tax filing and consolidation. Testing takes weeks because the consequences of an undetected error are material misstatement, not a bad user experience. Release cycles of six to twelve months were not bureaucratic sloth; they were proportionate to the risk. On the edge side, the competitive clock had accelerated sharply. Smartphones had created customer expectations that changed quarterly. Web-native competitors were shipping weekly. A business unit that had to wait for the next ERP release window to launch a customer feature was losing to companies with no ERP at all. Asking one governance model to serve both was producing two failures simultaneously: an edge that moved too slowly to compete, and a core that was being destabilised by changes pushed through at edge speed.
What the Model Got Right
Different systems genuinely carry different risk. The cost of an error in a marketing microsite is embarrassment. The cost of an error in revenue recognition is a restatement. Applying identical change control to both is either negligent or paralysing, depending on which way you standardise. Speed is a capability, not a shortcut. Teams shipping weekly develop better testing, better monitoring and better rollback than teams shipping annually, because they have to. The edge was frequently more disciplined than the core, not less. It gave business units a legitimate path. Before the model existed, urgent work routed around IT entirely and became shadow systems. A sanctioned fast track brought that work back into visibility.
What It Got Wrong
The failures were consistent enough that by the mid-2010s the model had attracted serious criticism. The boundary was never as clean as the diagram. Edge applications need core data. A customer-facing ordering app needs inventory, pricing and credit status from the system nobody is allowed to change quickly. The interesting work always lands exactly on the seam. It created two classes of team. One group got modern tooling, autonomy and interesting problems. The other maintained systems of record under heavy governance. Talent moved in one direction, and the core — the part that actually could not fail — gradually lost its strongest engineers. Integration debt accumulated invisibly. Each fast-moving edge application built its own connection to the core. After five years, the core had dozens of undocumented integrations, each a constraint on the change it was supposedly protected to receive safely. "Stable" became an excuse. Systems labelled core stopped being modernised at all. Stability was intended to mean controlled change; it was frequently interpreted as no change, which produced exactly the legacy crisis the model was meant to prevent.
What Replaced It
The more durable idea that emerged is not two speeds but appropriate speed with a common standard of engineering quality. Every system gets automated testing, version control, monitoring and a rollback path. What varies is release cadence, approval depth and blast radius — driven by the consequence of failure rather than by which side of an organisational line the system sits on. The architectural enabler is a clean interface layer. When the core exposes well-defined, versioned services, edge applications can move quickly without touching core internals, and the core can be modernised behind a stable contract. That is the difference between a genuinely layered architecture and two silos with point-to-point connections between them. The modern ERP equivalent is the clean core principle: keep the standard system standard, push extensions outside it onto a platform layer, and integrate through supported interfaces. It is the same insight, expressed as an architectural rule rather than an organisational one.
| Decision | What to define |
|---|---|
| Standard | Consistent testing and ownership across core and edge. |
| Cadence | Release pace matched to consequences. |
| Impact | Explicit approval and blast radius. |
| Interfaces | Ownership of versioned boundaries. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Making the Split Work
- Classify by consequence of failure, not by department. A revenue-affecting edge application deserves more control than an internal reporting tool inside the core.
- Invest in the interface layer first. Versioned APIs over the core are what make different speeds possible. Without them you have two silos and a growing pile of brittle integrations.
- Hold one engineering standard. Testing, source control, monitoring and rollback apply everywhere. Speed varies; quality does not.
- Rotate people across the boundary. It prevents the core from becoming a career backwater and spreads modern practice into the systems that need it most.
- Budget core modernisation explicitly. Stability must be funded as continuous maintenance, not treated as an excuse for deferral. Deferred core change becomes a crisis programme.
- Register every integration. Owner, contract, version, criticality. Undocumented integrations are what actually prevent the core from changing.
- Review the classification annually. Systems migrate between categories as the business changes. A stable-core list written five years ago describes a company that no longer exists.
The AI Version of the Same Question
AI adoption has recreated the split almost exactly. Experimentation is happening fast at the edge — content generation, customer support drafts, code assistance, analysis — with light governance and high tolerance for imperfect output. Core finance and operations are moving slowly, and correctly so, because an unexplained figure in a statutory report is a different category of problem from an awkward sentence in a marketing draft. The organizations handling it well are applying the lesson learned from bimodal IT rather than repeating it. They are not building an AI edge disconnected from a frozen core. They are defining clear interfaces between AI capability and systems of record, requiring the same engineering discipline in both places, and varying only the review depth and the tolerance for error. The insight from 2010 remains correct: not everything should move at the same speed. The mistake was believing that speed is a property of teams rather than a property of decisions.
Common Questions
What is two-speed or bimodal IT?
An architectural and organisational model that runs stable systems of record such as ERP under heavy governance and slow release cycles, while running customer-facing and experimental systems at a faster, lighter-governance tempo.
Why did bimodal IT attract criticism?
Because the boundary between core and edge is rarely clean, it created two classes of team with talent concentrating on one side, and it allowed core systems to stop being modernised under the label of stability.
What is a better alternative?
A single engineering standard — automated testing, version control, monitoring, rollback — applied everywhere, with release cadence and approval depth varying according to the consequence of failure, supported by a versioned interface layer over core systems.
How does this apply to AI adoption?
The same pattern is repeating: fast edge experimentation against slow-moving finance and operations systems. The durable approach is clear interfaces between AI capability and systems of record, with consistent engineering discipline and varied review depth.
Architecture Strategy Session — Outpace classifies your systems by consequence of failure, builds the interface layer that lets your core and edge move at different speeds safely, and stops stability being used as a word for neglect.