De systemen rond Salesforce

🌐 Ook beschikbaar in 28 talen

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

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 3 van 6 in het hoofdstuk Enterprisegegevens begrijpen, hoofdstuk 4 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: De soorten enterprisegegevens · Volgende: Teken het systeemlandschap

De vraag die deze module beantwoordt: Wat omringt Salesforce, en welke rol speelt elk systeem?

De vorige module deelde de data in. Nu wil ik haar ergens neerzetten, en hier komen Salesforce-architecten in de problemen. We kennen Salesforce, dus klantdata betekent account, orderdata betekent Order, documenten betekenen Files, analytics betekent Reports. Maar de enterprise kocht Salesforce niet om al het andere dat ze bezit te vervangen. Er kan een ERP zijn dat financiën en fulfilment draait, een datawarehouse met jaren historie, een integratieplatform, een identiteitsprovider, partnersystemen, een eventplatform, een MDM-platform, en Data 360 dat er meerdere verbindt. De taak is niet technologieën uit je hoofd leren. Het is begrijpen welke taak elk systeem heeft.

Begin niet bij de productnaam

“We hebben SAP” vertelt me niet genoeg. Snowflake, MuleSoft, Tableau of Data 360 ook niet. Ik wil weten wat dat systeem doet in deze architectuur: van welke data het eigenaar is, wat het leest, wat het wijzigt, wie het gebruikt, wat ervan afhankelijk is, wat er gebeurt als het uitvalt. Twee bedrijven kunnen precies dezelfde producten bezitten en een totaal andere architectuur hebben.

Dus label ik systemen op rol. Vier rollen dekken het meeste:

• Bronsysteem (system of record): waar de gezaghebbende versie van iets bijgehouden wordt.
• Engagementsysteem (system of engagement): waar mensen het werk doen.
• Referentiesysteem (system of reference): waar een systeem informatie haalt die het nodig heeft maar niet bezit.
• Inzichtsysteem (system of insight): waar data samenkomt om te meten, te analyseren en te voorspellen.

Eén platform kan meerdere rollen spelen, en de rollen verschillen per data. Salesforce kan het bronsysteem zijn voor cases, het engagementsysteem voor serviceagents, en een afnemer van productdata waarvan het ERP eigenaar is. Dus als iemand zegt “Salesforce is ons bronsysteem”, maak de zin af: bronsysteem waarvoor?

Het ERP: de backoffice heeft zwaartekracht

Het ERP is het systeem dat je het vaakst naast Salesforce vindt; het draait financiën, voorraad, inkoop, fulfilment en facturatie. Het patroon van module 1 (klanten en producten erin, orders eruit) betekent dat het ERP eigenaar is van de producten, maar verkopers hebben ze nog steeds nodig in Salesforce. Prima: haal ze binnen. Maar data kopiëren draagt geen eigenaarschap over. Een kopie is geen zeggenschap.

Mijn standpunt: data waarvan het ERP eigenaar is, wordt lokaal gelezen en gecontroleerd geschreven. Salesforce-gebruikers krijgen de data waar ze werken, maar Salesforce mag niet wijzigen waarvan het ERP eigenaar is. En dat maak ik zichtbaar in het schema: de velden van het ERP krijgen een prefix erp_, zoals erp_Product_Number__c, zodat iedereen die het object leest weet wie eigenaar is van elk veld en voorzichtig moet zijn met wijzigen. De prefix dwingt niets af; dat doen rechten, validatie en het integratiepatroon. Hij communiceert de bedoeling, en hij is de zeggenschapskaart, zichtbaar gemaakt.

Het datawarehouse, het data lake en het lakehouse

Operationele systemen draaien het bedrijf; analytische systemen helpen het te begrijpen. “Laat me mijn open verkoopkansen zien” is een Salesforce-rapport. “Laat me vijf jaar verkoop, fulfilment, retouren, cases, voorraad en financiën over elk kanaal zien” is een ander probleem.

Je komt drie soorten analytische opslag tegen. Een datawarehouse bevat gestructureerde data die voor analyse voorbereid is. Een data lake bevat veel meer data in meer vormen, vaak ruw. Een lakehouse combineert de twee: opslag in de stijl van een lake met analyse in de stijl van een warehouse. Ken ze, want ze verschijnen op landschappen. Maar mijn ervaring is dat lakehouses en data mesh nog een niche zijn in Salesforce-projecten. Het typische landschap is CRM, ERP, een datawarehouse en een integratielaag, met andere platformen waar het bedrijf ze echt nodig heeft. Leer de architectuur; jaag niet op de woordenschat.

Analytics staat waar de data staat

Dit is een van mijn stelligste standpunten: waar analytics staat, volgt waar de data staat. Als het rapport alleen accounts, verkoopkansen en verkopers nodig heeft, staat alles in de core: standaardrapporten en dashboards. Dan vraagt het bedrijf om ERP-facturen toe te voegen. Dan productkosten. Dan vijf jaar orders uit het datawarehouse. Dan websiteactiviteit. Op een gegeven moment heeft het geen zin meer om dat allemaal naar het operationele CRM te slepen alleen om erover te rapporteren. Zodra er andere dataopslag bij betrokken is, wordt een analyticsplatform nodig: Tableau (inclusief Tableau Next, gebouwd op Data 360), of CRM Analytics waar dat al in gebruik is. Het is onmisbaar als Salesforce-data samengevoegd wordt met een datawarehouse. De eis is niet alleen ingewikkelder geworden; het landschap veranderde waar de vraag beantwoord moet worden. Dus begin ik nooit met “welke analyticstool?” Ik begin met waar staat de data?

Ik vraag CTA-kandidaten hetzelfde: “Welk van mijn diagrammen lost dit prachtig op? Het landschap.” Als alles in de core staat, gebruik rapporten. Als je data in andere opslagplaatsen hebt, wil ik een analyticsplatform zien. Het landschap beantwoordt de rapportagevraag voordat iemand een rapportbouwer opent. (De productnamen veranderen; het hoofdstuk over Data 360 behandelt waar de analytics van Salesforce vandaag staat.)

MDM: wie is deze klant echt?

Stel nu dat klantinformatie in Salesforce staat, in het ERP, in e-commerce, in een loyaliteitsplatform en in een partnersysteem, en dat elk ervan denkt te weten wie de klant is. Daar komt master data management binnen: de gezaghebbende identiteit van belangrijke data over systemen heen vaststellen en besturen. Maar MDM is niet “een masterdatabase met klanten”. De moeilijke vragen zijn welk systeem de klant mag aanmaken, van welke attributen elk systeem eigenaar is, hoe duplicaten gevonden worden, welke identificator overblijft, en wat er gebeurt als systemen het oneens zijn. Hoofdstuk 6 gaat daar helemaal over. Herken hier de rol: als er een MDM-platform bestaat, kan het een cruciale zeggenschap zijn tussen Salesforce en de rest van de enterprise.

De integratielaag en de events

Verbind elk systeem rechtstreeks met elk ander, en het landschap wordt snel spaghetti. Daarom hebben enterprises een integratielaag: een ESB (enterprise service bus) of iPaaS (integration platform as a service). MuleSoft is degene die je het vaakst tegenkomt in Salesforce-landschappen. Hij bemiddelt, zodat niet elke applicatie elke andere hoeft te begrijpen.

Maar een vakje MuleSoft in het midden maakt de integratie niet goed. Ik wil nog steeds weten wat erdoorheen gaat en wat niet, wie de data transformeert, wie eigenaar is van het contract, wat er gebeurt als de bestemming uitvalt, of het synchroon of asynchroon is, en hoe we weten dat een bericht gelukt is. De cursus Integration Architect gaat er diep op in; herken het hier als een eigen rol.

En niet elke integratie is systeem A dat systeem B aanroept. Soms gebeurt er iets (een order wordt aangemaakt, een levering verandert van status, een vrachtwagen rijdt een regio binnen), een event wordt gepubliceerd, en wie geïnteresseerd is reageert. Events in beweging hebben ook infrastructuur: de eigen eventmogelijkheden van Salesforce, een enterprise-eventbus, andere messaging. Teken de mechanismen die de data dragen, niet alleen de databases.

Het systeem dat developers vergeten: identiteit

Er is één vakje dat ik altijd op het landschap wil en waar developers zelden aan denken: de identiteitsprovider. Developers loggen rechtstreeks in op hun sandboxes met een gebruikersnaam en wachtwoord, dus identiteit is onzichtbaar tijdens het bouwen. Dan komen UAT of productie, en opeens is er de single sign-on van het bedrijf voor medewerkers, misschien een tweede provider voor partners, social sign-on voor klanten. Identiteit was altijd deel van de architectuur. De developer zag het alleen nog niet.

Een identiteitsprovider (IdP) is het systeem dat een gebruiker authenticeert en de identiteit vaststelt die Salesforce vertrouwt. Hij hoort vanaf dag één op het landschap, ook als hij later in de releasepipeline geconfigureerd wordt, want wie binnen kan komen, bepaalt wie bij de data kan komen.

Er is ook een praktisch addertje: identiteitsconfiguratie is uitrolbaar, maar niet helemaal. De configuratie van SAML-single-sign-on en authenticatieproviders zijn Metadata API-types, dus ze reizen mee door de pipeline (SamlSsoConfig (opens in a new tab)). Maar consumer secrets van authenticatieproviders worden niet meer teruggegeven in antwoorden van de Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), en certificaten verschillen meestal per omgeving. Plan voor de delen die meereizen en de delen die dat niet doen.

Click to enlarge

Lees het landschap als rollen, niet als logo’s: wat elk systeem bezit, leest of beslist.

Waar staat Data 360?

Data 360 levert een mooie tekenvraag op. Ik zet het rechts, onder de ESB of MuleSoft. De reden zijn de verbindingen: gebruikers verbinden er nooit rechtstreeks mee, terwijl het rechtstreeks met veel backendsystemen verbindt. Dus het hoort bij het dataleidingwerk, waar die lijnen kort blijven, niet bij de gebruikers. Teken het als nog een scherm waar mensen op inloggen, en je vertelt het verkeerde verhaal.

Admins en datateams openen de schermen van Data 360 wel, maar die schermen staan in de org, in de core. De tenant die het werk doet, zijn data en zijn verwerking, draait buiten de core. Daarom noem ik het near-core: beheerd in de core, gehost buiten de core (module 1 legt de termen uit). De tekening volgt de tenant: hij staat bij het leidingwerk, met één lijn terug naar de org die hem beheert.

Wat het doet omvat, in de woorden van Salesforce, zero copy: een technologie voor datafederatie waarmee een enterprise data kan benaderen en bevragen zonder haar te kopiëren (Zero Copy (opens in a new tab)). De mogelijkheden en connectoren veranderen snel, dus het hoofdstuk over Data 360 behandelt ze goed, in plaats van deze module in een producttour te veranderen.

Lees het landschap als verantwoordelijkheden

Als je naar een landschap kijkt, lees dan niet de logo’s; lees de verantwoordelijkheden. Het ERP: waarvan is het eigenaar? Het datawarehouse: welke vragen beantwoordt het? Het integratieplatform: wat verplaatst het? De IdP: wie authenticeert hij? MDM: welke identiteit bestuurt het? Data 360: wat verbindt het, en waarvoor? Salesforce: waarvoor is het eigenlijk verantwoordelijk? Zodra je die kunt beantwoorden, betekenen de vakjes iets, en worden de pijlen ertussen veel interessanter. Hierna tekenen we ze bewust.

Wat een architect hier beslist

• Welke rol elk systeem speelt, voorbij zijn productnaam.
• Welk systeem gezaghebbend is voor elke belangrijke dataset, en waar Salesforce alleen een lokale kopie bewaart.
• Of data waarvan het ERP eigenaar is in Salesforce beschikbaar is met gecontroleerde schrijfacties, en hoe dat eigenaarschap in het schema zichtbaar is.
• Waar analytics hoort, op basis van waar de data staat.
• Waar identiteit, integratie, events en de zeggenschap over stamgegevens op het landschap staan.

Een landschap met tien rechthoeken is geen architectuur; het is een inventaris. Architectuur begint als je naar elke rechthoek kunt wijzen en zeggen waarom hij er staat, waarvan hij eigenaar is, wie hem gebruikt, wat Salesforce ervan nodig heeft, en wat er misgaat als je zijn rol verkeerd begrijpt.

Verder lezen

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (productpagina, Engels, gecontroleerd op 2026-10-14).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (Engels).