Luister naar de zelfstandige naamwoorden
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)
Module 1 van 6 in het hoofdstuk Data modelleren naar betekenis, hoofdstuk 2 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: het hoofdstukoverzicht · Volgende: Teken de relaties
De vraag die deze module beantwoordt: Hoe vind ik het begin van een datamodel in een gesprek over de business?
Een van de dingen die ik in een eerste gesprek met een klant doe, is luisteren naar de zelfstandige naamwoorden.
Ik heb het niet over de eerste ontwerpsessie. Ik heb het over dat eerste gesprek waarin ik nog probeer de business te begrijpen en wat ze proberen te bereiken.
Zij praten. Ik luister.
En ik luister naar woorden als:
Retailpartner. Ontvanger. Distributiecentrum. Vrachtlijst. Levering. Route. Bezorgploeg. Vrachtwagen.
Die zelfstandige naamwoorden trekken meteen mijn aandacht, want ergens in dat gesprek zit het begin van mijn datamodel.
Ik wacht niet tot ik denk dat ik het probleem helemaal begrijp. Ik begin de data al te zien terwijl ik nog luister: ik hoor de zelfstandige naamwoorden, ik begin te schetsen hoe ze samenhangen, en die schets helpt me het volgende gesprek vorm te geven. Soms heb ik aan het eind van een eerste afspraak met een klant al mijn eigen, privé-datamodel getekend.
Voor mij begint dat bij de zelfstandige naamwoorden.
Vergeet Salesforce even
Section titled “Vergeet Salesforce even ”Hier wil ik dat je een instinct weerstaat dat extra sterk is als je al een tijd Salesforce-admin bent.
De klant zegt klant, en jij denkt:
Account.
Ze zeggen persoon, en jij denkt:
Contactpersoon.
Ze zeggen distributiecentrum, en jij vraagt je al af of je een aangepast object nodig hebt.
Doe dat nog niet.
Op dit moment kan het me niet schelen of een klant uiteindelijk een account wordt, een persoonsaccount, een aangepast object of iets anders. Eerst wil ik de business begrijpen.
Dat is het verschil tussen de business modelleren en Salesforce configureren. Als ik begin met Salesforce-objecten, heb ik mijn denken al beperkt tot één implementatie. Misschien kom ik precies uit waar ik verwachtte, maar ik wil daar komen omdat de business me erheen leidde, niet omdat account en contactpersoon de eerste twee objecten waren die ik kende.
Vergeet Salesforce dus een paar minuten. Luister hoe de mensen die het bedrijf echt runnen hun wereld beschrijven.
Zit, Blijf, Modelleer
Section titled “Zit, Blijf, Modelleer ”Voordat we naar een bedrijf luisteren, luisteren we naar iets wat iedereen al begrijpt. Als ik dit live doceer, begin ik met honden.
Hier is een hond: Marcus is de eigenaar van Bella. Kennel Maple Ridge heeft haar gefokt. Ze is een labrador, en ze kent Zit, Blijf en Poot.
Luister naar de zelfstandige naamwoorden: Marcus, Bella, Kennel Maple Ridge, labrador, Zit. Dat zijn echter namen: de specifieke dingen. Wat ik wil, is het soort ding waar elke naam bij hoort. Bella is een Hond. Marcus is een Eigenaar. Kennel Maple Ridge is een Fokker. Labrador is een Ras. Zit is een Kunstje. Vijf zelfstandige naamwoorden, vijf kandidaat-vakjes.
Dan de vraag die ik bij elk zelfstandig naamwoord stel: is het een persoon die een taak uitvoert, of een stuk data? Marcus is een persoon. Maar eigenaar zijn van Bella is geen taak; het is een feit over Bella, en vroeg of laat vraagt iemand: “Van wie is deze hond?” Dus de Eigenaar hoort in het model. De trainer die Bella poot geven leerde, is een persoon die een taak uitvoert, en heeft misschien nooit een vakje nodig, tenzij het bedrijf gaat vragen wie welk kunstje leerde.
En let op het woord kandidaat. Is Ras echt een eigen vakje, of gewoon een woord dat op de hond geschreven staat? Houd die vraag vast; we beantwoorden haar als we normaliseren in module 4.
Dat is de hele techniek, op iets kleins. Laten we nu naar een echt bedrijf luisteren.
Zelfstandige naamwoorden geven je kandidaat-entiteiten
Section titled “Zelfstandige naamwoorden geven je kandidaat-entiteiten ”Laten we luisteren naar Steve Trucking, het familiebedrijf dat we in deze hele cursus gebruiken. Het bezorgt grote spullen (koelkasten, wasmachines, tv’s) vanuit de distributiecentra van grote winkelketens bij mensen thuis, en installeert een deel ervan.
In het eerste gesprek horen we:
- Retailpartner
- Ontvanger
- Distributiecentrum
- Vrachtlijst
- Levering
- Route
- Bezorgploeg
- Vrachtwagen
Dat is al nuttig. Ik kan blokken op een whiteboard gaan zetten.
Zet de zelfstandige naamwoorden dus in rechthoeken. Meer zijn ze op dit moment niet: blokken. Geen lijnen, geen kleuren, niets wat naar Salesforce verwijst. Later in de cursus gaan vormen en kleuren iets betekenen. Voor nu is een rechthoek gewoon iets waar de business over praat.
Ga ze dan ordenen. Terwijl je elk blok plaatst, wil je aan twee dingen denken: hoe ze met elkaar samenhangen, en wat voor soort data het zijn. Een deel is klantdata: de bedrijven en mensen waarmee we werken. Een deel is transactiedata, zoals orders en orderregels: de dingen die steeds weer gebeuren. En een deel is referentiedata, zoals de producten of diensten die een bedrijf aanbiedt: de dingen waar het werk van afhangt.
Bij Steve Trucking zijn de retailpartner en de ontvanger klantdata. De vrachtlijst, de levering en de route zijn transacties. Het distributiecentrum, de bezorgploeg en de vrachtwagen zijn waar het werk van afhangt.
Maar er staat hier een belangrijk woord: kandidaat.
Een zelfstandig naamwoord is een aanwijzing. Het is niet automatisch een entiteit, en zeker niet automatisch een Salesforce-object.
In een discoverysessie schrijf ik elk zelfstandig naamwoord op. Bij elk zelfstandig naamwoord dat ze zeggen, stel ik mezelf één vraag: is dat een persoon die een taak uitvoert, of is dat een stuk data? Een business development manager is een persoon die een taak uitvoert. Dat is een gebruiker, een rol, misschien een machtigingenset. Orders, facturen, orderregels: dat zijn stukken data. Beide doen ertoe, maar ze komen op heel verschillende plekken in het ontwerp terecht, en ze vroeg sorteren voorkomt dat ik een blok teken voor elke functietitel in het organigram.
Een deel van die zelfstandige naamwoorden zijn mensen. Bij Steve Trucking zijn dat de ontvanger die op de koelkast wacht, de mensen bij de retailpartner die de vrachtlijst sturen, en de bezorgploeg: de chauffeurs en helpers op de vrachtwagen. Dat zijn rollen, en een rol lijkt misschien geen data. Maar als mensen iets met data doen, of eraan gerelateerd zijn, moeten ze zelf in de data vertegenwoordigd zijn. Wie heeft dit bezorgd? Wie heeft ervoor getekend? Wie heeft de vrachtlijst gestuurd? Dus veel rollen, soms allemaal, komen ook in het model terecht.
Luister hoe Steve Trucking praat, en je merkt iets op. Ze zeggen nooit gewoon “klant”. Er zijn twee soorten klant. De retailpartner is de grote winkelketen voor wie Steve Trucking bezorgt: die stuurt de vrachtlijst en betaalt per levering. De ontvanger is de persoon bij wie de koelkast wordt afgeleverd. De ontvanger kocht hem in de winkel en heeft misschien nog nooit van Steve Trucking gehoord.
Als ik één blok Klant had getekend, had ik twee totaal verschillende dingen door elkaar gehaald.
Misschien is Distributiecentrum belangrijk genoeg voor een eigen record, historie, relaties en attributen.
Misschien blijkt een ander zelfstandig naamwoord niets meer te zijn dan een attribuut van iets anders.
Dat proberen we te ontdekken. We maken nog geen objecten. We bouwen ons begrip van de business op.
Luister nu naar de relaties
Section titled “Luister nu naar de relaties ”De zelfstandige naamwoorden geven me een beginpunt. Dan luister ik hoe de business ze met elkaar verbindt.
Een retailpartner heeft distributiecentra.
Een retailpartner stuurt een vrachtlijst per DC en bezorgdag.
Een vrachtlijst bevat leveringen.
Een levering gaat naar een ontvanger.
Een route is de rit van een dag met ongeveer tien stops.
Een bezorgploeg van twee rijdt op een vrachtwagen.
Nu gebeurt er iets. Ik kijk niet meer naar een lijst zelfstandige naamwoorden. Ik begin een model te zien.
Hier beginnen ook de vragen op te duiken.
Kan een retailpartner meer dan één distributiecentrum hebben?
Is een levering hetzelfde als een stop?
Kan één stop bij twee ontvangers afleveren?
Bestaat een bezorgploeg altijd uit dezelfde twee mensen?
Maakt het ons uit welke ploeg vorige maand welke vrachtwagen had, of alleen op welke vrachtwagen ze vandaag rijden?
Kijk wat we aan het doen zijn. We stellen nog geen Salesforce-vragen. We stellen bedrijfsvragen. En die antwoorden gaan uiteindelijk het Salesforce-ontwerp sturen.
Je eerste model hoeft niet perfect te zijn
Section titled “Je eerste model hoeft niet perfect te zijn ”Ik verwacht niet dat de eerste blokken die ik teken ongewijzigd overleven. Sterker nog, ik zou achterdochtig worden als dat wel zo was.
Het doel van het eerste model is niet gelijk hebben. Het doel is iets concreets genoeg hebben om te ontdekken waar we het mis hebben.
Zet Levering, Route, Bezorgploeg en Vrachtwagen op het bord en mensen kunnen erop reageren.
“Eigenlijk is een levering niet altijd één artikel. Het kan een wasmachine zijn, een droger en het afvoeren van de oude.”
Mooi. Vertel meer.
“We wijzen geen ploeg toe aan een levering. We wijzen de ploeg toe aan een route.”
Geweldig. Wat staat er op de route?
“En als er een installatie is, kan de ploeg de stop pas afsluiten als de checklist en de foto’s klaar zijn.”
Nu leren we iets belangrijks.
Een diagram heeft een vaag gesprek veranderd in iets wat we kunnen uitdagen. Dat is een van de redenen waarom ik graag vroeg modelleer. Ik probeer de zaal niet te imponeren met een prachtig diagram. Ik probeer sneller te leren.
Het model is onderdeel van het gesprek.
Dit is je conceptuele model
Section titled “Dit is je conceptuele model ”Er is een formele naam voor wat we zijn gaan bouwen: een conceptueel datamodel.
Op dit niveau interesseren me de belangrijke dingen waar de business om geeft en hoe ze samenhangen. Ik maak me nog geen zorgen over standaard- versus aangepaste objecten, API-namen van velden, lookup versus master-detail, verplichte velden, indexen, automatisering, Apex of Flows. Die dingen doen ertoe, en daar komen we nog. Maar als we ze beslissen voordat we begrijpen wat we modelleren, lossen we eerst het verkeerde probleem op.
Het conceptuele model moet logisch zijn voor de mensen in de zaal die Salesforce niet kennen. Dat is een nuttige test. Als ik moet uitleggen wat Delivery__c betekent voordat de operationeel manager mijn diagram kan lezen, ben ik te vroeg de implementatie in gegaan.
Ik wil dat ze naar het model kijken en zeggen:
“Ja, zo werkt ons bedrijf.”
Of, nog beter:
“Nee, zo werkt het niet.”
Want nu heb ik iets om te verbeteren.
Dezelfde techniek werkt als niemand praat
Section titled “Dezelfde techniek werkt als niemand praat ”Dit gebruik ik niet alleen bij discovery met klanten. Het werkt ook als de “klant” een document is.
Als ik een eisendocument doorwerk, doe ik grotendeels hetzelfde. Wat zijn de belangrijke bedrijfsconcepten? Welke relaties worden beschreven? Wat komt steeds terug? Wat heeft een eigen levenscyclus, moet op zichzelf identificeerbaar zijn of heeft historie nodig? Wat wordt aangemaakt, gewijzigd, toegewezen, overgedragen, ingepland of buiten gebruik gesteld?
Dat zijn dezelfde dingen waar ik in die eerste afspraak naar luister. Op papier veranderen die aanwijzingen alinea’s met eisen in een model waarover ik kan redeneren, en in betere vragen voor het volgende gesprek.
Een model is niet alleen iets wat je maakt nadat je het probleem hebt opgelost. Het is een van de gereedschappen waarmee je het probleem oplost.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”Aan het eind van deze eerste ronde probeer ik te beslissen:
- Welke zelfstandige naamwoorden zinvolle kandidaat-entiteiten zijn.
- Welke verschillende woorden voor hetzelfde bedrijfsconcept staan, en welk ene woord er twee verbergt (zoals “klant”).
- Welke concepten een eigen record en levenscyclus nodig hebben.
- Hoe de belangrijkste concepten met elkaar samenhangen.
- Welke vragen de business moet beantwoorden voordat ik ze met vertrouwen kan modelleren.
Ik beslis de Salesforce-implementatie nog niet. Eerst moeten we de business goed genoeg begrijpen om haar te tekenen. En zodra de zelfstandige naamwoorden op het bord staan, wil ik als volgende de lijnen ertussen begrijpen.
Voorbij het examen: wat AI verandert. Geef een AI-tool een eisendocument en het vindt binnen seconden de zelfstandige naamwoorden, stelt entiteiten voor en schetst relaties. Gebruik het om discovery te versnellen, maar besteed het begrijpen niet uit: het kan niet weten dat “klant” bij Steve Trucking twee verschillende dingen betekent, tenzij de business het je vertelt. Leg het eerste model voor aan de mensen die het bedrijf runnen en vraag: “Werkt jullie bedrijf echt zo?”