Carlos EscasainCommercial Systems & Process Architect
ENES

RA / 01

Global B2B commercial platform

A bounded CRM–integration–ERP topology that separates commercial, legal and analytical truth.

Reference pattern9 minUpdated 27 Sep 2026
Reference pattern

Independently created. Contains no employer or client implementation detail, internal names or figures.

01Purpose

A pattern to adapt, not a blueprint to copy.

This reference architecture makes responsibility and handoffs visible before technology selection. It assumes a multi-system commercial environment where user experience, operational recovery and analytical consistency all matter.

02Logical flow

  1. 01Website
  2. 02CRM
  3. 03Integration
  4. 04ERP
  5. 05Data platform
  6. 06Analytics
Reference view / customer creation
Customer creation: commercial user approves in CRM; CRM sends a command to the integration layer, which creates the customer in ERP; outcome and status flow back; events reach the data platform.ApproveCommandCreateOutcomeStatusEventHUMANCommercial userCOMMERCIALCRMPLATFORMIntegration layerFINANCEERPDATAData platform

Hover or focus a system to see what it owns, what it does not, and which flows it takes part in.

Synchronous callManaged command or eventOwner label on every node

03Platform responsibilities

Each platform owns one job—and has a boundary.

Capability ownership is what makes the diagram above an architecture. For every platform: what it owns, what it deliberately does not own, and what crosses each boundary.

CRM

Commercial workspace
Owns
  • Commercial lifecycle
  • Sales interaction
  • Working state
  • Relationship context
Deliberately does not own
  • Legal customer identity
  • Invoices and financial state
  • Analytical history

Integration layer

Delivery, not business truth
Owns
  • Transport
  • Delivery state
  • Idempotency
  • Retries
  • Correlation
Deliberately does not own
  • Business rules
  • Customer or order data
  • Deciding outcomes

ERP

Legal and financial truth
Owns
  • Legal customer
  • Transactional customer
  • Orders
  • Invoicing
  • Financial state
Deliberately does not own
  • Prospects and pipeline
  • Relationship context
  • Sales activity

Data platform

History and derived signals
Owns
  • Analytical history
  • Derived measures
  • Cross-system signals
Deliberately does not own
  • Operational writes
  • Transactional workflow
  • Record-level edits
  • CRM to Integration layer: Commands
  • Integration layer to ERP: Create · update
  • ERP to Integration layer: Outcomes · events
  • Integration layer to CRM: Status
  • CRM · ERP to Data platform: Events · facts
  • Data platform to CRM: Signals, read only

Examples for a global B2B context, not universal rules. The responsibilities are assigned deliberately—which is the point, not the particular split.

Systems & CRM Architecture · reference case 02Source of truth, identity, variation and access—designed across the same platforms

04Design rules

  1. 01
    Authority

    Name the owner of every write, status transition and identifier.

  2. 02
    Boundaries

    Exchange stable contracts; do not reproduce one system’s internal model everywhere.

  3. 03
    Recovery

    Give failed work an owner, an observable state and a safe replay path.

  4. 04
    Human control

    Place review where ambiguity becomes consequential—not at every step.

Reference noteThe boxes are the easy part. The architecture lives in the contracts, ownership and behavior between them.