Regelbok og portefølje

Hold ordet ‘dataprodukt’ nyttig: produkt vs komponent, livsløp, domener og eierskap.

Regelbok: Hva vi mener når vi sier “dataprodukt”

Begrepet mister verdi når alt kalles produkt. Da får dere en katalog som ser imponerende ut, men som ikke hjelper noen å ta trygge valg.

Den klassiske spiralen ser slik ut:

• katalogen blir stor, men lite er trygt å bygge på
• folk lager kopier “for sikkerhets skyld”
• endring blir bråk, fordi ingen vet hvem som faktisk eier hva

Regelboken under er laget for å holde ordet dataprodukt praktisk nyttig: få produkter med høy signalverdi, mange komponenter uten falske løfter.

Ti regler som skiller produkt fra komponent

1 Ingen forvaltning → ingen produktstatus.
Hvis dere ikke har kapasitet til å holde et løfte over tid, er “produkt” bare en dyr merkelapp.

2 Eier må være navngitt – og ha beslutningsrett.
“Eier” betyr: hvem kan bestemme definisjoner, prioritering og endring – og hvem svarer når noe ryker?

3 Dataproduktet må ha navngitte kunder.
Hvis målgruppen er “alle”, er det ofte et tegn på at dere ikke vet hvem som faktisk bruker det.

4 Dataproduktet må ha en tydelig bruk.
Ikke “for analyse”, men “for å gjøre X mulig for Y”.

5 Løftet må være tydelig nok til at andre tør å bygge på det.
Tilgang, oppdatering, kvalitetssignal og endringspraksis er ofte nok.

6 Produktflate først, implementasjon etterpå.
Det dere lover er grensesnittet mot bruk. Motorrommet skal kunne refaktoreres uten at alt blir en hendelse.

7 Kritiske avhengigheter er en del av ansvaret.
Hvis løftet avhenger av pipelines, referansetabeller eller kvalitetsjobber, må produktteamet eie konsekvensene — selv om implementasjonen kan ligge flere steder.

8 Kvalitet betyr “godt nok til bruk”.
Få tester som treffer bruken slår mange generiske tester dere ikke reagerer på.

9 Bruk må være synlig.
Hvis dere ikke vet hva som brukes, kan dere heller ikke prioritere, forvalte eller fase ut på en ryddig måte.

10 Livsløp må være definert.
“Pilot”, “aktiv”, “utfases” og “avviklet” er en enkel måte å unngå at alt blir stående for alltid.

Her er en liten illustrasjon, som du kan printe ut og ramme inn. Og kanskje henge i gangen hjemme - eller på kontoret…

“Team” og “eier” betyr ikke en Slack-kanal

Produktstatus gir først mening når dere kan peke på fire ting – kort, konkret og uten heltehistorier:

• Mandat: hvem tar beslutninger om definisjoner og endring?
• Kapasitet: hvem har faktisk tid til hendelser og forespørsler?
• Kontaktpunkt: hvor får kunder svar uten å være personavhengig?
• Run cost: hvem eier prioriteringen av drift/compute/support? (Det holder å eie prioriteringen. Dere trenger ikke fakturere hver query.)

Hvis dere ikke har dette, er det bedre å kalle leveransen en komponent inntil videre.

Livsløp: gjør status synlig i katalogen

En enkel status på produktsiden er ofte nok til å gjøre katalogen mer sann:

• Utkast – idé/arbeid, ingen løfter
• Pilot – noen få kunder, begrenset løfte
• Aktiv – produktløfte gjelder
• Utfases – erstatter er definert, frist og migrering er beskrevet
• Avviklet / nedgradert – ikke produkt lenger (komponent eller fjernet)

Poenget er ikke å være “prosess-voksen”. Poenget er å gjøre forventninger eksplisitte før noen bygger to kvartaler med logikk på noe dere egentlig hadde tenkt å kaste.

Tre nivåer som gjør porteføljen mer pragmatisk

I praksis trenger dere et språk for tre typer leveranser:

• Dataprodukt: forvaltet produktflate med kunder, løfte og livsløp
• Komponent: byggestein (tabell, modell, pipeline) uten produktløfte
• Eksperiment: midlertidig leveranse for å lære, kan oppgraderes senere

Lakmustesten er enkel: Hvis dere fjerner leveransen i morgen — vet dere hvem som savner den, og vet de hvem som tar telefonen?

Produktportefølje i praksis: hva er produkt, hva er “innside”, og hva koster det dere?

Når dere har et språk (produkt/komponent/eksperiment), kan dere også styre porteføljen. Her er to praktiske grep som ofte gir mest effekt per kalori:

1. Gi produktstatus til få ting som faktisk er viktige og deles.
2. Gi komponentstatus til resten – men gjør eierskap og formål synlig.

Dataprodukt eller komponent? En enkel beslutningstabell

Data som ikke er produkter: komponenter, domeneansvar og lett forvaltning

Ikke alt bør passes på som et dataprodukt. Men alt som blir brukt (og alt som kan misforstås) trenger et minimum av orden – ellers blir “selvbetjening” et sosialt eksperiment.

Komponenter er byggesteiner: tabeller, modeller, mellomlag, pipelines. De kan være kritiske, men de har ikke et løfte dere markedsfører som “stabil produktflate”.

Minimumspraksis for komponenter:

• hvilket domene den tilhører
• hvem som eier den (team) og kontaktpunkt
• én setning om formål
• klassifisering (særlig ved sensitivitet/PII)
• enkel livsløpsstatus (aktiv / under endring / på vei ut)
• lineage/avhengigheter (grovt)

Når det finnes navngitte kunder som ville klage hvis dette endret seg uten varsel, er dere i dataprodukt-land.

Eierskap og domener: hvem bestemmer, og hvem forvalter?

Dette er stedet mange “dataprodukt”-initiativer glipper: man blir enig om en definisjon, men ikke om hvem som skal stå i den når hverdagen kommer.

Hva mener vi med “domene” her?

Domene er et område der noen har mandat til å definere begreper og regler, fordi de eier prosessen og konsekvensene.

Det betyr ikke at domenekartet må være perfekt før dere starter. Det betyr at dere må ha en adresse for uenighet.

Dataeierskap: det dere ikke slipper unna

To ting som ofte blandes:

1. Forretningsmessig eierskap til semantikk og regler
   Hvem bestemmer definisjonen når det er uenighet?

2. Produktmessig/operativt eierskap til produktflaten
   Hvem forvalter løftet til kundene: tilgang, kvalitetssignal, endring og support?

Dette kan være samme team eller delt, men ansvaret må være tydelig. Ellers blir det mye “vi trodde dere eide det”.

Plattformteam vs produktteam

• Plattformteamet leverer standarder og “golden paths” (bygging, test, deploy, katalog, tilgang, observability).
• Produktteamet eier semantikk, produktflate, prioritering og endring.
• Domeneeier/forretning møter opp når definisjoner må landes.

Skala: hvor mange dataprodukter tåler dere?

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”

Tre kategorier for styring

• 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

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

Livssyklus: gjør forventninger synlige

Produkt vs komponent handler om hva noe er. Livssyklus handler om hvor trygt det er å bygge på det akkurat nå — og hva som skjer når det endrer seg. Uten en synlig livssyklus ender katalogen fort som en liste over “ting som finnes”, og deling blir personavhengig: folk spør i private meldinger om dette er støttet, om definisjonene er stabile, eller om det er på vei ut.

En enkel livssyklus gjør det mulig å være ærlig uten å være tung:

• Kandidat betyr “ingen løfter”
• Pilot betyr “noen få kunder og korte tilbakemeldingssløyfer”
• Aktiv betyr “produktløftet gjelder”
• Utfases betyr “vi har en erstatning, en frist og en overgang”.

Poenget er ikke flest mulig statuser — poenget er færre overraskelser, tydeligere prioritering og ryddigere opprydding.

Typologi: fire vanlige dataprodukttyper

En typologi gjør det enklere å velge riktig forventningsnivå (og å unngå at alt havner i samme “generisk datasett”-boks).