Orgstrategie is een landschapsbeslissing

🌐 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 5 van 6 in het hoofdstuk Enterprisegegevens begrijpen, hoofdstuk 4 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Teken het systeemlandschap · Volgende: Het landschap van Steve Trucking

De vraag die deze module beantwoordt: Eén org of meerdere, en waar draait hij?

Als ik CTA-kandidaten lesgeef, vertel ik ze dat de grootste beslissing in een scenario in de eerste vijf of tien minuten valt: met hoeveel Salesforce-orgs hebben we te maken? Eén grote org? Regionale orgs voor Noord-Amerika, EMEA en APAC? Aparte orgs voor aparte bedrijfsonderdelen? Een speciale org voor een land met eigen regels? En daar direct aan vast: waar draaien die orgs?

Dat zijn geen admindetails. Ze veranderen waar de data staat, de integraties, rapportage, identiteit, en hoe mensen over de hele wereld het systeem bereiken. Daarom behandel ik orgstrategie als een landschapsbeslissing, en daarom neem ik haar als eerste.

Begin met één org

Mijn uitgangspunt is eenvoudig: begin met één org. Niet omdat één org altijd juist is, maar omdat ik een reden nodig heb om er een toe te voegen. Eén org geeft me één plek voor gedeelde klantdata, één beveiligingsmodel, één plek om uit te rollen, één set integraties, één plek om te rapporteren. En één org kan nog steeds verschillende bedrijfsonderdelen, landen, processen, recordtypes, apps, sharingmodellen en ervaringen ondersteunen.

Dus ik voeg geen org toe omdat Europa dingen een beetje anders doet, of een divisie een eigen salesproces heeft, of de bedrijfsonderdelen elkaar niet mogen. Dat zijn eisen, geen orggrenzen. De vraag is: welke kracht is sterk genoeg om nog een org te rechtvaardigen?

Meerdere orgs hebben een prijs

Splits één org in drie (Noord-Amerika, Europa, Azië-Pacific) en je hebt geen drie nette vakjes getekend; je hebt nieuwe vragen gemaakt. Waar staat een wereldwijde klant? Wat als die in twee regio’s actief is: twee kopieën, en welke is eigenaar? Hoe rapporteert iemand wereldwijd? Integreert het ERP met alle drie, krijgt het datawarehouse drie feeds, verbindt de identiteitsprovider met alle drie? Rollen we dezelfde functionaliteit drie keer uit en houden we drie datamodellen gelijk? Als een agent een wereldwijd beeld van een klant nodig heeft, welke org vraagt hij dan?

Ga terug naar het landschap uit module 4. Eén Salesforce-vakje wordt er drie, en elke pijl wordt opnieuw getekend. Meerdere orgs zijn niet fout. Ze zijn nooit gratis.

Zoek naar echte grenzen

Wat kan nog een org rechtvaardigen? Grenzen die echt genoeg zijn om de architectuur te vormen: dataresidentie, regelgeving, juridische scheiding, werkelijk verschillende bedrijfsmodellen, een overname die nog niet samengevoegd is, een regionale hostingbeperking, heel verschillende governance, soms schaal of isolatie. De lijst is niet volledig. Het gaat erom “deze groepen zijn anders” te onderscheiden van “deze groepen hebben een architectuurgrens nodig.” De tweede lat ligt veel hoger.

Geografie is niet automatisch een orgstrategie

“We zijn actief in 30 landen, dus we hebben 30 orgs nodig.” Nee. Geografie doet ertoe als ze een architectuureis meebrengt. Een bedrijf kan gebruikers over de hele wereld hebben op één gemeenschappelijke architectuur. Dus ik tel geen landen; ik vraag wat ermee meekomt. Waar mag de data opgeslagen worden? Waar mag ze verwerkt worden? Zijn er grenzen aan het verplaatsen van persoonsgegevens over landsgrenzen? Contractuele beloftes over dataresidentie? Heeft een regio een andere Salesforce-dienst of host nodig? “Er is een kantoor in Duitsland” is op zichzelf niet genoeg.

Hosting hoort bij de tekening

Hier maakt het moderne platform het landschap interessanter. Hyperforce draait Salesforce op publieke cloudinfrastructuur in regio’s over de hele wereld, en geeft klanten meer keuze en controle over waar hun data staat (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Dus als ik een vakje “Salesforce, Europa” label, kan die locatie ertoe doen.

Maar wees precies. Kiezen waar een org staat is geen belofte dat elke byte van elke dienst daar blijft. Salesforce vraagt klanten de trust- en compliancedocumentatie voor Hyperforce door te nemen, inclusief de extra subverwerkers voor de diensten die ze kopen (zelfde bron). Zeg dus niet “we zitten op Hyperforce in land X, dus alles blijft in land X.” Weet welke diensten je echt gebruikt, en aan welke eis je voldoet. En let op wat je kiest: de regio, niet de cloud eronder. Hyperforce draait op AWS, vanaf eind 2026 ook op Google Cloud, en Salesforce beslist op welke provider een org staat; een klant met een gedocumenteerde regelgevende reden om er een te vermijden, neemt contact op met zijn accountteam (zelfde bron).

Speel geen advocaat

Hier moeten architecten ook hun rol kennen. Als iemand zegt “de Europese privacywet vereist een aparte org”, accepteer ik dat niet blind. Ik benoem mezelf ook niet tot advocaat van het bedrijf om te verklaren dat het niet zo is. Ik vraag: aan welke specifieke eis voldoen we? Waar data opgeslagen wordt, waar ze verwerkt wordt, doorgifte over de grens, wie erbij kan voor support, een contract, intern beleid? Dan werk ik met privacy, security, compliance en juridische zaken om die eis om te zetten in architectuur. Verzin geen juridische eisen, en negeer ze ook niet. Vertaal ze.

Als Europa een eigen org krijgt

Hier is een grens die ik in echte scenario’s zie. Een bedrijf heeft een grote aanwezigheid in de VS en een grote aanwezigheid in Europa: twee grote klantenbestanden, twee sales- en serviceorganisaties, en een Europees privacyprogramma gebouwd rond de AVG (GDPR). De AVG zegt niet “je hebt een aparte Salesforce-org nodig.” Ze stelt regels voor persoonsgegevens, onder meer wanneer die buiten de EU mogen worden doorgegeven (AVG, hoofdstuk V (opens in a new tab)). Maar dit bedrijf beslist, samen met zijn privacy- en juridische teams, dat de persoonsgegevens van zijn Europese klanten in een org moeten staan die in Europa gehost wordt, gerund door zijn Europese team, onder zijn Europese governance. Dat is een echte eis, en het is die van hen, niet de mijne.

Nu is “één grote wereldwijde org” geen voorkeur meer. Er staat een grens op het landschap, Salesforce AMER en Salesforce EMEA, en die moet ik tekenen. En de tweede org is nooit zomaar één vak extra.

Click to enlarge

Twee orgs, AMER en EMEA. Het amber is wat de tweede org toevoegt: niet één vak extra, maar elke pijl opnieuw.

Loop de pijlen opnieuw door

Met meer dan één org loop je het landschap opnieuw door. Stuurt het ERP producten naar elke org? Stuurt elke org orders terug? Waar worden klanten beheerd, en mag hun data regio’s oversteken? Is de integratielaag wereldwijd of regionaal? Welke identiteitsprovider logt welke gebruikers in? Waar gaat de analytische data heen?

Drie plekken laten de prijs het snelst zien:

Rapportage. De CEO wil een wereldwijde pipeline. In één org is dat een Salesforce-rapport. In drie is het een enterpriseprobleem voor rapportage: repliceren, naar het datawarehouse sturen, federeren? Hoe actueel moet het zijn, en definiëren de orgs “pipeline” eigenlijk wel op dezelfde manier? Waar analytics staat, volgt waar de data staat, en als je de operationele data bewust splitst, moet je ontwerpen hoe het inzicht weer samenkomt.

Stamgegevens. Een wereldwijde klant koopt in de VS, Duitsland en Japan. Drie orgs, dus waarschijnlijk drie accounts. Hoe weet je dat het hetzelfde bedrijf is? Wat is de wereldwijde identificator, en wie is er eigenaar van? Als één regio het adres wijzigt, moet dat zich verspreiden? Welke attributen zijn wereldwijd en welke regionaal? Orgstrategie lost identiteit niet op; ze verandert het identiteitsprobleem. Dat is hoofdstuk 6.

Integratie. Eén org: Salesforce, de integratielaag, het ERP. Drie orgs: drie verbindingen met de integratielaag, misschien één met een eigen host en connectiviteit, sommige stromen gedeeld, sommige regionaal, sommige data mag erover en sommige niet. Zelfs het netwerk kan veranderen: als de enterprise toegewijde privéconnectiviteit met Hyperforce nodig heeft (op AWS raadt Salesforce AWS Direct Connect aan; zelfde Hyperforce-FAQ), is elke org en host op de tekening nog een verbinding om te plannen. Waar een org draait, kan veranderen hoe de rest van de enterprise hem bereikt.

Eén org of meerdere is een beslissing die je nu neemt, aan het begin, op het landschap. Hoe de orgs daarna data delen (Salesforce Connect tussen orgs, integratie ertussen, Data 360) is de mechaniek, en hoofdstuk 14, Eén org of meerdere? (coming soon), behandelt die.

Als je het hele datamodel en de integratiearchitectuur ontwerpt en pas daarna hoort “o ja, dit moeten drie orgs worden”, heb je geen kleine aanpassing gedaan. Je hebt de architectuur veranderd. Daarom komt de beslissing eerst.

Splits niet alleen om de vakjes kleiner te maken

Een grote org voelt ingewikkeld: veel onderdelen, objecten, gebruikers, integraties. Iemand zegt: “Zou het niet overzichtelijker zijn als iedereen een eigen org had?” De tekening wordt misschien overzichtelijker. De enterprise misschien niet. Je hebt interne complexiteit geruild voor verspreide complexiteit: synchronisatie, dubbele data, identiteit over orgs heen, wereldwijde rapportage, meerdere releasepipelines, gedupliceerde integraties en automatisering, en governance over dat alles. Soms is dat nog steeds de juiste ruil. Maar apart is niet hetzelfde als eenvoudig.

En één org is ook niet gratis. Gedeelde governance doet er meer toe, teams kunnen elkaar beïnvloeden, beveiligingsgrenzen vragen een zorgvuldig ontwerp, het datamodel moet veel groepen dienen, releases vragen coördinatie, en regionale regels kunnen iedereen beperken. Dus het is niet “Steve zegt altijd één org.” Mijn neiging bij de start is één org; dan zoek ik de eis die sterk genoeg is om me daarvan af te brengen.

Maak de beslissing zichtbaar

Als orgstrategie ertoe doet, teken dan geen generieke Salesforce-wolk. Teken de orgs en label ze (AMER, EMEA, wat er ook echt is), noteer de hosting- of residentie-eis achter elk, en loop de verbindingen door. Een andere architect moet kunnen zien waarom elke grens bestaat. Als ik niet kan uitleggen waarom er drie Salesforce-vakjes zijn, heb ik de beslissing niet afgemaakt.

Steve Trucking draait één org, in de VS, en niets in de briefing vraagt om nog een. Maar houd deze module in gedachten voor de eindopdracht: een overname die met een eigen org binnenkomt, is precies het soort grens dat deze vragen op de proef stelt.

Voorbij het examen: wat AI verandert. Een agent kan een orggrens onzichtbaar maken voor de gebruiker. Daaronder moet de architectuur nog steeds beslissen welke org of welk systeem de agent mag vragen, welke data regio’s mag oversteken, en welk antwoord gezaghebbend is. AI kan de complexiteit in de ervaring verbergen; het haalt de governance of de grens niet weg.

Wat een architect hier beslist

• Of er een echte architectuurreden is voor meer dan één org, in plaats van de verschillen binnen één org op te lossen.
• Waar elke org draait, en welke residentie-, regelgevings-, contractuele of bedrijfseis hem daar zet.
• Welke data org- en regiogrenzen mag oversteken, waar stamgegevens gezaghebbend zijn, en hoe wereldwijde identiteit werkt.
• Hoe integratie, identiteit, analytics en rapportage veranderen als één Salesforce-vakje er meerdere worden.
• Of het voordeel van scheiding de verspreide architectuur waard is die ze oplevert.

Als ik een scenario lees, zoek ik eerst naar deze beslissing: één org of meerdere, waar gehost, en waardoor afgedwongen? Beantwoord die, en de rest van het landschap begint vorm te krijgen.

Verder lezen

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• EUR-Lex, Verordening (EU) 2016/679, de Algemene verordening gegevensbescherming (opens in a new tab), hoofdstuk V (doorgifte van persoonsgegevens aan derde landen), gecontroleerd op 2026-10-14.