Enterprise Architecture and Salesforce: Fitting the Platform into the Big Picture

Why EA Teams and Salesforce Teams Often Clash

Enterprise architecture teams and Salesforce delivery teams frequently operate with different vocabularies, different governance rhythms, and different success metrics. EA teams think in terms of landscape diagrams, capability models, and reference architectures. Salesforce teams think in terms of objects, flows, and releases. The gap between them creates friction that slows delivery and produces architectural debt.

The friction is predictable. EA teams worry that Salesforce will become a data silo, replicate capabilities that exist elsewhere, or create integration spaghetti. Salesforce teams worry that EA governance will slow them down, impose unnecessary constraints, or apply patterns designed for on-premise systems to a cloud platform.

Both concerns are legitimate. The resolution is a shared architecture model — one that gives EA teams the boundary clarity they need while giving Salesforce teams the autonomy to operate effectively within those boundaries.

Where Salesforce Sits in the Enterprise Landscape

Enterprise architecture frameworks — TOGAF, Zachman, ArchiMate — all have a way of classifying systems by the capabilities they support. In most enterprise landscapes, Salesforce sits in the customer engagement layer: the set of capabilities that manage interactions with customers, prospects, partners, and employees.

That layer sits above the core business systems (ERP, order management, billing) and below the data and analytics layer. Salesforce is not a system of record for financial data — that lives in ERP. It is not primarily a data warehouse — that lives in the data platform. It is a system of engagement and, increasingly, a system of intelligence through AI and analytics capabilities.

Understanding where Salesforce sits helps resolve boundary questions. When someone asks "should customer order history live in Salesforce?" the EA answer is: only if Salesforce is the primary channel through which that history needs to be acted upon. If the answer is yes (service agents need it to resolve issues), then it should be in Salesforce — either replicated from ERP or sourced directly. If the answer is no (it's only needed for billing reconciliation), it should stay in ERP.

The Five Boundary Decisions

Every enterprise Salesforce architecture must make five explicit boundary decisions. Leaving these implicit guarantees future conflicts.

1. System of Record vs System of Engagement. For each data entity (Account, Contact, Product, Order), decide whether Salesforce is the system of record (authoritative source, write-capable) or a system of engagement (read-capable, derived from another source of truth). Mixed status — where Salesforce and ERP both claim to be the record for the same entity — is the most common source of data quality problems.

2. Process Ownership. For each business process (lead to opportunity, case to resolution, quote to order), decide whether Salesforce owns the end-to-end process or only a segment of it. If Salesforce owns lead-to-opportunity but ERP owns quote-to-order, the handoff point must be explicit, governed, and monitored. Processes that span both systems without a clear owner become ungoverned gaps.

3. Integration Direction. For each integration, decide the canonical direction: does Salesforce push to the target system, or does the target system pull from Salesforce? Event-driven architectures blur this — but even then, the producer and consumer of each event type must be defined. Bidirectional synchronisation without clear ownership of conflict resolution is a reliability risk.

4. Identity and Master Data. Decide whether Salesforce participates in an enterprise Master Data Management (MDM) layer or operates its own identity model. If there is an enterprise customer master, Salesforce should consume and contribute to it, not operate independently. If there is no MDM, Salesforce often becomes the de facto customer master — which is a legitimate architectural choice, but one that should be made deliberately.

5. Platform Boundary for Customisation. Decide what types of custom functionality belong in Salesforce versus elsewhere. The general principle: if the functionality requires Salesforce data and is invoked within a Salesforce process, build it in Salesforce. If it requires Salesforce data but is primarily driven by non-Salesforce processes, consider whether an external service with an API call is more appropriate than Apex. This decision determines your technical debt profile over time.

Integration Tier Thinking

Not all integrations are equivalent. A useful model is to think in three tiers based on latency tolerance and criticality:

Tier 1 — Real-time, transaction-critical. Examples: payment status updates, real-time inventory checks, identity verification. These integrations must complete within the user's interaction window (seconds). They require synchronous patterns, circuit breakers, fallback behaviour, and extensive monitoring. Salesforce Platform Events or synchronous callouts may be appropriate here, but consider whether Salesforce is the right orchestrator for time-critical transactional flows.

Tier 2 — Near-real-time, operationally important. Examples: CRM order status from ERP, case updates from ITSM, contact synchronisation from HR systems. These integrations need to be current within minutes to hours. Event-driven patterns with a middleware layer (MuleSoft, Boomi, Azure Integration Services) are typical. Salesforce Change Data Capture (CDC) or platform events as producers work well here.

Tier 3 — Batch, reporting-oriented. Examples: financial period closes, marketing suppression lists, campaign performance data. These can be hours or days behind real-time. ETL patterns, nightly jobs, and bulk API calls are appropriate. Avoid over-engineering Tier 3 integrations with Tier 1 patterns — it creates operational complexity without benefit.

Data Ownership and the Golden Record Problem

The "golden record" — a single authoritative view of a customer, account, or entity — is one of the most persistent challenges in enterprise architecture. Salesforce often becomes a battleground for this problem because it is where customer data is most visibly used and where data quality problems most directly affect revenue-generating processes.

The three-layer model provides a useful frame: Source (where data originates — HR, ERP, Salesforce itself), Master (where the golden record is maintained — MDM, or Salesforce if it is designated), and Consumer (systems that use but don't own the data). Salesforce's role in each layer should be explicit.

If Salesforce is designated as the Account master, that means: ERP account records should be derived from Salesforce, not the other way around. Marketing databases should source their account lists from Salesforce. Data cleansing and deduplication tooling (RingLead, Dedupe.io, or native Duplicate Management) should run in Salesforce. This is a significant governance commitment — it means Salesforce teams own data quality for accounts enterprise-wide.

If Salesforce is a consumer of the Account master (held in MDM or ERP), then Salesforce teams should not be creating accounts ad hoc — they should provision through the MDM layer. This constrains how quickly sales teams can act on new prospects, which has real business impact and must be weighed explicitly.

Working with EA Teams Effectively

The most productive posture for a Salesforce architect engaging with EA is to bring a completed architecture decision record (ADR) to the conversation, not an open question. EA teams respond better to "here is our proposed decision, here are the alternatives we considered, here is the impact on the enterprise landscape — we are requesting review and approval" than to "we need to integrate with SAP, what should we do?"

Establish a small set of recurring touchpoints: a quarterly Salesforce architecture review where platform decisions with cross-enterprise impact are reviewed, and a lightweight change advisory process for integrations involving systems outside Salesforce's boundary. This creates predictability for EA teams without requiring approval for every configuration change.

Contribute to the EA landscape model. If your organisation uses ArchiMate or a similar notation, create and maintain the Salesforce portion of the diagram. Make it easy for EA teams to understand what Salesforce owns, what it integrates with, and where the boundaries are. Visibility reduces friction — EA teams often resist Salesforce changes because they don't know what the platform is doing, not because the changes are genuinely problematic.