Typene virksomhetsdata

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)

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. — Bildet er laget med KI

Modul 2 av 6 i kapitlet Forstå virksomhetens data, kapittel 4 i kurset Data Architect. Hver modul står på egne ben. Forrige: Salesforce er ett system blant mange · Neste: Systemene rundt Salesforce

Spørsmålet denne modulen besvarer: Hvilke typer data har en virksomhet, og hvorfor hører de hjemme på forskjellige steder?

En kundepost. En liste over land. En ordre. En feltdefinisjon. Fem år med salgstall. Fire millioner leveringsbilder. Alt er data, men arkitektonisk er de ikke det samme. De endrer seg forskjellig, vokser forskjellig, brukes forskjellig og eies av forskjellige mennesker, og de bør ikke automatisk bo på samme sted. Så når noen sier «vi trenger disse dataene i Salesforce», er mitt neste spørsmål: hva slags data er det? Svaret begynner å fortelle meg hva jeg skal gjøre med dem.

Start med typen, ikke objektet

Som Salesforce-folk oversetter vi krav til strukturer nesten umiddelbart: kunde, konto (Account); bilde, File; status, plukkliste. Det er nyttig etter hvert. På virksomhetsnivå vil jeg først vite hva slags informasjon jeg har med å gjøre. Det finnes mange måter å klassifisere den på (DAMAs kunnskapsgrunnlag, DMBOK, er standardreferansen), og jeg synes seks typer er nyttige: masterdata, referansedata, transaksjonsdata, metadata, analytiske data og ustrukturerte data. Kategoriene er ikke arkitekturen. De er en måte å stille bedre spørsmål på.

Masterdata: tingene virksomheten kjenner

Masterdata beskriver de varige tingene en virksomhet dreier seg om: kunder, produkter, priser, ansatte, leverandører, lokasjoner, eiendeler. I en salgsorg i Salesforce er det kontoene og kontaktene dine, produktene og prislistene dine. Hos Steve Trucking er en detaljhandelspartner (Retail Partner) masterdata. Keystone er ikke en hendelse; det er en organisasjon Steve Trucking har et løpende forhold til. De ni distribusjonssentrene er også masterdata.

Masterdata lever lenger enn transaksjonene som bruker dem: én detaljhandelspartner kan ha millioner av leveringer. Så det første spørsmålet om dem er alltid hvem eier dem? Det er kanskje ikke Salesforce. ERP-et kan eie produktene. Salesforce kan eie potensielle kunder, mens ERP-et blir autoritativt når de er blitt kunder. En MDM-plattform kan eie virksomhetens samlede identitet for en kunde, satt sammen fra flere systemer. Kapittel 6, Masterdata og identitet, går i dybden. Foreløpig er det nok å kjenne igjen formen.

Referansedata: vokabularet virksomheten deler

Referansedata er det kontrollerte vokabularet som brukes til å klassifisere andre data: landkoder, valutaer, produktkategorier, årsakskoder, statuser. Steve Truckings leveringsstatuser (planlagt, lastet, ute for levering, ankommer, levert, installert, avvik, returnert) er referansedata. De er ikke leveringer; de er ordene som brukes til å beskrive leveringer.

Det ser lite og harmløst ut, ofte en plukkliste med åtte verdier. Ikke forveksle lite med uviktig. Hvis Salesforce sier Delivered, ERP-et sier Complete og en detaljhandelspartner sender D, må noen definere hva hver av dem betyr og hvordan de kobles. Referansedata er der integrasjonsantakelsene gjemmer seg.

Transaksjonsdata: hva som skjedde

Transaksjonsdata registrerer aktivitet: en ordre lagt inn, en betaling gjort, en levering fullført, en sak åpnet. I den samme salgsorgen er det tilbud og tilbudslinjer, ordrer og ordrelinjer, betalinger: hver av dem peker tilbake på en kunde og et produkt. Steve Truckings million leveringer i året er transaksjonsdata, og det er statusoppdateringene deres også: rundt åtte per levering, altså åtte millioner statusendringer i året, i en virksomhet som vokser 30 % i året.

Det er en helt annen vekstkurve enn for masterdata. Tre detaljhandelspartnere på toppen; millioner av rader under. Det er her Steves «antall nuller» (Steve’s Number of Zeros) betyr noe: du kan ikke se på detaljhandelspartner → levering → status og gi hver boks samme vekt. Med transaksjonsdata tenker jeg straks på volum, hastighet, oppbevaring, historikk, arkivering, integrasjon og hvordan folk faktisk trenger å finne dem. Del 2 bruker mye tid der.

Metadata: data om dataene

Du har jobbet med metadata gjennom hele kurset: et objekts definisjon, et felts type, beskrivelsen, relasjonene. Hele virksomheten har det: skjemaer i datavarehuset, integrasjonskoblinger, datakataloger, API-kontrakter, og for hvert felt en eier, et sensitivitetsnivå, en definisjon, dataopphav (lineage) og en oppbevaringsregel. Verdiene er data; beskrivelsen av hva de betyr, er metadata. Som kapittel 3 sa: Flag2__c forteller ingen noe som helst, og det betyr mer nå som KI (AI) leser metadata for å finne ut hva data betyr.

Analytiske data: data vi har laget av andre data

«Hva er presisjonsgraden vår per detaljhandelspartner de siste fem årene?» er ikke en transaksjon. Det er et analytisk spørsmål, besvart ved å avlede nye data fra millioner av leveringer: andel i tide, skadeandel, inntekt per partner, installasjonskvalitet, trender for teamene. Og det er en annen jobb. Koordinatoren som spør «hva er neste stopp for lastebil 217?», trenger ikke skanne fem år med historikk. Ledelsen som sammenligner fem år med leveringspresisjon per region, gjør det. Derfor bor analytiske data vanligvis i et datavarehus, et lakehouse eller en analyseplattform bygget for det arbeidet. At Salesforce kan lagre noe, gjør ikke den operative plattformen til stedet der hver analyse av det skal kjøres.

Ustrukturerte data: det som ikke passer i rader

Dokumenter, PDF-er, bilder, lyd, video, e-poster, transkripsjoner, kunnskapsartikler. Hos Steve Trucking: leveringsbildene, rundt fire per levering, flere med installasjoner, fire til fem millioner i året. Et bilde er ikke bare enda et felt. Det er stort, det kan vise innsiden av noens hjem, det har sine egne oppbevaringsregler, og det søkes i på en annen måte, om i det hele tatt.

Denne typen betyr mer for hvert år, fordi KI nå kan gjøre nyttige ting med informasjon som før lå utenfor den strukturerte modellen. En transkripsjon er data. En PDF-manual er data. Et installasjonsbilde er data. Det betyr ikke at det hører hjemme i Salesforce sin core. Det betyr at det hører hjemme på landskapet.

Click to enlarge

Seks typer, fire spørsmål hver. Svarene endrer seg fra type til type, og det er hele poenget.

Typen er bare halve spørsmålet: arbeidsbelastningen

Det er ikke nok å vite hva slags data vi har. Jeg vil også vite hva vi gjør med dem. Tre arbeidsbelastninger betyr noe her, og blander du dem sammen, blir arkitekturen dårlig.

Operativ: drive virksomheten. En koordinator oppdaterer en levering, et team fullfører et stopp, en agent åpner en sak. Mange små lesinger og skrivinger: finn dette, oppdater det, vis meg dagens stopp. Dette er OLTP, online transaksjonsbehandling, og Salesforce er veldig god på det; det er der admins og utviklere bor.

Analytisk: forstå virksomheten. Hver levering i fem år, gruppert per partner og DC, sammenlignet år for år, koblet til økonomi. Nå skanner og aggregerer vi. Dette er OLAP, online analytisk behandling, og det er det datavarehus, lakehouses og analyseplattformer er bygget for. Enkelt sagt: orgen driver virksomheten; datavarehus og datasjøer analyserer den. En klassisk feil er å legge den arbeidsbelastningen på den operative plattformen og bli overrasket når nullene vokser. Hvis noen vil skanne enorme mengder historikk gang på gang, ikke behandle det som «bare enda en rapport». Spør om det er riktig plattform. Del 2 kommer tilbake til dette i Design for skala (coming soon) (ikke gjør core til datavarehuset ditt), og del 3 viser hvordan analytiske strukturer bygges i Utover relasjonsdatabasen (coming soon).

Strømmende: data i bevegelse. Hendelser, telemetri, statusendringer, sensormålinger. Steve Truckings lastebiler sender rundt 200 000 GPS-målinger om dagen. Koordinatoren bryr seg om hvor lastebil 217 er nå. Trenger Salesforce å ta vare på hver måling, minutt for minutt, fra hver lastebil? Kanskje ikke. «Hvor er den nå?» og «hvordan var trendene for ruteeffektivitet forrige kvartal?» kommer fra samme kilde og fører til helt forskjellige lagringsbeslutninger.

Hvor fort må det gå?

Så forsinkelse. I klassen sier jeg det slik: sanntid er å vente i døra på at noen skal komme tilbake. Du sender dem ut og blir stående, fordi du ikke kan fortsette før de er tilbake. Det er synkront. Nesten sanntid er å se dem gå og gjøre noe annet i mellomtiden; når de kommer tilbake litt senere, tar du deg av det. Det er asynkront. Og så har vi batch: ingen går ut døra én om gangen. Dataene venter og flyttes som en gruppe etter en tidsplan: hver time, med noen timers mellomrom eller daglig. Det finnes mange situasjoner der batch er tilstrekkelig, og noen der det ikke er det. Å vite hvilke som er hvilke, er jobben. De tre er ikke bare integrasjonsbegreper; de er arkitektoniske valg.

Ta den vanlige ERP-integrasjonen. Et nytt produkt opprettes i ERP-et kl. 11.00. Trenger salg virkelig å kunne selge det innen kl. 12.00? Jeg har sett begge svarene. Noen kunder vil ha det så fort som mulig; andre sier at hvis vi ikke har sendt det varenummeret ut til dere, kan vi ikke forvente at dere selger det ennå. Så produkter er vanligvis daglig, noen ganger raskere. Kunder minst daglig; jeg har sett hver time, og i ekstreme tilfeller nesten sanntid. Ordrer er annerledes: ordreoppfyllelsen må starte, så nesten sanntid. Selgeren lukker avtalen og går videre, og ordren lander i ERP-et i løpet av sekunder til et par minutter. Det finnes ingen enkelt riktig forsinkelse for «virksomhetsdata». Spør hva virksomheten faktisk trenger, og ikke gjør alt til sanntid fordi det høres imponerende ut. Sanntid har en kostnad.

De fire spørsmålene bak kategoriene

Du trenger ikke gå rundt og kunngjøre «dette er transaksjonsdata!» Klassifiseringen er der for å utløse fire spørsmål om hvert viktig datasett:

Hvem eier det? Hvilket system er autoritativt? Jeg deler det i tre: hvor blir det opprettet, hvor blir det redigert, og hvor blir det referert til? Kapittel 6 går i dybden på disse (Opprettet, redigert, referert, og hvor raskt?).
Hvor fort endrer det seg? Én gang i året, daglig, ti til hundre ganger i sekundet?
Hvor stort blir det? Ti poster, ti tusen, ti millioner, ti milliarder?
Hva er livssyklusen? Lever det for alltid, blir det arkivert, må det slettes, mister det verdi over tid?

De fire forteller meg mye mer enn «kan Salesforce lagre dette?» Og de samler det vi allerede har lært: eierskap, livssyklus, antall nuller, hvor data bor.

Én virksomhet produserer alle typene

Hos Steve Trucking er detaljhandelspartneren masterdata; statusvokabularet er referansedata; hver levering er transaksjonsdata; definisjonene av feltene er metadata; femårsoversikten over leveringspresisjon er analytiske data; installasjonsbildet er ustrukturerte data; og GPS-strømmen er strømmende data. Alt sammen er «Steve Truckings data». Ingenting av det betyr at det hører hjemme i samme database. Det er skiftet.

Utover eksamen: hva KI endrer. For å svare på ett spørsmål kan en agent trenge en strukturert kundepost, en nylig transaksjon, en PDF-manual, en transkripsjon fra kundeservice og levende telemetri. Ustrukturerte og strømmende data blir fullverdige deler av arkitekturen selv når de ikke hører hjemme i CRM-databasen, og arkitekten må fortsatt vite hvem som eier hver kilde, hvor oppdatert den er, og om agenten bør stole på den.

Hva en arkitekt bestemmer her

Hva slags data hvert viktig datasett er, og hvem som eier det.
Om arbeidsbelastningen er operativ, analytisk, strømmende eller en blanding.
Hvor fort det endrer seg, og hvor fort andre systemer virkelig trenger å se endringen.
Hvordan volum og livssyklus former hvor det bor, og hvor lenge.
Om Salesforce skal eie det, holde en kopi, referere til det eller la det bli et sted som passer bedre for arbeidsbelastningen.

Når noen gir deg et krav, ikke hopp rett til hvilket objekt, hvilket felt, hvilket API. Spør først hva slags data det er, hvem som eier dem, hvor fort de endrer seg, hvor store de blir, hvor lenge de lever, og hva vi prøver å gjøre med dem. En konto, en leveringshendelse, et femårsaggregat og et fotografi kan alle bety noe for den samme virksomheten uten å være det samme arkitektoniske problemet.

Les mer

DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. utgave (2017), på engelsk: standardreferansen for datakategorier og datahåndtering.
Briefen for Steve Trucking, del 4 (volumer).