Lyt efter navneordene
Findes også på 28 sprog
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 af 6 i kapitlet Modellér data for betydning, kapitel 2 i kurset Data Architect. Hvert modul står på egne ben. Forrige: kapiteloversigten · Næste: Tegn relationerne
Spørgsmålet, dette modul besvarer: Hvordan finder jeg begyndelsen på en datamodel i en forretningssamtale?
Noget af det, jeg gør i det første opkald med en kunde, er at lytte efter navneordene.
Jeg taler ikke om den første designworkshop. Jeg taler om den indledende samtale, hvor jeg stadig prøver at forstå forretningen, og hvad de prøver at opnå.
De taler. Jeg lytter.
Og jeg lytter efter ord som:
Detailpartner. Modtager. Distributionscenter. Manifest. Levering. Rute. Team. Lastbil.
De navneord fanger straks min opmærksomhed, for et sted i den samtale ligger begyndelsen på min datamodel.
Jeg venter ikke, til jeg tror, jeg forstår problemet fuldstændigt. Jeg begynder at se dataene, mens jeg stadig lytter: jeg hører navneordene, jeg begynder at skitsere, hvordan de hænger sammen, og den skitse hjælper mig med at ramme den næste samtale ind. Nogle gange har jeg allerede min egen private datamodel tegnet op ved slutningen af det første møde med en kunde.
For mig starter det med navneordene.
Glem Salesforce et øjeblik
Sektion kaldt “Glem Salesforce et øjeblik ”Det er her, jeg vil have dig til at modstå et instinkt, der er særligt stærkt, hvis du har været Salesforce-admin i et stykke tid.
Kunden siger kunde, og du tænker:
Konto (Account).
De siger person, og du tænker:
Kontakt (Contact).
De siger distributionscenter, og du overvejer allerede, om du skal have et brugerdefineret objekt.
Gør det ikke endnu.
På dette tidspunkt er jeg ligeglad med, om en kunde i sidste ende bliver en konto, en personkonto (Person Account), et brugerdefineret objekt eller noget helt andet. Først vil jeg forstå forretningen.
Det er forskellen på at modellere forretningen og at konfigurere Salesforce. Hvis jeg starter med Salesforce-objekter, har jeg allerede låst min tænkning fast på én implementering. Jeg ender måske præcis der, hvor jeg forventede, men jeg vil nå dertil, fordi forretningen førte mig dertil, ikke fordi konto og kontakt var de to første objekter, jeg kendte.
Så glem Salesforce i et par minutter. Lyt til, hvordan de mennesker, der faktisk driver forretningen, beskriver deres verden.
Sit, bliv, modellér
Sektion kaldt “Sit, bliv, modellér ”Før vi lytter til en virksomhed, så lad os lytte til noget, alle allerede forstår. Når jeg underviser i det her live, starter jeg med hunde.
Her er en hund: Marcus ejer Bella. Maple Ridge Kennels har opdrættet hende. Hun er en labrador, og hun kan Sit, Bliv og Giv pote.
Lyt efter navneordene: Marcus, Bella, Maple Ridge Kennels, labrador, Sit. Det er dog navne: de konkrete ting. Det, jeg vil have, er den slags ting, hvert navn hører til. Bella er en Hund. Marcus er en Ejer. Maple Ridge Kennels er en Opdrætter. Labrador er en Race. Sit er et Trick. Fem navneord, fem kandidatkasser.
Så kommer det spørgsmål, jeg stiller til hvert navneord: er det en person, der udfører et job, eller er det et stykke data? Marcus er en person. Men at eje Bella er ikke et job; det er en kendsgerning om Bella, og før eller siden spørger nogen: »Hvem ejer den her hund?« Så Ejer hører hjemme i modellen. Træneren, der lærte Bella at give pote, er en person, der udfører et job, og har måske aldrig brug for en kasse, medmindre forretningen begynder at spørge, hvem der lærte hvilken hund hvilket trick.
Og læg mærke til ordet kandidat. Er Race virkelig en kasse for sig, eller bare et ord, der står på hunden? Hold fast i det spørgsmål; vi besvarer det, når vi normaliserer i modul 4.
Det er hele teknikken, på noget lille. Lad os nu lytte til en rigtig virksomhed.
Navneord giver dig kandidater til entiteter
Sektion kaldt “Navneord giver dig kandidater til entiteter ”Lad os lytte til Steve Trucking, det familieejede firma, vi bruger gennem hele kurset. Det leverer store varer (køleskabe, vaskemaskiner, fjernsyn) fra store detailkæders distributionscentre hjem til folk og installerer nogle af dem.
I den første samtale hører vi:
- Detailpartner (Retail Partner)
- Modtager (Recipient)
- Distributionscenter (Distribution Center)
- Manifest (Manifest)
- Levering (Delivery)
- Rute (Route)
- Team (Crew)
- Lastbil (Truck)
Det er allerede nyttigt. Jeg kan begynde at sætte kasser op på en tavle.
Så sæt navneordene i rektangler. Det er alt, de er på dette tidspunkt: kasser. Ingen streger, ingen farver, intet, der siger Salesforce. Senere i kurset begynder former og farver at betyde noget. Indtil videre er et rektangel bare en ting, forretningen taler om.
Begynd så at placere dem. Når du placerer hver kasse, skal du tænke på to ting: hvordan de hænger sammen med hinanden, og hvilken slags data de er. Noget af det er kundedata: de virksomheder og mennesker, vi arbejder med. Noget er transaktionsdata, som ordrer og ordrelinjer: de ting, der sker, igen og igen. Og noget er referencedata, som de produkter eller ydelser, en virksomhed tilbyder: de ting, arbejdet afhænger af.
Hos Steve Trucking er detailpartneren og modtageren kundedata. Manifestet, leveringen og ruten er transaktioner. Distributionscentret, teamet og lastbilen er det, arbejdet afhænger af.
Men der er et vigtigt ord her: kandidat.
Et navneord er et spor. Det er ikke automatisk en entitet, og det er bestemt ikke automatisk et Salesforce-objekt.
Når jeg er i en discovery-session, skriver jeg hvert eneste navneord ned. For hvert navneord, de siger, stiller jeg mig selv ét spørgsmål: er det en person, der udfører et job, eller er det et stykke data? En business development manager er en person, der udfører et job. Det er en bruger, en rolle, måske et tilladelsessæt. Ordrer, fakturaer, linjeposter: det er stykker data. Begge dele betyder noget, men de ender meget forskellige steder i designet, og når jeg sorterer dem tidligt, slipper jeg for at tegne en kasse for hver jobtitel i organisationsdiagrammet.
Nogle af de navneord vil være mennesker. Hos Steve Trucking er det modtageren, der venter på køleskabet, folkene hos detailpartneren, der sender manifestet, og teamet: chaufførerne og medhjælperne på lastbilen. Det er roller, og en rolle virker måske ikke som data. Men når mennesker handler på data eller er relateret til dem, skal de selv være repræsenteret i dataene. Hvem leverede det her? Hvem kvitterede for det? Hvem sendte manifestet? Så mange roller, nogle gange dem alle, ender også i modellen.
Lyt til, hvordan Steve Trucking taler, og du vil lægge mærke til noget. De siger aldrig bare »kunde«. Der er to slags kunder. Detailpartneren er den store detailkæde, som Steve Trucking leverer for: den sender manifestet og betaler pr. levering. Modtageren er den person, køleskabet leveres til. Modtageren købte det i butikken og har måske aldrig hørt om Steve Trucking.
Hvis jeg havde tegnet én kasse, der hed Kunde, havde jeg blandet to helt forskellige ting sammen.
Måske er distributionscentret vigtigt nok til at have sin egen post, historik, relationer og attributter.
Måske viser et andet navneord sig ikke at være andet end en attribut på noget andet.
Det er det, vi prøver at finde ud af. Vi opretter ikke objekter endnu. Vi bygger vores forståelse af forretningen.
Lyt nu efter relationerne
Sektion kaldt “Lyt nu efter relationerne ”Navneordene giver mig et sted at starte. Så lytter jeg til, hvordan forretningen forbinder dem.
En detailpartner driver distributionscentre.
En detailpartner sender et manifest for hvert DC og hver leveringsdag.
Et manifest oplister leveringer.
En levering går til en modtager.
En rute er en dags tur med cirka ti stop.
Et team på to kører en lastbil.
Nu sker der noget. Jeg kigger ikke længere på en liste med navneord. Jeg begynder at se en model.
Det er også her, spørgsmålene begynder at dukke op.
Kan en detailpartner have mere end ét distributionscenter?
Er en levering det samme som et stop?
Kan ét stop levere til to modtagere?
Er et team altid de samme to personer?
Går vi op i, hvilket team der havde hvilken lastbil i sidste måned, eller kun i, hvilken lastbil de kører i dag?
Læg mærke til, hvad vi gør. Vi stiller ikke Salesforce-spørgsmål endnu. Vi stiller forretningsspørgsmål. Og de svar vil i sidste ende styre designet i Salesforce.
Din første model behøver ikke være perfekt
Sektion kaldt “Din første model behøver ikke være perfekt ”Jeg forventer ikke, at de første kasser, jeg tegner, overlever uændret. Faktisk ville jeg blive mistænksom, hvis de gjorde.
Pointen med den første model er ikke at have ret. Pointen er at give os noget konkret nok til at opdage, hvor vi tager fejl.
Sæt levering, rute, team og lastbil op på tavlen, og folk kan reagere på dem.
»Faktisk er en levering ikke altid én vare. Det kan være en vaskemaskine, en tørretumbler og bortkørsel af de gamle.«
Godt. Fortæl mig mere.
»Vi tildeler ikke et team til en levering. Vi tildeler teamet til en rute.«
Fint. Hvad er der på ruten?
»Og hvis der er en installation, kan teamet ikke lukke stoppet, før tjeklisten og billederne er klaret.«
Nu lærer vi noget vigtigt.
Et diagram har forvandlet en vag samtale til noget, vi kan udfordre. Det er en af grundene til, at jeg godt kan lide at modellere tidligt. Jeg prøver ikke at imponere rummet med et smukt diagram. Jeg prøver at lære hurtigere.
Modellen er en del af samtalen.
Det her er din konceptuelle model
Sektion kaldt “Det her er din konceptuelle model ”Der er et formelt navn for det, vi er begyndt at bygge: en konceptuel datamodel.
På dette niveau er jeg interesseret i de vigtige ting, forretningen går op i, og hvordan de hænger sammen. Jeg bekymrer mig endnu ikke om standardobjekter over for brugerdefinerede objekter, API-navne på felter, lookup over for master-detail, påkrævede felter, indekser, automatisering, Apex eller Flows. De ting betyder noget, og vi kommer dertil. Men hvis vi beslutter dem, før vi forstår, hvad vi modellerer, løser vi det forkerte problem først.
Den konceptuelle model skal give mening for de mennesker i rummet, der ikke kender Salesforce. Det er en nyttig test. Hvis jeg skal forklare, hvad Delivery__c betyder, før driftschefen kan læse mit diagram, er jeg gået over i implementeringen for tidligt.
Jeg vil have, at de kigger på modellen og siger:
»Ja, sådan fungerer vores forretning.«
Eller, endnu bedre:
»Nej, sådan fungerer det ikke.«
For nu har jeg noget at rette.
Den samme teknik virker, når ingen taler
Sektion kaldt “Den samme teknik virker, når ingen taler ”Det er ikke kun noget, jeg bruger i discovery hos kunder. Det virker også, når »kunden« er et dokument.
Når jeg arbejder mig igennem et kravdokument, gør jeg stort set det samme. Hvad er de vigtige forretningsbegreber? Hvilke relationer bliver beskrevet? Hvad går igen? Hvad har sin egen livscyklus, skal kunne identificeres for sig eller har brug for historik? Hvad bliver oprettet, ændret, tildelt, overført, planlagt eller pensioneret?
Det er de samme ting, jeg lytter efter på det første møde. På papiret forvandler de spor afsnit med krav til en model, jeg kan ræsonnere om, og til bedre spørgsmål til den næste samtale.
En model er ikke bare noget, du laver, efter du har løst problemet. Den er et af de værktøjer, du bruger til at løse problemet.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”Ved slutningen af denne første gennemgang prøver jeg at beslutte:
- Hvilke navneord der repræsenterer meningsfulde kandidater til entiteter.
- Hvilke forskellige ord der repræsenterer det samme forretningsbegreb, og hvilket ét ord der skjuler to (som »kunde«).
- Hvilke begreber der har brug for deres egen post og livscyklus.
- Hvordan de vigtigste begreber hænger sammen med hinanden.
- Hvilke spørgsmål forretningen skal besvare, før jeg trygt kan modellere dem.
Jeg beslutter ikke implementeringen i Salesforce endnu. Først skal vi forstå forretningen godt nok til at tegne den. Og når vi har navneordene oppe på tavlen, er det næste, jeg vil forstå, stregerne mellem dem.
Ud over eksamen: hvad AI ændrer. Giv et AI-værktøj et kravdokument, og det finder navneordene, foreslår entiteter og skitserer relationer på få sekunder. Brug det til at sætte fart på discovery, men overlad ikke forståelsen til det: det kan ikke vide, at »kunde« betyder to forskellige ting hos Steve Trucking, medmindre forretningen fortæller dig det. Læg dets første model frem for de mennesker, der driver forretningen, og spørg: »Er det virkelig sådan, jeres forretning fungerer?«