Bygg för i dag. Planera för i morgon. Planera för fel.

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 5 av 7 i kapitlet Tänk som en dataarkitekt, kapitel 1 i kursen Data Architect. Varje modul står på egna ben. Föregående: Arkitektur är konsten att göra avvägningar · Nästa: Känn dina verktyg: de nio frågorna

Frågan den här modulen besvarar: Hur designar du för dagens krav och planerar samtidigt för tillväxt och för fel?

Ett av de lättaste misstagen inom arkitektur är att bara designa för de krav som ligger framför dig. Vi har ett projekt, en backlog och krav. Vi bygger något som uppfyller dem. Det fungerar, och vi utropar seger. Sex månader senare förändras verksamheten, eller data växer, eller en annan affärsenhet vill använda det, eller vi köper ett företag, eller ett nytt system behöver integreras, eller något går sönder som ingen planerat för.

Inget av det borde överraska en arkitekt. Vi kan inte förutse allt som kommer att hända, men vi kan designa med vetskapen att något kommer att hända. Därför ser jag på arkitektur genom tre linser:

Bygg för i dag. Planera för i morgon. Planera för fel.

Du behöver alla tre.

Click to enlarge

Bygg för i dag

Arkitektur börjar med det problem vi faktiskt har. Det låter självklart, men arkitekter kan göra det motsatta misstaget mot kortsiktigt tänkande: vi kan överarkitekta. Tänk om vi köper tolv företag, får en miljard kunder, expanderar till 40 länder och varje system behöver integration i realtid? Kanske. Men är det verkliga möjligheter, eller hittar vi på problem? Arkitektur handlar inte om att bygga det mest sofistikerade system vi kan föreställa oss. Det handlar om att bygga det lämpliga.

Så börja med i dag: vad verksamheten behöver, de faktiska volymerna, användarna och transaktionerna, hur ofta data ändras och hur snabbt de måste röra sig, vem som behöver åtkomst och var data kommer ifrån och vart de tar vägen. Och viktigast av allt: varför? De svaren ger oss något konkret att designa.

Leta efter de underförstådda kraven

Kraven du får är inte nödvändigtvis alla krav du har. Det finns nästan alltid underförstådda krav.

Verksamheten säger: ”Vi behöver kunddata i Salesforce.” Okej. Då måste någon äga de data och bestämma hur färska de måste vara. Vi behöver veta vad som händer när källsystemet ligger nere, hur vi märker när synkroniseringen misslyckas och vilken sida som vinner när Salesforce och källan inte är överens. Vi behöver en lagringstid, en åtkomstmodell, ett beslut om känsliga fält och ett sätt att rätta felaktiga data.

Inget av det stod i user storyn. Det är ändå arkitektur, allihop. En stor del av att bli arkitekt är att lära sig känna igen de frågor som ingen har ställt än.

Känn dina siffror

Jag pushar ständigt arkitekter att kvantifiera. Säg inte att det finns mycket data; säg hur mycket. Tio tusen, tio miljoner, hundra miljoner, en miljard? Det är väldigt olika arkitekturer. Säg inte att integrationen körs ofta: varje timme, varje minut, tusen gånger i sekunden? Säg inte att vi växer snabbt. Hur snabbt?

När jag inte har en bättre siffra är min utgångspunkt 30 % tillväxt per år. Det är ingen prognos; det är ett sätt att tvinga fram frågan. Om någon säger att vi har 10 miljoner poster i dag vill jag inte att diskussionen stannar vid 10 miljoner. Med 30 % om året är vi på ungefär 13 miljoner nästa år, 17 miljoner året därpå och runt 22 miljoner året efter det. Nu kan vi prata om designen. Om verksamheten säger att 30 % är löjligt, utmärkt: ge mig den verkliga siffran. Poängen är att göra tillväxt till en del av arkitekturdiskussionen.

Jag kallar det här Steves ”antal nollor” (Steve’s Number of Zeros). En extra nolla kan helt ändra din arkitektur. Tio tusen, hundra tusen, en miljon, tio miljoner, hundra miljoner: funktionen ändrades inte, och kravet kanske inte ändrades heller, men arkitekturen kan ha gjort det.

Minns du besöken från modul 1? Nu sätter vi de verkliga siffrorna på dem. Över 1 200 platser, 100 besök per plats och dag, sex dagar i veckan, ungefär 305 dagar om året. Det blir över 36 miljoner besök det första året. Varje besök skapar två poster, så över 73 miljoner poster. Behåll nu fem års historik, med 30 % tillväxt per år, så är det över 650 miljoner poster. Samma funktion, samma krav. Ett par nollor till, och en helt annan arkitektur.

Planera för i morgon

När jag förstår i dag tittar jag framåt: vad är rimligt troligt att förändras? Volymen är en del av det, men i morgon betyder inte bara mer. Det kan också betyda annorlunda: fler produkter, affärsenheter och länder; andra integritetskrav; nya kanaler och integrationer; en fusion eller ett uppköp; en ny masterdatastrategi eller analysplattform; en AI-agent som konsumerar information som bara designades för människor.

Därför bryr jag mig så mycket om huruvida arkitekturen kan växa genom tillägg snarare än ständiga förändringar. Om verksamheten lägger till en produkt, klarar modellen det? Om ett annat system behöver data, kan vi exponera dem på ett rent sätt? Om volymen rusar, har vi någonstans att ta vägen? Om verksamhetens struktur ändras, måste vi riva upp datamodellen? Vi försöker inte förutse framtiden perfekt. Vi försöker att inte måla in oss i ett hörn.

Bygg inte morgondagen i dag

Här finns en balans. Att planera för i morgon betyder inte att bygga morgondagens system i dag. Om vi har 100 000 poster och kanske har 100 miljoner om fem år betyder det inte att vi bygger arkitekturen för 100 miljoner poster nu. Det kan föra med sig kostnader och komplexitet som vi inte behöver än.

Frågan jag vill ha svar på är: kan dagens arkitektur utvecklas till morgondagens? Om vi kan börja enkelt med en tydlig väg framåt är det ofta bättre än att betala komplexitetskostnaden flera år i förväg. Faran är inte att börja litet. Faran är att börja någonstans där det inte finns någon väg vidare.

Planera för fel

Nu till delen som ingen tycker om att prata om: saker går sönder. Jag har aldrig designat ett system där varje komponent förblev tillgänglig för evigt, varje integration lyckades, varje användare matade in perfekta data och varje externt system betedde sig exakt som dokumenterat. Så designa inte det systemet.

Fråga vad som kan gå fel, och fråga sedan vad som händer när det gör det. En integration får timeout. Ett API avvisar en begäran. En nattlig laddning bearbetar 800 000 poster och misslyckas på 200 000. Ett källsystem går ner. En användare matar in ogiltiga data. En extern identifierare dyker upp två gånger. Ett system uppströms ändrar formatet på ett värde utan att ändra fältnamnet. En process lyckas i ett system och misslyckas i ett annat. Det här är inte ovanliga kantfall. Det är så produktion ser ut.

Delvis lyckat är fortfarande ett fel som du behöver förstå

Delvisa fel är särskilt farliga i dataarkitektur. Tänk dig att du flyttar en miljon poster, och processen rapporterar att den är klar. Utmärkt. Men kom det fram en miljon, eller 999 997, och vilka tre saknas? Kanske misslyckades 200 000, en del skapades två gånger, eller allt kom fram men en del fält misslyckades i transformeringen.

”Jobbet slutfört” är inte samma sak som att data är korrekta. En dataarkitekt tänker på avstämning: hur vet vi vad som borde ha hänt, vad som faktiskt hände och skillnaden? Och vad gör vi åt den?

Så här gör jag när systemen blir komplexa. Poster går från A till B, från vänster till höger. Sedan skickar B något tillbaka: en bekräftelse för varje post den tog emot och sparade. Nu kan A jämföra det den skickade med det som bekräftades. Om varje post har sin bekräftelse lyckades körningen. Om några bekräftelser saknas gjorde den inte det, vad jobbstatusen än säger, och vi vet exakt vilka poster vi ska ta hand om: försöka igen, skicka dem till en person eller larma.

Click to enlarge

Gå sönder på ett kontrollerat sätt

När fel uppstår vill jag veta vad systemet gör härnäst: om det försöker igen, och automatiskt eller inte; vad som händer om samma transaktion bearbetas två gånger; vart misslyckade poster tar vägen, och om bra poster fortsätter att flöda förbi en dålig; vem som larmas, med vilken information, och hur de spelar upp felet igen; och hur en användare får reda på att något gick fel.

Och viktigast av allt: kan vi återhämta oss utan att göra problemet värre? En strategi för nya försök som skapar dubbletter är inte mycket till återställningsstrategi. God arkitektur utgår från att fel händer och ger oss en väg tillbaka.

Övervaka det som spelar roll

Att planera för fel utan övervakning är egentligen ingen planering. Om en integration fallerar klockan 02.00 och ingen märker det förrän en kund ringer tre dagar senare, hade vi ingen driftarkitektur. Vi hade hopp.

Bestäm vad som måste vara observerbart: körde processen, hur lång tid tog den, hur många poster bearbetades, hur många lyckades och misslyckades? Skiljer sig volymerna plötsligt från det normala? Växer kön, ökar felen? Arkitekturen tar inte slut när driftsättningen lyckas. Någon måste driva det här systemet i morgon, och det är en del av designen.

Tänk i alla tre riktningarna

Fortsätt använda de tre linserna genom resten av kursen. När vi designar en datamodell: fungerar den i dag, kan den växa i morgon, och vad händer när data är felaktiga eller ofullständiga? En integration: flyttar den dagens data, klarar den morgondagens volymer och system, och vad händer när ena sidan ligger nere? Stora datavolymer: vad har vi i dag, vart är siffrorna på väg, och hur återhämtar vi oss när en stor operation bara delvis lyckas?

Tekniken ändras från kapitel till kapitel. Frågorna gör det inte.

Arkitektur finns över tid

En utvecklare kan ibland titta på ett krav och fråga: ”Fungerar det här?” Arkitekten måste fråga mer: fungerar det i dag, kommer det fortfarande att fungera i morgon, och vad händer när det inte fungerar alls? De tre frågorna tar oss bortom implementationen och in i systemets liv.

Du kommer inte att förutse varje framtida krav eller förhindra varje fel. Det är inte målet. Målet är att bygga något som passar det vi vet i dag, lämna oss någonstans att ta vägen i morgon och ha en plan för när verkligheten inte samarbetar.

Bygg för i dag. Planera för i morgon. Planera för fel. Vi kommer att använda de tre linserna om och om igen.

Vad en arkitekt bestämmer här

• Vilka de verkliga volymerna och den verkliga tillväxten är, och vilka siffror som skulle ändra designen.
• Vilka underförstådda krav verksamheten inte har uttalat än.
• Hur dagens design kan utvecklas till morgondagens, utan att bygga morgondagens system i dag.
• Vad som händer när något går fel: återställning, avstämning och övervakning.