Arkitektur er kunsten å avveie

🌐 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 4 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: Reversibilitetstesten · Neste: Bygg for i dag. Planlegg for i morgen. Planlegg for feil.

Spørsmålet denne modulen besvarer: Når flere løsninger kan fungere, hvordan velger en arkitekt, og hvordan forklarer arkitekten valget?

Hvis arkitektur bare handlet om å finne det riktige svaret, ville det vært mye enklere. Lær plattformen, lær mønstrene, lær grensene, velg det riktige, ferdig.

Slik fungerer ikke ekte arkitektur. De vanskelige beslutningene står som regel ikke mellom en åpenbart god løsning og en åpenbart dårlig. De står mellom flere løsninger som kan fungere, hver med fordeler og ulemper, og hver drar arkitekturen i en litt annen retning. Det er der arkitekten gjør seg fortjent til plassen ved bordet.

Mange måter å løse problemet på

Jeg har brukt en versjon av dette eksemplet mange ganger når jeg underviser arkitekter.

Det kan finnes mange måter å løse et problem på i Salesforce. Noen ganger setter jeg et tall på det, for eksempel ti, men det er en analogi, ikke en opptelling. Mange av alternativene har problemer fra start: de støter mot en begrensning i plattformen, bommer på et kritisk krav eller skaper et sikkerhets- eller ytelsesproblem vi ikke kan akseptere. Dem kan vi raskt legge til side. Noen andre fungerer i dag, men får problemer når dataene vokser. De fungerer teknisk sett, men de holder ikke under veksten vi allerede vet kommer.

Det som er igjen, er et lite antall alternativer som kan dekke behovene dine fremover, og nå blir det interessant. Hvert av dem kan fungere, skalere og oppfylle kravene. Så hvilket er riktig? Kanskje alle. Arkitektens jobb er å forstå forskjellene.

Selv noe så enkelt som en plukkliste fungerer i dag og kan få problemer når dataene vokser. En plukkliste er enkel for brukerne. Men spør hvor verdiene kommer fra, og hvor mange det kan bli. Plukklister fungerer best med færre enn rundt 20 verdier. Av og til går vi opp til 50, som delstatene i USA, og sjelden over 100, som land, og da blir de uhåndterlige. Så for hver plukkliste: kjenn den øvre grensen. Og å endre verdiene i en plukkliste er en metadataendring, ikke en dataendring.

Bruk en lookup-relasjon i stedet, og brukergrensesnittet blir litt mer komplisert. Men listen kan fortsette å vokse uten øvre grense, og nye verdier kan komme fra en integrasjon. Det er en avveining mot brukervennlighet. Det er balansen.

Click to enlarge

Optimal betyr ikke perfekt

Jeg bruker ordet optimal med omhu. En optimal arkitektur er ikke en der hver enkelt beslutning er perfekt; den arkitekturen finnes sannsynligvis ikke. Det er en der løsningen som helhet er balansert.

Si at løsning A gir best ytelse, men er dyr og vanskelig å vedlikeholde. Løsning B koster mindre og er enklere å drifte, men gir fra seg noe ytelse. Løsning C er mer fleksibel for fremtiden, men gir mer kompleksitet i dag. Hvilken er optimal? Det kan jeg ikke svare på ut fra disse fakta alene. Jeg må kjenne virksomheten, kravene og prioriteringene, og vite hvilke begrensninger som er reelle og hvilke som er preferanser. Arkitektur avhenger av konteksten. Derfor kan mønsteret som var riktig for én kunde, være helt feil for den neste.

Og jobben din som dataarkitekt er å balansere disse beslutningene. Du kommer til å ta dusinvis av dem selv eller sammen med teamet ditt. Vit hvilke det er, og vit når en beslutning har større konsekvenser, for kostnad, tid eller funksjonalitet, og må opp til de viktigste beslutningstakerne.

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

Dette er en av de viktigste ideene i kapitlet. Noen ganger tar jeg bevisst en suboptimal beslutning i én del av arkitekturen fordi den gjør hele løsningen bedre.

Kanskje dupliserer jeg en liten mengde data, fordi det å fjerne dupliseringen ville skape unødvendig integrasjonskompleksitet. Kanskje velger jeg en enklere datamodell, fordi den teoretisk renere ville gjort rapportering og daglig bruk mye vanskeligere. Kanskje aksepterer jeg en liten ytelseskostnad, fordi alternativet krever infrastruktur organisasjonen ikke er klar til å drifte.

Ser du på en av dem isolert, vil du si at den ikke er optimal. Riktig. Men arkitektur handler ikke om å optimalisere hver komponent for seg; den handler om å optimalisere systemet. En lokalt suboptimal beslutning kan være en del av en globalt optimal arkitektur, så lenge vi forstår avveiningen vi gjør. Det farlige er å gjøre avveiningen uten å vite at du gjør den.

Vit hva du gir avkall på

Hver gang noen sier til meg «dette er den beste løsningen», er neste spørsmål mitt «best til hva?» Raskest? Billigst? Enklest? Mest skalerbar, sikrest, mest fleksibel? Enklest å drifte, raskest å levere, minst avhengig av spesialkompetanse? Det finnes nesten alltid en annen dimensjon der svaret ikke er «best». Det er avveiningen. Jeg vil vite hva vi får, og jeg vil også vite hva vi gir opp.

Ta to alternativer for en stor mengde virksomhetsdata. Det ene kopierer dataene inn i Salesforce, noe som gjør Salesforces egne funksjoner enklere å bruke, men nå er vi ansvarlige for å flytte dem, lagre dem, synkronisere dem, sikre enda en kopi og håndtere forsinkelse. Det andre lar dataene ligge der de er og henter dem ved behov. Vi har fjernet noe duplisering, men nå betyr tilgjengelighet, spørringsytelse, nettverksavhengigheter og hva det eksterne systemet kan, mer. Ingen av beskrivelsene forteller oss hva vi skal velge. De forteller oss hvilke spørsmål vi skal stille.

Krav er ikke like viktige

Avveininger tvinger oss også til å se at ikke alle krav veier like mye.

Noen sier: «Dataene må være tilgjengelige umiddelbart.» Ok, hva betyr umiddelbart? Ett sekund, ti sekunder, ett minutt? Og hvorfor? Kanskje det er svindeloppdagelse, der sekunder teller. Kanskje noen bare ikke liker å vente på den nattlige innlastingen. Det er helt ulike krav, og arkitekten fortsetter å spørre til vi vet hvilket vi har.

Jeg liker krav som tåler spørsmål: hvor mye, hvor mange, hvor raskt, hvor ofte, for hvem, og hva skjer hvis vi ikke gjør det? «Raskt» er ikke et arkitekturkrav. «95 % av kundeoppdateringene må være tilgjengelige for serviceagenten innen 30 sekunder» er mye nærmere. Nå kan vi vurdere avveininger.

Begrensninger endrer svaret

Noen ganger er arkitekturen ikke begrenset av teknologi i det hele tatt. Den er begrenset av penger, folk, tid, lisenser eller hvor moden organisasjonen er.

En arkitektur som er teknisk utmerket, men krever et driftsteam selskapet ikke har, er ikke en god arkitektur. En funksjon som løser problemet elegant, men krever lisenser kunden ikke vil kjøpe, er heller ikke løsningen. Og den perfekte treårige transformasjonen hjelper ikke et selskap som må lansere om åtte uker.

Ikke noe av dette betyr at vi forlater god arkitektur på grunn av en frist. Det betyr at vi forstår hva vi inngår kompromiss om, hvorfor, og hvilke konsekvenser vi aksepterer, og helst hvordan vi kommer oss fra dagens kompromiss til morgendagens arkitektur.

Arkitekten trenger et bilde av «optimalt»

Her er en interessant spenning. Jeg sier at det ofte ikke finnes ett perfekt svar, og samtidig vil jeg at du skal ha et bilde i hodet av hvordan en optimal løsning ser ut. Det er ikke en motsetning. Du trenger et referansepunkt.

Når jeg ser på en datamodell, vil jeg vite hva jeg ville bygget hvis jeg kunne optimalisere for kravene uten unødvendige begrensninger. Når reelle begrensninger så skyver oss bort fra det designet (vi gjør deler av modellen flatere, dupliserer noen data, utsetter en integrasjon, aksepterer en midlertidig manuell prosess), inngår jeg ikke tilfeldige kompromisser. Jeg vet i hvilken retning jeg beveger meg bort fra det optimale, og hvorfor. Det er arkitekturens kunst, og instinktet krever øvelse.

Tegn det

En av de beste måtene å forstå en avveining på er å tegne den. Arkitekturdiagrammer er ikke pynt i en lysbildepresentasjon; de er tenkeverktøy. Hvis vi velger mellom to tilnærminger, tegn begge. Hvor bor dataene, og hvor flyttes de? Hva eier dem? Hvor går grensene, og hvor håndheves sikkerheten? Hva skjer når noe feiler, og hva endrer seg når volumet vokser?

Et diagram tvinger uklarheter frem i lyset, og det gir alle det samme bildet å peke på.

Jeg lærte hvor mye det betyr på et prosjekt for et energiselskap. Gjennomgang etter gjennomgang forklarte jeg de samme begrepene på nytt og dro samtalen tilbake til det opprinnelige designet. Så jeg endret måten jeg ledet de møtene på: hver gjennomgang startet med datamodellen på skjermen. Ikke den detaljerte med hvert felt. En oppsummert modell: en konto har kontakter, denne posten har underordnede poster, her henger arbeidet. Rommet var stort sett fullt av ledere, og det tok et par minutter.

Fordi det var de samme folkene møte etter møte, ble diagrammet vårt felles språk. Folk begynte å bruke navnene i det. De gjentatte spørsmålene ble borte, og møtene ble mye enklere. Jeg kaller det å forankre møtet: et enkelt diagram, vist hver gang, var verdt langt mer enn det kostet å lage.

Målet er ikke kunstnerisk perfeksjon. Noen ganger er det et detaljert diagram for utviklere, noen ganger fem bokser og seks piler for en leder. Målet er klarhet.

Forklar avveiningen

En god arkitekt legger det frem i rekkefølge: her er alternativene vi vurderte, her er hva hvert av dem gir oss, her er hva hvert av dem koster oss, her er alternativet jeg anbefaler, og her er hvorfor.

Legg merke til at anbefalingen kommer etter avveiningene. Jeg vil ikke at arkitektur skal bli «jeg har gjort dette før, stol på meg». Erfaring betyr enormt mye; den hjelper deg å kjenne igjen mønstre raskere og se problemer tidligere. Men erfaringen din skal gjøre resonnementet ditt bedre, ikke erstatte det. Jobben vår er ikke bare å forstå arkitekturen. Den er å hjelpe organisasjonen å forstå beslutningen, særlig når de som tar den endelige avgjørelsen, ikke er arkitekter.

Think Correct. Think Fast.

Du har ikke alltid tre uker til å analysere hvert alternativ. Noen ganger har du tre minutter. Et krav endres i et møte, noen nevner en begrensning du ikke visste om, eller en leder spør: «Hva om vi trenger dette i Europa neste år?»

Jeg har brukt uttrykket Think Correct. Think Fast. (tenk riktig, tenk raskt). Fart kommer ikke av å hoppe over tenkningen. Den kommer av å ha tenkt nok før øyeblikket kommer: du har lært mønstrene, du kjenner plattformen, du har sett ting feile, du vet hvilke spørsmål du skal stille og hvilke beslutninger som er vanskelige å reversere. Derfor jobber vi oss gjennom scenarioer gjennom hele kurset. Jo flere beslutninger du analyserer, desto raskere kjenner du igjen formen på den neste.

Jeg hadde en kunde som trengte skjemaregistrering. Men det var mange skjemaer, og spørsmålene kunne endre seg over tid. Jeg kjente raskt igjen behovet for en datamodell for spørreundersøkelser, et mønster vi kommer tilbake til senere i kurset. Fordi jeg kjente igjen mønsteret og løsningen, kunne jeg komme med en mer komplett datamodell, en som håndterte kravene som ennå ikke var kommet, ikke bare dem vi hadde foran oss.

Arkitektur handler om balanse

Etter hvert som vi går dypere inn i dataarkitektur, kommer du til å møte valg der jeg vegrer meg for å gi deg en enkel regel. Normalisere eller gjøre flatt? Kopiere dataene eller føderere dem? Synkront eller asynkront? Standardobjekt eller egendefinert? Arkivere eller beholde tilgjengelig?

Det finnes prinsipper, mønstre og grenser, og noen ganger klart feile svar. Men ofte er arkitektens jobb å finne riktig balanse for dette systemet, denne virksomheten og dette øyeblikket.

Vit hvordan det optimale ser ut. Forstå begrensningene. Finn de levedyktige alternativene. Gjør avveiningene synlige. Ta så beslutningen.

Det er ikke ubesluttsomhet. Det er arkitektur.

Hva en arkitekt bestemmer her

• Hvilke alternativer som er levedyktige, og hvilke som er feil nå eller blir dårlige om et år.
• Hva hvert levedyktige alternativ vinner og gir opp, målt mot krav som tåler spørsmål.
• Hvilke begrensninger som er reelle, og hvilke som bare er preferanser.
• Hvilket alternativ du skal anbefale, etter å ha lagt frem avveiningene, og hvordan du forklarer det.