De soorten enterprisegegevens

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)

A kitchen where each kind of food is kept its own way: bins and jars on the pantry shelves, fresh food on the counter, the fridge and freezer, a recipe book. — Afbeelding gegenereerd met AI

Module 2 van 6 in het hoofdstuk Enterprisegegevens begrijpen, hoofdstuk 4 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Salesforce is één systeem van vele · Volgende: De systemen rond Salesforce

De vraag die deze module beantwoordt: Welke soorten data heeft een enterprise, en waarom horen ze op verschillende plekken?

Een klantrecord. Een lijst met landen. Een order. Een velddefinitie. Vijf jaar verkooptotalen. Vier miljoen leveringsfoto’s. Het is allemaal data, maar architecturaal is het niet hetzelfde. Ze veranderen anders, groeien anders, worden anders gebruikt en hebben verschillende eigenaren, en ze horen niet automatisch op dezelfde plek. Dus als iemand zegt “we hebben deze data nodig in Salesforce”, is mijn volgende vraag: wat voor soort data is het? Het antwoord begint me te vertellen wat ik ermee moet doen.

Begin bij de soort, niet bij het object

Als Salesforce-mensen vertalen we eisen bijna meteen naar structuren: klant, account; foto, File; status, keuzelijst. Dat is uiteindelijk nuttig. Op enterpriseniveau wil ik eerst weten met wat voor informatie ik te maken heb. Er zijn veel manieren om haar in te delen (de DAMA body of knowledge is het standaardnaslagwerk), en ik vind zes soorten nuttig: stamgegevens, referentiegegevens, transactiegegevens, metadata, analytische gegevens en ongestructureerde gegevens. De categorieën zijn niet de architectuur. Ze zijn een manier om betere vragen te stellen.

Stamgegevens: de dingen die het bedrijf kent

Stamgegevens beschrijven de duurzame dingen waar een bedrijf om draait: klanten, producten, prijzen, medewerkers, leveranciers, locaties, assets. In een Salesforce-salesorg zijn dat je accounts en contactpersonen, je producten en je prijsboeken. Bij Steve Trucking is een retailpartner (Retail Partner) een stamgegeven. Keystone is geen gebeurtenis; het is een organisatie waarmee Steve Trucking een doorlopende relatie heeft. De negen distributiecentra zijn ook stamgegevens.

Stamgegevens leven langer dan de transacties die ze gebruiken: één retailpartner kan miljoenen leveringen hebben. Dus de eerste vraag erover is altijd wie is eigenaar? Dat is misschien niet Salesforce. Het ERP kan eigenaar zijn van producten. Salesforce kan eigenaar zijn van prospects, terwijl het ERP gezaghebbend wordt zodra ze klant zijn. Een MDM-platform kan eigenaar zijn van de enterprise-identiteit van een klant, samengesteld uit meerdere systemen. Hoofdstuk 6, Stamgegevens en identiteit, gaat er diep op in. Herken voor nu de vorm.

Referentiegegevens: de woordenlijst die het bedrijf deelt

Referentiegegevens zijn de gecontroleerde woordenlijst waarmee andere data ingedeeld wordt: landcodes, valuta’s, productcategorieën, redencodes, statussen. De leveringsstatussen van Steve Trucking (ingepland, geladen, onderweg, bijna daar, geleverd, geïnstalleerd, uitzondering, geretourneerd) zijn referentiegegevens. Het zijn geen leveringen; het zijn de woorden waarmee leveringen beschreven worden.

Ze lijken klein en onschuldig, vaak een keuzelijst met acht waarden. Verwar klein niet met onbelangrijk. Als Salesforce Delivered zegt, het ERP Complete en een retailpartner D stuurt, moet iemand definiëren wat elk betekent en hoe ze op elkaar aansluiten. In referentiegegevens verstoppen zich de aannames van integraties.

Transactiegegevens: wat er gebeurd is

Transactiegegevens leggen activiteit vast: een geplaatste order, een betaling, een voltooide levering, een geopende case. In dezelfde salesorg zijn dat offertes en offerteregels, orders en orderitems, betalingen: elk ervan wijst terug naar een klant en een product. Het miljoen leveringen per jaar van Steve Trucking zijn transactiegegevens, en hun statusupdates ook: ongeveer acht per levering, dus acht miljoen statuswijzigingen per jaar, bij een bedrijf dat 30% per jaar groeit.

Dat is een heel andere groeicurve dan bij stamgegevens. Drie retailpartners bovenaan; miljoenen rijen eronder. Hier doet Steve’s aantal nullen ertoe: je kunt niet naar retailpartner → levering → status kijken en elk vakje hetzelfde gewicht geven. Bij transactiegegevens denk ik meteen aan volume, snelheid, bewaren, historie, archiveren, integratie, en hoe mensen ze echt moeten vinden. Deel 2 besteedt daar veel tijd aan.

Metadata: data over de data

Je hebt de hele cursus al met metadata gewerkt: de definitie van een object, het type van een veld, de omschrijving ervan, de relaties. De hele enterprise heeft het: datawarehouseschema’s, integratiemappings, datacatalogi, API-contracten, en voor elk veld een eigenaar, een gevoeligheidsniveau, een definitie, herkomst en een bewaarregel. De waarden zijn data; de beschrijving van wat ze betekenen is metadata. Zoals hoofdstuk 3 zei: Flag2__c vertelt niemand iets, en dat doet er meer toe nu AI metadata leest om uit te zoeken wat data betekent.

Analytische gegevens: data die we van andere data maakten

“Wat is ons percentage op tijd per retailpartner over de afgelopen vijf jaar?” is geen transactie. Het is een analytische vraag, beantwoord door nieuwe data af te leiden uit miljoenen leveringen: percentage op tijd, schadepercentage, omzet per partner, installatiekwaliteit, trends per ploeg. En het is een andere taak. De planner die vraagt “wat is de volgende stop voor vrachtwagen 217?” hoeft geen vijf jaar historie te doorzoeken. Het management dat vijf jaar prestaties op tijd per regio vergelijkt wel. Daarom staan analytische gegevens meestal in een datawarehouse, een lakehouse of een analyticsplatform dat voor dat werk gebouwd is. Dat Salesforce iets kan opslaan, maakt het operationele platform nog niet de plek om er elke analyse op te draaien.

Ongestructureerde gegevens: wat niet in rijen past

Documenten, pdf’s, afbeeldingen, audio, video, e-mails, transcripties, kennisartikelen. Bij Steve Trucking de leveringsfoto’s: ongeveer vier per levering, meer bij installaties, vier tot vijf miljoen per jaar. Een foto is niet zomaar een veld. Hij is groot, hij kan de binnenkant van iemands huis laten zien, hij heeft eigen bewaarregels, en er wordt anders in gezocht, als er al in gezocht wordt.

Deze soort doet er elk jaar meer toe, omdat AI nu nuttige dingen kan doen met informatie die vroeger buiten het gestructureerde model stond. Een transcriptie is data. Een pdf-handleiding is data. Een installatiefoto is data. Dat betekent niet dat ze in de core van Salesforce hoort. Het betekent dat ze op het landschap hoort.

Click to enlarge

Zes soorten, elk vier vragen. De antwoorden verschillen per soort, en daar gaat het om.

De soort is maar de helft van de vraag: de workload

Weten wat voor soort data we hebben is niet genoeg. Ik wil ook weten wat we ermee doen. Hier doen drie workloads ertoe, en wie ze verwart, maakt slechte architectuur.

Operationeel: het bedrijf draaiende houden. Een planner werkt een levering bij, een ploeg rondt een stop af, een agent opent een case. Veel kleine lees- en schrijfacties: vind dit, werk dat bij, laat me de stops van vandaag zien. Dit is OLTP, online transaction processing, en Salesforce is hier heel goed in; hier leven admins en developers.

Analytisch: het bedrijf begrijpen. Elke levering van vijf jaar, gegroepeerd per partner en distributiecentrum, jaar op jaar vergeleken, gekoppeld aan finance. Nu zijn we aan het doorzoeken en aggregeren. Dit is OLAP, online analytical processing, en daarvoor zijn datawarehouses, lakehouses en analyticsplatforms gebouwd. Simpel gezegd: de org runt het bedrijf; warehouses en lakes analyseren het. Een klassieke fout is die workload op het operationele platform zetten en verrast zijn als de nullen groeien. Als iemand steeds weer enorme hoeveelheden historie wil doorzoeken, behandel het dan niet als “gewoon nog een rapport”. Vraag of het het juiste platform is. Deel 2 komt hierop terug in Ontwerpen voor schaal (coming soon) (maak van de core niet je datawarehouse), en Deel 3 laat zien hoe analytische structuren gebouwd worden in Voorbij relationeel (coming soon).

Streaming: data in beweging. Events, telemetrie, statuswijzigingen, sensormetingen. De vrachtwagens van Steve Trucking sturen ongeveer 200.000 gps-metingen per dag. De planner wil weten waar vrachtwagen 217 nu is. Moet Salesforce elke meting van minuut tot minuut van elke vrachtwagen bewaren? Misschien niet. “Waar is hij nu?” en “wat waren de trends in routeefficiëntie vorig kwartaal?” komen uit dezelfde bron en leiden tot totaal verschillende opslagbeslissingen.

Hoe snel moet het bewegen?

Dan vertraging. In de klas zeg ik het zo: realtime is bij de deur wachten tot iemand terugkomt. Je stuurt hem weg en blijft staan, omdat je niet verder kunt tot hij terug is. Dat is synchroon. Bijna realtime is hem zien vertrekken en ondertussen iets anders doen; als hij kort daarna terugkomt, handel je het af. Dat is asynchroon. En dan is er batch: niemand gaat één voor één de deur uit. De data wacht en beweegt als groep volgens een schema: elk uur, om de paar uur, of dagelijks. Er zijn genoeg situaties waarin batch volstaat, en sommige waarin dat niet zo is. Weten welke welke is, dat is het werk. Die drie zijn niet alleen integratietermen; het zijn architectuurkeuzes.

Neem de gewone ERP-integratie. Om 11.00 uur wordt in het ERP een nieuw product aangemaakt. Moet sales het echt om 12.00 uur kunnen verkopen? Ik heb beide antwoorden gezien. Sommige klanten willen het zo snel mogelijk; anderen zeggen: als we die SKU nog niet naar jullie verscheept hebben, kunnen we niet verwachten dat jullie hem al verkopen. Dus producten zijn meestal dagelijks, soms sneller. Klanten minstens dagelijks; ik heb elk uur gezien, en in extreme gevallen bijna realtime. Orders zijn anders: de uitvoering moet beginnen, dus bijna realtime. De verkoper sluit de deal en gaat verder, en de order komt binnen enkele seconden tot een minuut of twee in het ERP aan. Er is niet één juiste vertraging voor “enterprisegegevens”. Vraag wat het bedrijf echt nodig heeft, en maak niet alles realtime omdat het indrukwekkend klinkt. Realtime heeft een prijs.

De vier vragen achter de categorieën

Je hoeft niet rond te lopen met “dit zijn transactiegegevens!” De indeling is er om vier vragen op te roepen over elke belangrijke dataset:

Wie is eigenaar? Welk systeem is gezaghebbend? Ik splits het op in drie: waar wordt het aangemaakt, waar wordt het bewerkt, en waar wordt ernaar verwezen? Hoofdstuk 6 gaat hier diep op in (Aangemaakt, bewerkt, verwezen, en hoe snel?).
Hoe snel verandert het? Eén keer per jaar, dagelijks, tientallen tot honderden keren per seconde?
Hoe groot wordt het? Tien records, tienduizend, tien miljoen, tien miljard?
Wat is de levenscyclus? Leeft het voor altijd, wordt het gearchiveerd, moet het verwijderd worden, verliest het na verloop van tijd waarde?

Die vier vertellen me veel meer dan “kan Salesforce dit opslaan?” En ze brengen samen wat we al geleerd hebben: eigenaarschap, levenscyclus, het aantal nullen, waar data staat.

Eén bedrijf maakt elke soort

Bij Steve Trucking is de retailpartner een stamgegeven; de woordenlijst van statussen is referentiedata; elke levering is een transactie; de definities van de velden zijn metadata; het scorebord van vijf jaar op tijd is analytisch; de installatiefoto is ongestructureerd; en de gps-feed is streaming. Het is allemaal “data van Steve Trucking”. Niets daarvan betekent dat het in dezelfde database hoort. Dat is de omslag.

Voorbij het examen: wat AI verandert. Om één vraag te beantwoorden heeft een agent misschien een gestructureerd klantrecord nodig, een recente transactie, een pdf-handleiding, een servicetranscriptie en live telemetrie. Ongestructureerde en streaming data worden volwaardige delen van de architectuur, zelfs als ze niet in de CRM-database horen, en de architect moet nog steeds weten wie eigenaar is van elke bron, hoe actueel die is, en of de agent haar moet vertrouwen.

Wat een architect hier beslist

Wat voor soort data elke belangrijke dataset is, en wie er eigenaar van is.
Of de workload operationeel, analytisch, streaming of een mix is.
Hoe snel ze verandert, en hoe snel andere systemen de wijziging echt moeten zien.
Hoe volume en levenscyclus bepalen waar ze staat en hoe lang.
Of Salesforce er eigenaar van moet zijn, een kopie moet bewaren, ernaar moet verwijzen, of haar moet laten op een plek die beter bij de workload past.

Als iemand je een eis geeft, spring dan niet meteen naar welk object, welk veld, welke API. Vraag eerst wat voor soort data het is, wie eigenaar is, hoe snel ze verandert, hoe groot ze wordt, hoe lang ze leeft, en wat we ermee proberen te doen. Een account, een leveringsevent, een aggregaat over vijf jaar en een foto kunnen allemaal belangrijk zijn voor hetzelfde bedrijf zonder hetzelfde architectuurprobleem te zijn.

Verder lezen

DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2e editie (2017): het standaardnaslagwerk voor datacategorieën en databeheer (Engels).
De briefing van Steve Trucking, sectie 4 (volumes).