Retail Director EA FAQs - Why do 120 IT Projects ≠ Retail Enterprise Architecture?
- Sunil Dutt Jha

- 6 days ago
- 8 min read
Updated: 3 days ago

Most retailers still treat Enterprise Architecture as an IT exercise, which is why EA efforts don’t change merchandising outcomes, pricing consistency, inventory accuracy, supply chain flow, store operations, or customer experience.
Retail EA ≠ Retail IT.
This Director EA FAQ explains where traditional EA breaks down and how a true enterprise anatomy reveals the structure that IT alone cannot see, align, or repair.
It explains the logic of shadow anatomies, 12 retail use cases, and the One Retail One Anatomy™ advantage.
Q1: Why do 170 IT projects ≠ Retail Enterprise Architecture?
Myth:
Retail EA = Retail IT (POS upgrades, ERP modernization, e-commerce platform rebuilds, mobile app improvements, or OMS/WMS integrations).
Reality:
Retail operates through 15 departments (D1–D15)—Merchandising, Pricing, Supply Chain, Promotions, Store Ops, Returns, Omnichannel—each with its own P1–P6 decision cycles.
A project inventory cannot show how pricing, promotions, routing, inventory allocation, and returns decisions align across channels.
Retail IT is only one department.
EA(IT) ≠ Enterprise Anatomy.
Q2. Why do so many IT projects fail to represent the retail enterprise?
Because retail IT automates only small fragments of P5 tasks, while retail’s true operating architecture exists in P1–P4, not in the task layer.
Every retail function — Merchandising, Pricing, Supply Chain, Store Ops, e-Commerce, Loyalty, Finance — operates on a full P1–P6 structure:
P1 (Strategy) defines category, margin, and omni-channel strategy.
P2(Processes) defines pricing workflows, promotion flows, allocation, replenishment, and fulfilment processes.
P3 (System logic) defines discount logic, rule priority, inventory meaning (ATP/ATS), routing logic, and loyalty rules.
P4 (Component Spec) defines components such as price files, rule tables, eligibility rules, item attributes, datasets, and routing engines.
This is the architecture (P1-P4) of the retailer.
IT projects typically touch P5 only — the manual task layer — and automate just slices of operational work:
updating price files
routing orders
capturing item data
applying SOME validations
triggering promotions
pushing inventory updates
sending notifications
None of these represent the enterprise logic that actually governs the retail business.
This is the structural mismatch:
IT Systems automate "tasks".
Retail operates on Architecture (P1-P5).
Those rules (P1–P3) and components (P4) were never unified.
Because P1–P4 was never architected (MODELLLED):
pricing logic behaves differently across POS, ERP, OMS, and e-commerce
promotions produce inconsistent outcomes across channels
ATP/ATS meaning varies across systems and regions
routing decisions differ by warehouse, store, SLA, or vendor
item attributes diverge between ERP, PIM, OMS, and digital catalog
loyalty rules are interpreted differently by POS, CRM, mobile apps
Retail IT does not fail due to weak systems —it fails because it is built on an incomplete representation of the retail enterprise.
Until the full departmental anatomy (P1–P4) is built, retail IT will continue to automate isolated P5 tasks, not the enterprise logic that drives pricing, promotions, inventory, fulfilment, and customer experience.
Q3. What drives the high project count in retail?
Retail behaves like a multi-layered rule machine, which means any small change creates cascading impacts across channels.
A price change updates POS, ERP, OMS, e-commerce engines, and promotional rule sets.
A promotion creates dependencies across pricing logic, CRM segmentation, POS behavior, mobile displays, and coupon eligibility.
Inventory adjustments recalibrate ERP, WMS, OMS, store inventory systems, safety stock buffers, and ATP/ATS logic.
A new fulfillment model (such as BOPIS, BORIS, ship-from-store, or express delivery) changes routing logic, SLA thresholds, pick-pack processes, and exception workflows.
Vendor or category changes ripple into PIM, ERP, forecasting, assortment planning, allocation, and replenishment.
Loyalty program updates alter POS behavior, CRM logic, wallet balance computations, and omni-channel experience flows.
Retail does not have many projects because IT is slow. It has many projects because retail is structurally complex at the rule level.
Q4. What is unique about Retail’s 15 Functions (D1–D15)?
Each retailer has a distinctive 15-function anatomy (D1–D15 × P1–P6).
Retail highlights:
D3 Merchandising – defines category, assortment, margins, and buying cycles D5 Pricing – holds base price, promotional logic, markdown logic, rule priority D7 Supply Chain – governs allocation, replenishment, inventory movement, routing D9 Store Operations – governs POS execution, store workflows, exception handling D11 e-Commerce – governs search, browse, cart, checkout, offer evaluation D13 Loyalty – governs accrual, burn, exclusions, tiers, entitlements
These departments generate the strongest P1–P6 drift, making alignment critical.
Each of these functions has its own P1–P6 perspectives. When these perspectives drift from each other, retail performance becomes inconsistent across channels, regions, stores, or fulfillment centers.
Shadow anatomies emerge when each department evolves without reference to a single enterprise model.
Q5. What does P1–P6 look like in the retail industry?
This explains how strategy (P1) → operations (P6) breaks down.
Retail P1–P6 drift:
P1 Strategy:
category strategy, pricing strategy, margin targets, omni-channel strategy, and fulfillment promise.
P2 Process:
buying, price updates, promotions, allocation, replenishment, picking, packing, shipping, customer service, and returns.
P3 Logic:
discount rules, offer eligibility rules, promotion prioritisation rules, category buying rules, routing logic, ATP/ATS definitions, forecast logic, replenishment rules, and loyalty rules.
P4 Components:
ERP, POS, OMS, WMS, PIM, CRM, e-commerce engines, pricing engines, loyalty engines, and data platforms.
P5 Implementation:
vendor builds, channel-specific adaptations, warehouse-specific variations, custom POS logic, integration patches, and tactical workarounds.
P6 Operations:
store teams, warehouse teams, digital teams, and contact centers — each operating with slightly different interpretations of the same policy, rule, or exception.
Retail drift happens when strategy → process → logic → components → operations no longer form one integrated sequence.
Q6. We already have 1,000+ pages of architecture documentation. Why redo this?
Myth: More documentation means we understand the enterprise.
Reality: Documentation shows parts of the retailer. Enterprise Anatomy shows the retailer as one integrated enterprise model.
Think of the human body:
It has 11 organ systems — circulatory, respiratory, nervous, endocrine, immune, digestive, etc. Each system has its own functions, but they are not optional, not interchangeable, and not isolated. They work as one integrated model with thousands of interdependencies.
No amount of medical paperwork can replace understanding how the body actually works as a single system.
A retailer is the same.
A retailer’s anatomy = 15 Functions (D1–D15) × 6 Perspectives (P1–P6)
This creates hundreds of functional flows and thousands of decision, data, and rule connections across:
• Strategy (P1)• Process (P2)• Rule / logic cycles (P3)• Component definitions (P4)• Implementation tasks (P5)• Daily operations (P6)
Traditional documentation describes these parts separately — system by system, department by department.
But none of those 1,000+ pages show:
• How pricing, promotion, and inventory decisions actually flow • Where processes diverge from rules • Where logic fragments get duplicated • Why channels behave differently for the same customer • Where drift starts and how it spreads
You get a library — not a model.
Enterprise Anatomy collapses complexity into ONE integrated model.
Instead of:
• 1,000 pages of descriptions • dozens of process maps • hundreds of system diagrams • unconnected rule documents • inconsistent SOPs • vendor-specific architecture artefacts
You get One Retail One Anatomy™:
• One P1–P6 spine • One D1–D15 functional map • One enterprise rule model • One view of strategy → operations • One meaning for pricing, promotions, inventory, fulfilment, and returns across channels
This is something documentation can never achieve.
Why documentation must be redone through Enterprise Anatomy
Because today’s documentation:
• describes symptoms, not the enterprise • is project-centric, not anatomy-centric • cannot diagnose drift or misalignment • cannot be used by leadership to guide execution
Enterprise Anatomy gives you:
• one integrated model • one source of truth • one way to diagnose • one way to execute
Exactly the way the human body works — integrated, interdependent, and non-negotiable.
In short:
Documentation shows parts. Enterprise Anatomy shows the enterprise.
That is why even with 1,000+ pages of architecture documentation, you still need One Retail One Anatomy™.
Q7. How do we evolve from EA(IT) → EA(Departments) → One Retail One Anatomy™?
Most organisations stop at EA = IT architecture.
The next evolution is:
Step 1: Elevate EA (IT) Create P1–P4 model of Retail IT itself. i.e model of IT strategy, IT processes, IT logic, IT components of Retail IT (POS upgrades, ERP modernization, e-commerce platform rebuilds, mobile app improvements, or OMS/WMS integrations).
Step 2: Create EA (Departments) 15 Retail functions mapped end-to-end (P1–P6). Clear view of strategy, processes, rule cycles, component definitions, implementation tasks, and operations.
Step 3: Create One Retail One Anatomy™ A single P1–P6 model across the full enterprise.Shared understanding of how pricing, promotions, inventory, fulfilment, and customer experience decisions flow.
Alignment of operations, channels, merchandising, supply chain, and financial outcomes.
This is where structural drift stops — and execution accelerates.
Q8. What can One Retail One Anatomy™ do that traditional EA cannot?
Traditional EA focuses on systems, integrations, and documentation. It cannot see that every department in a retailer is running its own shadow anatomy — its own version of strategy, process, rules, data checks, and operations.
A medium-size retailer typically carries 100–300 shadow anatomies, for example:
•Pricing has different rule interpretations across POS, ERP, OMS, and online
•Promotions have parallel logic in CRM, web, mobile, and store channels• Inventory logic varies between ERP, WMS, OMS, and stores
•Supply chain has routing, batching, and allocation logic scattered in multiple engines
•Loyalty has accrual/burn logic stored across POS, CRM, apps, and backend platforms
Traditional EA tries to document these inconsistencies. One Retail One Anatomy™ eliminates them.
What One Retail One Anatomy™ enables
It collapses hundreds of shadow anatomies into one coherent enterprise anatomy across P1–P6:
• One strategy model
• One process model (not 14 fulfilment variants)
• One rule/logic model (pricing, promotions, ATP/ATS, routing, loyalty)
• One data meaning across all systems
• One decision flow from channel to fulfilment to accounting
This unification allows the retailer to solve issues traditional EA has never been able to solve.
How it Impacts the 12 Core Retail Use Cases
Using One Retail One Anatomy™, the retailer can finally address enterprise-wide failures across use cases such as:
1. Pricing Consistency Across Channels
One interpretation of base price, promotional price, markdown logic, and rule priority across POS, ERP, OMS, web, and mobile — instead of five conflicting versions.
2. Promotion Creation, Evaluation, and Execution
One rule engine for eligibility, stacking, exclusions, and prioritisation — rather than embedded, divergent logic inside POS, CRM, e-commerce, and mobile apps.
3. Inventory Visibility (ATP/ATS) and Meaning
Unified definition of available inventory across ERP, WMS, OMS, and stores — eliminating mismatched availability, false promises, and channel-specific overrides.
4. Product Setup, Catalog, and Attribute Governance
One P1–P6 model for item creation, classification, attributes, variant control, eligibility rules, and lifecycle, instead of fragmented PIM–ERP–OMS catalog interpretations.
5. Order Orchestration & Omni-Channel Fulfilment
Consistent routing logic for BOPIS, ship-from-store, ship-to-home, pickup-point, and express delivery models — not dozens of warehouse, store, or region-specific exceptions.
6. Returns, Refunds, and Reverse Logistics
One logic sequence for return eligibility, inspection rules, refund triggers, and financial posting — ensuring identical outcomes across branch, store, web, and partner channels.
7. Loyalty Accrual, Redemption, and Offer Personalisation
One loyalty rule model across POS, CRM, mobile apps, partner systems, and e-commerce — preventing divergence in points, tiers, burn rules, and exclusions.
8. Allocation, Replenishment, and Forecasting
Unified buying, forecasting, allocation, and replenishment rules — not disconnected models that treat stores, warehouses, digital, and regions as separate worlds.
9. Vendor, Category, and Item Lifecycle Operations
One place to define vendor terms, category strategies, margin rules, item onboarding flows, eligibility, and discontinuation logic — instead of four or five departmental variants.
10. Fraud, Abuse, and Exception Handling
One logic framework for validating orders, detecting anomalies, enforcing thresholds, and governing exceptions across all channels — not isolated rule fragments buried inside systems.
11. Financial Posting, Margin Integrity, and Reconciliation
One meaning for price, discount, tax, fee, adjustment, and refund amounts — enabling reconciled financials instead of channel-wise misalignments.
12. Customer Experience Alignment Across All Touchpoints
Same decision logic for pricing, promotions, inventory, routing, loyalty, and returns across store, mobile, web, call center, and partner journeys — eliminating inconsistent experiences.
With One Retail One Anatomy™, every one of these use cases becomes predictable, coherent, and improvable — because they run on one enterprise logic stack.
Why traditional EA cannot achieve this
Traditional EA cannot unify:
• departmental rule cycles • decision logic fragmentation • process deviations • inconsistent data definitions • buried exceptions across POS, OMS, WMS, ERP, apps • channel-specific overrides in CRM, e-commerce, and store systems
It documents the drift — but cannot remove it.
One Retail One Anatomy™ removes the drift by replacing 100–300 shadow anatomies with one shared enterprise anatomy.
EA (IT) remains inside IT, the EA (Enterprise) enterprise continues to expand department by department.
A retailer regains coherence only when its entire P1–P6 structure is mapped as one integrated anatomy.
A retailer regains coherence only when its full P1–P6 structure is restored as One Retail One Anatomy™.
As long as EA is defined as technology, retail performance will remain unpredictable.
Coherence returns only when the organisation operates from one integrated P1–P6 model across merchandising, pricing, supply chain, stores, and digital.
The actionable path forward is clear: create the enterprise anatomy, unify the rule systems, and make every channel and department run on the same structural blueprint. Write to us for a one-on-one team presentation.



