Hva er et dataprodukt?

Definisjon og eksempler på dataprodukter – og hva som bare er en komponent.

En definisjon (og hva det ikke er)

I følge Gartner er dataprodukter følgende:

“A Data Product is an integrated and self-contained combination of data, metadata, semantics and templates. It includes access and logic-certified implementation for tackling specific data and analytics (D&A) scenarios and reuse. A Data Product must be consumption-ready (trusted by consumers), up to date (by engineering teams) and approved for use (governed). Data Products enable various D&A use cases, such as data sharing, data monetization, analytics and application integration.”

Min enklere oversetting er at et dataprodukt er en data-leveranse dere behandler som et produkt.

Det betyr fire ting i praksis:

1. Kunder: navngitte kundegrupper, ikke “alle”
2. Eierskap: et team med mandat til å ta beslutninger og stå i konsekvensene
3. Et løfte: forventninger til tilgang, oppdatering, dokumentasjon, kvalitet og endring
4. Verdi: etterprøvbar (helst målbar), knyttet til faktisk bruk

Når disse er på plass, får dere repeterbarhet som en bieffekt: flere kan bruke samme leveranse over tid, uten at hvert team må lage sin egen variant.

Hvis du ikke kan peke på hvem som bruker det og hva dere lover når det endrer seg, er det sjelden et dataprodukt. Det er ofte bare en viktig tabell.

Eksempler: slik ser dataprodukter ut

I praksis er et dataprodukt ofte en forvaltet leveranse som flere team bygger på, med tydelig bruk, kontrakt og eierskap.

Eksempler som ofte fortjener produktstatus:

• Ordre/ordrelinjer med standardisert hendelseslogikk: én statusmodell og én tidslogikk for ordre, retur og kansellering.
• Metrikk-lag for finansielle KPI-er: definisjoner og beregninger som flere rapporter bygger på.
• Kunde 360 – kjerne: stabil kundedefinisjon, historikk og join keys på tvers av flater.
• Samtykke- og reservasjonsgrunnlag: forvaltet, auditert grunnlag for kontaktbarhet.
• Produktkatalog for analyse: konsistente attributter (kategori, merke, margin, sesong) med tydelig livsløp.

Og dette er vanligvis ikke dataprodukter: staging-/mellomlag (stg_*, “cleaned_v17”), interne hjelpetabeller og engangsartefakter uten navngitte kunder, løfte eller forvaltning.

Hvor mange dataprodukter kan vi ha?

Så mange som dere faktisk klarer å forvalte med kvalitet — med kunder, løfte og et team som svarer.

Antallet dataprodukter bør ikke styres av antall tabeller, men av antall produktflater dere har kapasitet til å holde stabile over tid.

• For få → monolitt: én stor leveranse ingen tør å endre
• For mange → lav signalverdi: vanskelig å finne “det anbefalte”

Vi kan for eksempel besteemme oss for tre kategorier av data:

• Dataprodukt: forvaltet produktflate med løfte
• Komponent: nyttig byggestein uten produktløfte
• Kandidat: kan bli dataprodukt ved økt bruk eller høyere risiko

Bruk må være synlig

For dataprodukter, må bruken være synlig. Velg 1–2 brukssignaler og start enkelt:

• konsum i BI/semantisk lag
• query-/tilgangslogger på produktflater
• antall navngitte konsumentmiljøer i katalog/README
• upstream/downstream i pipelines

Hvilke typer dataprodukter finnes?

En typologi gjør det enklere å velge riktig forventningsnivå. Her er et forslag: