Typerna av företagsdata

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 2 av 6 i kapitlet Förstå företagets data, kapitel 4 i kursen Data Architect. Varje modul står på egna ben. Föregående: Salesforce är ett system bland många · Nästa: Systemen runt Salesforce

Frågan den här modulen besvarar: Vilka typer av data har ett företag, och varför hör de hemma på olika ställen?

En kundpost. En lista över länder. En order. En fältdefinition. Fem års försäljningssummor. Fyra miljoner leveransfoton. Allt är data, men arkitektoniskt är det inte samma sak. De ändras olika, växer olika, används olika och ägs av olika personer, och de ska inte automatiskt bo på samma ställe. Så när någon säger ”vi behöver de här data i Salesforce” är min nästa fråga: vilken typ av data är det? Svaret börjar tala om för mig vad jag ska göra med dem.

Börja med typen, inte objektet

Som Salesforce-folk översätter vi krav till strukturer nästan direkt: kund, konto; foto, fil; status, plocklista. Det är användbart så småningom. På företagsnivå vill jag först veta vilken sorts information jag har att göra med. Det finns många sätt att klassificera den (DAMA:s kunskapsbank är standardreferensen), och jag tycker att sex typer är användbara: masterdata, referensdata, transaktionsdata, metadata, analytiska data och ostrukturerade data. Kategorierna är inte arkitekturen. De är ett sätt att ställa bättre frågor.

Masterdata: det verksamheten känner till

Masterdata beskriver de beständiga saker som en verksamhet kretsar kring: kunder, produkter, prissättning, anställda, leverantörer, platser, tillgångar. I en säljorg i Salesforce är det dina konton och kontakter, dina produkter och dina prisböcker. Hos Steve Trucking är en detaljhandelspartner (Retail Partner) masterdata. Keystone är ingen händelse; det är en organisation som Steve Trucking har en löpande relation med. De nio distributionscentralerna är också masterdata.

Masterdata lever längre än transaktionerna som använder dem: en detaljhandelspartner kan ha miljontals leveranser. Så den första frågan om dem är alltid vem äger dem? Det kanske inte är Salesforce. ERP:t kanske äger produkterna. Salesforce kanske äger prospekten medan ERP:t blir auktoritativt när de väl är kunder. En MDM-plattform kanske äger kundens identitet i företaget, sammansatt från flera system. Kapitel 6, Masterdata och identitet, går på djupet. För tillfället räcker det att du känner igen formen.

Referensdata

Referensdata är det kontrollerade ordförrådet som används för att klassificera andra data: landskoder, valutor, produktkategorier, orsakskoder, statusar. Steve Truckings leveransstatusar (schemalagd, lastad, ute för leverans, på väg fram, levererad, installerad, avvikelse, returnerad) är referensdata. De är inte leveranser; de är orden som används för att beskriva leveranser.

Det ser litet och ofarligt ut, ofta en plocklista med åtta värden. Blanda inte ihop litet med oviktigt. Om Salesforce säger Delivered, ERP:t säger Complete och en detaljhandelspartner skickar D måste någon definiera vad var och en betyder och hur de mappas. Referensdata är där integrationsantagandena gömmer sig.

Transaktionsdata: vad som hände

Transaktionsdata registrerar aktivitet: en order som lagts, en betalning som gjorts, en leverans som slutförts, ett ärende som öppnats. I samma säljorg är det offerter och offertrader, ordrar och orderrader, betalningar: var och en pekar tillbaka på en kund och en produkt. Steve Truckings miljon leveranser om året är transaktionsdata, och det är deras statusuppdateringar också: ungefär åtta per leverans, alltså åtta miljoner statusändringar om året, i en verksamhet som växer med 30 % om året.

Det är en helt annan tillväxtkurva än för masterdata. Tre detaljhandelspartner överst; miljontals rader under. Det är här Steves ”antal nollor” (Steve’s Number of Zeros) spelar roll: du kan inte titta på detaljhandelspartner → leverans → status och ge varje låda samma vikt. Med transaktionsdata tänker jag direkt på volym, hastighet, lagringstid, historik, arkivering, integration och hur folk faktiskt behöver hitta dem. Del 2 lägger mycket tid där.

Metadata: data om data

Du har arbetat med metadata hela kursen: ett objekts definition, ett fälts typ, dess beskrivning, dess relationer. Hela företaget har det: scheman i datalagret, integrationsmappningar, datakataloger, API-kontrakt, och för varje fält en ägare, en känslighetsnivå, en definition, datahärkomst och en lagringsregel. Värdena är data; beskrivningen av vad de betyder är metadata. Som kapitel 3 sa: Flag2__c säger ingenting till någon, och det spelar större roll nu när AI läser metadata för att lista ut vad data betyder.

Analytiska data: data vi har gjort av andra data

”Vad är vår punktlighet per detaljhandelspartner de senaste fem åren?” är ingen transaktion. Det är en analytisk fråga, som besvaras genom att härleda nya data ur miljontals leveranser: andel i tid, skadefrekvens, intäkt per partner, installationskvalitet, trender för teamen. Och det är ett annat jobb. Trafikledaren som frågar ”vilket är nästa stopp för lastbil 217?” behöver inte gå igenom fem års historik. Ledningen som jämför fem års punktlighet per region gör det. Därför bor analytiska data oftast i ett datalager, ett lakehouse eller en analysplattform byggd för det arbetet. Att Salesforce kan lagra något gör inte den operativa plattformen till stället där varje analys av det ska köras.

Ostrukturerade data: det som inte får plats i rader

Dokument, PDF:er, bilder, ljud, video, mejl, transkriptioner, kunskapsartiklar. Hos Steve Trucking är det leveransfotona: ungefär fyra per leverans, fler med installationer, fyra till fem miljoner om året. Ett foto är inte bara ännu ett fält. Det är stort, det kan visa insidan av någons hem, det har egna lagringsregler, och det söks på ett annat sätt, om alls.

Den här typen blir viktigare för varje år, eftersom AI nu kan göra användbara saker med information som förr låg utanför den strukturerade modellen. En transkription är data. En PDF-manual är data. Ett installationsfoto är data. Det betyder inte att det hör hemma i Salesforce core. Det betyder att det hör hemma på landskapet.

Click to enlarge

Sex typer, fyra frågor var. Svaren ändras från typ till typ, och det är hela poängen.

Typen är bara halva frågan

Att veta vilken typ av data vi har räcker inte. Jag vill också veta vad vi gör med dem. Tre arbetslaster spelar roll här, och att blanda ihop dem ger dålig arkitektur.

Operativ: driva verksamheten. En trafikledare uppdaterar en leverans, ett team slutför ett stopp, en handläggare öppnar ett ärende. Massor av små läsningar och skrivningar: hitta det här, uppdatera det där, visa mig dagens stopp. Det här är OLTP, online transaction processing, och Salesforce är väldigt bra på det; det är där admins och utvecklare bor.

Analytisk: förstå verksamheten. Varje leverans under fem år, grupperad per partner och DC, jämförd år för år, sammanfogad med ekonomidata. Nu skannar och aggregerar vi. Det här är OLAP, online analytical processing, och det är vad datalager, lakehouses och analysplattformar är byggda för. Enkelt uttryckt: orgen driver verksamheten; datalager och datasjöar analyserar den. Ett klassiskt misstag är att lägga den arbetslasten på den operativa plattformen och bli förvånad när nollorna växer. Om någon vill skanna enorma mängder historik gång på gång, behandla det inte som ”bara ännu en rapport”. Fråga om det är rätt plattform. Del 2 återkommer till det i Designa för skala (coming soon) (gör inte core till ditt datalager), och del 3 visar hur analytiska strukturer byggs i Bortom relationsdatabasen (coming soon).

Strömmande: data i rörelse. Händelser, telemetri, statusändringar, sensoravläsningar. Steve Truckings lastbilar skickar ungefär 200 000 GPS-avläsningar om dagen. Trafikledaren bryr sig om var lastbil 217 är nu. Behöver Salesforce spara varje avläsning, minut för minut, från varje lastbil? Kanske inte. ”Var är den nu?” och ”hur såg trenderna för rutteffektivitet ut förra kvartalet?” kommer från samma källa och leder till helt olika beslut om lagring.

Hur snabbt måste det röra sig?

Sedan latens. I klassrummet säger jag så här: realtid är att vänta vid dörren på att någon ska komma tillbaka. Du skickar ut dem och står kvar, eftersom du inte kan fortsätta förrän de är tillbaka. Det är synkront. Nära realtid är att se dem gå och fortsätta med något annat; när de kommer tillbaka en stund senare tar du hand om det. Det är asynkront. Och sedan finns batch: ingen går ut genom dörren en i taget. Data väntar och flyttas som en grupp enligt ett schema: varje timme, med några timmars mellanrum eller dagligen. Det finns många situationer där batch räcker, och några där det inte gör det. Att veta vilket som är vilket är jobbet. De tre är inte bara integrationstermer; de är arkitektoniska val.

Ta den vanliga ERP-integrationen. En ny produkt skapas i ERP:t klockan 11.00. Behöver säljarna verkligen kunna sälja den till klockan 12.00? Jag har sett båda svaren. Vissa kunder vill ha den så snart som möjligt; andra säger att om vi inte har skickat ut den SKU:n till er kan vi inte förvänta oss att ni säljer den än. Så produkter är oftast dagliga, ibland snabbare. Kunder minst dagligen; jag har sett varje timme, och i extrema fall nära realtid. Ordrar är annorlunda: leveransen måste komma igång, så nära realtid. Säljaren stänger affären och går vidare, och ordern landar i ERP:t inom några sekunder till en minut eller två. Det finns ingen enskild rätt latens för ”företagsdata”. Fråga vad verksamheten faktiskt behöver, och gör inte allt till realtid för att det låter imponerande. Realtid har ett pris.

De fyra frågorna bakom kategorierna

Du behöver inte gå runt och utropa ”det här är transaktionsdata!”. Klassificeringen finns där för att väcka fyra frågor om varje viktig datamängd:

• Vem äger den? Vilket system är auktoritativt? Jag delar upp det i tre: var skapas den, var redigeras den, och var refereras den? Kapitel 6 går på djupet med dem (Skapas, redigeras, refereras, och hur snabbt?).
• Hur snabbt ändras den? En gång om året, dagligen, tiotals till hundratals gånger i sekunden?
• Hur stor blir den? Tio poster, tiotusen, tio miljoner, tio miljarder?
• Vilken livscykel har den? Lever den för evigt, arkiveras den, måste den raderas, förlorar den värde med tiden?

De fyra säger mig mycket mer än ”kan Salesforce lagra det här?”. Och de knyter ihop det vi redan har lärt oss: ägarskap, livscykel, antalet nollor, var data bor.

En verksamhet producerar alla typer

Hos Steve Trucking är detaljhandelspartnern masterdata; statusordförrådet är referensdata; varje leverans är transaktionsdata; definitionerna av dess fält är metadata; femårsöversikten över punktlighet är analytiska data; installationsfotot är ostrukturerade data; och GPS-flödet är strömmande data. Allt är ”Steve Truckings data”. Inget av det betyder att det hör hemma i samma databas. Det är skiftet.

Bortom provet: vad AI ändrar. För att besvara en enda fråga kan en agent behöva en strukturerad kundpost, en färsk transaktion, en PDF-manual, en transkription från service och telemetri i realtid. Ostrukturerade och strömmande data blir fullvärdiga delar av arkitekturen även när de inte hör hemma i CRM-databasen, och arkitekten måste fortfarande veta vem som äger varje källa, hur aktuell den är och om agenten ska lita på den.

Vad en arkitekt bestämmer här

• Vilken typ av data varje viktig datamängd är, och vem som äger den.
• Om dess arbetslast är operativ, analytisk, strömmande eller en blandning.
• Hur snabbt den ändras, och hur snabbt andra system verkligen behöver se ändringen.
• Hur volym och livscykel formar var den bor och hur länge.
• Om Salesforce ska äga den, ha en kopia, referera den eller låta den ligga någonstans som passar arbetslasten bättre.

När någon ger dig ett krav, hoppa inte direkt till vilket objekt, vilket fält, vilket API. Fråga först vilken typ av data det är, vem som äger dem, hur snabbt de ändras, hur stora de blir, hur länge de lever och vad vi försöker göra med dem. Ett konto, en leveranshändelse, ett femårsaggregat och ett fotografi kan alla spela roll för samma verksamhet utan att vara samma arkitektoniska problem.

Utforska vidare

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2:a upplagan (2017): standardreferensen för datakategorier och datahantering (på engelska).
• Uppdragsbeskrivningen för Steve Trucking, avsnitt 4 (volymer).