Pattern Name: Two-Speed IT (Bimodal IT) Category: EA Strategy / Operating Model Complexity: Medium Stability: Established: widely discussed, increasingly nuanced in practice
Modern organizations face two genuinely different types of IT demand simultaneously. On one hand, systems of record: core banking platforms, ERP systems, claims management systems: must be reliable, secure, compliant, and stable. On the other hand, systems of engagement: customer-facing digital channels, mobile applications, marketing platforms: must evolve rapidly to meet changing customer expectations and competitive pressure.
These two demand types have fundamentally different risk profiles, governance requirements, delivery cadences, and technology characteristics. Attempting to manage them with a single set of processes and standards tends to produce either an organization that is too slow for digital (standards designed for the system of record applied to customer experience) or too unreliable for operations (agile delivery practices applied to financial transaction processing).
How do you structure your technology organization and architecture to deliver reliable, governed core systems and rapid, innovative digital capabilities simultaneously, without compromising either?
The failure mode when organizations try to apply uniform processes to both is well-documented: either the compliance and change management overhead designed for core systems stifles digital delivery (making the organization uncompetitive), or the speed and agility designed for digital products is applied to core systems (creating operational and compliance risk). The organization cannot win.
Explicitly architect your IT operating model into two distinct modes with different processes, standards, risk tolerance, governance, and technology choices:
Mode 1: Systems of Record (Run IT): Optimised for reliability, stability, security, and compliance. Characteristics: batch processing or low-frequency updates; long-lived, well-understood data; high cost of failure; regulatory oversight; long technology cycles. Governance: heavyweight change management, full EA compliance review, documented architecture decisions, risk-assessed deployments. Typical examples: core banking, ERP, claims systems, HR systems, financial ledgers.
Mode 2: Systems of Engagement (Change IT): Optimised for speed of learning, customer responsiveness, and innovation. Characteristics: high-frequency change; customer-facing; A/B testing and experimentation; shorter technology cycles; lower cost of individual failure (because failures are contained and reversible). Governance: lightweight architecture principles, pattern-based self-service, rapid review cycles, automated compliance checking. Typical examples: mobile apps, web portals, marketing platforms, analytics dashboards, customer service tools.
The integration layer is critical: Mode 1 and Mode 2 systems must be connected but insulated from each other. An API layer (often the integration hub) provides Mode 2 systems with access to Mode 1 data and services through stable, versioned interfaces. This prevents Mode 2 changes from destabilising Mode 1 systems while giving digital teams the data access they need.
The two-speed model is not a permanent architecture: it is a transitional framework. Over time, cloud-native platforms are reducing the distinction: modern core banking platforms can be updated frequently without sacrificing reliability. But for organizations with significant legacy estate, the bimodal framework provides a practical governance structure.
Element types to use:
Diagram types: ArchiMate Application Architecture diagram with Mode 1 / Mode 2 / Integration Layer zones clearly delineated; technology architecture diagram showing platform segregation; governance process diagram (UML Activity) showing the different review paths for each mode
MDG considerations: The «ITMode» tagged value is the governance instrument. Every application in the portfolio should carry this tag: it drives which governance process applies, which delivery standards apply, and which technology standards apply. Build a model search template that lists all Mode 1 and Mode 2 applications separately. Validation rules should ensure every application has a mode assigned and a named owner. Over time, as Mode 1 systems are modernized onto cloud-native platforms, the mode designation may change: the tagged value makes this transition trackable.
Package structure: An Application Portfolio package with Mode 1 Applications, Mode 2 Applications, and Integration Layer sub-packages. A Governance package with principles and standards documents for each mode. A Technology Standards package with approved technology choices listed separately for Mode 1 (stability-focused) and Mode 2 (capability-focused) stacks.
EA GraphLink and AI integration: The two-speed model raises natural AI-answerable governance questions: “How many applications are classified as Mode 1?”, “Which Mode 2 applications directly access Mode 1 databases rather than going through the API layer?”, “What is the Mode classification of the Customer Portal?”. The last question: identifying direct Mode 2 to Mode 1 database connections: represents a security and governance risk that is easy to query via EA GraphLink but difficult to find manually. AI tools querying the model via MCP can surface these violations in real time as part of routine governance reporting.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.