Salesforce is één systeem van vele

🌐 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 1 van 6 in het hoofdstuk Enterprisegegevens begrijpen, hoofdstuk 4 van de cursus Data Architect. Elke module staat op zichzelf. Volgende: De soorten enterprisegegevens

De vraag die deze module beantwoordt: Waarom tekent een data-architect wat de org omringt voordat hij de org ontwerpt?

Als ik CTA-kandidaten lesgeef, is het huiswerk na de eerste dag altijd hetzelfde. Lees het scenario. Begin het systeemlandschap op een leeg canvas. Waag je pas daarna aan het datamodel. Niet de objecten, niet de integraties in detail: het landschap. Ik wil zien wat Salesforce omringt voordat we beslissen wat erin hoort.

Dat is voor veel Salesforce-professionals een andere blik. Als je je hele loopbaan admin of developer bent geweest, is Salesforce vanzelfsprekend het middelpunt van je wereld. Je opent Setup, maakt objecten, bouwt flows, schrijft Apex en integreert andere systemen in Salesforce. Alles lijkt bij de org te beginnen. Een architect moet uitzoomen, want in een enterprise is Salesforce één systeem van vele, en vaak is het niet het systeem dat eigenaar is van de data.

Teken eerst het landschap

Hoofdstuk 2 bouwde het logische model, en hoofdstuk 3 vroeg hoe het op Salesforce leeft. Nu maak ik het probleem groter. Voordat ik beslis waar Salesforce eigenaar van moet zijn, wil ik de enterprise eromheen begrijpen. Welke systemen bestaan er al? Waar worden klanten aangemaakt, producten gedefinieerd, orders gestart, facturen gegenereerd? Waar staat identiteit? Waar gebeurt analytics, waar worden documenten bewaard, waar staat de historie? Welke systemen hebben de data van Salesforce nodig, en van welke is Salesforce afhankelijk?

Die vragen veranderen de architectuur. Dus begin ik op een leeg canvas, zet Salesforce in het midden en teken alles eromheen. Module 4 laat precies zien hoe ik het indeel. Voor nu is de les gewoon: ontwerp de org niet voordat je de wereld begrijpt waarin hij moet leven.

Salesforce is vaak niet het bronsysteem

Neem een heel gewone enterprise: Salesforce plus een ERP, een systeem voor enterprise resource planning zoals SAP of Oracle, dat financiën, producten, voorraad, inkoop en fulfilment regelt. Stel nu een eenvoudige vraag: waar staat de klant?

Dat kan Salesforce zijn, het ERP, of allebei, en daar wordt het interessant. Verkopers kunnen prospects als accounts in Salesforce bewerken, terwijl het ERP het officiële klantnummer uitgeeft zodra ze betalende klant worden. Producten en prijzen? Waarschijnlijk het ERP. Voorraad? Bijna nooit Salesforce. Orders worden misschien in Salesforce vastgelegd en in het ERP uitgevoerd; facturen komen uit het ERP; service staat in Salesforce; analytics is verdeeld tussen Salesforce-rapporten en een datawarehouse. Opeens is ons mooie Salesforce-datamodel niet het enterprisedatamodel. Het is er één deel van.

De integratie die ik steeds weer zie

De meest voorkomende integratie die ik zie gaat zo: klanten, producten en prijzen stromen vanuit het ERP Salesforce in, en orders stromen eruit. Vervang het door SAP, Oracle of een ander ERP; de vorm is dezelfde. Het ERP is eigenaar van het golden record voor de klant en het product, dus die stromen komen van rechts, Salesforce in. Sales sluit de deal in Salesforce, dus de order begint daar en gaat terug naar het ERP om uitgevoerd, gefactureerd en verantwoord te worden.

Die stromen zijn niet zomaar integraties. Ze vertellen me waar de enterprise gelooft dat de waarheid staat.

Pijlen in één richting maken me nerveus

Als ik een integratie zie met maar één flow, begin ik me zorgen te maken. Op hoog niveau tekent iemand één pijl: orders van Salesforce naar het ERP. Prima. Kijk nu dieper. Hoe kan ik een order naar het ERP sturen als ik zijn klanten, zijn producten of zijn prijzen niet ken? De order moet gekoppeld zijn aan een klant die het ERP al heeft, en elke regel moet een SKU zijn die het ERP al verkoopt. Ik kan geen orderregel sturen voor een product dat aan de andere kant niet bestaat. Dus voordat die orderpijl kan werken, moeten er terugstromen bestaan, die de andere kant op lopen.

Dat is de vraag die ik bij elke pijl stel: waar hangt deze stroom van af? De pijl op hoog niveau die je ziet, heeft meestal terugstromen nodig die je nog niet getekend hebt.

Kijk nog dieper en je vindt de terugweg. Salesforce stuurt een order. En dan? Is hij geaccepteerd of geweigerd? Is hij verzonden, deels verzonden, geannuleerd? Is hij gefactureerd? Moet iemand in Salesforce dat weten? Misschien niet. Maar iemand had het moeten vragen. Als er niets terugkomt, prima. Vertel me waarom.

De enterprise kwam er niet in één keer

Landschappen worden ingewikkeld, deels omdat niemand ze in één keer bouwde. Data kwam in golven. Eerst bestanden: records met een vast formaat, daarna bestanden met scheidingstekens zoals CSV. Dan relationele databases voor operationele data. Dan datawarehouses om alles samen te brengen voor analyse. Dan NoSQL-databases voor documenten, key-valueparen en grafen die niet netjes in tabellen passen. Dan data lakes voor enorme hoeveelheden ruwe en semigestructureerde data, en lakehouses die de twee combineren. Eventstreams, zoals Kafka of de Salesforce-eventbus, verplaatsen data op het moment dat het gebeurt in plaats van in nachtelijke batches. En nu federatie, waarbij data niet eerst naar één plek gekopieerd hoeft te worden voordat een ander platform haar kan gebruiken.

De technologie is nog niet het punt. Dit wel: de nieuwe golf laat de oude zelden verdwijnen. Loop een grote enterprise binnen en je vindt ze allemaal tegelijk: relationele databases, het ERP, Salesforce, een datawarehouse, een data lake, SFTP-bestanden, API’s, eventstreams, de spreadsheet die iemand nog elke vrijdag mailt, en dat ene systeem dat iedereen niet durft aan te raken omdat de persoon die het bouwde zes jaar geleden met pensioen ging. Dat is de enterprise waarvoor je de architectuur maakt, niet die uit de productbrochure.

Verschillende systemen bestaan om verschillende redenen

Daarom begin ik ook nooit met “hoe krijgen we alle data in Salesforce?” Waarom zou ik alles daar willen hebben? Salesforce is misschien de beste plek voor sales- en servicemensen om met klanten te werken. Dat maakt het nog niet het financiële systeem, het enterprisedatawarehouse, de telemetrieopslag, het documentarchief, of het thuis van elke klik, elke gps-meting en elke historische transactie die het bedrijf ooit heeft geproduceerd.

Hoofdstuk 3 vroeg waar hoort deze data te staan? voor één org. Op enterpriseniveau wordt dezelfde vraag groter: soms is Salesforce eigenaar van de data, soms bewaart het een kopie, soms alleen een verwijzing, en soms zou het de data helemaal niet moeten hebben.

Core, off-core en Hyperforce

Er is nog een grens om te begrijpen: zelfs “Salesforce” is niet één runtime en één database. In hoofdstuk 3 betekende in de core waar de data staat: op je bureau, in de eigen objecten van de org. Hier beschrijven dezelfde woorden waar een product draait. Je hoort architecten beide gebruiken.

Historisch draaide het grootste deel van het platform op de Core-runtime. Vandaag beschrijft Salesforce een platform van honderden onafhankelijke, metadatagestuurde services, waarbij Core het enige bronsysteem voor applicatiemetadata blijft (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Daarom hoor je architecten zeggen dat een functie in de core of buiten de core draait.

Het deed er al toe lang voordat het platform zich in services opsplitste. Als ik een klas vraag waarom Salesforce voor offertes SteelBrick kocht en niet Apttus, is het antwoord dat ik zoek simpel: SteelBrick was 100% in de core gebouwd. Flows en triggers leven in de core, dus een product dat daar gebouwd is, krijgt de metadata, aanpassingen en automatisering van het platform erbij. Dat offerteproduct heeft inmiddels plaatsgemaakt voor Revenue Cloud, maar de les niet. Dan is er near-core (dicht bij de core), en Data 360 is het voorbeeld dat ik gebruik. Data 360 is geen core. Zijn tenant staat buiten de core: de data en de mechanismen die haar verwerken draaien in een eigen lakehouse, naast de relationele database van de org in plaats van erin (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Maar de schermen waarmee je het inricht en bestuurt, worden in de core getoond, in de org. Dus zo precies als ik het kan zeggen: beheerd in de core, gehost buiten de core. Geen van de data of verwerking draait echt in Core; de UI in Core bestuurt de tenant buiten de core. En dan is er natuurlijk alles wat buiten de core staat omdat het helemaal geen Salesforce is.

Ik vind het minder belangrijk om uit je hoofd te leren welk product dit jaar waar draait, want dat verandert, dan de gewoonte: een grens kan invloed hebben op dataverkeer, vertraging, identiteit, integratie en dataresidentie. Ga er dus niet van uit dat de data van een product dat Salesforce heet vlak naast je accountrecords staat. Kijk naar de werkelijke architectuur.

Dan is er Hyperforce: de infrastructuur van Salesforce, gebouwd voor de publieke cloud en gedefinieerd als code, in plaats van de traditionele eigen datacenters, die klanten meer keuze geeft over waar hun data staat (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Dat doet ertoe, en module 5 komt erop terug. Maar infrastructuurarchitectuur is geen enterprisedata-architectuur. Een org naar de publieke cloud verhuizen vertelt je niet wie eigenaar is van de klant, waar de voorraad staat, waar analytics draait of welke data een grens mag oversteken. Hyperforce kan sommige van die beslissingen vormen, vooral dataresidentie. Het vervangt niet dat je het landschap kent.

Het landschap komt vóór het vakje

Dus dit is de gewoonte. Iemand geeft je een scenario. Begin niet met het bouwen van de Salesforce-oplossing. Vind eerst de systemen: het ERP, de identiteitsprovider, het datawarehouse, het integratieplatform, partnersystemen, klantkanalen, documentopslag. Vind dan de data die ertussen beweegt: klanten, producten, orders, facturen, documenten, events, identiteiten. Vraag dan wie eigenaar is van elk ervan. Beslis pas daarna wat er in Salesforce hoort. Anders ontwerp je een vakje zonder te weten waarmee het verbonden is.

Click to enlarge

Stap 1 van 3: de org die we ontwerpen, op zichzelf. Van hieruit lijkt het de hele wereld.

Click to enlarge

Stap 2 van 3: zoom uit. Salesforce is één systeem tussen vele (module 4 leert je deze indeling).

Click to enlarge

Stap 3 van 3: de eerste pijlen. Klanten, producten en prijzen in vanuit het ERP, orders uit: ze laten zien waar de organisatie gelooft dat de waarheid woont.

Het landschap verandert het datamodel

Daarom doet het ertoe voor een data-architect. Hoofdstuk 2 zegt dat de klant een belangrijke entiteit is. Prima. Dan zegt het landschap dat het ERP gezaghebbend is voor de klant. Dat verandert het fysieke model. Salesforce kan nog steeds een lokaal account bewaren, omdat mensen het elke dag gebruiken, maar nu hebben we de identificator van het ERP nodig als externe ID; moeten we weten welke velden Salesforce mag wijzigen (ik markeer de velden van het ERP met een prefix erp_, zoals we in module 3 zullen zien); hoe snel ERP-wijzigingen aankomen; of Salesforce een klant kan aanmaken voordat het ERP ervan weet; en wat er gebeurt als de twee het oneens zijn. Dat zijn geen integratievragen voor later. Het zijn data-architectuurvragen, en het landschap heeft ze blootgelegd.

Zo kan er een gaan bijten. Een verkoper converteert een lead voor een groot drankenbedrijf, maakt het account aan, wint de deal, en de klant gaat over naar het ERP. Maar het bedrijf doet al jaren zaken met dat drankenbedrijf, en het ERP heeft het al. Nu zijn er twee. Had de verkoper dat account überhaupt mogen aanmaken? Hoofdstukken 5 en 6 komen erop terug; in het landschap zie je het aankomen.

Wat een architect hier beslist

• Welke systemen Salesforce omringen, en welke rol elk speelt.
• Welk systeem eigenaar is van elke belangrijke soort data, voordat je beslist hoeveel ervan Salesforce bewaart.
• Wat Salesforce in stroomt, wat eruit stroomt, en wat er terugkomt.
• Welke data Salesforce moet bezitten, kopiëren, ernaar verwijzen, federeren, archiveren of met rust laten.
• Welke platform- en infrastructuurgrenzen ertoe doen, in plaats van aan te nemen dat alles met het merk Salesforce op één plek staat.

De stap van developer naar architect is vaak niet nog een functie leren. Het is leren wanneer je moet stoppen met naar Salesforce kijken: uitzoomen, de data volgen, vinden wie eigenaar is van de waarheid, en dan terugkomen en beslissen wat de taak van Salesforce moet zijn.

Verder lezen

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).