Skip to content
SteveTechArcSteveTechArc Courses

Understanding Enterprise Data

Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Chapter 4 of Data Architect, Part 1: Becoming a Data Architect. Previous: Salesforce Data Architecture.

When I teach CTA candidates, the homework after the first day is always the same. Read the scenario. Start the system landscape from a blank canvas. Then, and only then, take a stab at the data model.

People are surprised by the order. We’re data architects; shouldn’t we start with the data model? Here’s why I don’t. If I draw the data model first, I’ve already decided what belongs in Salesforce. If I draw the landscape first, I can see everything that should shape that decision: the ERP that owns the customers and products, the warehouse that answers the five-year questions, the identity provider that decides who gets in, the partner sending a file every afternoon, the legacy system everybody says is being retired.

Chapters 2 and 3 designed the org: what the model should be, and how it lives on Salesforce. This chapter pulls the camera back and draws what surrounds the org, before the org is designed. Salesforce is one system among many, and quite often it isn’t the one that owns the data.

Lead architect drawing a system landscape around Salesforce on a whiteboard for two colleagues on a misty morning

Image generated with AI.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • The landscape comes first. Find the systems, then the data moving between them, then who owns each piece. Only then decide what Salesforce’s job is.
  • An arrow depends on other arrows. Orders out to the ERP need customers, products and prices in first. Whenever I see an integration with only one flow, I start to get concerned.
  • Data comes in kinds, and workloads. Master, reference, transactional, metadata, analytical and unstructured data change, grow and get used differently; operational (OLTP), analytical (OLAP) and streaming workloads want different homes. The org runs the business; warehouses and lakes analyze it.
  • Systems have roles, not just logos. Record, engagement, reference, insight. “Salesforce is our system of record”: for what?
  • Where analytics lives follows where the data lives. All on core: standard reports. Data in other stores: an analytics platform, and the warehouse when Salesforce data is merged with it.
  • Data 360 is near-core: managed on core, hosted off core. Users never connect to it, so it sits with the plumbing.
  • ERP-owned data is read locally and written under control, with an erp_ prefix so the schema shows who owns each field.
  • On a landscape, an arrow starts at the system that opens the connection, and its label says what moves and which way. Two flows are two arrows; a double-headed arrow is only for a connector.
  • Every arrow has a client and a server, and each owns its half. None of it goes on the landscape, but every arrow has it.
  • Count before you draw the arrows. The zeros go in the inventory, and they choose the mechanism: batch, synchronous or events.
  • Org strategy is a landscape decision, made in the first minutes: one org or many, and where it runs.
  • A current state shows what’s wrong. Red for a bad process, dashed for by hand, red dots for what’s missing.

Steve’s landscape layout

Section titled “Steve’s landscape layout”

There are many ways to draw a system landscape. This is mine, refined over many years, and it reads like a sentence: people on the left reach Salesforce in the middle, trusted through the systems above it, served through the channels below it, and connected to the back office on the right.

WhereWhat goes there
LeftThe people, top to bottom: internal users, partners, customers
CenterSalesforce, one plain box, with its communities touching it below
TopIdentity providers over Salesforce; AppExchange slid right; public websites top left
RightThe integration layer, then the internal systems: ERP, finance, warehouse
Below the integration layerData 360, near-core, with the plumbing
BottomCustomer channels: email, web forms, phone, messaging
Bottom rightData in and out: archives, data loads, external sources, partners

Systems are cards in faint, labeled zones, each with an icon, and a legend says what everything means. Behind the picture sits an inventory: for each data set or flow, its owner, volume, mechanism and timing, authentication, and whether to copy, reference or federate it.

The landscape with its arrows The same landscape as before, now with arrows; each starts at the system that opens the connection, and its label says what moves and which way. Internal users reach Salesforce, partner users the Partner Community, customers the Customer Community. Each identity provider and Salesforce share a certificate, shown as a dotted green line with a certificate at each end: trust, not a direct call, because sign-on travels through the user's browser as redirects. The employee identity provider also sends user updates to Salesforce. Salesforce sends documents out to the AppExchange e-signature app, and orders out to the integration layer, which sends products in to Salesforce. The integration layer sends orders out and brings products in from the ERP; the ERP sends order status in to the integration layer; the integration layer brings payments in from finance. Data 360, below the integration layer, opens its connections: CRM data out of Salesforce, zero copy to the warehouse, and a reference to the external data. From below, email sends cases in and web forms send leads in to Salesforce; Salesforce sends old cases out to the archive; data loads send records in. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.28.0", "built": "2026-10-15", "id": "DGM-DA-ED-42", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "system-landscape 0.10.0", "theme": "stevetecharc 1.4.0"} ABOVE: IDENTITY, APPEXCHANGE, WEB PEOPLE RIGHT: INTERNAL SYSTEMS BELOW: CUSTOMER CHANNELS BOTTOM RIGHT: DATA IN AND OUT Internal users sales, service, operations Partner users Customers Public website Employee IdP single sign-on Partner IdP single sign-on AppExchange app e-signature Partner Community Customer Community Data 360 near-core: managed on core, hosted off core INTEGRATION LAYER (ESB) ERP orders, invoices Finance payments Order management Warehouse analytics Email email-to-case Web forms web-to-lead Phone contact centre Messaging SMS, chat Archive old cases Data loads migration External data referenced, not copied Salesforce the org we design around shared certificate user updates shared certificate documents out orders out products in orders out, products in order status in payments in CRM data out zero copy referenced cases in leads in old cases out records in Salesforce a community people identity, apps, web an internal system a customer channel data in and out the integration layer dashed: not live yet, or referenced starts at the system that opens the connection; the label says what moves a shared certificate: trust, no direct call © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Module 4’s landscape, with its arrows.

The path through this chapter

Section titled “The path through this chapter”

Six modules, each one standing on its own.

  1. Salesforce Is One System Among Many. Why the landscape comes before the box, the integration I see over and over and the back flows it depends on, data in waves, and core, near-core and Hyperforce.
  2. The Kinds of Enterprise Data. Six kinds; created, edited, referenced; OLTP and OLAP; real time, near real time and batch; the four questions behind the categories.
  3. The Systems Around Salesforce. System roles; the ERP, the warehouse and the lakehouse; analytics follows the data; MDM; integration and events; the identity provider developers forget; where Data 360 sits.
  4. Draw the System Landscape. My layout, built up from a blank canvas; the zeros before the arrows; arrows that start at the initiator; the client and the server behind every arrow, both ways; swim lanes for conversations; the inventory behind the picture.
  5. Org Strategy Is a Landscape Decision. Start with one org; what justifies another; the region, not the provider; a GDPR-driven split into AMER and EMEA; what the second org adds.
  6. Steve Trucking’s Landscape. Today, before a proper implementation, marked: manifests landing in RouteDesk, routes rekeyed into Salesforce and back by hand, an island of GPS data, a spreadsheet feeding finance, and 108,000 “where’s my delivery?” calls a year.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

Section titled “What an architect decides here”
  • Which systems surround Salesforce, and what role each one plays.
  • Which system owns each important kind of data, before deciding how much of it Salesforce keeps.
  • How every connection works: what moves, in which direction, how it authenticates, how fast, and what comes back.
  • How many orgs, and where they run, decided first, because everything else on the landscape depends on it.
  • Whether the current state is understood well enough to design a target state.

Beyond the exam: the landscape is becoming an agent map. Before an agent can answer “where’s my delivery?”, someone has to know which system is authoritative for each fact, how current it is, and how the agent may reach it. Each module ends with what AI changes for its part of the picture.

Explore

Section titled “Explore”

Next: Data Quality and Governance