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.

I praksis er dette forskjellen på:

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

Tar dere 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

• 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 upresist som produktflate hvis det ikke sier hva som er offisielt.
• Dashboard er presentasjon. Det er vanligvis konsument, ikke dataprodukt.

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”.

Deling består 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?

Sjekk om dere tilbyr en hel delingsreise før dere diskuterer verktøy og katalog.

På produktsiden må dere 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)

Klarer dere ikke svare kort på disse, ender deling i private meldinger og muntlige forklaringer. Sosial kapital som integrasjonslag.

Deling innen domene

Innen et domene har folk mer kontekst, felles språk og kortere vei til kildene. En enkel praksis holder, så lenge den er tydelig:

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

Dette handler ikke 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.

Deler dere bare skjema, deler dere muligheten til å misforstå raskere.

Ta Kunde 360 – Core som eksempel: det er nettopp på tvers av domener at “hvem er en kunde?” slutter å være selvsagt. CRM-teamet, kundeservice og salgsanalyse har alle sin variant. Et type A-produkt med stabil semantikk og kontrollerte keys er svaret, ikke enda en join.

Ekstern deling

Deler dere eksternt, endrer forventningene seg: kost ved feil blir tydeligere, og compliance er ofte styrende for produktflate og tilgang.

Kontrakt, endring og support må være tydelig. 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?

Hva som regnes som breaking, og hvordan dere håndterer overganger, tar vi for oss i kapittel 8 om endring og utfasing.

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

Jo flere avhengigheter, jo høyere risiko og jo oftere endring, jo større sjanse er det at dere trenger en datakontrakt. I mange tilfeller holder det lenge med “kontrakt light”: de feltene folk misforstår, keys/tidslogikk og endringspraksis.

Neste steg er å gjøre produktet synlig og brukbart i katalogen: I praksis: produktside, katalog og komponenter.