Reversibilitetstesten
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)
Modul 3 av 7 i kapitlet Tenk som en dataarkitekt, kapittel 1 i kurset Data Architect. Hver modul står på egne ben. Forrige: Datamodellen er skjelettet · Neste: Arkitektur er kunsten å avveie
Spørsmålet denne modulen besvarer: Hvordan skiller du en arkitektonisk beslutning fra en vanlig?
Arkitekter tar mange beslutninger.
Men ikke alle beslutninger er arkitektoniske beslutninger.
Det er et viktig skille. Hvis vi behandler hver beslutning som arkitektur, bruker vi all tiden vår på å diskutere ting som er relativt enkle å endre. Hvis vi ikke kjenner igjen beslutningene som virkelig er arkitektoniske, kan vi ta en beslutning på fem minutter i dag som tar fem år å nøste opp.
Så hvordan ser vi forskjellen?
Jeg liker å stille et enkelt spørsmål:
Hvor vanskelig blir denne beslutningen å reversere senere?
Jeg kaller dette reversibilitetstesten (the Reversibility Test).
Jo vanskeligere noe er å reversere, og jo mer annet som kommer til å avhenge av det, desto mer arkitektonisk oppmerksomhet fortjener det.
Noen beslutninger er billige å endre
Section titled “Noen beslutninger er billige å endre ”La oss starte med noe enkelt.
Vi kaller et felt Kundekategori. Seks måneder senere bestemmer virksomheten at alle egentlig kaller det Kundesegment. Vi endrer etiketten. Det kan være litt dokumentasjon å oppdatere og litt brukeropplæring, men dette er ingen stor arkitektonisk hendelse. Vi må likevel leve med det opprinnelige API-navnet, for å endre det har mye større konsekvenser. Så dette kan bety at vi må håndtere en endret etikett, og forvirringen som kan følge med.
Vi tok en beslutning. Vi ombestemte oss. Vi gikk videre.
Sammenlign det med en annen beslutning.
Vi lager en identifikator for kunder. Vi bestemmer hva den betyr, hvilket format den har, og hvilket system som oppretter den. Så publiserer vi den.
Salesforce bruker den. Datavarehuset bruker den. Integrasjonsplattformen bruker den. Kundeportalen bruker den. Fem andre applikasjoner begynner å lagre den. Rapporter og datapipelines bruker den. Kanskje ser kundene den etter hvert.
Tre år senere sier noen:
Vi burde nok ikke ha designet identifikatoren sånn.
Det er en helt annen samtale.
Forskjellen er ikke at den ene beslutningen er mer teknisk enn den andre.
Forskjellen er reversibilitet.
Slik kan det skje. Si at virksomheten har bygget nøklene sine av en del av kundens navn pluss et nummer. Det fungerer i årevis, fordi ingen noen gang har måttet endre et navn. Så, et år eller mer senere, endres et navn likevel, og plutselig passer ikke nøklene med mønsteret resten av dataene forventer. Dette er en av grunnene til at nøkler ikke bør ha noen iboende betydning.
Arkitektur skaper tyngdekraft
Section titled “Arkitektur skaper tyngdekraft ”En arkitektonisk beslutning har en tendens til å samle ting rundt seg. Jeg tenker på det som tyngdekraft.
Velg en objektmodell, og automatisering bygges rundt den.
Velg en nøkkel, og andre systemer begynner å lagre den.
Velg hvor masterdata bor, og integrasjoner begynner å flyte mot og bort fra det stedet.
Velg en delingsmodell, og forretningsprosesser begynner å avhenge av hvem som kan se hva.
Velg et integrasjonsmønster, og systemer begynner å avhenge av timingen og oppførselen dets.
Jo lenger disse beslutningene eksisterer, desto mer tyngdekraft får de. Til slutt betyr det å endre den opprinnelige beslutningen å endre alt som har samlet seg rundt den.
KI kjenner også den tyngdekraften. Et KI-verktøy jobber ut fra det som allerede finnes i systemet: når et sentralt designelement først er der, behandler hver KI-interaksjon etterpå det elementet som et faktum og fortsetter å bygge på det, og bygge på det, og bygge på det. Beslutningen gir gjenklang fremover gjennom mange flere beslutninger, og ingen mennesker går noen gang tilbake og ser på den opprinnelige. Hver generering legger til tyngdekraft.
Derfor betyr det noe at datamodellen er «skjelettet». Vi er ikke forsiktige fordi endring er dårlig. Vi er forsiktige fordi avhengigheter gjør endring dyrt.
Still to spørsmål
Section titled “Still to spørsmål ”Når jeg ser på en designbeslutning, stiller jeg to spørsmål:
Hvor vanskelig er dette å reversere?
Hvor mye kommer til å avhenge av det?
De henger sammen, men er ikke identiske. Noe kan være teknisk enkelt å endre, men ha hundrevis av konsumenter. Folk pleide å gi standardobjekter nye etiketter for tydelighetens skyld, for eksempel konto (Account) som «Kunde». Enkelt å gjøre. Så ville et annet system bruke kontoer til partnere, og det gikk ikke. Noe annet kan ha bare noen få konsumenter, men kreve en enorm migrering for å endres, som API-navnet til et objekt som refereres mange steder internt. Ingen utenfor ser det, men et feil navn fortsetter å forvirre teamet. Begge deler fortjener oppmerksomhet.
Tenk på noen vanlige databeslutninger:
- Hvilket Salesforce-objekt representerer dette forretningsbegrepet?
- Hva er den unike ID-en?
- Hvilket system er system of record (kildesystemet)?
- Kopieres disse dataene inn i Salesforce, eller hentes de et annet sted?
- Er dette ett objekt eller flere relaterte objekter?
- Hvem eier dataene, og hvor lenge beholder vi dem?
- Hva er standardgrensene våre for tilgang?
- Hvordan flyttes disse dataene mellom systemer?
Det er noe helt annet enn å bestemme hvor et felt skal vises på en Lightning-side. Sidedesign betyr også noe. Prisen for å ta feil er en annen.
Tenk på sprengradiusen
Section titled “Tenk på sprengradiusen ”En annen måte å tenke på reversibilitet er sprengradius (blast radius): hvis jeg endrer denne beslutningen, hva annet flytter seg?
Si at noe vi modellerte som et felt, egentlig må bli et underordnet objekt. Det er ikke bare en skjemaendring. Hva skjer med de eksisterende dataene? Med rapportene, integrasjonene som forventer det feltet, Apex og Flows som refererer til det, sikkerheten, analysene, en KI-agent med handlinger som avhenger av den opprinnelige strukturen?
Jo større radius, desto mer omhyggelig bør vi ta den opprinnelige beslutningen.
Det er også derfor arkitekter må se lenger enn sin egen del av systemet. Innenfra Salesforce kan en endring se enkel ut. Sett fra virksomheten kan den påvirke tolv andre systemer.
Beslutninger for virksomheten og beslutninger i Salesforce
Section titled “Beslutninger for virksomheten og beslutninger i Salesforce ”En dataarkitekt tenker på to nivåer.
Inne i Salesforce bestemmer vi objekter, relasjoner, nøkler, volum, tilgang, automatisering og hvordan data oppfører seg på plattformen.
På tvers av virksomheten stiller vi bredere spørsmål. Hvor bor Kunde egentlig? Hvem eier Produkt? Hvilket system oppretter en Ordre? Hva er vår autoritative identifikator? Hvilken informasjon kopieres mellom systemer, og hvilken blir der den er?
De to nivåene må henge sammen. Jeg har sett Salesforce-implementeringer der den interne modellen ga perfekt mening isolert sett, men ikke passet med virksomheten rundt. Det er ikke nok. Strukturene i Salesforce må være representert på virksomhetsnivå, og beslutninger i virksomheten må flyte tilbake inn i Salesforce.
Arkitektur er toveistrafikk.
Senk farten for de dyre beslutningene
Section titled “Senk farten for de dyre beslutningene ”En fare i teknologi er at de beslutningene som er enklest å implementere, kan se ut som de enkleste å ta. Det er ikke det samme.
Å lage et nytt egendefinert objekt er enkelt. Å lage et nytt felt er enkelt. Å koble til et nytt API blir stadig enklere, og KI gjør alt sammen enda enklere.
Men hvor enkelt noe er å implementere, sier nesten ingenting om hva den arkitektoniske beslutningen koster.
Før en beslutning som er vanskelig å reversere, senk farten lenge nok til å spørre: Hvilket problem løser vi egentlig? Hvilke alternativer vurderte vi? Hva antar vi? Hva skjer når volumet vokser, og når virksomheten endrer seg? Hva annet kommer til å avhenge av dette? Hva skjer hvis vi tar feil?
Vi trenger ikke seks måneders gjennomgang hver gang vi lager et objekt. Men vi trenger ettertanke i forhold til hva det koster å ta feil. Hvis det er et objekt for én enkelt avdeling eller ett delsystem, kan du gå raskere frem. Hvis det er referansedata, et sentralt kundeobjekt eller noe som brukes på tvers av systemer, ta deg tid til å tenke det gjennom.
Skriv ned hvorfor
Section titled “Skriv ned hvorfor ”Det finnes et annet problem med viktige beslutninger: folk glemmer hvorfor de ble tatt.
Noen ser på en arkitektur tre år senere og spør: «Hvorfor i all verden har noen designet det sånn?» Noen ganger er svaret at det var et dårlig design. Det skjer. Men noen ganger fantes det en veldig god grunn: en begrensning i plattformen som ikke lenger finnes, et regulatorisk krav, et annet system som ikke støttet den foretrukne løsningen, en avveining som ble akseptert bevisst for å nå en frist.
Hvis vi bare registrerer hva vi bestemte og ikke hvorfor, har den neste arkitekten ingen mulighet til å vite det.
Skriv ned viktige beslutninger. Det trenger ikke være et dokument på 50 sider. En nyttig beslutningslogg kan være veldig liten:
Kontekst: Hvilket problem løser vi?
Alternativer: Hvilke realistiske alternativer vurderte vi?
Beslutning: Hva valgte vi?
Konsekvenser: Hva vinner vi, og hva gir vi opp?
Eier: Hvem står ansvarlig for denne beslutningen?
Gjennomgang: Hvilken grunn eller dato bør få oss til å se på den igjen?
Verdien ligger ikke i dokumentet. Verdien ligger i å ta vare på resonnementet.
Og når en beslutning endres, ikke slett den opprinnelige. Erstatt den med en ny. Beslutningen som var riktig i 2027, er kanskje ikke riktig i 2030, fordi volumene, virksomheten, Salesforce og forståelsen vår endrer seg. Det jeg vil ta vare på, er historien: her var konteksten, her var beslutningen og hvorfor, her er hva som endret seg, og her er hva vi bestemmer nå. Det er langt mer verdifullt enn å late som om vi alltid visste svaret.
Utover eksamen: KI forkorter tiden fra beslutning til avhengighet. Et KI-verktøy kan foreslå en datamodell på sekunder, og deretter lage objektene, automatiseringen, integrasjonskoden og brukergrensesnittet oppå den. Før tok det måneder med utvikling før mye avhang av en tvilsom beslutning; nå kommer avhengighetene nesten med en gang. Så gjennomgå beslutningene under resultatet, ikke bare resultatet. KI kan hjelpe: den kan liste opp alternativer, utfordre antakelser og lage utkast til beslutningsloggen. Men det er fortsatt arkitekten som bestemmer, og jo vanskeligere beslutningen er å reversere, desto viktigere er det menneskelige skjønnet.
Vit hvilke beslutninger som betyr noe
Section titled “Vit hvilke beslutninger som betyr noe ”En av ferdighetene jeg vil at du skal utvikle, er å vite hvor du skal bruke oppmerksomheten din.
Ikke gjør hvert konfigurasjonsvalg om til et arkitekturtoppmøte.
Men ikke ta lettvint en beslutning som organisasjonen må leve med det neste tiåret.
Spør:
Hvor vanskelig blir dette å reversere?
Hvor mye kommer til å avhenge av det?
Hvis svarene er svært vanskelig og mye, har du sannsynligvis funnet en arkitektonisk beslutning.
Senk farten. Forstå kravet. Utforsk alternativene. Gjør avveiningene synlige. Ta beslutningen. Og skriv ned hvorfor.
Målet med arkitektur er ikke å ta beslutninger som aldri kan endres.
Målet er å kjenne igjen beslutningene der det kommer til å bli dyrt å ombestemme seg.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvilke beslutninger som er arkitektoniske: vanskelige å reversere, og med mye som avhenger av dem.
- Hvor mye oppmerksomhet hver beslutning får, i forhold til hva det koster å ta feil.
- Hvilke beslutninger som skrives ned, med kontekst, alternativer, konsekvenser, eier og tidspunkt for gjennomgang.
- Hvordan beslutningene i Salesforce henger sammen med virksomhetens.
Les mer
Section titled “Les mer ”- Object Relationships Overview (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): i en master-detail-relasjon følger detaljpostens tilgang og eierskap masterposten, og når du sletter en masterpost, slettes detaljpostene.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): en lookup-relasjon kan bare gjøres om til master-detail når hver post har en verdi i den; konverteringen endrer delingsmodellen (til Controlled by Parent), og relasjonstypen avgjør hvilke standard rapporttyper som er tilgjengelige.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelsk, kontrollert 2026-10-09; kontrollert på nytt 2026-10-12): sammendragsfelt (roll-up summary) finnes bare på master-detail-relasjoner, og må slettes før en master-detail-relasjon kan bli en lookup-relasjon.