Bygg for i dag. Planlegg for i morgen. Planlegg for feil.

🌐 Finnes også på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 5 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: Arkitektur er kunsten å avveie · Neste: Kjenn verktøyene dine: de ni spørsmålene

Spørsmålet denne modulen besvarer: Hvordan designer du for dagens krav og samtidig planlegger for vekst og for feil?

En av de letteste feilene i arkitektur er å designe bare for kravene som ligger foran deg. Vi har et prosjekt, en backlog og krav. Vi bygger noe som oppfyller dem. Det fungerer, og vi erklærer seier. Seks måneder senere endrer virksomheten seg, eller dataene vokser, eller en annen forretningsenhet vil bruke det, eller vi kjøper et selskap, eller et nytt system skal integreres, eller noe feiler som ingen hadde planlagt for.

Ingenting av dette bør overraske en arkitekt. Vi kan ikke forutsi alt som kommer til å skje, men vi kan designe i visshet om at noe kommer til å skje. Derfor ser jeg på arkitektur gjennom tre linser:

Bygg for i dag. Planlegg for i morgen. Planlegg for feil.

Du trenger alle tre.

Click to enlarge

Bygg for i dag

Arkitektur starter med problemet vi faktisk har. Det høres selvsagt ut, men arkitekter kan gjøre den motsatte feilen av kortsiktig tenkning: vi kan overarkitekte. Hva om vi kjøper opp tolv selskaper, får en milliard kunder, utvider til 40 land, og hvert system trenger sanntidsintegrasjon? Kanskje. Men er det reelle muligheter, eller finner vi opp problemer? Arkitektur handler ikke om å bygge det mest sofistikerte systemet vi kan forestille oss. Det handler om å bygge det passende.

Så start med i dag: hva virksomheten trenger, de faktiske volumene, brukerne og transaksjonene, hvor ofte dataene endres og hvor raskt de må flyttes, hvem som trenger tilgang, og hvor dataene kommer fra og går. Og viktigst av alt: hvorfor? De svarene gir oss noe konkret å designe.

Se etter de underforståtte kravene

Kravene du får, er ikke nødvendigvis alle kravene du har. Det finnes nesten alltid underforståtte krav.

Virksomheten sier: «Vi trenger kundedata i Salesforce.» Ok. Da må noen eie de dataene og bestemme hvor ferske de må være. Vi må vite hva som skjer når kildesystemet er nede, hvordan vi oppdager at synkroniseringen feiler, og hvilken side som vinner når Salesforce og kilden er uenige. Vi trenger en oppbevaringstid, en tilgangsmodell, en beslutning om sensitive felt og en måte å rette dårlige data på.

Ingenting av dette sto i brukerhistorien. Det er likevel arkitektur, alt sammen. En stor del av det å bli arkitekt er å lære å kjenne igjen spørsmålene som ingen har stilt ennå.

Kjenn tallene dine

Jeg presser hele tiden arkitekter til å tallfeste. Ikke si at det er mye data; si hvor mye. Ti tusen, ti millioner, hundre millioner, en milliard? Det er helt ulike arkitekturer. Ikke si at integrasjonen kjører ofte: hver time, hvert minutt, tusen ganger i sekundet? Ikke si at vi vokser raskt. Hvor raskt?

Når jeg ikke har et bedre tall, er utgangspunktet mitt 30 % årlig vekst. Det er ingen prognose; det er et tvangsmiddel for å få tenkt gjennom veksten. Hvis noen sier at vi har 10 millioner poster i dag, vil jeg ikke at diskusjonen skal stoppe ved 10 millioner. Med 30 % i året er vi på omtrent 13 millioner neste år, 17 millioner året etter og rundt 22 millioner året etter det. Nå kan vi snakke om designet. Hvis virksomheten sier at 30 % er latterlig, flott: gi meg det reelle tallet. Poenget er å gjøre vekst til en del av arkitekturdiskusjonen.

Jeg kaller dette Steves «antall nuller» (Steve’s Number of Zeros). Én ekstra null kan endre arkitekturen din fullstendig. Ti tusen, hundre tusen, en million, ti millioner, hundre millioner: funksjonen endret seg ikke, og kravet har kanskje ikke endret seg, men arkitekturen kan ha gjort det.

Husker du timeavtalene fra modul 1? La oss sette de reelle tallene på dem. Over 1 200 steder, 100 avtaler per sted per dag, seks dager i uka, rundt 305 dager i året. Det blir over 36 millioner avtaler det første året. Hvert besøk lager to poster, altså over 73 millioner poster. Behold så fem års historikk, med 30 % vekst i året, og det blir over 650 millioner poster. Samme funksjon, samme krav. Et par nuller til, og en helt annen arkitektur.

Planlegg for i morgen

Når jeg forstår i dag, ser jeg fremover: hva er det rimelig sannsynlig at endrer seg? Volum er en del av det, men i morgen betyr ikke bare mer. Det kan også bety annerledes: flere produkter, forretningsenheter og land; andre personvernkrav; nye kanaler og integrasjoner; en fusjon eller et oppkjøp; en ny masterdatastrategi eller analyseplattform; en KI-agent som bruker informasjon som bare var designet for mennesker.

Derfor bryr jeg meg så mye om arkitekturen kan vokse ved å legge til i stedet for å endres hele tiden. Hvis virksomheten legger til et produkt, kan modellen ta imot det? Hvis et annet system trenger dataene, kan vi eksponere dem på en ryddig måte? Hvis volumet hopper, har vi et sted å gå? Hvis forretningsstrukturen endres, må vi rive datamodellen fra hverandre? Vi prøver ikke å forutsi fremtiden perfekt. Vi prøver å ikke male oss inn i et hjørne.

Ikke bygg morgendagen i dag

Her finnes det en balanse. Å planlegge for i morgen betyr ikke å bygge morgendagens system i dag. Hvis vi har 100 000 poster og kanskje får 100 millioner om fem år, betyr ikke det at vi bygger arkitekturen for 100 millioner poster nå. Den kan gi kostnader og kompleksitet vi ikke trenger ennå.

Spørsmålet jeg vil ha svar på, er: kan dagens arkitektur utvikle seg til morgendagens? Hvis vi kan starte enkelt med en tydelig vei videre, er det ofte bedre enn å betale kompleksitetskostnaden flere år for tidlig. Faren er ikke å starte i det små. Faren er å starte et sted der det ikke finnes noen vei videre.

Planlegg for feil

Nå til den delen ingen liker å snakke om: ting feiler. Jeg har aldri designet et system der hver komponent var tilgjengelig for alltid, hver integrasjon lyktes, hver bruker registrerte perfekte data og hvert eksterne system oppførte seg nøyaktig som dokumentert. Så ikke design det systemet.

Spør hva som kan feile, og spør så hva som skjer når det gjør det. En integrasjon får tidsavbrudd. Et API avviser en forespørsel. En nattlig innlasting behandler 800 000 poster og feiler på 200 000. Et kildesystem går ned. En bruker registrerer ugyldige data. En ekstern identifikator dukker opp to ganger. Et system oppstrøms endrer formatet på en verdi uten å endre feltnavnet. En prosess lykkes i ett system og feiler i et annet. Dette er ikke uvanlige spesialtilfeller. Slik ser produksjon ut.

Delvis suksess er fortsatt feil du må forstå

Delvise feil er spesielt farlige i dataarkitektur. Tenk deg at du flytter en million poster, og prosessen melder at den er fullført. Flott. Men kom det en million, eller 999 997, og hvilke tre mangler? Kanskje 200 000 feilet, noen ble opprettet to ganger, eller alt kom frem, men noen felt feilet i transformasjonen.

«Jobben er fullført» er ikke det samme som at dataene er riktige. En dataarkitekt tenker på avstemming: hvordan vet vi hva som skulle ha skjedd, hva som faktisk skjedde, og forskjellen? Og hva gjør vi med det?

Dette gjør jeg når systemene blir komplekse. Postene går fra A til B, fra venstre mot høyre. Så sender B noe tilbake: en bekreftelse for hver post det mottok og lagret. Nå kan A sammenligne det det sendte, med det som ble bekreftet. Hvis hver post har sin bekreftelse, lyktes kjøringen. Hvis noen bekreftelser mangler, gjorde den ikke det, uansett hva jobbstatusen sier, og vi vet nøyaktig hvilke poster vi må ta tak i: prøve dem på nytt, sende dem til en person eller utløse et varsel.

Click to enlarge

Feil på en kontrollert måte

Når feil skjer, vil jeg vite hva systemet gjør etterpå: om det prøver på nytt, og om det skjer automatisk eller ikke; hva som skjer hvis den samme transaksjonen behandles to ganger; hvor poster som feilet havner, og om gode poster fortsetter å flyte forbi en dårlig; hvem som får varsel, med hvilken informasjon, og hvordan de kjører feilen på nytt; og hvordan en bruker finner ut at noe gikk galt.

Og viktigst av alt: kan vi gjenopprette uten å gjøre problemet verre? En strategi for nye forsøk som lager dupliserte data, er ikke mye til gjenopprettingsstrategi. God arkitektur forutsetter feil og gir oss en vei tilbake.

Overvåk det som betyr noe

Å planlegge for feil uten overvåking er egentlig ikke planlegging. Hvis en integrasjon feiler kl. 02.00 og ingen merker det før en kunde ringer tre dager senere, hadde vi ingen driftsarkitektur. Vi hadde håp.

Bestem hva som må kunne observeres: kjørte prosessen, hvor lang tid tok den, hvor mange poster ble behandlet, hvor mange lyktes og hvor mange feilet? Er volumene plutselig annerledes enn normalt? Vokser køen, øker antallet feil? Arkitektur slutter ikke når utrullingen lykkes. Noen må drifte dette systemet i morgen, og det er en del av designet.

Tenk i alle tre retninger

Fortsett å bruke de tre linsene gjennom resten av kurset. Når vi designer en datamodell: fungerer den i dag, kan den vokse i morgen, og hva skjer når dataene er feil eller ufullstendige? En integrasjon: flytter den dagens data, tåler den morgendagens volum og systemer, og hva skjer når den ene siden er nede? Store datavolumer: hva har vi i dag, hvor er tallene på vei, og hvordan gjenoppretter vi når en stor operasjon bare delvis lykkes?

Teknologien endrer seg fra kapittel til kapittel. Spørsmålene gjør det ikke.

Arkitektur finnes over tid

En utvikler kan noen ganger se på et krav og spørre: «Fungerer dette?» Arkitekten må spørre mer: fungerer det i dag, vil det fortsatt fungere i morgen, og hva skjer når det ikke fungerer i det hele tatt? De tre spørsmålene tar oss forbi implementeringen og inn i systemets liv.

Du kommer ikke til å forutsi hvert fremtidige krav eller forhindre hver feil. Det er ikke målet. Målet er å bygge noe som passer for det vi vet i dag, gi oss selv et sted å gå i morgen, og ha en plan for når virkeligheten ikke samarbeider.

Bygg for i dag. Planlegg for i morgen. Planlegg for feil. Vi kommer til å bruke de tre linsene igjen og igjen.

Hva en arkitekt bestemmer her

• Hva de reelle volumene og veksten er, og hvilke tall som ville endre designet.
• Hvilke underforståtte krav virksomheten ikke har uttalt ennå.
• Hvordan dagens design kan utvikle seg til morgendagens, uten å bygge morgendagens system i dag.
• Hva som skjer når noe feiler: gjenoppretting, avstemming og overvåking.