Du sitter på tredje møte denne uken og prøver for n'te gang å forklare dataanalytikerene at dataene de trenger ligger i sølvlaget, og at de derfor har ansvaret for å foredle dem videre i gull. Frustrasjonen stiger - hvorfor føles det som en evig kamp å få dem til å forstå? Eller kanskje du og teamet ditt sitter fast i en diskusjon om hvilken transformasjon som egentlig hører til sølv, og hvilken som må vente til gull? Eller så har du en irreversibel schemaendring på et viktig datasett, og du lurer på hvordan du skal versjonere det uten å miste oversikt, da utbryter en på teamet: "Hva med pre-silver?"

Disse situasjonene er ikke uvanlige i miljøer som følger medaljongarkitekturen. I stedet for å skape verdi, blir dataarbeid ofte en øvelse i å forstå hvor dataene skal ligge, heller enn å forstå hva de faktisk betyr og hvordan de kan brukes. Denne artikkelen tar for seg hvorfor jeg mener medaljongarkitekturen er en utdatert tilnærming, og hvordan vi heller bør designe data med sluttbrukeren i fokus.

Hva er medaljongarkitekturen?

Medaljongarkitekturen, også kjent som en flerlagsarkitektur, er et designmønster som brukes til å organisere data i et lakehouse. Målet er å forbedre strukturen og kvaliteten på dataene trinnvis etter hvert som de beveger seg gjennom de ulike lagene i arkitekturen:

• Bronse: Rå, ubehandlet data
• Sølv: Validerte og rensede data
• Gull: Berikede, aggregerte data klare for analyse

Denne tilnærmingen har blitt populær fordi den gir en strukturert metode for å forbedre datakvaliteten og gjøre dataene mer egnet for analyse og maskinlæring.

Hvorfor oppstod medaljongarkitekturen?

Medaljongarkitekturen oppstod fordi den ga data engineers en følelse av kontroll og forenkling i en verden av komplekse datasystemer. Ved å bryte ned store problemer i mindre deler, skapte man en slags oversikt og håndterbarhet. Den gjorde det lettere å forklare dataflyten og etablere standardiserte prosesser for databehandling.

Dette har hjulpet oss i en viss grad, men medaljongarkitekturen løser dessverre ikke de grunnleggende utfordringene med datastyring og datakvalitet. Den adresserer ikke behovet for tydelig eierskap, fleksibel dataforvaltning eller bedre forståelse av hvordan data faktisk brukes i praksis. Resultatet blir ofte et rigid system der data flyttes mekanisk mellom lag uten at dette nødvendigvis gir mer verdi til sluttbrukeren.

Problemene med medaljongarkitekturen

Til tross for sin utbredelse har medaljongarkitekturen flere svakheter:

• Kontekstbaserte definisjoner: Hva som hører hjemme i bronse-, sølv- og gullagene er ofte uklart og varierer ikke bare mellom organisasjoner, men også internt i en enkelt organisasjon.
  • Begrepet "rådata" er i seg selv tvetydig – hva som regnes som rådata vil variere avhengig av kontekst og hvem som definerer det. I noen tilfeller refererer det til data som er hentet direkte fra en kilde uten noen form for behandling, mens i andre tilfeller kan det være data som allerede har vært gjennom en form for transformasjon før det når plattformen.
  • Veiledningen rundt sølvlaget ofte noe i duren "hold transformasjonene minimale", men hva betyr egentlig det i praksis? Det er sjelden en klar definisjon, og det kan føre til usikkerhet rundt hvilke transformasjoner som er akseptable. Uten en tydelig forståelse av hva som menes med minimale transformasjoner, risikerer man at sølvlaget enten blir for nært bronselaget og dermed ikke tilfører verdi, eller at det utvikler seg til å ligne et gullag med for omfattende transformasjoner. Dette gjør at den tradisjonelle inndelingen av medaljongarkitekturen kan bli kunstig og misvisende.
• Unødvendige mellomlag: Mangelen på fleksibilitet fører til at nye lag opprettes, som "platinum" eller "pre-silver", noe som skaper mer kompleksitet enn verdi. Et eksempel på en ønsket fleksibilitet er når et sølvlag også har behov for interim-tabeller. Dette kan for eksempel være nødvendig ved versjonering av datasett, der data må mellomlagres eller transformeres i flere steg for å sikre historikk og sporbarhet.
• Redundant databehandling: Ikke all data trenger å gå gjennom tre transformasjonsstadier, men medaljongarkitekturen tvinger oss gjennom dem. Dette øker latensen ved at data må passere gjennom flere lag før de blir tilgjengelige for sluttbrukerne, og kan skape unødvendig kompleksitet når enkle transformasjoner låses til definerte stadier selv når en mer direkte tilnærming kunne vært mer effektiv.
• Dårlig brukerfokus: Medaljongarkitekturen prioriterer tekniske prosesser fremfor sluttbrukernes behov og brukervennlighet, noe som ofte resulterer i at data flyttes og transformeres på en måte som ikke nødvendigvis skaper verdi for de som faktisk skal bruke dataene. Ved å fokusere for mye på interne standarder og prosesskrav kan organisasjoner miste av syne hvordan dataene skal brukes i praksis, noe som fører til unødvendig kompleksitet og ineffektive arbeidsprosesser for sluttbrukerne.

Dataprodukttankegangen – et bedre alternativ

Før vi dytter data gjennom en rigid struktur, må vi forstå behovet og bruken av dataene. Uten denne innsikten risikerer vi å bygge en løsning som ikke oppfyller de faktiske kravene. Akkurat som en bygning må designes før de første byggeklossene legges, må vi ha en tydelig plan for hvordan dataene skal organiseres og brukes. Hvis ikke, ender vi opp med et ustabilt system bestående av deler som ikke passer sammen og som ikke gir reell verdi.

Måten vi gjør det er å se på data som produkter. Et dataprodukt er en veldefinert enhet av data designet for å være nyttig for en spesifikk gruppe brukere. Det kan være et datasett, et API-endepunkt, en rapport eller et maskinlæringsmodellert datasett, alt avhengig av behovet.

En dataprodukttankegang innebærer at data skapes og administreres med sluttbrukeren i fokus. Produsenten av dataproduktet tar ansvar for kvalitet, tilgjengelighet og brukervennlighet, slik at data ikke bare flyttes gjennom ulike lag, men faktisk tilfører verdi til de som trenger det.

Mange tror kanskje at de allerede produserer dataprodukter, fordi de leverer tabeller, rapporter eller datasett. Men et dataprodukt er mer enn bare en dataenhet. Det har egenskaper, kontekst og attributter som gjør det lettere å finne, bruke og forvalte over tid. En tilfeldig tabell eller rapport uten en tydelig struktur for bruk og vedlikehold oppfyller ikke kravene til et dataprodukt.

Jeg skjønner dersom du sitter og er bekymret for at all gjenbrukbar logikk som man ofte får ut av et sølvlag, forsvinner med en dataprodukttankegang. Men hvis en transformasjon brukes av mange, betyr det at dette i seg selv burde være et dataprodukt. I stedet for å låse logikken til et spesifikt lag i medaljongarkitekturen, kan det eksponeres som et gjenbrukbart dataprodukt som gir verdi på tvers av domener.

Så, hva skal til for at vi skal kunne betegne noe som et dataprodukt? Jo, det må oppfylle følgende krav:

• Oppdagbart: Andre team i en organisasjon bør enkelt kunne finne et dataprodukt, for eksempel via en datakatalog. Dette forhindrer at data blir liggende ubrukt og foreldreløse, som kun opptar lagringsplass uten å skape forretningsverdi.
• Identifiserbart: Hvert dataprodukt bør ha en unik identifikator, slik at andre team enkelt kan finne og bruke det. Dette kan være en datakobling med database/tabellkombinasjon, en S3 URI til en Parquet-fil eller en URL til en rapport.
• Pålitelig og observerbart: Konsumere bør kunne inspisere et dataprodukt og se dets opprinnelse og når det sist ble oppdatert. Dette er viktig for å gi brukerne tillit til riktigheten av dataproduktet.
• Selvbeskrivende: Et dataprodukt inneholder metadata som forklarer forretningsformålet, feltene og hvordan dataene er beregnet.
• Interoperabelt: Dataprodukter bør tilby måter å trekke ut og bruke data på, enten via SQL-kompatibilitet, API-er eller definerte filformater.
• Sikkert og styrt: Et dataprodukt bør ha mekanismer for tilgangskontroll og identifisering av sensitiv informasjon for å sikre samsvar med regulatoriske krav.

Et marked for data

Ved å behandle data som produkter gjør vi det enklere for andre brukere å oppdage og gjenbruke dataprodukter som kan være relevante for dem. På denne måten blir en dataplattform mer enn bare et lagrings- og prosesseringsverktøy, men heller et marked for data, der hvem som helst kan "shoppe" det de trenger for sine analyser og løsninger. Dette skaper en mer dynamisk og verdifull dataøkonomi internt i organisasjonen.

Jobben blir morsommere når du vet hva du driver med

Som data engineer trives jeg mye bedre med det jeg driver med når jeg faktisk forstår dataen og dens bruksområder. Medaljongarkitekturen derimot, dytter meg i retning av å bli en "kode monkey" som kun flytter data mellom lag uten å kreve at jeg vet noe om dets innhold og verdi. Dette fører til at prosessen mister mening og at datahåndtering blir en mekanisk oppgave i stedet for en strategisk, verdiskapende aktivitet. Ved å adoptere en dataprodukttankegang kan organisasjoner skape mer verdi, redusere kompleksitet og gjøre data mer tilgjengelig for forbrukere. Det er på tide å flytte fokuset fra tekniske prosesser til faktiske brukerbehov.