Lytt etter substantivene
Finnes også på 28 språk
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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 1 av 6 i kapitlet Modeller data for mening, kapittel 2 i kurset Data Architect. Hver modul står på egne ben. Forrige: kapitteloversikten · Neste: Tegn relasjonene
Spørsmålet denne modulen besvarer: Hvordan finner jeg begynnelsen på en datamodell i en forretningssamtale?
Noe av det jeg gjør i den første samtalen med en kunde, er å lytte etter substantivene.
Jeg snakker ikke om den første designøkten. Jeg snakker om den innledende samtalen der jeg fortsatt prøver å forstå virksomheten og hva de prøver å oppnå.
De snakker. Jeg lytter.
Og jeg lytter etter ord som:
Detaljhandelspartner. Mottaker. Distribusjonssenter. Manifest. Levering. Rute. Team. Lastebil.
De substantivene fanger oppmerksomheten min med en gang, for et sted i den samtalen ligger begynnelsen på datamodellen min.
Jeg venter ikke til jeg tror jeg forstår problemet helt. Jeg begynner å se dataene mens jeg fortsatt lytter: jeg hører substantivene, jeg begynner å skissere hvordan de henger sammen, og den skissen hjelper meg å ramme inn neste samtale. Noen ganger har jeg allerede tegnet min egen private datamodell når det første møtet med en kunde er over.
For meg starter det med substantivene.
Glem Salesforce et øyeblikk
Section titled “Glem Salesforce et øyeblikk ”Det er her jeg vil at du skal motstå et instinkt som er spesielt sterkt hvis du har vært Salesforce-admin en stund.
Kunden sier kunde, og du tenker:
Konto (Account).
De sier person, og du tenker:
Kontakt (Contact).
De sier distribusjonssenter, og du lurer allerede på om du trenger et egendefinert objekt.
Ikke gjør det ennå.
På dette stadiet bryr jeg meg ikke om en kunde til slutt blir en konto, en personkonto (Person Account), et egendefinert objekt eller noe annet. Først vil jeg forstå virksomheten.
Det er forskjellen på å modellere virksomheten og å konfigurere Salesforce. Hvis jeg starter med Salesforce-objekter, har jeg allerede låst tankegangen min til én implementering. Jeg ender kanskje nøyaktig der jeg forventet, men jeg vil komme dit fordi virksomheten ledet meg dit, ikke fordi konto og kontakt var de to første objektene jeg kjente.
Så glem Salesforce i noen minutter. Lytt til hvordan de som faktisk driver virksomheten, beskriver sin verden.
Sitt, bli, modellér
Section titled “Sitt, bli, modellér ”Før vi lytter til en virksomhet, la oss lytte til noe alle allerede forstår. Når jeg underviser dette live, starter jeg med hunder.
Her er en hund: Marcus eier Bella. Maple Ridge Kennels avlet henne. Hun er en labrador, og hun kan Sitt, Bli og Gi labb.
Lytt etter substantivene: Marcus, Bella, Maple Ridge Kennels, labrador, Sitt. Men det er navn: de konkrete tingene. Det jeg vil ha, er hvilken type ting hvert navn hører til. Bella er en Hund. Marcus er en Eier. Maple Ridge Kennels er en Oppdretter. Labrador er en Rase. Sitt er et Triks. Fem substantiver, fem kandidatbokser.
Så kommer spørsmålet jeg stiller om hvert substantiv: er det en person som gjør en jobb, eller er det en bit data? Marcus er en person. Men å eie Bella er ikke en jobb; det er et faktum om Bella, og før eller siden spør noen: «Hvem eier denne hunden?» Så Eier hører hjemme i modellen. Treneren som lærte Bella å gi labb, er en person som gjør en jobb, og trenger kanskje aldri en boks, med mindre virksomheten begynner å spørre hvem som lærte bort hvilket triks.
Og legg merke til ordet kandidat. Er Rase virkelig en egen boks, eller bare et ord som står skrevet på hunden? Hold fast på det spørsmålet; vi svarer på det når vi normaliserer i modul 4.
Det er hele teknikken, på noe lite. La oss nå lytte til en ekte virksomhet.
Substantiver gir deg kandidatentiteter
Section titled “Substantiver gir deg kandidatentiteter ”La oss lytte til Steve Trucking, det familieeide selskapet vi bruker gjennom hele kurset. Det leverer store varer (kjøleskap, vaskemaskiner, TV-er) fra distribusjonssentrene til store varehuskjeder hjem til folk, og installerer noen av dem.
I den første samtalen hører vi:
- Detaljhandelspartner (Retail Partner)
- Mottaker (Recipient)
- Distribusjonssenter (Distribution Center)
- Manifest
- Levering (Delivery)
- Rute (Route)
- Team (Crew)
- Lastebil (Truck)
Det er allerede nyttig. Jeg kan begynne å sette bokser på en tavle.
Så sett substantivene i rektangler. Det er alt de er på dette stadiet: bokser. Ingen linjer, ingen farger, ingenting som sier Salesforce. Senere i kurset begynner former og farger å bety noe. Foreløpig er et rektangel bare en ting virksomheten snakker om.
Begynn så å orientere dem. Mens du plasserer hver boks, bør du tenke på to ting: hvordan de henger sammen med hverandre, og hva slags data de er. Noe er kundedata: virksomhetene og menneskene vi jobber med. Noe er transaksjonsdata, som ordrer og ordrelinjer: det som skjer, om og om igjen. Og noe er referansedata, som produktene eller tjenestene en virksomhet tilbyr: det arbeidet avhenger av.
Hos Steve Trucking er detaljhandelspartneren og mottakeren kundedata. Manifestet, leveringen og ruten er transaksjoner. Distribusjonssenteret, teamet og lastebilen er det arbeidet avhenger av.
Men det er et viktig ord her: kandidat.
Et substantiv er et hint. Det er ikke automatisk en entitet, og det er absolutt ikke automatisk et Salesforce-objekt.
Når jeg er i en kartleggingsøkt, skriver jeg ned hvert eneste substantiv. For hvert substantiv de sier, stiller jeg meg selv ett spørsmål: er det en person som gjør en jobb, eller er det en bit data? En forretningsutvikler er en person som gjør en jobb. Det er en bruker, en rolle, kanskje et tillatelsessett. Ordrer, fakturaer, linjeelementer: det er biter av data. Begge deler betyr noe, men de havner på helt forskjellige steder i designet, og å sortere dem tidlig sparer meg for å tegne en boks for hver stillingstittel i organisasjonskartet.
Noen av de substantivene kommer til å være mennesker. Hos Steve Trucking er det mottakeren som venter på kjøleskapet, folkene hos detaljhandelspartneren som sender manifestet, og teamet: sjåførene og hjelperne på lastebilen. Dette er roller, og en rolle virker kanskje ikke som data. Men når mennesker handler på data, eller er knyttet til dem, må de selv være representert i dataene. Hvem leverte dette? Hvem kvitterte for det? Hvem sendte manifestet? Så mange roller, noen ganger alle, havner også i modellen.
Lytt til hvordan Steve Trucking snakker, så legger du merke til noe. De sier aldri bare «kunde». Det finnes to typer kunder. Detaljhandelspartneren er den store varehuskjeden Steve Trucking leverer for: den sender manifestet og betaler per levering. Mottakeren er personen kjøleskapet leveres til. Mottakeren kjøpte det i butikken og har kanskje aldri hørt om Steve Trucking.
Hvis jeg hadde skrevet én boks som het Kunde, ville jeg ha blandet sammen to helt forskjellige ting.
Kanskje er distribusjonssenteret viktig nok til å ha sin egen post, historikk, relasjoner og attributter.
Kanskje viser et annet substantiv seg å være ikke noe mer enn et attributt til noe annet.
Det er det vi prøver å finne ut. Vi lager ikke objekter ennå. Vi bygger forståelsen vår av virksomheten.
Lytt nå etter relasjonene
Section titled “Lytt nå etter relasjonene ”Substantivene gir meg et sted å starte. Så lytter jeg til hvordan virksomheten kobler dem sammen.
En detaljhandelspartner driver distribusjonssentre.
En detaljhandelspartner sender et manifest for hvert DC og hver leveringsdag.
Et manifest lister opp leveringer.
En levering går til en mottaker.
En rute er en dags kjøring med rundt ti stopp (Stops).
Et team på to kjører en lastebil.
Nå skjer det noe. Jeg ser ikke lenger på en liste med substantiver. Jeg begynner å se en modell.
Det er også her spørsmålene begynner å dukke opp.
Kan en detaljhandelspartner ha mer enn ett distribusjonssenter?
Er en levering det samme som et stopp?
Kan ett stopp levere til to mottakere?
Er et team alltid de samme to personene?
Bryr vi oss om hvilket team som hadde hvilken lastebil forrige måned, eller bare om hvilken lastebil de kjører i dag?
Legg merke til hva vi gjør. Vi stiller ikke Salesforce-spørsmål ennå. Vi stiller forretningsspørsmål. Og de svarene kommer til slutt til å styre designet i Salesforce.
Den første modellen din trenger ikke å være perfekt
Section titled “Den første modellen din trenger ikke å være perfekt ”Jeg forventer ikke at de første boksene jeg tegner, overlever uendret. Faktisk ville jeg blitt mistenksom om de gjorde det.
Poenget med den første modellen er ikke å ha rett. Poenget er å gi oss noe konkret nok til å oppdage hvor vi tar feil.
Sett levering, rute, team og lastebil på tavlen, så kan folk reagere på dem.
«Faktisk er en levering ikke alltid én vare. Det kan være en vaskemaskin, en tørketrommel og bortkjøring av de gamle.»
Bra. Fortell meg mer.
«Vi tildeler ikke et team til en levering. Vi tildeler teamet til en rute.»
Flott. Hva ligger på ruten?
«Og hvis det er en installasjon, kan ikke teamet lukke stoppet før sjekklisten og bildene er ferdige.»
Nå lærer vi noe viktig.
Et diagram har gjort en vag samtale om til noe vi kan utfordre. Det er en av grunnene til at jeg liker å modellere tidlig. Jeg prøver ikke å imponere rommet med et vakkert diagram. Jeg prøver å lære raskere.
Modellen er en del av samtalen.
Dette er den konseptuelle modellen din
Section titled “Dette er den konseptuelle modellen din ”Det vi har begynt å bygge, har et formelt navn: en konseptuell datamodell.
På dette nivået er jeg interessert i de viktige tingene virksomheten bryr seg om, og hvordan de henger sammen. Jeg bekymrer meg ennå ikke for standardobjekter kontra egendefinerte objekter, API-navn på felt, lookup kontra master-detail, obligatoriske felt, indekser, automatisering, Apex eller Flows. Det betyr noe, og vi kommer dit. Men hvis vi bestemmer det før vi forstår hva vi modellerer, løser vi feil problem først.
Den konseptuelle modellen bør gi mening for dem i rommet som ikke kan Salesforce. Det er en nyttig test. Hvis jeg må forklare hva Delivery__c betyr før driftslederen kan lese diagrammet mitt, har jeg gått over i implementeringen for tidlig.
Jeg vil at de skal se på modellen og si:
«Ja, det er slik virksomheten vår fungerer.»
Eller, enda bedre:
«Nei, det er ikke slik det fungerer.»
For da har jeg noe å rette opp.
Den samme teknikken virker når ingen snakker
Section titled “Den samme teknikken virker når ingen snakker ”Dette er ikke bare noe jeg bruker i kartlegging med kunder. Det virker også når «kunden» er et dokument.
Når jeg jobber meg gjennom et kravdokument, gjør jeg omtrent det samme. Hva er de viktige forretningsbegrepene? Hvilke relasjoner beskrives? Hva dukker opp gang på gang? Hva har sin egen livssyklus, må kunne identifiseres for seg selv eller trenger historikk? Hva blir opprettet, endret, tildelt, overført, planlagt eller pensjonert?
Det er de samme tingene jeg lytter etter i det første møtet. På papiret gjør de hintene avsnitt med krav om til en modell jeg kan resonnere rundt, og til bedre spørsmål til neste samtale.
En modell er ikke bare noe du lager etter at du har løst problemet. Den er et av verktøyene du bruker for å løse problemet.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”Når denne første runden er over, prøver jeg å bestemme:
- Hvilke substantiver som representerer meningsfulle kandidatentiteter.
- Hvilke ulike ord som representerer det samme forretningsbegrepet, og hvilket enkeltord som skjuler to (som «kunde»).
- Hvilke begreper som trenger en egen post og en egen livssyklus.
- Hvordan de viktigste begrepene henger sammen med hverandre.
- Hvilke spørsmål virksomheten må svare på før jeg kan modellere dem med trygghet.
Jeg bestemmer ikke implementeringen i Salesforce ennå. Først må vi forstå virksomheten godt nok til å tegne den. Og når vi har substantivene på tavlen, er det neste jeg vil forstå, linjene mellom dem.
Utover eksamen: hva KI endrer. Gi et KI-verktøy et kravdokument, så finner det substantivene, foreslår entiteter og skisserer relasjoner på sekunder. Bruk det til å sette fart på kartleggingen, men ikke sett bort forståelsen: det kan ikke vite at «kunde» betyr to forskjellige ting hos Steve Trucking med mindre virksomheten forteller deg det. Legg den første modellen frem for dem som driver virksomheten, og spør: «Er det virkelig slik virksomheten deres fungerer?»