The Simplicity Paradigm of Enterprise Data

Introduction

Ask any business analyst to sketch the core data model of a retail company, and within fifteen minutes they'll produce something remarkably similar to what every other analyst would draw. Customers buy Products. Those purchases create Orders. Orders draw from Inventory. Inventory arrives via Shipments from Suppliers. There might be a few additional entities—Stores, Warehouses, Promotions—but the fundamental model is strikingly simple and consistent across nearly every retail business.

This conceptual simplicity is not an accident. It reflects the essential nature of commercial exchange that has remained unchanged for centuries. Whether you're running a Roman trading house or a modern omnichannel retailer, you're tracking fundamentally the same things: what you sell, who buys it, what you have in stock, and how it moves through your supply chain.

Yet anyone who has worked with enterprise data systems knows a troubling truth: while the conceptual model fits on a napkin, the actual implementation is a labyrinth of complexity. This article series explores why this gap exists and what we can do about it. We begin by establishing just how simple the core model really is.

Note: This article has been mostly generated by AI following my prompts about the core ideas of the contrast between the conceptual simplicity of enterprise data models and the convoluted implementations of the model across many enterprise applications. With the advent of "vibe coding", I suspect that the complexity of data tracking will increase significantly. Since my days at Business Objects, I have been a proponent of the semantic layer concept. We will explore in this series of articles why the advances in agentic AI bring a fresh new opportunity for the semantic layer as a solution to fragmented enterprise data models. Many of these ideas are being implemented in the BDB Platform

See a recent post about BDB's semantic layer

The Core Entities: A Retail Example

Let's examine a mid-sized retail merchant—call them "ModernRetail Inc."—operating both physical stores and e-commerce. Here's their conceptual data model:

Customer

• Identity (name, contact information)
• Preferences and history
• Loyalty status
• Payment methods

Product

• Identity (SKU, description)
• Attributes (size, color, category)
• Pricing
• Supplier information

Order

• Customer reference
• Line items (products and quantities)
• Pricing and discounts
• Fulfillment status
• Payment status

Inventory

• Product reference
• Location (warehouse, store)
• Quantity on hand
• Quantity allocated
• Reorder points

Shipment

• Origin and destination
• Contents (products and quantities)
• Carrier and tracking
• Status and timestamps

Supplier

• Identity and contact
• Terms and conditions
• Products supplied
• Performance metrics

Store/Location

• Physical address
• Operating details
• Inventory capacity
• Staff assignment

This model is deliberately simplified, but it captures the essential entities. You could sketch it on a whiteboard in twenty minutes, and any experienced business person would immediately understand it. The relationships are intuitive: Customers place Orders, Orders contain Products, Products come from Suppliers, Inventory tracks Products at Locations, Shipments move Products between Locations.

The Relationships That Matter

The real power of this model lies in its relationships:

• Customer ↔ Order: A customer's order history drives personalization, loyalty programs, and lifetime value calculations
• Order ↔ Product: Order line items connect customer demand to inventory requirements
• Product ↔ Inventory: Real-time inventory positions enable accurate order promising
• Inventory ↔ Shipment: Inbound shipments replenish inventory; outbound shipments fulfill orders
• Product ↔ Supplier: Supplier relationships determine procurement lead times and costs
• Order ↔ Shipment: Linking orders to shipments enables tracking and delivery promises

These relationships aren't complex graph theory—they're straightforward foreign key relationships that any database designer learned in their first week of training.

Why This Model is Universal

This model appears everywhere because it maps directly to the fundamental activities of commerce:

1. You sell something → Product
2. Someone buys it → Customer, Order
3. You must have it available → Inventory
4. You must get it from somewhere → Supplier, Shipment
5. You deliver it somewhere → Location, Shipment

Manufacturing companies add production entities (Bill of Materials, Work Orders, Production Runs). Service companies might replace Product with Service Offering. But the core pattern remains: entities that represent what you offer, who you serve, what transactions occur, and how resources flow.

The Implementation Reality

Now let's look at how ModernRetail Inc. actually implements this conceptually simple model. Their enterprise architecture looks something like this:

SAP ERP

• System of Record for: Product master data, Supplier master data, Inventory, Purchase Orders
• Core modules: Materials Management (MM), Sales & Distribution (SD), Finance (FI)
• What it does: Manages the financial backbone, inventory positions, procurement, and core transactional processing

Salesforce

• System of Record for: Customer master data, Opportunities, Customer interactions
• What it does: Manages customer relationships, marketing campaigns, sales pipeline, customer service cases
• The catch: Maintains its own copy of Product data (for quoting), its own Order objects (for sales ops), and syncs customer data back to SAP

Supply Chain Management System (e.g., Blue Yonder, Manhattan Associates)

• System of Record for: Demand forecasts, Replenishment plans, Warehouse operations
• What it does: Optimizes inventory allocation, manages warehouse operations, plans shipments
• The catch: Operates on nightly extracts of Inventory and Product data from SAP, pushes shipment updates back

E-commerce Platform (e.g., Shopify Plus, Salesforce Commerce Cloud)

• System of Record for: Online orders, Digital customer behavior
• What it does: Powers the website, shopping cart, checkout experience
• The catch: Maintains its own Product catalog (with web-specific attributes), checks inventory via API calls to SAP, creates orders that get pushed to SAP for fulfillment

Integration Platform (e.g., MuleSoft, Boomi)

• System of Record for: Nothing—it owns no master data
• What it does: Orchestrates data movement between all the other systems
• The challenge: Manages dozens of integration flows, data transformations, error handling, and retry logic

The Fragmentation

Notice what happened to our simple entities:

• Customer lives authoritatively in Salesforce, but exists in read-only copies in SAP (for billing) and the e-commerce platform (for personalization)
• Product lives authoritatively in SAP, but exists in copies in Salesforce (for selling), the supply chain system (for planning), and the e-commerce platform (with additional digital attributes)
• Order has split personalities: e-commerce orders start online, Salesforce orders start in CRM, but all orders eventually land in SAP for fulfillment and financial recording
• Inventory lives in SAP but is constantly queried by the e-commerce platform, replicated nightly to the supply chain system, and monitored by business intelligence tools

The conceptually simple model has fractured across system boundaries. Each system is the System of Record for some entities while operating on cached or synchronized copies of others.

Why This Matters

You might argue: "So what? These are all necessary systems, each doing its job. The integration platform keeps them in sync. Problem solved."

Not quite. This fragmentation creates several deep problems:

Data consistency challenges: When is a customer update in Salesforce reflected in SAP? If the integration fails, which system is correct?

Latency issues: E-commerce customers see inventory positions that might be minutes or hours old. In high-velocity scenarios, this leads to overselling.

Complex change management: Want to add a new product attribute? You might need to change schemas in SAP, Salesforce, the e-commerce platform, and multiple integration flows.

Debugging nightmares: When an order is missing or incorrect, which system failed? Where did the data transformation go wrong?

Organizational friction: Who owns the customer entity—Marketing (Salesforce) or Finance (SAP)? These aren't just technical questions; they're political ones.

The Core Insight

Here's the thesis we'll explore throughout this series: Enterprise data systems are conceptually simple. The complexity emerges not from the domain model itself, but from the way we fragment that model across organizational and technical boundaries.

The entities—Customer, Product, Order, Inventory, Shipment—are well-understood. The relationships are straightforward. What makes enterprise data systems complex is that we've taken a simple, unified model and shattered it across multiple systems, each with its own technology, ownership, update cycles, and consistency guarantees.

In the next article, we'll explore why this fragmentation happens. It's not stupidity or poor planning. There are real forces—historical, organizational, technical, and economic—that push us toward this architecture. Understanding these forces is the first step toward addressing them.

Conclusion

The next time someone tells you that enterprise data is inherently complex, push back. The domain isn't complex. Commerce has been around for millennia, and we understand it well. What's complex is the implementation—the way we've chosen to build systems that violate the natural unity of the domain model.

This matters because if we misdiagnose the problem, we'll never fix it. If we believe enterprise data is inherently complex, we'll resign ourselves to managing that complexity. But if we recognize that the complexity is accidental rather than essential, we can start asking the right questions: Why did we fragment the model? Can we un-fragment it? If not, how can we better manage the fragmentation?

These are the questions we'll tackle in the articles ahead.

---

Next in this series: Article 2 - "Why Enterprise Systems Fracture: The Forces Behind Fragmentation"