Grensesnitt først: deling og datakontrakter

Dataproduktet er grensesnittet – motorrommet skal kunne refaktoreres uten at brukerne er klar over det.

Dataproduktet er grensesnittet

Et dataprodukt er et grensesnitt mot bruk. Alt bak grensesnittet er implementasjon — og bør få lov til å endre seg uten at kundene blir nervøse.

Det høres banalt ut, men i praksis er dette forskjellen på:

• “vi tør ikke røre noe, fordi alt henger sammen”
• og “vi kan forbedre motorrommet uten å ringe halve organisasjonen”.

Når dere tar grensesnittet på alvor, blir deling enklere, endring mindre dramatisk — og dere slipper at folk lager kopier “for sikkerhets skyld”.

Utside vs innside

Utside (produktflate) er det dere står inne for over tid: semantikk, keys, tidslogikk, anbefalt konsumvei, endringspraksis og forventninger.

Innside (motorrom) er alt dere bør kunne endre ofte: staging, mellomlag, pipelines, optimalisering og refaktorering.

Tabell, modell, datasett og dashboard

Det er lett å blande begrepene. Her er en praktisk avklaring, først og fremst for å holde diskusjonene korte:

• Tabell/view er en leveranseform. Noen tabeller er produktflate. Mange er innside.
• Modell er hvordan dere produserer leveransen. Modellen er sjelden et løfte til kunden.
• Datasett er et nyttig samleord, men ofte upresist som produktflate hvis det ikke sier hva som er offisielt.
• Dashboard er presentasjon. Det er vanligvis konsument, ikke dataprodukt.

Poenget er ikke å være språklig streng. Poenget er å kunne si: “Dette er den støttede flaten. Resten er motorrom.”

Hvordan deler vi dataprodukter innen domener, mellom domener og eksternt?

Et dataprodukt som ikke kan deles, er i praksis en intern leveranse. Og deling er mer enn å “publisere i katalogen”.

I praksis består deling av tre trinn:

1. Finne
2. Forstå
3. Få tilgang

Mange forbedrer bare trinn 1 og blir overrasket over at selvbetjening ikke skjer. Katalogen blir penere. Hverdagen blir ikke enklere.

Delingsreisen: hva må være på plass?

Før dere diskuterer verktøy og katalog, er det verdt å sjekke om dere faktisk tilbyr en hel delingsreise.

På produktsiden bør dere alltid svare på tre spørsmål:

1. Hva er dette (og hva er det ikke)?
2. Hvordan bruker jeg det? (anbefalt konsumvei + eksempel)
3. Hva kan jeg forvente? (tilgang, oppdatering, kvalitetssignal, endring)

Hvis dere ikke kan svare kort på disse, ender deling ofte i private meldinger og muntlige forklaringer. Altså: sosial kapital som integrasjonslag.

Deling innen domene

Innen et domene har folk mer kontekst, felles språk og ofte kortere vei til kildene. Da fungerer ofte en enkel praksis godt — så lenge den er tydelig.

Typisk fungerer:

• felles inngang i katalog
• tydelig skille produktflate vs komponent
• kort vei til kontaktpunkt
• enkel endringspraksis

Legg merke til at dette ikke handler om “mer dokumentasjon”. Det handler om rett type signal på rett sted.

Deling mellom domener: betydning før skjema

På tvers av domener forsvinner kontekst. Det som var “selvsagt” blir plutselig en kilde til misforståelser.

Da må dere være presise på:

• begreper (semantikk)
• keys og tidslogikk
• begrensninger
• endring/varsling

Deling uten felles begreper skaper sjelden gjenbruk. Det skaper kopier.

Hvis dere kun deler skjema, deler dere ofte bare muligheten til å misforstå raskere.

Ekstern deling

Når dere deler eksternt endrer spillet seg: forventninger blir høyere, og kost ved feil blir tydeligere.

Her må kontrakt, endring og support være tydelig. I tillegg blir compliance ofte styrende for produktflate og tilgang.

Et godt tegn på modenhet er at dere kan svare på:

• Hvem varsler vi, når noe endrer seg?
• Hva er “breaking” for eksterne konsumenter?
• Hvem tar imot supporthenvendelser — og hva er normal responstid?

Datakontrakt: bruk den når risiko og avhengighet tilsier det

Datakontrakter er ikke et mål i seg selv. Det er et verktøy for forutsigbarhet når “håper det går bra” blir for dyrt.

Vurder å innføre kontrakter når:

• flere team er avhengige
• kostnaden ved feil er høy
• endring skjer ofte

En enkel beslutningsregel kan være: Jo flere avhengigheter × jo høyere risiko × jo oftere endring, jo større sannsynlighet er at dere trenger en datakontrakt. Og i mange tilfeller holder det lenge med “kontrakt light” (de feltene folk misforstår, keys/tidslogikk, og endringspraksis).

Les mer: Guide til datakontrakter