Arkitektur er kunsten at afveje

🌐 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 4 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Reversibilitetstesten · Næste: Byg til i dag. Planlæg for i morgen. Planlæg for fejl.

Spørgsmålet, dette modul besvarer: Når flere løsninger kunne virke, hvordan vælger en arkitekt så, og hvordan forklarer arkitekten valget?

Hvis arkitektur bare handlede om at finde det rigtige svar, ville det være meget nemmere. Lær platformen, lær mønstrene, lær grænserne, vælg det rigtige, færdig.

Sådan fungerer rigtig arkitektur ikke. De svære beslutninger står som regel ikke mellem en åbenlyst god løsning og en åbenlyst dårlig. De står mellem flere løsninger, der kunne virke, hver med fordele og ulemper, og hver flytter arkitekturen i en lidt anden retning. Det er dér, arkitekten gør sig fortjent til sin plads ved bordet.

Mange måder at løse problemet på

Jeg har brugt en udgave af dette eksempel mange gange, når jeg underviser arkitekter.

Der kan være mange måder at løse et problem på i Salesforce. Nogle gange sætter jeg et tal på, lad os sige ti, men det er en sammenligning, ikke en optælling. Mange af mulighederne har problemer fra starten: de støder ind i en begrænsning i platformen, rammer ved siden af et kritisk krav eller skaber et sikkerheds- eller ydelsesproblem, vi ikke kan acceptere. Dem kan vi hurtigt lægge til side. Nogle andre virker i dag, men får problemer, når dataene vokser. De fungerer teknisk set, men de holder ikke til den vækst, vi allerede ved kommer.

Tilbage er et lille antal muligheder, der kan bære dine behov fremover, og nu bliver det interessant. Hver af dem kan måske virke, skalere og opfylde kravene. Så hvilken er den rigtige? Måske dem alle sammen. Arkitektens job er at forstå forskellene.

Selv noget så enkelt som en valgliste virker i dag og kan få problemer, når dataene vokser. En valgliste er nem for brugerne. Men spørg, hvor værdierne kommer fra, og hvor mange der kan være. Valglister fungerer bedst med færre end cirka 20 værdier. Af og til går vi op til 50, som delstaterne i USA, og sjældent over 100, som lande, og så bliver de uhåndterlige. Så kend den øvre grænse for hver valgliste. Og at ændre en valglistes værdier er en metadataændring, ikke en dataændring.

Brug en lookup-relation i stedet, og brugergrænsefladen bliver en smule mere kompleks. Men listen kan blive ved med at vokse uden øvre grænse, og nye værdier kan komme fra en integration. Det er en afvejning mod brugervenlighed. Det er balancen.

Click to enlarge

Optimal betyder ikke perfekt

Jeg bruger ordet optimal med omhu. En optimal arkitektur er ikke en, hvor hver enkelt beslutning er perfekt; den arkitektur findes sandsynligvis ikke. Det er en, hvor den samlede løsning er afbalanceret.

Forestil dig, at løsning A giver den bedste ydelse, men er dyr og svær at vedligeholde. Løsning B koster mindre og er nemmere at drive, men giver afkald på noget ydelse. Løsning C er mere fleksibel for fremtiden, men tilføjer kompleksitet i dag. Hvilken er optimal? Det kan jeg ikke svare på ud fra de fakta alene. Jeg skal kende forretningen, kravene og prioriteterne, og hvilke begrænsninger der er reelle, og hvilke der er præferencer. Arkitektur afhænger af konteksten. Derfor kan det mønster, der var rigtigt for én kunde, være helt forkert for den næste.

Og dit job som dataarkitekt er at afbalancere de beslutninger. Du kommer til at træffe snesevis af dem selv eller sammen med dit team. Ved, hvilke det er, og ved, hvornår en beslutning har større betydning for pris, tid eller funktionalitet og skal op til de vigtigste beslutningstagere.

En suboptimal beslutning kan være en del af en optimal arkitektur

Det her er en af de vigtigste idéer i kapitlet. Nogle gange træffer jeg bevidst en suboptimal beslutning i én del af arkitekturen, fordi den gør hele løsningen bedre.

Måske duplikerer jeg en lille mængde data, fordi det at fjerne duplikeringen ville skabe unødvendig kompleksitet i integrationen. Måske vælger jeg en enklere datamodel, fordi den teoretisk renere ville gøre rapportering og daglig brug meget sværere. Måske accepterer jeg en lille ydelsesomkostning, fordi alternativet tilføjer infrastruktur, som organisationen ikke er klar til at drive.

Se på en hvilken som helst af dem for sig, og du vil sige, at den ikke er optimal. Korrekt. Men arkitektur handler ikke om at optimere hver komponent for sig; det handler om at optimere systemet. En lokalt suboptimal beslutning kan være en del af en globalt optimal arkitektur, så længe vi forstår den afvejning, vi foretager. Det farlige er at foretage afvejningen uden at vide, at du gør det.

Ved, hvad du giver afkald på

Når nogen siger til mig »det her er den bedste løsning«, er mit næste spørgsmål »bedst til hvad?« Hurtigst? Billigst? Enklest? Mest skalerbar, mest sikker, mest fleksibel? Nemmest at drive, hurtigst at levere, mindst afhængig af specialiserede kompetencer? Der er næsten altid en anden dimension, hvor svaret ikke er »bedst«. Det er afvejningen. Jeg vil vide, hvad vi får, og jeg vil også vide, hvad vi giver afkald på.

Tag to muligheder for et stort sæt virksomhedsdata. Den ene kopierer dataene ind i Salesforce, hvilket gør det nemmere at bruge Salesforces egne funktioner, men nu er vi ansvarlige for at flytte dem, gemme dem, synkronisere dem, sikre endnu en kopi og håndtere forsinkelse. Den anden lader dataene blive, hvor de er, og henter dem, når der er brug for dem. Vi har fjernet noget duplikering, men nu betyder tilgængelighed, forespørgselsydelse, netværksafhængigheder og fjernsystemets muligheder mere. Ingen af beskrivelserne fortæller os, hvad vi skal vælge. De fortæller os, hvilke spørgsmål vi skal stille.

Krav er ikke lige vigtige

Afvejninger tvinger os også til at se, at ikke alle krav vejer lige meget.

Nogen siger: »Dataene skal være tilgængelige med det samme.« Okay, hvad betyder med det samme? Ét sekund, ti sekunder, et minut? Og hvorfor? Måske er det svindelopdagelse, hvor sekunder tæller. Måske kan nogen bare ikke lide at vente på den natlige indlæsning. Det er meget forskellige krav, og arkitekten bliver ved med at spørge, indtil vi ved, hvilket af dem vi har.

Jeg kan godt lide krav, der overlever spørgsmål: hvor meget, hvor mange, hvor hurtigt, hvor ofte, for hvem, og hvad sker der, hvis vi ikke gør det? »Hurtigt« er ikke et arkitekturkrav. »95 % af kundeopdateringerne skal være tilgængelige for servicemedarbejderen inden for 30 sekunder« er meget tættere på et. Nu kan vi vurdere afvejninger.

Begrænsninger ændrer svaret

Nogle gange er arkitekturen slet ikke begrænset af teknologi. Den er begrænset af penge, mennesker, tid, licenser eller organisatorisk modenhed.

En arkitektur, der er teknisk fremragende, men kræver et driftsteam, som virksomheden ikke har, er ikke en god arkitektur. En funktion, der løser problemet elegant, men kræver licenser, som kunden ikke vil købe, er heller ikke løsningen. Og den perfekte treårige transformation hjælper ikke en virksomhed, der skal gå i luften om otte uger.

Intet af det betyder, at vi opgiver god arkitektur på grund af en deadline. Det betyder, at vi forstår, hvad vi går på kompromis med, hvorfor, og hvilke konsekvenser vi accepterer, og helst også hvordan vi kommer fra dagens kompromis til morgendagens arkitektur.

Arkitekten har brug for et billede af »optimal«

Her er en interessant spænding. Jeg siger til dig, at der ofte ikke findes ét perfekt svar, og samtidig vil jeg have, at du har et billede i hovedet af, hvordan en optimal løsning ser ud. Det er ikke modstridende. Du har brug for et referencepunkt.

Når jeg ser på en datamodel, vil jeg vide, hvad jeg ville bygge, hvis jeg kunne optimere til kravene uden unødvendige begrænsninger. Når reelle begrænsninger så skubber os væk fra det design (vi gør en del af modellen fladere, duplikerer nogle data, udskyder en integration, accepterer en midlertidig manuel proces), er det ikke tilfældige kompromiser. Jeg ved, i hvilken retning jeg bevæger mig væk fra det optimale, og hvorfor. Det er arkitekturens kunst, og instinktet kræver øvelse.

Tegn det

En af de bedste måder at forstå en afvejning på er at tegne den. Arkitekturdiagrammer er ikke pynt til et slideshow; de er værktøjer til at tænke med. Hvis vi skal vælge mellem to tilgange, så tegn begge. Hvor bor dataene, og hvor bevæger de sig hen? Hvad ejer dem? Hvor går grænserne, og hvor håndhæves sikkerheden? Hvad sker der, når noget fejler, og hvad ændrer sig, når volumen vokser?

Et diagram tvinger uklarheder frem i lyset, og det giver alle det samme billede at pege på.

Jeg lærte, hvor meget det betyder, på et projekt for et forsyningsselskab. Møde efter møde opdagede jeg, at jeg forklarede de samme begreber igen og trak samtalen tilbage til det oprindelige design. Så jeg ændrede den måde, jeg holdt møderne på: hver gennemgang startede med datamodellen på skærmen. Ikke den detaljerede med alle felter. En oversigtsmodel: en konto har kontakter, denne post har underordnede poster, her hænger arbejdet. Rummet var mest fuldt af direktører, og det tog et par minutter.

Fordi det var de samme mennesker møde efter møde, blev diagrammet vores fælles sprog. Folk begyndte at bruge dets navne. De gentagne spørgsmål forsvandt, og møderne blev meget nemmere. Jeg kalder det at forankre mødet: et enkelt diagram, vist hver gang, var langt mere værd, end det kostede at lave.

Målet er ikke kunstnerisk perfektion. Nogle gange er det et detaljeret diagram til udviklere, andre gange fem kasser og seks pile til en direktør. Målet er klarhed.

Forklar afvejningen

En god arkitekt lægger det frem i rækkefølge: her er de muligheder, vi overvejede, her er, hvad hver af dem giver os, her er, hvad hver af dem koster os, her er den mulighed, jeg anbefaler, og her er hvorfor.

Læg mærke til, at anbefalingen kommer efter afvejningerne. Jeg vil ikke have, at arkitektur bliver til »jeg har gjort det før, stol på mig«. Erfaring betyder enormt meget; den hjælper dig med at genkende mønstre hurtigere og se problemer tidligere. Men din erfaring skal forbedre din begrundelse, ikke erstatte den. Vores job er ikke bare at forstå arkitekturen. Det er at hjælpe organisationen med at forstå beslutningen, især når dem, der træffer den endelige beslutning, ikke er arkitekter.

Think Correct. Think Fast.

Du har ikke altid tre uger til at analysere hver mulighed. Nogle gange har du tre minutter. Et krav ændrer sig på et møde, nogen nævner en begrænsning, du ikke kendte til, eller en direktør spørger: »Hvad hvis vi får brug for det her i Europa næste år?«

Jeg har brugt udtrykket Think Correct. Think Fast. (tænk rigtigt, tænk hurtigt). Hastighed kommer ikke af at springe tænkningen over. Den kommer af at have tænkt nok, før øjeblikket kommer: du har lært mønstrene, du kender platformen, du har set fejl, du ved, hvilke spørgsmål du skal stille, og hvilke beslutninger der er svære at omgøre. Derfor arbejder vi med scenarier gennem hele kurset. Jo flere beslutninger du analyserer, desto hurtigere genkender du formen på den næste.

Jeg havde en kunde, der havde brug for at udfylde formularer. Men der var mange formularer, og spørgsmålene kunne ændre sig over tid. Jeg genkendte hurtigt behovet for en datamodel til spørgeskemaer, et mønster, vi vender tilbage til senere i kurset. Fordi jeg genkendte mønsteret og løsningen, kunne jeg komme med en mere komplet datamodel, en, der håndterede de krav, der stadig var på vej, ikke kun dem, vi havde foran os.

Arkitektur handler om balance

Når vi går dybere ind i dataarkitektur, møder du valg, hvor jeg undlader at give dig en simpel regel. Normalisere eller gøre fladt? Kopiere dataene eller føderere dem? Synkront eller asynkront? Standardobjekt eller brugerdefineret? Arkivere eller holde online?

Der er principper, mønstre og grænser, og nogle gange klart forkerte svar. Men ofte er arkitektens job at finde den rette balance for dette system, denne forretning og dette øjeblik.

Ved, hvordan det optimale ser ud. Forstå begrænsningerne. Find de levedygtige muligheder. Gør afvejningerne synlige. Træf så beslutningen.

Det er ikke ubeslutsomhed. Det er arkitektur.

Hvad en arkitekt beslutter her

• Hvilke muligheder der er levedygtige, og hvilke der er forkerte nu eller vil gå galt om et år.
• Hvad hver levedygtig mulighed vinder og giver afkald på, målt mod krav, der overlever spørgsmål.
• Hvilke begrænsninger der er reelle, og hvilke der kun er præferencer.
• Hvilken mulighed der skal anbefales, efter at afvejningerne er lagt frem, og hvordan den forklares.