I praksis: produktside, katalog og komponenter

Hvordan dataprodukter bør se ut i katalog og drift.

Hvorfor datakataloger ofte blir lite brukt

Mange datakataloger feiler ikke på søk, UI eller “manglende metadata”. De feiler på signal.

Når alt ser likt ut, får brukeren ikke svar på det viktigste spørsmålet:

Hva er trygt å bygge på - og hva er bare innside-komponenter?

Hvis katalogen ikke gir dette svaret raskt, skjer det tre ting:

• søk blir støy (du finner mye, men ikke det du tør å bruke)
• tilliten faller (“hva er egentlig støttet?”)
• folk omgår katalogen helt

Vil dere “få mer verdi av katalogen”: slutt å starte med flere felter. Start med en tydelig klassifisering som betyr noe i hverdagen.

Produkt vs komponent

Dette er kjernen i hele dataprodukt-tanken i praksis:

Dataprodukt = et forvaltet grensesnitt mot bruk (produktflate dere støtter).
Komponent = byggestein/motorrom (viktig, men uten produktforpliktelse).

Konsekvensen er konkret:

• Når du sier dataprodukt, sier du samtidig: “Vi har kunder, eierskap, løfte - og vi håndterer endring.”
• Når du sier komponent, sier du: “Dette kan endre seg for å forbedre motorrommet. Du kan bruke det, men du bygger på egen risiko.”

Her er det mange går på en smell: de kaller alt “dataprodukt”, og ender med en katalog som gir null trygghet. Da får dere “alt er produkt” → “ingenting er produkt”. Se gjerne på porteføljestyring i kapittel 2 for hvordan skillet mellom produkt, komponent og eksperiment bør styres over tid.

Den praktiske testen

Spør disse to spørsmålene, og du lander riktig:

1. Hvis dette endrer seg i morgen - hvem klager? (navngitte konsumenter)
2. Hvis noe ryker - hvem tar telefonen? (navngitt eierteam + kontaktpunkt)

Klarer dere ikke svare tydelig, er det nesten alltid en komponent (eller et eksperiment) - selv om den er viktig.

Dataprodukt: når dere mener “støttet”

Et dataprodukt er katalogens “forreste rekke”: ting dere ønsker at flere skal bruke over tid.

Minimum på en dataproduktside:

• eierteam + kontaktpunkt (ikke personavhengig)
• kunder + verdihypotese (navngitte kundegrupper)
• én anbefalt konsumvei (den offisielle produktflaten)
• tilgangsmønster uten sosial kapital (hvordan få tilgang, ikke hvem du kjenner)
• endring/utfasing (changelog + varsling + overgang ved breaking)
• kontrakt light: keys/tidslogikk + definisjoner folk ofte misforstår
• kolonnebeskrivelser med betydning, ikke bare type: hva feltet faktisk inneholder, eksempelverdier og lukkede sett. Dette er det høyest-leverende tiltaket når AI-agenter er konsumenter (mer i kapittel 8).
• forretningsregler eksplisitt kodet: standardfiltre, kjente unntak, ekskluderinger som lever i hodet på analytikere bør stå skrevet et sted en konsument - menneske eller agent - kan finne dem.
• eksempler: “slik bruker du det” (join, typiske mønstre, fallgruver)

Dette er ikke “mye dokumentasjon”. Det er friksjonsfjerning: finn → forstå → få tilgang.

Ta Kunde 360 - Core som eksempel: eierteam er datadomenet i CRM-teamet, navngitte kunder er salgsteamet og kundeservice, anbefalt konsumvei er et view med join key og gyldighetsperiode, og tilgangsmønsteret er én Jira-forespørsel til eierteamet. Det er ikke mye å skrive. Det er akkurat nok til at neste team slipper å spørre i Slack.

Komponent: når det er motorrom (men fortsatt må være ryddig)

Komponenter trenger mindre - men de må være tydelige på at de er innside.

Minimum på en komponent-side:

• eier (team) og kontaktpunkt
• formål (én setning som gjør den forståelig)
• lineage/avhengigheter (grovt holder)
• klassifisering ved sensitivitet/PII
• en tydelig setning som sier: “Dette er en komponent (innside), ikke en støttet produktflate.”

Det siste punktet er undervurdert: brukere tåler godt at noe er innside - de tåler dårlig å bli lurt til å tro at innside er støttet grensesnitt.

Slik gjør dere forskjellen synlig i datakatalogen

Å “ha to typer” holder ikke hvis det bare står i en wiki. Forskjellen må være synlig og filtrerbar. Datakatalogen bør beskrive både komponenter og dataprodukter, men den må gjøre forskjellen synlig.

Forskjeller som virker

Start med det enkle:

• en tydelig type: Dataprodukt / Komponent
• en synlig badge i søk og lister
• et filter som lar brukeren velge “vis bare dataprodukter”
• en produktflate-markering som skiller “støttet” fra “innside”
• en enkel livsløpsstatus på dataprodukter (utkast/pilot/aktiv/utfases/avviklet)

Får dere på plass dette, vil dere se mer bruk av katalogen uten at dere har “fylt ut alt”.

En praktisk regel for nye ting

Start med nye leveranser som komponent.

Promoter til dataprodukt når:

• dere har konsumenter dere kan navngi
• dere kan holde et løfte over tid (eierskap + kapasitet)
• dere har valgt én støttet produktflate

Dette gir dere en naturlig porteføljestyring uten at dere innfører et styringsregime.

Neste steg er å definere hva kvalitet betyr for produktet, og hvilke løfter dere kan måle: Kvalitet og SLO for dataprodukter.