Typerne af virksomhedsdata

🌐 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)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 2 af 6 i kapitlet Forstå virksomhedens data, kapitel 4 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Salesforce er ét system blandt mange · Næste: Systemerne omkring Salesforce

Spørgsmålet, dette modul besvarer: Hvilke typer data har en virksomhed, og hvorfor hører de hjemme forskellige steder?

En kundepost. En liste over lande. En ordre. En feltdefinition. Fem års salgstotaler. Fire millioner leveringsfotos. Det er alt sammen data, men arkitektonisk er det ikke det samme. De ændrer sig forskelligt, vokser forskelligt, bruges forskelligt og ejes af forskellige mennesker, og de skal ikke automatisk bo samme sted. Så når nogen siger »vi skal have disse data i Salesforce«, er mit næste spørgsmål: hvilken type data er det? Svaret begynder at fortælle mig, hvad jeg skal gøre med dem.

Start med typen, ikke objektet

Som Salesforce-folk oversætter vi krav til strukturer næsten med det samme: kunde, konto; foto, File; status, valgliste. Det er nyttigt på et tidspunkt. På virksomhedsniveau vil jeg først vide, hvilken type information jeg har med at gøre. Der er mange måder at klassificere den på (DAMA’s body of knowledge er standardreferencen), og jeg finder seks typer nyttige: masterdata, referencedata, transaktionsdata, metadata, analytiske data og ustrukturerede data. Kategorierne er ikke arkitekturen. De er en måde at stille bedre spørgsmål på.

Masterdata: de ting, virksomheden kender

Masterdata beskriver de varige ting, en virksomhed drejer sig om: kunder, produkter, priser, medarbejdere, leverandører, lokationer, aktiver. I en Salesforce-org til salg er det dine konti og kontakter, dine produkter og dine prislister. Hos Steve Trucking er en detailpartner (Retail Partner) masterdata. Keystone er ikke en hændelse; det er en organisation, Steve Trucking har en løbende relation til. De ni distributionscentre er også masterdata.

Masterdata lever længere end de transaktioner, der bruger dem: én detailpartner kan have millioner af leveringer. Så det første spørgsmål om dem er altid hvem ejer dem? Det er måske ikke Salesforce. ERP’et ejer måske produkterne. Salesforce ejer måske emner, mens ERP’et bliver autoritativt, når de er blevet kunder. En MDM-platform ejer måske en kundes identitet på tværs af virksomheden, sammensat fra flere systemer. Kapitel 6, Masterdata og identitet, går i dybden. Lige nu skal du bare genkende formen.

Referencedata: det ordforråd, virksomheden deler

Referencedata er det kontrollerede ordforråd, der bruges til at klassificere andre data: landekoder, valutaer, produktkategorier, årsagskoder, statusser. Steve Truckings leveringsstatusser (planlagt, læsset, ude til levering, ankommer, leveret, installeret, undtagelse, returneret) er referencedata. De er ikke leveringer; de er de ord, der bruges til at beskrive leveringer.

Det ser lille og harmløst ud, ofte en valgliste med otte værdier. Forveksl ikke lille med uvigtigt. Hvis Salesforce siger Delivered, ERP’et siger Complete, og en detailpartner sender D, skal nogen definere, hvad hver af dem betyder, og hvordan de kobles. Referencedata er der, hvor integrationsantagelserne gemmer sig.

Transaktionsdata: det, der skete

Transaktionsdata registrerer aktivitet: en ordre afgivet, en betaling gennemført, en levering afsluttet, en sag åbnet. I den samme salgs-org er det tilbud og tilbudslinjer, ordrer og ordrelinjer, betalinger: hver af dem peger tilbage på en kunde og et produkt. Steve Truckings million leveringer om året er transaktionsdata, og det er deres statusopdateringer også: omkring otte pr. levering, altså otte millioner statusændringer om året, i en virksomhed, der vokser 30 % om året.

Det er en helt anden vækstkurve end masterdata. Tre detailpartnere i toppen; millioner af rækker nedenunder. Det er her, Steves »antal nuller« (Steve’s Number of Zeros) betyder noget: du kan ikke kigge på detailpartner → levering → status og give hver kasse den samme vægt. Med transaktionsdata tænker jeg straks på volumen, hastighed, opbevaring, historik, arkivering, integration, og hvordan folk faktisk skal finde dem. Del 2 bruger meget tid der.

Metadata: data om dataene

Du har arbejdet med metadata hele kurset: et objekts definition, et felts type, dets beskrivelse, dets relationer. Hele virksomheden har det: datavarehusskemaer, integrationskoblinger, datakataloger, API-kontrakter og for hvert felt en ejer, et følsomhedsniveau, en definition, en dataoprindelse og en opbevaringsregel. Værdierne er data; beskrivelsen af, hvad de betyder, er metadata. Som kapitel 3 sagde, fortæller Flag2__c ingen noget, og det betyder mere nu, hvor AI læser metadata for at finde ud af, hvad data betyder.

Analytiske data: data, vi har lavet af andre data

»Hvad er vores rettidighed pr. detailpartner over de seneste fem år?« er ikke en transaktion. Det er et analytisk spørgsmål, der besvares ved at aflede nye data fra millioner af leveringer: procent til tiden, skadesrate, omsætning pr. partner, installationskvalitet, tendenser for teamene. Og det er et andet job. Disponenten, der spørger »hvad er næste stop for lastbil 217?«, behøver ikke at gennemsøge fem års historik. Ledelsen, der sammenligner fem års rettidighed pr. region, gør. Derfor bor analytiske data som regel i et datavarehus, et lakehouse eller en analyseplatform, der er bygget til det arbejde. At Salesforce kan gemme noget, gør ikke den operationelle platform til stedet, hvor du kører alle analyser på det.

Ustrukturerede data: det, der ikke passer ind i rækker

Dokumenter, PDF’er, billeder, lyd, video, e-mails, transskriptioner, vidensartikler. Hos Steve Trucking leveringsfotoene: omkring fire pr. levering, flere med installationer, fire til fem millioner om året. Et foto er ikke bare endnu et felt. Det er stort, det kan vise indersiden af nogens hjem, det har sine egne opbevaringsregler, og der søges anderledes i det, hvis der overhovedet søges.

Denne type betyder mere for hvert år, der går, fordi AI nu kan gøre nyttige ting med information, der før lå uden for den strukturerede model. En transskription er data. En PDF-manual er data. Et installationsfoto er data. Det betyder ikke, at det hører hjemme i Salesforces core. Det betyder, at det hører hjemme på landskabet.

Click to enlarge

Seks typer, fire spørgsmål hver. Svarene skifter fra type til type, og det er hele pointen.

Typen er kun det halve spørgsmål: arbejdsbelastningen

Det er ikke nok at vide, hvilken type data vi har. Jeg vil også vide, hvad vi gør med dem. Tre arbejdsbelastninger betyder noget her, og hvis man forveksler dem, bliver arkitekturen dårlig.

Operationel: driv forretningen. En disponent opdaterer en levering, et team afslutter et stop, en medarbejder åbner en sag. Masser af små læsninger og skrivninger: find det her, opdatér det der, vis mig dagens stop. Det er OLTP, online transaktionsbehandling, og det er Salesforce rigtig god til; det er der, admins og udviklere bor.

Analytisk: forstå forretningen. Hver levering i fem år, grupperet efter partner og DC, sammenlignet år for år, koblet med økonomi. Nu gennemsøger og aggregerer vi. Det er OLAP, online analytisk behandling, og det er det, datavarehuse, lakehouses og analyseplatforme er bygget til. Sagt enkelt: org’en driver forretningen; datavarehuse og data lakes analyserer den. En klassisk fejl er at lægge den arbejdsbelastning på den operationelle platform og blive overrasket, når nullerne vokser. Hvis nogen gentagne gange vil gennemsøge enorme mængder historik, så behandl det ikke som »bare endnu en rapport«. Spørg, om det er den rigtige platform. Del 2 vender tilbage til det i Design til skala (coming soon) (gør ikke core til dit datavarehus), og del 3 viser, hvordan analytiske strukturer bygges, i Ud over relationsdatabasen (coming soon).

Streaming: data i bevægelse. Hændelser, telemetri, statusændringer, sensormålinger. Steve Truckings lastbiler sender omkring 200.000 GPS-målinger om dagen. Disponenten bekymrer sig om, hvor lastbil 217 er nu. Skal Salesforce gemme hver eneste minut-for-minut-måling fra hver lastbil? Måske ikke. »Hvor er den nu?« og »hvordan var tendenserne for ruteeffektivitet sidste kvartal?« kommer fra den samme kilde og fører til helt forskellige lagringsbeslutninger.

Hvor hurtigt skal det bevæge sig?

Så latens. I undervisningen siger jeg det sådan her: realtid er at vente ved døren på, at nogen kommer tilbage. Du sender dem ud og bliver stående, fordi du ikke kan fortsætte, før de er tilbage. Det er synkront. Næsten realtid er at se dem gå og så tage fat på noget andet; når de kommer tilbage kort efter, tager du dig af det. Det er asynkront. Og så er der batch: ingen går ud ad døren én ad gangen. Dataene venter og flytter sig samlet efter en tidsplan: hver time, med få timers mellemrum eller dagligt. Der er masser af situationer, hvor batch er tilstrækkeligt, og nogle, hvor det ikke er. At vide hvilke er jobbet. De tre er ikke bare integrationsbegreber; de er arkitektoniske valg.

Tag den almindelige ERP-integration. Et nyt produkt oprettes i ERP’et kl. 11.00. Skal salg virkelig kunne sælge det kl. 12.00? Jeg har set begge svar. Nogle kunder vil have det så hurtigt som muligt; andre siger: Hvis vi ikke har sendt den SKU ud til jer, kan vi ikke forvente, at I sælger den endnu. Så produkter er som regel dagligt, nogle gange hurtigere. Kunder mindst dagligt; jeg har set hver time og i ekstreme tilfælde næsten realtid. Ordrer er anderledes: ordreudførelsen skal i gang, så næsten realtid. Sælgeren lukker aftalen og går videre, og ordren lander i ERP’et i løbet af sekunder til et minut eller to. Der findes ikke én rigtig latens for »virksomhedsdata«. Spørg, hvad forretningen faktisk har brug for, og gør ikke alt til realtid, fordi det lyder imponerende. Realtid har en pris.

De fire spørgsmål bag kategorierne

Du behøver ikke at gå rundt og annoncere »det her er transaktionsdata!« Klassifikationen er der for at udløse fire spørgsmål om hvert vigtigt datasæt:

• Hvem ejer det? Hvilket system er autoritativt? Jeg deler det op i tre: hvor bliver det oprettet, hvor bliver det redigeret, og hvor bliver der refereret til det? Kapitel 6 går i dybden med dem (Oprettet, redigeret, refereret, og hvor hurtigt?).
• Hvor hurtigt ændrer det sig? En gang om året, dagligt, ti til hundrede gange i sekundet?
• Hvor stort bliver det? Ti poster, ti tusind, ti millioner, ti milliarder?
• Hvad er dets livscyklus? Lever det for evigt, bliver det arkiveret, skal det slettes, mister det værdi over tid?

De fire fortæller mig langt mere end »kan Salesforce gemme det her?« Og de samler det, vi allerede har lært: ejerskab, livscyklus, antallet af nuller, hvor data bor.

Én virksomhed producerer alle typer

Hos Steve Trucking er detailpartneren masterdata; statusordforrådet er referencedata; hver levering er transaktionsdata; definitionerne af dens felter er metadata; femårsscorekortet for rettidighed er analytiske data; installationsfotoet er ustrukturerede data; og GPS-strømmen er streaming. Det er alt sammen »Steve Truckings data«. Intet af det betyder, at det hører hjemme i den samme database. Det er skiftet.

Ud over eksamen: hvad AI ændrer. For at besvare ét spørgsmål kan en agent have brug for en struktureret kundepost, en nylig transaktion, en PDF-manual, en serviceudskrift og telemetri i realtid. Ustrukturerede data og streamingdata bliver fuldgyldige dele af arkitekturen, selv når de ikke hører hjemme i CRM-databasen, og arkitekten skal stadig vide, hvem der ejer hver kilde, hvor aktuel den er, og om agenten skal stole på den.

Hvad en arkitekt beslutter her

• Hvilken type data hvert vigtigt datasæt er, og hvem der ejer det.
• Om dets arbejdsbelastning er operationel, analytisk, streaming eller en blanding.
• Hvor hurtigt det ændrer sig, og hvor hurtigt andre systemer reelt har brug for at se ændringen.
• Hvordan volumen og livscyklus former, hvor det bor, og hvor længe.
• Om Salesforce skal eje det, have en kopi, referere til det eller lade det ligge et sted, der passer bedre til arbejdsbelastningen.

Når nogen giver dig et krav, så spring ikke direkte til hvilket objekt, hvilket felt, hvilket API. Spørg først, hvilken type data det er, hvem der ejer dem, hvor hurtigt de ændrer sig, hvor store de bliver, hvor længe de lever, og hvad vi prøver at gøre med dem. En konto, en leveringshændelse, et femårsaggregat og et fotografi kan alle betyde noget for den samme virksomhed uden at være det samme arkitektoniske problem.

Læs mere

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. udgave (2017) (på engelsk): standardreferencen for datakategorier og datahåndtering.
• Steve Truckings brief (på engelsk), afsnit 4 (volumener).