Byg til i dag. Planlæg for i morgen. Planlæg for fejl.

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 5 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Arkitektur er kunsten at afveje · Næste: Kend dine værktøjer: de ni spørgsmål

Spørgsmålet, dette modul besvarer: Hvordan designer du til dagens krav og planlægger samtidig for vækst og for fejl?

En af de nemmeste fejl i arkitektur er kun at designe til de krav, der ligger foran dig. Vi har et projekt, en backlog og krav. Vi bygger noget, der opfylder dem. Det virker, og vi erklærer sejr. Seks måneder senere ændrer forretningen sig, eller dataene vokser, eller en anden forretningsenhed vil bruge det, eller vi opkøber en virksomhed, eller et nyt system skal integreres, eller noget fejler, som ingen havde planlagt for.

Intet af det burde overraske en arkitekt. Vi kan ikke forudsige alt, hvad der kommer til at ske, men vi kan designe med viden om, at noget vil ske. Derfor ser jeg på arkitektur gennem tre linser:

Byg til i dag. Planlæg for i morgen. Planlæg for fejl.

Du har brug for alle tre.

Click to enlarge

Byg til i dag

Arkitektur starter med det problem, vi faktisk har. Det lyder indlysende, men arkitekter kan begå den modsatte fejl af kortsigtet tænkning: vi kan overarkitekte. Hvad hvis vi opkøber tolv virksomheder, får en milliard kunder, udvider til 40 lande, og hvert system skal have integration i realtid? Måske. Men er det reelle muligheder, eller opfinder vi problemer? Arkitektur handler ikke om at bygge det mest avancerede system, vi kan forestille os. Det handler om at bygge det passende.

Så start med i dag: hvad forretningen har brug for, de faktiske mængder, brugere og transaktioner, hvor ofte dataene ændrer sig, og hvor hurtigt de skal flytte sig, hvem der skal have adgang, og hvor dataene kommer fra og skal hen. Og vigtigst af alt: hvorfor? De svar giver os noget konkret at designe ud fra.

Se efter de underforståede krav

De krav, du får, er ikke nødvendigvis alle de krav, du har. Der er næsten altid underforståede krav.

Forretningen siger: »Vi skal have kundedata i Salesforce.« Okay. Så skal nogen eje de data og beslutte, hvor friske de skal være. Vi skal vide, hvad der sker, når kildesystemet er nede, hvordan vi opdager, når synkroniseringen fejler, og hvilken side der vinder, når Salesforce og kilden er uenige. Vi har brug for en opbevaringsperiode, en adgangsmodel, en beslutning om følsomme felter og en måde at rette dårlige data på.

Intet af det stod i brugerhistorien. Det er alt sammen stadig arkitektur. En stor del af at blive arkitekt er at lære at genkende de spørgsmål, der endnu ikke er blevet stillet.

Kend dine tal

Jeg presser hele tiden arkitekter til at sætte tal på. Sig ikke til mig, at der er mange data; sig, hvor mange. Ti tusind, ti millioner, hundrede millioner, en milliard? Det er meget forskellige arkitekturer. Sig ikke, at integrationen kører ofte: hver time, hvert minut, tusind gange i sekundet? Sig ikke, at vi vokser hurtigt. Hvor hurtigt?

Når jeg ikke har et bedre tal, er mit udgangspunkt 30 % årlig vækst. Det er ikke en forudsigelse; det er en tvangsfunktion. Hvis nogen siger, at vi har 10 millioner poster i dag, vil jeg ikke have, at diskussionen stopper ved 10 millioner. Med 30 % om året er vi på cirka 13 millioner næste år, 17 millioner året efter og omkring 22 millioner året efter det. Lad os så tale om designet. Hvis forretningen siger, at 30 % er latterligt, fint: giv mig det rigtige tal. Pointen er at gøre vækst til en del af arkitekturdiskussionen.

Jeg kalder det Steves »antal nuller« (Steve’s Number of Zeros). Ét ekstra nul kan ændre din arkitektur fuldstændigt. Ti tusind, hundrede tusind, en million, ti millioner, hundrede millioner: funktionen ændrede sig ikke, og kravet har måske ikke ændret sig, men arkitekturen kan have gjort det.

Kan du huske aftalerne fra modul 1? Lad os sætte de rigtige tal på. Over 1.200 lokationer, 100 aftaler pr. lokation om dagen, seks dage om ugen, cirka 305 dage om året. Det er over 36 millioner aftaler det første år. Hvert besøg skaber to poster, så over 73 millioner poster. Gem nu fem års historik med 30 % vækst om året, og så er det over 650 millioner poster. Samme funktion, samme krav. Et par nuller mere og en helt anden arkitektur.

Planlæg for i morgen

Når jeg forstår i dag, kigger jeg fremad: hvad vil med rimelig sandsynlighed ændre sig? Volumen er en del af det, men i morgen er ikke bare mere. Det kan også betyde anderledes: flere produkter, forretningsenheder og lande; andre krav til privatliv; nye kanaler og integrationer; en fusion eller et opkøb; en ny masterdatastrategi eller analyseplatform; en AI-agent, der bruger oplysninger, som kun var designet til mennesker.

Derfor går jeg så meget op i, om arkitekturen kan vokse ved tilføjelse frem for konstant ændring. Hvis forretningen tilføjer et produkt, kan modellen så rumme det? Hvis et andet system har brug for dataene, kan vi så stille dem rent til rådighed? Hvis volumen springer op, har vi så et sted at gå hen? Hvis forretningsstrukturen ændrer sig, skal vi så rive datamodellen fra hinanden? Vi prøver ikke at forudsige fremtiden perfekt. Vi prøver ikke at male os selv op i et hjørne.

Byg ikke morgendagen i dag

Der er en balance her. At planlægge for i morgen betyder ikke at bygge morgendagens system i dag. Hvis vi har 100.000 poster og måske får 100 millioner om fem år, betyder det ikke, at vi bygger arkitekturen til 100 millioner poster nu. Den kan bringe omkostninger og kompleksitet med sig, som vi ikke har brug for endnu.

Det spørgsmål, jeg vil have besvaret, er: kan dagens arkitektur udvikle sig til morgendagens? Hvis vi kan starte enkelt med en klar vej fremad, er det ofte bedre end at betale for kompleksiteten flere år for tidligt. Faren er ikke at starte i det små. Faren er at starte et sted, hvor der ingen vej er videre.

Planlæg for fejl

Nu kommer den del, ingen kan lide at tale om: ting fejler. Jeg har aldrig designet et system, hvor alle komponenter forblev tilgængelige for evigt, alle integrationer lykkedes, alle brugere indtastede perfekte data, og alle eksterne systemer opførte sig præcis som dokumenteret. Så design ikke det system.

Spørg, hvad der kan fejle, og spørg så, hvad der sker, når det gør. En integration får timeout. Et API afviser en anmodning. En natlig indlæsning behandler 800.000 poster og fejler på 200.000. Et kildesystem går ned. En bruger indtaster ugyldige data. Et eksternt id dukker op to gange. Et system længere oppe i kæden ændrer formatet på en værdi uden at ændre feltnavnet. En proces lykkes i ét system og fejler i et andet. Det er ikke usædvanlige specialtilfælde. Sådan ser produktion ud.

Delvis succes er stadig fejl, du skal forstå

Delvise fejl er særligt farlige i dataarkitektur. Forestil dig, at du flytter en million poster, og processen melder, at den er færdig. Fint. Men kom der en million frem, eller 999.997, og hvilke tre mangler? Måske fejlede 200.000, nogle blev oprettet to gange, eller alt kom frem, og nogle felter fejlede i transformationen.

»Job fuldført« er ikke det samme som at dataene er korrekte. En dataarkitekt tænker på afstemning: hvordan ved vi, hvad der skulle være sket, hvad der faktisk skete, og hvad forskellen er? Og hvad gør vi ved det?

Her er, hvad jeg gør, når systemerne bliver komplekse. Poster går fra A til B, fra venstre mod højre. Så sender B noget tilbage: en bekræftelse for hver post, det har modtaget og gemt. Nu kan A sammenligne det, det sendte, med det, der blev bekræftet. Hvis hver post har sin bekræftelse, lykkedes kørslen. Hvis der mangler bekræftelser, lykkedes den ikke, uanset hvad jobstatus siger, og vi ved præcis, hvilke poster vi skal tage os af: prøve dem igen, sende dem til et menneske eller slå alarm.

Click to enlarge

Fejl med ynde

Når en fejl sker, vil jeg vide, hvad systemet gør bagefter: om det prøver igen, og om det sker automatisk eller ej; hvad der sker, hvis den samme transaktion behandles to gange; hvor fejlede poster havner, og om gode poster bliver ved med at flyde forbi en dårlig; hvem der får besked, med hvilke oplysninger, og hvordan de afspiller fejlen igen; og hvordan en bruger finder ud af, at noget gik galt.

Og vigtigst af alt: kan vi komme på fode igen uden at gøre problemet værre? En strategi for genforsøg, der skaber dubletter, er ikke meget af en gendannelsesstrategi. God arkitektur forventer fejl og giver os en vej tilbage.

Overvåg det, der betyder noget

At planlægge for fejl uden overvågning er ikke rigtig planlægning. Hvis en integration fejler kl. 02.00, og ingen opdager det, før en kunde ringer tre dage senere, havde vi ikke en driftsarkitektur. Vi havde håb.

Beslut, hvad der skal kunne observeres: kørte processen, hvor lang tid tog den, hvor mange poster blev behandlet, hvor mange lykkedes, og hvor mange fejlede? Er mængderne pludselig anderledes end normalt? Vokser køen, stiger antallet af fejl? Arkitekturen slutter ikke, når deploymentet lykkes. Nogen skal drive dette system i morgen, og det er en del af designet.

Tænk i alle tre retninger

Bliv ved med at bruge de tre linser i resten af kurset. Når vi designer en datamodel: virker den i dag, kan den vokse i morgen, og hvad sker der, når dataene er forkerte eller ufuldstændige? En integration: flytter den dagens data, kan den klare morgendagens mængder og systemer, og hvad sker der, når den ene side er nede? Store datamængder: hvad har vi i dag, hvor er tallene på vej hen, og hvordan kommer vi på fode igen, når en stor operation kun delvist lykkes?

Teknologien skifter fra kapitel til kapitel. Spørgsmålene gør ikke.

Arkitektur eksisterer over tid

En udvikler kan nogle gange se på et krav og spørge: »Virker det her?« Arkitekten skal spørge om mere: virker det i dag, virker det stadig i morgen, og hvad sker der, når det slet ikke virker? De tre spørgsmål tager os ud over implementeringen og ind i systemets liv.

Du kommer ikke til at forudsige alle fremtidige krav eller forhindre alle fejl. Det er ikke målet. Målet er at bygge noget, der passer til det, vi ved i dag, at give os selv en vej videre i morgen og at have en plan for, når virkeligheden ikke samarbejder.

Byg til i dag. Planlæg for i morgen. Planlæg for fejl. Vi bruger de tre linser igen og igen.

Hvad en arkitekt beslutter her

• Hvad de reelle mængder og den reelle vækst er, og hvilke tal der ville ændre designet.
• Hvilke underforståede krav forretningen endnu ikke har udtalt.
• Hvordan dagens design kan udvikle sig til morgendagens uden at bygge morgendagens system i dag.
• Hvad der sker, når noget fejler: gendannelse, afstemning og overvågning.