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

Ett produkt, flere konsumflater

Den vanligste fellen i organisasjoner som har kommet litt på vei med dataprodukter, er å bygge parallelle produkter for ulike konsumenter. Operasjon trenger lav latens og lager et eget produkt. Analyse trenger fleksibel querying og lager et eget. Compliance trenger auditerbart format og lager et eget.

Resultatet er at “Kunde 360” finnes i tre varianter med tre litt ulike definisjoner. Dere har løst gjenbruksproblemet for teknologi, men gjenintrodusert det for semantikk.

Én kjerne, flere utganger

Et modent dataprodukt bygges rundt én felles definisjon, og eksponerer flere konsumflater fra samme forvaltede kjerne:

                ┌─ Operasjon (near-real-time API)
Felles kjerne ──┼─ Analyse (fleksibel querying via tabeller)
                └─ Compliance (standardisert, auditerbar eksport)

Bare utgangen endres, ikke definisjonen. Kunde 360-produktet kan tjene marketing-segmentering, salgskvalifisering, customer success-helse og AI-personalisering samtidig, fra samme forvaltede kjerne, gjennom forskjellige output-grensesnitt.

Ta Kunde 360 - Core fra de foregående kapitlene som eksempel: én definisjon av “kunde”, én logikk for nøkler og gyldighet. Eksponert som et view for analyse, et API for operasjonelle systemer, og en eksport for compliance. Definisjonen er ett sted. Konsumflatene er flere.

Beskytt kjernen

Etterhvert som bruken øker, presser nye team på tilpasninger: “kan vi få en variant der aktiv kunde ekskluderer de som bare har én ordre?”, “kan vi få et felt som flagger interne kunder annerledes for vår bruk?”.

Sier dere ja for ofte, ødelegges kjernen. Da får dere duplisert transformasjon, semantisk drift, og er tilbake i kopi-helvetet. Modne dataprodukter isolerer bruks-logikk fra grunnmodellen: kjernen forblir stabil og forvaltet, mens den brukspesifikke logikken lever modulært i et logisk view.

Å beskytte kjernen er ikke rigiditet. Det er det som gjør varig gjenbruk og langsiktig tillit mulig.

Mønsteret er også grunnen til at AI-agenter får konsistente svar på tvers av kanaler: én definisjon av “Revenue”, uavhengig av om spørsmålet kommer via Slack, dashboard eller API. Mer om hvorfor dette betyr noe i en AI-verden kommer i kapittel 8 om AI-klare dataprodukter.

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 9 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, nøkler/tidslogikk og endringspraksis. Vil dere standardisere format senere, finnes Open Data Contract Standard (ODCS) som etablert spesifikasjon å bygge på.

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