Designing the system boundaries behind a global commercial platform
A fictional, composite case: leadership asked for “one commercial platform”. The work was to decide what each platform inside it is for—and what it must not become.
Independently created. Contains no employer or client implementation detail, internal names or figures.
The case in brief
Current reality
Everyone talks about “one commercial platform”, but a website, a CRM, an integration layer, several ERPs and a data platform all take part—and without explicit boundaries every new requirement drifts into the CRM.
What must become true
Users work in one coherent commercial environment, while each platform has one clear role, explicit responsibilities and non-responsibilities, the concepts it is authoritative for, declared interfaces—and a reason to be in the architecture.
Design question
Which commercial capability belongs to which platform—and which boundaries should not be erased just to make the experience look unified?
01The reality · current state
What the platform looks like today.
A fictional global B2B manufacturer sells through its own subsidiaries, through distributors and through a growing digital channel. Several platforms take part in every commercial moment: web forms and portals capture demand, the CRM runs the relationship, an integration layer moves requests and outcomes, each subsidiary’s ERP executes orders and invoices, and a data platform keeps the history. Each project so far solved its own need by adding data or logic to the CRM—because that is where the users are.
- Customer, product, price, stock and order data are copied into the CRM “so users see everything”
- Order status can be changed in two places, and nobody knows which one is right
- Retry counters and error states are stored as CRM fields that sales users can edit
- Historical analysis runs on CRM reports that were never designed to hold history
- Order-execution steps are rebuilt as CRM automation, next to the ERP’s own controls
- Every new request asks “can the CRM do it?” instead of “where does this belong?”
02The boundary problem
What is mixed today.
The CRM was slowly becoming four systems at once. Each request was reasonable on its own; together they erased the boundaries.
- A partial ERPPrices, stock and order states copied and edited in the CRM, drifting away from the transactional truth.
- A partial data warehouseYears of transactions loaded for reports the CRM was never designed to run.
- A workflow engineOrder-execution steps rebuilt as CRM automation, duplicating controls the ERP already enforces.
- An integration hubRetry counters, payload copies and error states kept on business records.
03Key dimension · Capability → platform responsibility
One capability, one owner—and declared secondary roles
The matrix starts from business capabilities, not from products. For each one: where its truth is created, where the work is done, who orchestrates, who only consumes—and what must not move.
| Business capability | Digital | CRM | Integration | ERP | Data | What must not move |
|---|---|---|---|---|---|---|
| Customer relationship | Consumes | Owns | No role | Consumes | Consumes | The ERP customer is a legal identity, not the relationship. |
| Lead & opportunity | Acts on | Owns | No role | No role | Derives | Portals capture demand; qualification stays in the CRM. |
| Activities & commercial planning | No role | Owns | No role | No role | Derives | Plans live where sellers act on them. |
| Quotes & proposals | Consumes | Owns | Orchestrates | Consumes | No role | A quote is a proposal; it becomes an order only in the ERP. |
| Price conditions | Consumes | Consumes | No role | Owns | Derives | The CRM reads the price a quote needs; it never maintains conditions. |
| Product & stock | Consumes | Consumes | No role | Owns | Derives | Availability is shown to sellers, not stored as CRM truth. |
| Order execution & invoicing | Consumes | Consumes | Orchestrates | Owns | Derives | Status is visible in the CRM and never edited there. |
| Legal & transactional customer | No role | Consumes | Orchestrates | Owns | Consumes | Issued by the ERP after validation; the CRM keeps a reference. |
| Integration delivery state | No role | Consumes | Owns | Consumes | No role | Shown to users as a status—never a business field. |
| History & performance signals | No role | Consumes | No role | Consumes | Owns | The CRM receives signals, not years of transactions. |
- Owns
- Where its truth is created and changed
- Acts on
- Where part of the work is done
- Orchestrates
- Moves it across platforms
- Consumes
- Uses it without changing it
- Derives
- Computes something new from it
A unified user experience does not require unified system ownership.
Global B2B commercial platform05Interaction design
What crosses a boundary, when—and why.
What crosses each boundary is a business state with an identity and an owner—not one API calling another.
| Business event | Identity | State | Who stays authoritative | Timing |
|---|---|---|---|---|
| An enquiry is submittedCrosses: Digital → CRM | Submission ID and party-match candidates | Enquiry received—not yet a lead | The CRM decides whether it is a lead; the portal only confirms receipt | Asynchronous: the visitor gets an acknowledgement, not a decision |
| A quote needs a priceCrosses: CRM → ERP (read) | Item and ERP customer reference | A price proposal for this quote | The ERP stays authoritative; the quote records the price used and when | On demand, at quote time |
| A won deal becomes an orderCrosses: CRM → integration → ERP | Opportunity ID, ERP customer number, correlation ID | Commercially committed; order requested | The ERP decides whether the order exists; the CRM continues once the outcome arrives | Asynchronous command with an explicit pending state |
| An order ships or is invoicedCrosses: ERP → integration → CRM | Order number and ERP customer number | Order status summary | Read-only in the CRM | An event whenever the state changes |
| History becomes a signalCrosses: ERP → data platform → CRM | Commercial account and period | A derived signal: trend, gap or risk | The data platform derives it; the CRM acts on it | Published per period |
06Failure & recovery
Rejected, late, uncertain or unavailable.
Every boundary needs a designed answer for rejection, delay and uncertainty—otherwise the CRM absorbs the workaround.
| Situation | Designed response | Who repairs it | How it is detected |
|---|---|---|---|
| The ERP rejects an order request | The opportunity stays won; the request shows a reason code and returns to its commercial owner | Commercial owner, with order management | A rejection event with a stable reason code |
| No answer arrives | Treated as unknown, not failed: the ERP is queried by correlation ID before any retry | Integration support | Pending beyond its expected window |
| The price read is unavailable | The quote can be prepared but not issued; the last price used is shown with its date | Seller, then pricing | A failed read at quote time |
| A copy drifts from its source | Reconciliation compares references and states; the source wins and the difference is logged | CRM platform owner | A scheduled reconciliation run |
07Candidate architectures
Credible options, judged against these premises.
Make the CRM the single commercial system
Small, single-entity operations
Cost: The CRM becomes a partial ERP, warehouse and hub; every change is riskyLet each project decide where its data lives
Fast local delivery
Cost: Duplicated truth and point-to-point couplingOne owning platform per capability, one experience through declared interfaces
A multi-entity estate with several ERPs
Cost: Needs a capability map, interface contracts and a boundary ownerDesign decision
Give every commercial capability one owning platform—the one where its truth is created—let the CRM present and act on the rest through declared interfaces, and keep the integration layer responsible for delivery, never for business truth.
08Resulting architecture
Every platform, one job—and a boundary.
What each platform owns in this design, and what it deliberately does not. These are the responsibilities for this context, not universal rules.
Website & portalsCRMIntegration layerERPsData platform
Website & portals
Where demand enters- Capturing enquiries and requests
- Self-service views for customers and partners
- Consent at the point of capture
- Qualification decisions
- Customer identity after validation
- Prices beyond what is published
CRM
Where the commercial relationship is run- Relationship, lead and opportunity state
- Activities, plans and commercial approvals
- The quote as a commercial proposal
- Presenting operational context to sellers
- Price conditions and stock
- Order execution and invoicing
- The delivery state of integrations
- Historical analytics
Integration layer
How state crosses a boundary- Delivery state of every request
- Mapping between models
- Correlation, replay and reconciliation runs
- Any business decision
- The truth of the records it moves
ERPs
Where transactions are executed- Legal and transactional customer
- Item master, price conditions and stock
- Orders, deliveries and invoices
- The commercial pipeline
- Relationship context
Data platform
Where history becomes signals- Conformed history across systems
- Derived commercial signals and KPIs
- Operational decisions
- Editing any source record
09Governance & operations
Who owns the boundary over time.
Boundaries erode one request at a time unless someone owns them.
| What | Owner | Cadence | Evidence |
|---|---|---|---|
| The capability ownership map | Platform architecture board | With every request that would move a capability | Requests that ask a platform to take on a new role |
| Interface contracts | Integration owner | Versioned on every change | Contract changes and the consumers they affect |
| Copies held in the CRM | CRM platform owner | Quarterly | Replicated domains, their volume and their use |
10The second layer
Questions that change the architecture.
Ownership
- Where is this truth created—and where is it only changed by accident?
- Does the CRM need the fact, or a useful representation of it?
- Who owns the definition of each concept?
Experience
- Which views must feel unified to the user?
- Which boundaries must stay visible, even on one screen?
- What does the user see while another system decides?
Change
- Which request would move a capability—and who approves it?
- What must stay transactional, and what belongs to analytics?
- Where does orchestration live?
11Decisions & outputs
What the work produces.
- 01Capability ownership map
- 02Platform role statements
- 03Non-responsibilities per platform
- 04Interface catalogue
- 05Boundary review process
- 06Reference architecture