Systems & CRM Architecture
Design the commercial platform before configuring the CRM.
I translate business lifecycles into system responsibilities—deciding what the CRM owns, what the ERP owns, where data authority lives, how identities move, and how the platforms evolve without becoming tightly coupled.
The same commercial lifecycle across four platforms. Choose one to see what it owns—and when authority changes hands.
| 01Decision: Lead | 02Human action: Prospect | 03Human action: Opportunity | 04Approval gate: Approval | 05System action: Customer | 06System action: Order | |
|---|---|---|---|---|---|---|
| CRM | Lead record & routing — owns | Prospect account — owns | Opportunity & quote — owns | Approval record — owns | Shows ‘creation pending’ — supports | Order status, read only — supports |
| Integration | Not involved | Party lookup — supports | Not involved | Not involved | Creation command · delivery state — owns | Order and invoice events — supports |
| ERP | Not involved | Party index, read only — supports | Not involved | Not involved | Legal customer & number (authority transfers) — owns | Order, delivery & invoice — owns |
| Data platform | Source history — supports | Not involved | Pipeline history — supports | Not involved | Lifecycle events — supports | Revenue & performance — owns |
| Customer authority | CRM — owns | CRM — owns | CRM — owns | CRM — owns | ERP (authority transfers) — owns | ERP — owns |
01LeadLead record & routing
- CRM
- Lead record & routing — owns
- Integration
- Not involved
- ERP
- Not involved
- Data platform
- Source history — supports
- Customer authority
- CRM — owns
02ProspectProspect account · Party index, read only
- CRM
- Prospect account — owns
- Integration
- Party lookup — supports
- ERP
- Party index, read only — supports
- Data platform
- Not involved
- Customer authority
- CRM — owns
03OpportunityOpportunity & quote
- CRM
- Opportunity & quote — owns
- Integration
- Not involved
- ERP
- Not involved
- Data platform
- Pipeline history — supports
- Customer authority
- CRM — owns
04ApprovalApproval record
- CRM
- Approval record — owns
- Integration
- Not involved
- ERP
- Not involved
- Data platform
- Not involved
- Customer authority
- CRM — owns
05CustomerShows ‘creation pending’ · Legal customer & number
- CRM
- Shows ‘creation pending’ — supports
- Integration
- Creation command · delivery state — owns
- ERP
- Legal customer & number — owns
- Data platform
- Lifecycle events — supports
- Customer authority
- ERP — owns
06OrderOrder status, read only · Order, delivery & invoice
- CRM
- Order status, read only — supports
- Integration
- Order and invoice events — supports
- ERP
- Order, delivery & invoice — owns
- Data platform
- Revenue & performance — owns
- Customer authority
- ERP — owns
Not a CRM configuration. The responsibilities behind the platforms.
Systems architecture decides what each platform is for before anyone decides how to configure it: which capability it carries, which concepts it owns, and where its boundary sits.
Deciding which CRM object to createAdding fields until the requirement fitsConnecting applications because they hold related dataAssuming the CRM should own every commercial concept
- CapabilitiesDefine what the business must be able to do.
- Lifecycle statesDefine the business states and what changes them.
- System boundariesDecide which platform does what—and what it does not.
- OwnershipAssign one owner to every capability and concept.
- IdentityDefine how an entity stays the same across systems.
- Integration contractsDesign what crosses a boundary, and with which guarantees.
- VariationDecide what may differ by region—and where it lives.
- AccessDesign who can see, create and change what.
- Failure behaviorDefine what happens when a system is slow, wrong or down.
- EvolutionDesign what can change without changing everything.
- CRM“Customer master”
- ERP“Customer master”
- E-commerce“Customer master”
- Data platform“Customer master”
Four masters, one customer: every change becomes a reconciliation.
- Commercial statusCRM
- Legal customer numberERP
- Billing address (after creation)ERP
- Web account & preferencesE-commerce
- Customer performanceData platform
Authority is a matrix, not a trophy awarded to one system.
If every system owns the customer, no system owns the customer.
A platform boundary is as important as a platform capability.
Most architecture problems appear when two systems both believe they are authoritative.
From business capability to platform architecture.
Nine moves that turn a business lifecycle into system responsibilities. Each produces an artefact the next one depends on—and configuration comes after all of them.
01Start from the business capability
What does the business need to be able to do?
Define capabilities before technologies.
- Manage a prospect
- Qualify an opportunity
- Approve commercial conditions
- Create a legal customer
- Process an order
- Measure account performance
A capability without an owner becomes a feature every system half-implements
Start from the business capability
What does the business need to be able to do?
Define capabilities before technologies.
- Manage a prospect
- Qualify an opportunity
- Approve commercial conditions
- Create a legal customer
- Process an order
- Measure account performance
Capability mapA capability without an owner becomes a feature every system half-implements
Define the lifecycle
Which business states exist, and what changes them?
States describe the business, not a screen.
- State
- Transition
- Trigger
- Owner
- System representation
Lifecycle & state modelThe same state can be represented differently in two systems—as long as its meaning is shared
Assign system responsibility
Which platform should execute each capability?
One capability, one executing platform—even when several read the result.
- CRM
- ERP
- Integration layer
- Data platform
- External services
- Human process
Capability-to-system map‘Both’ is rarely an answer; it is usually a future reconciliation problem
Define data authority
Who may create and change each business concept?
Authority belongs to concepts and fields, not to whole records.
- CRM: commercial status
- ERP: legal customer number
- Data platform: derived analytical measures
Data authority matrixAuthority can move with the lifecycle—a proposal in CRM becomes a validated fact in ERP
Define identity
How does the same business entity stay the same across systems?
Identity is not a field mapping.
- External IDs
- Canonical IDs
- Natural keys
- Duplicate rules
- Merge behavior
- Identity transfer
Identity modelMost integration defects are identity defects in disguise
Design platform boundaries
What should each platform deliberately not do?
A boundary is as important as a capability.
- Responsibility boundaries
- Duplicated capability
- Shadow ownership
- Forbidden coupling
System responsibility mapIf two systems both believe they are authoritative, reconciliation becomes a permanent job
Design access and governance
Who can see, create and change what?
Access is architecture, not a late admin task.
- Record visibility
- Organizational access
- Ownership
- Hierarchy
- Delegation
- Sensitive fields
- Governance
Access & governance modelOwnership is accountability; visibility is a separate design decision
Design interfaces and failure
How do systems collaborate when things go wrong?
Design the unknown outcome before the happy path.
- Synchronous or asynchronous
- Delivery state
- Retries
- Idempotency
- Reconciliation
- Observability
- Eventual consistency
Integration contract modelA timeout is not a failure; it is an unknown outcome
Design for evolution
What can change independently?
Every coupling is a future release dependency.
- Configuration or code
- Global or local
- Capability boundaries
- Versioning
- Release ownership
- Roadmap dependencies
Architecture evolution roadmapA roadmap organized only by projects hides which capabilities are coupled
The symptoms arrive as configuration requests.
“Add a field.” “Sync it both ways.” “Give them their own record type.” Underneath, a responsibility was never assigned.
The CRM and the ERP both modify the same customer attributes.
Usually missingField-level data authorityLifecycle states exist in several systems, with different meanings.
Usually missingOne lifecycle definition, represented per systemTeams keep creating duplicate customer records.
Usually missingIdentity rules: match before createOpportunity stages reflect the configuration, not the way the business sells.
Usually missingA motion-aware opportunity modelAccess rules grew organically; nobody can explain who sees what.
Usually missingAn explicit access modelRegional variation is implemented through forks and exceptions.
Usually missingDeclared configuration pointsIntegrations depend on another system’s internal structures.
Usually missingStable integration contractsThe CRM has become a reporting database, with analytics inside transactional workflows.
Usually missingA boundary between operational and analytical systems
Artefacts a platform team can build, govern and evolve from.
Each one settles a question that configuration would otherwise answer by accident.
- Capability mapWhat must the business be able to do, independent of tools?
- CRM domain modelWhich commercial concepts exist, and how do they relate?
- Customer lifecycle modelWhich business states exist, and what changes them?
- Account & relationship modelWhat does an account represent, and how do accounts relate?
- Opportunity architectureWhich motions share a lifecycle, and which need their own?
- System responsibility mapWhat does each platform own—and deliberately not own?
- Source-of-truth matrixWho may create, change, read or derive each concept?
- Identity modelHow does one entity stay the same across systems?
- Access & visibility modelWho can see, create and change what?
- Integration topologyWhich systems exchange what, how, and with which guarantees?
- Global/local variation modelWhat is core, configurable or a local extension?
- Architecture decision recordsWhich choices were made, on which premises?
- Platform roadmapWhat changes when—and what can change independently?
Start from capabilities. Then assign each one a platform.
A business capability is what the organization must be able to do. A system is one way of implementing it—and some capabilities belong to a person, not a platform.
Manage a commercial opportunity
implemented by CRM
Approve commercial conditions
implemented by CRMDecided by a person, recorded in the CRM
Create a legal customer
implemented by ERP
Issue an invoice
implemented by ERP
Route a failed integration
implemented by Integration layer
Compute historical customer performance
implemented by Data platform
Check registration and sanctions data
implemented by External service
Decide credit above a threshold
implemented by Human processRecorded in the ERP
What each platform owns—and does not
CRM
Commercial workspace- Commercial lifecycle
- Sales interaction
- Working state
- Relationship context
- Legal customer identity
- Invoices and financial state
- Analytical history
Integration layer
Delivery, not business truth- Transport
- Delivery state
- Idempotency
- Retries
- Correlation
- Business rules
- Customer or order data
- Deciding outcomes
ERP
Legal and financial truth- Legal customer
- Transactional customer
- Orders
- Invoicing
- Financial state
- Prospects and pipeline
- Relationship context
- Sales activity
Data platform
History and derived signals- Analytical history
- Derived measures
- Cross-system signals
- 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 truths. In another business the ERP may own pricing, or the CRM may never hold an order at all—the point is that every responsibility is assigned deliberately.
Nine concepts, and who owns each part of them.
Select a concept to see what it represents, which system owns each aspect of it, where it comes from and what depends on it. Not every concept belongs natively in the CRM.
Account
The commercial relationship
- Commercial owner
- CRM
- Legal identity
- ERP
- Analytical performance
- Data platform
- Lifecycle
- Prospect → customer → inactive
- Source
- CRM while prospecting; legal data from the ERP after creation
- Relationships
- Lead converts to Account · Account has Contact · Account has Opportunity
- Downstream
- ContactsOpportunitiesOrdersInvoicesReporting
One account, three authorities: that is the design, not a conflict.
One customer, three identities.
The commercial relationship, the registered legal entity and the customer in each ERP are different things with different issuers. Identity architecture keeps them linked without pretending they are one.
- CRM account IDCommercial identity—the relationship we sell toIssued by the CRMLinks 1 → 1…n
- Canonical business identityThe registered legal entity, one party IDIssued once by master dataLinks 1 → 1…n
- ERP customer ID(s)That legal entity as a customer of each of our companiesIssued by each ERP
01Canonical identifiers
One issuer per identifier. Every other system stores it as a reference and never generates it.
02System-specific identifiers
Each system keeps its own ID; the cross-reference links them. Nobody rebuilds identity from names.
03Natural keys
Registration number, tax ID, normalized name and country—used to find candidates, never as the primary key.
04Duplicate candidates
Checked before creation. A candidate is a question for a person, not an automatic merge.
05Merge
The survivor keeps its ID; history and cross-references move to it; the retired ID remains as an alias.
06Retirement
Retired identities stay resolvable, so historical orders and reports still point somewhere.
07Correlation IDs
Every cross-system request carries one, so an outcome is matched to its request without guessing.
08Parent–child
Hierarchies describe how we sell and report. A parent link never merges two legal entities.
ADR 005 · Separate commercial identity from legal customer identity
Isolate variation instead of forking the platform.
Regions differ for legal, fiscal and operational reasons. The design question is not whether they may differ, but which layer absorbs each difference—and who owns it.
- Global core
The same everywhere—changed only through global governance
- Common lifecycle
- Canonical data concepts
- Shared reporting semantics
- Configurable variation
Varies through declared configuration, within global limits
- Approval thresholds
- Assignment rules
- Local roles
- Selected validation
- Local extension
Only where legal, fiscal or ERP constraints cannot be configured
- Country-specific legal fields
- A local ERP mapping
- Local document output
Every step to the right has a cost: it is tested, documented and upgraded separately. A local extension needs a reason that configuration cannot satisfy—and an owner and a review date in the variation register.
ADR 006 · Represent regional variation through configuration, not CRM forks
Who can see, create and change what is a design decision.
Access models that grow one exception at a time end up unexplainable. Designed ones derive visibility from ownership, teams and hierarchy—and keep edit authority deliberately narrower.
| Ring | Who | View | Edit |
|---|---|---|---|
| Owner | One accountable account manager | Full | Full |
| Account team | Specialists and global account leads | Full | Their own contributions |
| Hierarchy | Managers above the owner | Full | None by default |
| Region & global | Regional and global roles | Summary | None |
- Ownership Accountability, not visibility.
- Visibility Derived from teams and hierarchy, not granted by hand.
- Edit authority Narrower than view—by design.
- Sensitive data Credit terms and margin sit behind their own boundary.
- Sharing Manual exceptions carry an owner and an expiry.
Six platform questions, six architectural answers.
Synthetic global B2B scenarios built from recurring patterns. Each opens into its own page with system responsibilities, data authority, options and trade-offs, and the questions that change the design.
- Case 01Selected workProcess → system boundary → identity → state
Designing a CRM–ERP customer lifecycle
“CRM should create customers in ERP” hides three identities, two approval boundaries and a failure state that can interrupt revenue.
When does the CRM stop owning the customer—and what does the user see while the ERP decides?
CRMIntegration layerERPData & IntegrationsProcess Architecture - Case 02Reference architectureCapability ownership across the platform
Global B2B commercial platform
A multi-system commercial estate in which nobody can say which platform owns which capability.
Which platform owns each capability—and where do operational and analytical systems meet?
WebsiteCRMIntegrationERPData platformData & IntegrationsRevenue Operations - Case 03Global core vs. configurable variation
Designing a global CRM without forking the operating model
Subsidiaries need genuinely different rules, and every difference so far has become a copy of the configuration.
What belongs in the global core, what is configurable—and what must never be forked?
Global CRMIntegration layerLocal ERPsData platformDigital Operating ModelData & Integrations - Case 04Common core + specialized motion
Designing one CRM for multiple commercial motions
New business, strategic projects, expansion and account growth are forced through one lifecycle—or about to be split into incompatible models.
Which states are universal, which stages differ, and what does ‘Closed Won’ mean for each motion?
CRMPricingERPData platformRevenue OperationsProcess Architecture - Case 05Identity & hierarchy
Designing customer identity across CRM and ERP
Prospects, subsidiaries, several ERP customer numbers and duplicates all live under one word: ‘account’.
What does an account represent—and who issues the identity every system can trust?
CRMIntegration layerERPsData platformData & IntegrationsProcess Architecture - Case 06Ownership, visibility & edit authority
Designing CRM visibility for a global commercial organization
Access rules grew one request at a time; nobody can explain who sees what, or why.
Does ownership mean accountability or visibility—and how is access granted without making everything public?
CRMHR & org dataIdentity providerData platformDigital Operating ModelRevenue Operations
Every configuration request has a second layer.
The visible request is where the architecture starts, not where it ends.
“Create an Account.”
Add an account record with the customer’s name and address.
4 of 6 questions surfaced
A group, a legal entity, a relationship or a location? Each answer gives a different data model.
Platform boundaries shape every other capability.
Systems & CRM Architecture
- Process Architecture
The process defines the lifecycle and decisions; systems architecture decides which platform carries each one.
- Digital Operating Model
Ownership, governance and variation rules come from the operating model; the platform encodes them.
- Data & Integrations
Authority and identity decisions become integration contracts, events and reconciliation.
- Automation
Automation runs inside one platform’s boundary; orchestration is designed where boundaries meet.
- Revenue Operations
Pipeline, forecast and account models are CRM architecture decisions RevOps runs every day.
- AI & Agentic Workflows
Agents inherit the identity and authority model—clear ownership is what makes their actions safe.
- Change & Adoption
A platform that fits the way people sell is adopted; one that encodes the org chart is worked around.
Architecture decisions
Related work
A CRM is not the architecture. The architecture is the set of decisions that defines
- Capabilities
- Lifecycles
- System responsibilities
- Identity
- Data authority
- Access
- Integration
- Variation
- Evolution
The CRM is one platform implementing part of that architecture.
Two systems that both believe they own the customer?
- Which concept has two masters—or none?
- Where does authority change hands, and who sees it?
- What would a new region force you to fork?