- New Insights
- Whitepaper
Designing Retail IT Architecture for Agility
How Execution-Centric Architecture Built on Unified Commerce Unlocks Scalable Change
Many retailers have chosen Unified Commerce - but still struggle to scale, adapt, or innovate. This Insight explains why agility isn’t a product feature, but an architectural outcome - and how execution-centric design enables faster change, lower risk, and AI-readiness.
Table of Contents
But the platform alone is not the final enabler - it’s the foundation. What determines whether that foundation unlocks real-time execution, modular innovation and AI-readiness is not just what you’ve chosen, but how you structure it.
Because agility doesn’t begin with tooling. It begins with architecture - and more specifically, with where execution lives and how logic flows across the organization. When pricing, inventory, promotions and customer logic are still distributed across legacy systems, agility becomes a coordination effort. But when these flows converge in a unified, real-time core, change becomes safe, repeatable and fast by design.
That’s the role of execution-centric architecture: a structure where Unified Commerce is not just connected to other systems, but becomes the operational center - where decisions are made, customer journeys are orchestrated, and business logic becomes modular and replaceable.
In this Insight, grounded in executive interviews, architecture programs and industry benchmarks, we outline:
- Why complexity often persists even after selecting a Unified Commerce platform.
- How fragmented orchestration limits adaptability and delays value realization. What structural capabilities are required to support initiatives
- like click & collect, transfer orders, fiscal logic and AI. How to design an architecture that reduces friction - without compromising governance, traceability or control.
Executive Summary
Why Retail Agility Begins with Structural Design
Retailers continue to invest in Unified Commerce platforms - but architecture still determines whether that investment leads to agility or friction. This insight outlines how execution-centric architecture enables speed, modularity, and replaceability by design - not integration effort.
1. Architecture Still Limits Execution Speed
Despite modern platforms, most retailers operate in fragmented environments. With 66–152 systems in play, every change activates risk, rework and delay. Integration alone doesn’t fix this - structural simplification does.
2. ERP Is Critical - But Must Be Contained
ERP remains essential for finance, compliance and control. But when it governs promotions, pricing or fulfilment logic, it slows the business. Execution must be separated from finance to enable responsiveness at scale.
3. Synchronization Introduces Latency and Risk
Relying on batch syncs and cross-system orchestration adds complexity with every new capability. Real-time execution requires real-time structure - not patched integrations.
4. Modularity Enables Safe, Repeatable Change
Execution-centric design allows retailers to adjust, upgrade or replace systems without systemic regression. Change becomes testable, local and reversible - not high-risk.
Conclusion:
Agility doesn’t come from integration. It comes from where execution lives - and how well the architecture is designed to support it.
Unified Commerce is the right foundation - but agility depends on what you build around it.
Retailers must design for change: placing execution where it belongs, simplifying what slows them down, and preparing for AI to operate across the business. Agility isn’t a feature. It’s a structural choice.
1. From Vision to Architecture
Why Unified Commerce Is Not the Solution but the Structure That Makes Solutions Possible
Retailers have spent years modernizing at the surface while architecture remained unchanged underneath. E-commerce engines layered onto ERP. Loyalty platforms bolted next to CRM. Real-time POS applications grafted onto batch-based fulfilment logic. The result is a technology landscape that looks modern - but behaves like it’s still 2002.
You can’t innovate around customer experience if your architecture still reflects 2002.
- CTO, Global Specialty Retailer (Deloitte, 2024)
Unified Commerce is often introduced as the fix. But it’s not a product - and certainly not a finish line. It is a structural decision. And unless it becomes the execution layer - the place where pricing, promotions, inventory and customer logic come together in real time the result is just a more responsive version of the same fragmented architecture.
Modern Best-of-Breed tools may promise agility. But no platform can compensate for architectural misalignment. In many cases, the problem isn’t what the systems do - it’s where logic lives, how orchestration is handled, and whether change can occur without triggering cross-platform regression.
Why Architecture Still Can Limit Retail Execution
Despite platform and Best-in-Breed investments, most retailers continue to experience operational drag.
According to Gartner’s 2024 CIO Study:
% of Retail CIOs Impacted by the following issues
Limited organizational agility74%
Persistent integration complexity69%
Fragmented siloed data65%
Vendor and middleware overhead60%
Governance challenges due to architectural sprawl57%
These are not software problems. They are structural outcomes - caused by architectures that prioritize internal ownership over end-to-end responsiveness. No matter how advanced the tooling, execution can only move at the speed the architecture allows.
Why “Best-of-Breed” Often Builds the Worst Outcomes
Retailers typically operate with 66 to 152 systems spread across customer, operational and integration layers. Some of these tools are best-in-class. But collectively, they create overlapping logic, duplicated responsibilities, and orchestration that’s brittle by design.
Instead of clarity, integration layers often introduce abstraction - adding technical glue but losing business context. When every function lives in its own tool, each with its own sync rules, business logic and data model, agility breaks down. Not because the tools are weak - but because the structure can’t absorb change.
# of Systems per Application Layer
Customer-Facing Applications | 25 ~ 55 |
Operational Enablement Tools | 18 ~ 35 |
Middleware & Integration Layers | 5 ~ 12 |
Custom Utilities & Reports | 10 ~ 30 |
ERP & Backoffice Systems | 8 ~ 18 |
Total per Retailer | 66 ~ 152 |
FrankenStacks aren’t built by accident - they emerge when well-meant choices lack architectural direction.
Albert Visser - SME Blueprinting and Logistic
Two Structural Paths - One Real Choice
Adopting Unified Commerce doesn’t remove architectural decisions - it exposes them. Retailers face a fundamental choice:
Either extend orchestration around existing systems - surrounding platforms like CRM, OMS and promotion engines, and downstream systems such as ERP - preserving vertical control.
Or redesign the execution layer entirely - consolidating customer logic into one real-time platform, with downstream systems like ERP supporting where needed.
This is not a tooling distinction. It defines where data lives, how fast change can happen, and whether the organization can scale horizontally through replaceability - or vertically through integration control. A 2024 McKinsey study on retail transformation found that:
Retail IT-Architecture Choices Have Measurable Impact
Retailers still choosing Best-of-Breed tools based on departmental requirements82%
Retailers facing recurring integration pain72%
But those that align architecture around execution – rather than systems or reporting lines – report:
Increase in operational agility+35%
Reduction in integration issues-40%
2. Building for Agility: Reframing the Role of ERP in Execution-Centric Architecture
Why Structural Simplicity - Not System Loyalty - Determines Retail Responsiveness
Unified Commerce gives retailers more than integration. It offers a way to execute in real time, scale horizontally, and change faster than legacy models allow. But unlocking that potential requires more than selecting the right platform - it demands a different architectural design. One that shifts the center of execution away from distributed systems like ERP, OMS and CRM, and places it where responsiveness belongs: in a real-time, customer-facing operational core.
Across the industry retailers still operate within vertically siloed environments, where each system owns its own logic and synchronization keeps things aligned. In structurally agile organizations, all core flows - pricing, promotions, tax, inventory, loyalty and contextual business rules - are orchestrated from one unified layer. That’s not a best-practice integration setup. It’s a structural commitment to placing logic where it performs best: close to the customer, not buried in finance or middleware.
You don’t escape a FrankenStack by swapping platforms - you escape it by rethinking what your architecture serves.
Lub ten Napel - Enterprise Architect
What Structural Agility Actually Enables
True agility isn’t abstract. It becomes visible in daily execution: dynamic promotions, inventory-aware pricing, tax logic by country or exampt rules for customer groups, journey-level orchestration across web and store, where validated scripting applies business rules in real time. These flows are not back-office. They define the customer experience - and they require immediate adaptability.
If these flows are still governed by configurations in surrounding architecture or downstream systems such as ERP, batch syncs or layered integrations, agility isn’t built in - it’s conditional. Systems respond only when everything lines up perfectly, and fall apart when they don’t.
The Role of Downstream Systems: Essential for Control - Not Execution
ERP remains indispensable for financial ledgering, accounting and things like product lifecycle management. But in a modern execution model, that role must be clearly bounded. ERP governs the ledger, not the customer. It secures governance, not orchestration. And it should never drive logic for real-time pricing, promotions, returns, or regional fulfilment flows.
Function | Belongs in... |
|---|---|
General ledger, compliance, financial control | ERP |
Customer logic (pricing, inventory, tax, loyalty) | Unified Commerce platform
|
Real-time orchestration and routing | Unified Commerce platform |
Integration with surrounding systems | Unified Commerce platform |
When ERP stretches beyond what it was built for - attempting to control edge logic - it creates latency, duplication and point of failure. In architectures optimized for change, execution is decoupled from finance, and operational risk becomes isolated, not systemic.
A Useful Contrast: ERP-Centric vs. Execution-Centric Design
The core distinction is not between systems. It’s between where execution happens - and how change propagates. ERP-centric stacks concentrate control in tools not built for adaptation. Execution-centric models consolidate logic where it can evolve quickly, safely and contextually.
Dimension | ERP-Centric | Execution-Centric |
|---|---|---|
System of Record | ERP governs financial and operational core | Unified Commerce governs operational logic |
Customer Logic | Fragmented across ERP, CRM, POS, OMS | Centralized in real-time operational platform |
Data Flow | Batch-based synchronization | Event-driven, real-time by design |
Orchestration Model | Split across systems and middleware | Fully contained within Unified Commerce platform |
Integration Approach | Point-to-point, ESB or middleware | Native API, domain-driven by design |
Change Velocity | Slow – cross-system coordination needed | Fast – localized and modular |
Risk Profile | High – changes ripple through stack | Low – impact is isolated and reversible |
This is not a tooling preference. It’s a structural divergence - with lasting consequences for adaptability, governance and cost of change.
Why ERP-Centric Can Feel Safer - and Why That’s Misleading
ERP-centric models can persist because they feel familiar. ERP is audited. It’s stable. It’s embedded. But comfort with existing structures often reinforces the very rigidity that prevents innovation. Teams are trained around ERP processes. Roadmaps are built around its upgrade cycles. And change is scoped around what ERP allows - not what the business needs.
Operational Impact of Execution-Centric Design
But each of these reasons defends a system designed for control - not change. And as demands grow more real-time, more personalized, and more channel-fluid, that “stability” becomes friction. It slows delivery, multiplies regression risk, and drives up architectural debt.
Synchronization Isn’t a Detail - It’s a Design Choice
Justification | Perceived Benefit |
|---|---|
Historic Investment | Already paid for, deeply embedded |
Risk Avoidance | Central control feels safer |
Team Familiarity | Process logic built around ERP |
Governance Alignment | Financial compliance anchored in ERP |
Synchronization sounds manageable - align data, align rules, keep systems in sync. In reality, it’s a structural trade-off. Real-time flows require timely, consistent data - but the way synchronization is handled defines the balance between flexibility and control.
When operational logic such as promotions, returns, or pricing relies on regular syncs from downstream systems, the result is both opportunity and constraint: context-rich execution on one side, but added latency and risk on the other. True architectural agility means designing for real-time action, while acknowledging where data ownership and orchestration actually reside.
The Real Cost Curve
ERP-centric architectures often appear cheaper to maintain - at first. But the real cost is not in what it takes to run them. It’s in what it takes to change them. Execution-centric design requires an initial shift. But it pays back in speed, flexibility and reduced coordination overhead.
Category | ERP-Centric |
| ||
|---|---|---|---|---|
Initial Cost | 🟢 Low – reuse ERP | ⚪ Moderate – redesign execution layer | ||
Ongoing Cost | 🟠 High – integration, sync
| 🟢 Low – decoupled, testable updates | ||
Strategic Agility | 🟠 Low – ERP is central | 🟢 High – logic is modular, edge-driven |
The Future of Agility Is AI
What looks cheaper in year one often becomes the constraint in year three. Design for where you want to go - not for what you have.
Three Architectures, Three Outcomes
Why the structure behind your systems defines the speed of your retail execution. This visual compares three structural models common in retail IT today - from legacy ERP stacks to execution-centric design. Each pyramid shows how orchestration, data flow and business logic are layered. The key difference is not just where systems sit - but where decisions are made, and how easily change can happen.
From complex middleware and overlapping tools to modular, real-time execution, the transition is not just technical. It’s strategic. Only execution-centric architecture enables agility, replaceability and AI-readiness by design - not integration effort.
3. From Complexity to Modularity
How Execution-Centric Architecture Enables Safe, Repeatable and Agile Change
Retailers rarely fall behind because they lack functionality. They fall behind because their architecture cannot absorb change. Whether it’s adapting to new tax legislation, rolling out a new promotion model, or revamping BI capabilities by unlocking the power of a datalake, each change in a layered environment triggers regression risk: reconfiguring integration services, retesting middleware, and coordinating multiple teams across disconnected platforms.
Structural Fragility vs. Modular Readiness
Not all change is created equal - and neither is the architecture that supports it. Whether you’re making a small adjustment, upgrading core functions, or enabling entirely new capabilities, the difference between friction and flow depends on where logic lives. Architectures built on heavy integrations and dependencies with downstream systems spread responsibility - and risk - across many platforms. In contrast, execution-centric models keep change close to the source, making adaptation faster and safer at every level. The tables below illustrate how these structural choices directly impact your ability to adapt.
1. Adjustments, Upgrades and Replacements
Even minor changes become risky when logic is scattered - and safe when structure is modular.
Type of Change | ERP-Centric Architecture | Execution-Centric Architecture |
|---|---|---|
Adjustments (e.g. tax) | Delayed by ERP/middleware dependencies | Executed in real-time via centralized logic |
Upgrades (e.g. engine) | Requires full-system regression testing | Module-level updates with isolated impact |
Replacements (e.g. OMS) | High-risk, vendor lock-in, complex rollout | Decoupled logic enables phased replacement |
Risk Profile | High – changes ripple through stack | Low – impact is isolated and reversible |
2. Innovation Load: Campaigns, Extensions, Pivots
Structural agility determines whether innovation scales - or stalls.
Innovation Scenario | ERP-Centric Architecture | Execution-Centric Architecture |
|---|---|---|
Launching new campaign logic | Requires ERP config, POS updates, CRM alignment | Rolled out centrally, monitored in real time |
Changing loyalty rules mid-program | Impacts multiple systems and reporting flows | Updated in one platform with full auditability |
Adding new journeys (e.g. B2B) | Requires new flows and re-integration | Built on existing orchestration and logic reuse |
3. Scaling Pressure: Volume, Geography, Functions
Architectures either absorb growth - or amplify its complexity.
Scaling Scenario
| ERP-Centric Architecture | Execution-Centric Architecture |
|---|---|---|
Transaction volume growth | Batch limits and synchronization failures | Stateless, real-time scale |
Entering new regions or markets | Requires ERP reconfiguration and tax updates | Local logic layered on global orchestration |
Expanding fulfilment use cases | Cross-system alignment slows rollout | Orchestrated in real time, contextually routed |
Operational Impact of Execution-Centric Design
These design decisions translate directly into business performance. Retailers who place operational logic in a Unified Commerce execution core - rather than distributing it across legacy systems - report faster rollouts, lower risk and greater responsiveness.
Operational Metric | ERP-Centric Architecture | Execution-Centric Architecture |
|---|---|---|
Store rollout time | 8–12 weeks | 2–4 weeks |
Promotion deployment latency | 1 day | Near real time |
Inventory update frequency | Daily (batch) | Real-time (event-driven) |
Customer data consistency | Fragmented across tools | Unified via operational platform |
Recovery after failed release | Manual patch / 2–5 days | Instant hotfix / <2 hours |
Architecture becomes an enabler of agility - when change is built into the design.
4. Designing for Agility
Tactical Principles for Structuring Execution-Centric Retail Architecture
Rigidity doesn’t appear overnight. It grows from tactical decisions made without architectural oversight - slowly creating fragmented logic, slower rollouts, and misalignment between business needs and what systems can deliver.
Agility at scale demands more than modern platforms. It requires architectural discipline - the ability to design execution around change, rather than integration. The following principles guide that discipline and ensure that Unified Commerce remains not just a platform layer, but the foundation for adaptability, replaceability and AI-readiness.
1. Assign Responsibility by Layer - Not by System Function
Good architecture doesn’t start by asking what a system can do, but what it should be responsible for. Clear structural boundaries prevent systems from overreaching, reduce duplication of logic, and eliminate orchestration conflicts that slow execution.
Layer | Primary Responsibility | Must Not Control |
|---|---|---|
ERP | Finance, compliance, procurement | Customer logic, orchestration |
Integration Layer | Event propagation, decoupling, observability | Business rules, user interaction behavior |
Unified Commerce Core | Customer logic, real-time orchestration | Customer logic, real-time orchestration |
A system that owns everything eventually governs nothing.
Steven Bakker - Strategist
2. Design for the Future - Not the Stack You Inherited
Legacy structures reflect past constraints - not future ambition. To be agile, architecture must respond to speed, modularity and autonomy requirements - not to sunk cost logic. Forward design builds structure for change - not for containment.
That means asking:
- What must happen in milliseconds?
- Which logic should live closest to the customer?
- Can new services plug in without rewriting core flows?
- Can decisions be made where the data lives - not where it’s pushed?
3. Treat Integration as Infrastructure - Not a Patch Layer
Integration is not a tool - it’s a design capability. In execution-centric models, the integration layer enables decoupling, transparency and traceability across flows.
Done well, it creates autonomy. Done poorly, it cements fragility.
High-performing integration layers are:
- Event-driven
- Stateless
- Observable and traceable
- Designed to separate operational execution from reporting
Good integration clears the path. Bad integration becomes the path.
Unified Commerce isn’t about collapsing everything into a single tool - it’s about placing execution in one real-time operational core, while surrounding systems remain modular, decoupled and focused. Modularity isn’t fragmentation. It’s what enables scale without re-architecting - and keeps a unified platform flexible by design.
Modular - but unified through orchestration
Real-time at the edge - stable at the core
Designed for evolution - not for completeness
Architectural Simplification: The Engine Behind Agility and AI-Readiness
Reducing architectural volume is not a matter of cost optimization. It’s a prerequisite for agility, speed and AI-readiness. Fragmented environments slow down change - but they also block intelligence. When logic is distributed across dozens of systems, no AI model can reason over it, act in real time or learn from consistent feedback. Consolidating execution into one real-time operational core removes that barrier - structurally.
Application Layer | ERP-Centric Stack | Execution-Centric Stack |
|---|---|---|
Customer-Facing Systems | 25–55 | 12–25 |
Operational Enablement Tools | 18–35 | 8–15 |
Custom Utilities & Reports | 10–30 | 3–10 |
Middleware & Integration Layers | 5–12 | 2–6 |
Core Backoffice Systems | 8–18 | 4–8 |
Total Per Retailer | 66-152
| 29-64 |
Economic Impact of Structural Simplification
Execution-centric architecture doesn’t just reduce the number of systems. It reduces their entanglement - and with that, the cost of change, coordination and regression. Based on data from IDC, McKinsey and Deloitte (2024), structurally simplified retailers report fewer project delays, shorter release cycles and lower total IT overhead.
Cost Category | ERP-Centric Stack | Execution-Centric Stack | Why It Improves |
|---|---|---|---|
Integration & Maintenance | Very High | Low | Event-driven design eliminates sync complexity |
Change Management & Testing | High | Low | Updates are modular and isolated |
Licensing & Vendor Overhead | High | Low | Fewer overlapping tools, clearer ownership |
Reporting & Governance | High | Moderate | Unified execution logic reduces reporting layers |
Support & Training | High | Low | Fewer interfaces, cleaner handoffs |
Delivery & Rollout Timelines | Frequent delays | Minimal delays | Replaceability reduces coordination bottlenecks |
IT Ops Cost Index
ERP-Centric Stack100%
Execution-Centric Stack55%
Simplification doesn’t just reduce cost - it restores the ability to move, scale and learn in real time.
The Future of Agility Is AI
Why architecture determines whether AI becomes a feature - or your competitive edge
Agility is the right goal - and execution-centric architecture is the right path to get there. But the next evolution of agility is already emerging: not just faster change, but intelligent orchestration. A future where AI doesn’t sit on top of your systems, but inside your structure - sensing, deciding and acting in real time.
This shift is closer than it seems. Retailers are already experimenting with AI assistants, journey automation and predictive workflows. But these remain isolated features unless your architecture allows AI to operate across all domains, in real time, with context.
Only when Unified Commerce governs execution can AI become horizontal, adaptive and truly customer-centric - not as a plug-in, but as the operational brain.
You don’t prepare for AI by installing it - you prepare for it by building the system it needs to run on.
5. Strategic Conclusions and Recommendations
Traditional retailers treat modernization as a delivery challenge: integrating new tools, replacing legacy components, or extending ERP functionality with cloud services. But as this insight makes clear, the real issue is not what the stack can do - but how it is structured. And structure is not something you upgrade. It is something you design.
Most Architectures Still Protect the Past
The majority of retail IT environments are still built around historical responsibility: finance owns ERP, operations own tools, IT owns integration. That logic is reflected in architecture. The result is a system landscape that preserves previous ownership decisions - not customer responsiveness.
Synchronization Is Not Integration
Batch synchronization, shared databases and workaround APIs may create the appearance of alignment, but they do not remove complexity. Every change still activates regression risk. Every extension still triggers coordination. Synchronization protects fragmentation - it doesn’t fix it.
Replaceability Only Works by Design
Most systems today can technically be replaced. But structurally, they are embedded in workflows that span tools, teams and timelines. Replaceability is not a tooling feature - it is a property of modular design. And design choices can’t be patched retroactively.
Execution Needs a Home
Responsiveness requires a single place where operational logic lives, executes and evolves. That place cannot be shared across ERP, OMS, CRM and middleware. Without a unified execution core, agility becomes a coordination problem - not a capability.
Leadership Is Architectural
The core decision is no longer which platforms to integrate. It is whether to keep structuring the business around systems - or start structuring systems around how the business needs to work. That shift begins with recognizing architecture as a leadership responsibility.
Final Thought: Tecchnology won’t make your organization agile. But the structure you build around it can. Unified Commerce is not a product decision. It’s a design commitment.
And like all design choices - it’s a reflection of leadership.
References
- McKinsey - Retail Transformation Study, 2024
- Gartner - Retail IT Complexity Benchmark, 2024
- Deloitte - Retail IT Survey, 2024
- IDC - Retail Insights, 2024
- Forrester – Retail Technology Landscape, 2024
