I praksis: produktside, katalog og komponenter

Hvordan dataprodukter faktisk 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 ganske forutsigbart:

• søk blir støy (du finner mye, men ikke det du tør å bruke)
• tilliten faller (“hva er egentlig støttet?”)
• deling ender i private meldinger og muntlige forklaringer

Så hvis du vil “få mer verdi av katalogen”: slutt å starte med flere felter. Start med en tydelig klassifisering som faktisk 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).

Det kan høres akademisk ut, men konsekvensen er veldig 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.”

Det er også her 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”.

Eller: vi har 1000 dataprodukter, men egentlig bare 13 - men de er det ingen som finner, fordi de andre 987 datakomponentene hevder de er et produkt.

Den praktiske testen

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

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

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

To asset-typer i datakatalogen

Datakatalogen bør beskrive både komponenter og dataprodukter. Men den må gjøre forskjellen synlig.

Dataprodukt: når dere faktisk 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
• eksempler: “slik bruker du det” (join, typiske mønstre, fallgruver)

Legg merke til at dette ikke er “mye dokumentasjon”. Det er friksjonsfjerning: Finn → forstå → få tilgang.

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 er ofte nok)
• 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.

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)

Hvis dere får på plass dette, vil dere ofte 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 faktiske 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.