Arkitektur är konsten att göra avvägningar

🌐 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 4 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: Reversibilitetstestet · Nästa: Bygg för i dag. Planera för i morgon. Planera för fel.

Frågan den här modulen besvarar: När flera lösningar skulle kunna fungera, hur väljer en arkitekt, och hur förklarar den valet?

Om arkitektur bara handlade om att hitta rätt svar skulle det vara mycket lättare. Lär dig plattformen, lär dig mönstren, lär dig gränserna, välj rätt, klart.

Det är inte så verklig arkitektur fungerar. De svåra besluten står oftast inte mellan en uppenbart bra lösning och en uppenbart dålig. De står mellan flera lösningar som skulle kunna fungera, var och en med för- och nackdelar, var och en flyttar arkitekturen i en lite annan riktning. Det är där arkitekten gör sig förtjänt av sin plats vid bordet.

Många sätt att lösa problemet

Jag har använt en variant av det här exemplet många gånger när jag undervisar arkitekter.

Det kan finnas många sätt att lösa ett problem i Salesforce. Ibland sätter jag en siffra på det, säg tio, men det är en liknelse, inte en räkning. Många av alternativen har problem från början: de krockar med en begränsning i plattformen, missar ett kritiskt krav eller skapar ett säkerhets- eller prestandaproblem som vi inte kan acceptera. De kan vi snabbt lägga åt sidan. Några andra fungerar i dag men kommer att få problem när data växer. De fungerar tekniskt, men de håller inte för den tillväxt vi redan vet kommer.

Kvar blir ett litet antal alternativ som kan bära dina behov framåt, och nu blir det intressant. Vart och ett av dem kanske fungerar, skalar och uppfyller kraven. Så vilket är rätt? Kanske alla. Arkitektens jobb är att förstå skillnaderna.

Till och med något så enkelt som en plocklista fungerar i dag och kan få problem när data växer. En plocklista är enkel för användarna. Men fråga var värdena kommer ifrån, och hur många de kan bli. Plocklistor fungerar bäst med färre än ungefär 20 värden. Ibland går vi upp till 50, som delstaterna i USA, och sällan över 100, som länder, och då blir de otympliga. Så för varje plocklista: känn till den övre gränsen. Och att ändra en plocklistas värden är en metadataändring, inte en dataändring.

Använd en lookup-relation i stället, så blir användargränssnittet lite mer komplext. Men listan kan fortsätta växa utan övre gräns, och nya värden kan komma in från en integration. Det är en avvägning mot användbarheten. Det är balansen.

Click to enlarge

Optimalt betyder inte perfekt

Jag använder ordet optimal med omsorg. En optimal arkitektur är inte en där varje enskilt beslut är perfekt; en sådan arkitektur finns troligen inte. Det är en där helhetslösningen är balanserad.

Anta att lösning A ger bäst prestanda men är dyr och svår att underhålla. Lösning B kostar mindre och är lättare att driva men ger upp en del prestanda. Lösning C är mer flexibel för framtiden men lägger till komplexitet i dag. Vilken är optimal? Det kan jag inte svara på utifrån de fakta enbart. Jag behöver känna verksamheten, kraven och prioriteringarna, och veta vilka begränsningar som är verkliga och vilka som är önskemål. Arkitektur beror på sammanhanget. Det är därför mönstret som var rätt för en kund kan vara helt fel för nästa.

Och ditt jobb som dataarkitekt är att balansera de här besluten. Du kommer att fatta dussintals av dem själv, eller med ditt team. Vet vilka de är, och vet när ett beslut har större påverkan, på kostnad, tid eller funktionalitet, och behöver gå upp till de viktigaste beslutsfattarna.

Ett suboptimalt beslut kan vara en del av en optimal arkitektur

Det här är en av de viktigaste idéerna i kapitlet. Ibland fattar jag medvetet ett suboptimalt beslut i en del av arkitekturen eftersom det gör helhetslösningen bättre.

Kanske duplicerar jag en liten mängd data, eftersom att ta bort dupliceringen skulle skapa onödig integrationskomplexitet. Kanske väljer jag en enklare datamodell, eftersom den teoretiskt renare skulle göra rapportering och vardagsanvändning mycket svårare. Kanske accepterar jag en liten prestandakostnad, eftersom alternativet lägger till infrastruktur som organisationen inte är redo att driva.

Titta på vilket som helst av dem isolerat och du skulle säga att det inte är optimalt. Stämmer. Men arkitektur handlar inte om att optimera varje komponent för sig; det handlar om att optimera systemet. Ett lokalt suboptimalt beslut kan vara en del av en globalt optimal arkitektur, så länge vi förstår avvägningen vi gör. Det farliga är att göra avvägningen utan att veta att du gör den.

Vet vad du ger upp

När någon säger till mig ”det här är den bästa lösningen” är min nästa fråga ”bäst på vad?” Snabbast? Billigast? Enklast? Mest skalbar, säkrast, mest flexibel? Lättast att driva, snabbast att leverera, minst beroende av specialistkompetens? Det finns nästan alltid en annan dimension där svaret inte är ”bäst”. Det är avvägningen. Jag vill veta vad vi får, och jag vill också veta vad vi ger upp.

Ta två alternativ för en stor mängd företagsdata. Det ena kopierar data in i Salesforce, vilket gör Salesforce-inbyggda funktioner enklare att använda, men nu ansvarar vi för att flytta dem, lagra dem, synkronisera dem, säkra ytterligare en kopia och hantera latens. Det andra lämnar data där de är och hämtar dem vid behov. Vi har tagit bort en del duplicering, men nu spelar tillgänglighet, frågeprestanda, nätverksberoenden och fjärrsystemets förmågor större roll. Ingen av beskrivningarna säger oss vilket vi ska välja. De säger oss vilka frågor vi ska ställa.

Alla krav väger inte lika

Avvägningar tvingar oss också att se att inte alla krav väger lika tungt.

Någon säger: ”Data måste vara tillgängliga direkt.” Okej, vad betyder direkt? En sekund, tio sekunder, en minut? Och varför? Kanske handlar det om bedrägeriupptäckt, där sekunder spelar roll. Kanske gillar någon bara inte att vänta på nattens laddning. Det är väldigt olika krav, och arkitekten fortsätter fråga tills vi vet vilket vi har.

Jag gillar krav som tål frågor: hur mycket, hur många, hur snabbt, hur ofta, för vem, och vad händer om vi inte gör det? ”Snabbt” är inget arkitekturkrav. ”95 % av kunduppdateringarna måste vara tillgängliga för serviceagenten inom 30 sekunder” är mycket närmare ett. Nu kan vi utvärdera avvägningar.

Begränsningar ändrar svaret

Ibland begränsas arkitekturen inte alls av tekniken. Den begränsas av pengar, människor, tid, licenser eller organisationens mognad.

En arkitektur som är tekniskt utmärkt men kräver ett driftteam som företaget inte har är ingen bra arkitektur. En funktion som löser problemet elegant men kräver licenser som kunden inte tänker köpa är inte heller lösningen. Och den perfekta treåriga transformationen hjälper inte ett företag som måste lansera om åtta veckor.

Inget av det betyder att vi överger god arkitektur på grund av en deadline. Det betyder att vi förstår vad vi kompromissar med, varför och vilka konsekvenser vi accepterar, och helst hur vi ska ta oss från dagens kompromiss till morgondagens arkitektur.

Arkitekten behöver en bild av ”optimalt”

Här finns en intressant spänning. Jag säger till dig att det ofta inte finns ett enda perfekt svar, och samtidigt vill jag att du bär med dig en bild i huvudet av hur en optimal lösning ser ut. Det motsäger inte varandra. Du behöver en referenspunkt.

När jag tittar på en datamodell vill jag veta vad jag skulle bygga om jag kunde optimera för kraven utan onödiga begränsningar. Sedan, när verkliga begränsningar trycker oss bort från den designen (vi plattar till en del av modellen, duplicerar en del data, skjuter upp en integration, accepterar en tillfällig manuell process), gör jag inte slumpmässiga kompromisser. Jag vet åt vilket håll jag rör mig bort från det optimala, och varför. Det är arkitekturens konst, och instinkten kräver övning.

Rita det

Ett av de bästa sätten att förstå en avvägning är att rita den. Arkitekturdiagram är inte dekorationer i en presentation; de är verktyg för att tänka. Om vi väljer mellan två angreppssätt, rita båda. Var bor data, och var rör de sig? Vad äger dem? Var går gränserna, och var upprätthålls säkerheten? Vad händer när något går sönder, och vad ändras när volymen växer?

Ett diagram tvingar fram otydligheter i ljuset, och det ger alla samma bild att peka på.

Jag lärde mig hur mycket det spelar roll i ett projekt med ett energibolag. Granskning efter granskning märkte jag att jag förklarade samma begrepp igen och drog tillbaka samtalet till den ursprungliga designen. Så jag ändrade hur jag ledde de mötena: varje granskning började med datamodellen på skärmen. Inte den detaljerade med varje fält. En sammanfattande modell: ett konto har kontakter, den här posten har underordnade poster, här hänger arbetet. Rummet bestod mest av chefer, och det tog ett par minuter.

Eftersom det var samma personer möte efter möte blev diagrammet vårt gemensamma språk. Folk började använda dess namn. De upprepade frågorna försvann, och mötena blev mycket enklare. Jag kallar det att förankra mötet: ett enkelt diagram, som visades varje gång, var värt mycket mer än det kostade att göra.

Målet är inte konstnärlig perfektion. Ibland är det ett detaljerat diagram för ingenjörer, ibland fem rutor och sex pilar för en chef. Målet är tydlighet.

Förklara avvägningen

En bra arkitekt lägger fram det i ordning: här är alternativen vi övervägde, här är vad vart och ett ger oss, här är vad vart och ett kostar oss, här är alternativet jag rekommenderar, och här är varför.

Lägg märke till att rekommendationen kommer efter avvägningarna. Jag vill inte att arkitektur ska bli ”jag har gjort det här förut, lita på mig”. Erfarenhet spelar enormt stor roll; den hjälper dig att känna igen mönster snabbare och se problem tidigare. Men din erfarenhet ska förbättra ditt resonemang, inte ersätta det. Vårt jobb är inte bara att förstå arkitekturen. Det är att hjälpa organisationen att förstå beslutet, särskilt när de som fattar det slutliga beslutet inte är arkitekter.

Think Correct. Think Fast.

Du kommer inte alltid att ha tre veckor på dig att analysera varje alternativ. Ibland har du tre minuter. Ett krav ändras på ett möte, någon nämner en begränsning du inte kände till, eller en chef frågar: ”Tänk om vi behöver det här i Europa nästa år?”

Jag har använt frasen Think Correct. Think Fast. (tänk rätt, tänk snabbt). Snabbheten kommer inte av att hoppa över tänkandet. Den kommer av att ha tänkt tillräckligt innan ögonblicket kommer: du har lärt dig mönstren, du kan plattformen, du har sett misslyckanden, du vet vilka frågor du ska ställa och vilka beslut som är svåra att backa. Därför arbetar vi oss igenom scenarier genom hela kursen. Ju fler beslut du analyserar, desto snabbare känner du igen formen på nästa.

Jag hade en kund som behövde formulärinmatning. Men det fanns många formulär, och frågorna kunde ändras över tid. Jag kände snabbt igen behovet av en datamodell för enkäter, ett mönster vi återkommer till senare i kursen. Eftersom jag kände igen mönstret och lösningen kunde jag ta in en mer komplett datamodell, en som klarade de krav som ännu inte kommit, inte bara dem vi hade framför oss.

Arkitektur handlar om balans

När vi går djupare in i dataarkitektur kommer du att möta val där jag inte vill ge dig en enkel regel. Normalisera eller platta till? Kopiera data eller federera dem? Synkront eller asynkront? Standardobjekt eller anpassat? Arkivera eller behålla online?

Det finns principer, mönster och gränser, och ibland uppenbart felaktiga svar. Men ofta är arkitektens jobb att hitta rätt balans för det här systemet, den här verksamheten och det här ögonblicket.

Vet hur optimalt ser ut. Förstå begränsningarna. Identifiera de genomförbara alternativen. Gör avvägningarna synliga. Fatta sedan beslutet.

Det är inte obeslutsamhet. Det är arkitektur.

Vad en arkitekt bestämmer här

• Vilka alternativ som är genomförbara, och vilka som är fel nu eller kommer att bli dåliga inom ett år.
• Vad varje genomförbart alternativ vinner och ger upp, mätt mot krav som tål frågor.
• Vilka begränsningar som är verkliga och vilka som bara är önskemål.
• Vilket alternativ som ska rekommenderas, efter att avvägningarna lagts fram, och hur det ska förklaras.