Reversibilitetstesten
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)
Modul 3 af 7 i kapitlet Tænk som en dataarkitekt, kapitel 1 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Datamodellen er skelettet · Næste: Arkitektur er kunsten at afveje
Spørgsmålet, dette modul besvarer: Hvordan skelner du en arkitektonisk beslutning fra en almindelig?
Arkitekter træffer mange beslutninger.
Men ikke alle beslutninger er arkitektoniske beslutninger.
Det er en vigtig skelnen. Hvis vi behandler enhver beslutning som arkitektur, bruger vi al vores tid på at diskutere ting, der er forholdsvis nemme at ændre. Hvis vi ikke genkender de beslutninger, der virkelig er arkitektoniske, kan vi i dag træffe en beslutning på fem minutter, som tager fem år at rulle tilbage.
Så hvordan kender vi forskel?
Jeg kan godt lide at stille et enkelt spørgsmål:
Hvor svært bliver det at omgøre denne beslutning senere?
Jeg kalder det reversibilitetstesten (the Reversibility Test).
Jo sværere noget er at omgøre, og jo flere andre ting der kommer til at afhænge af det, desto mere arkitektonisk opmærksomhed fortjener det.
Nogle beslutninger er billige at ændre
Sektion kaldt “Nogle beslutninger er billige at ændre ”Lad os starte med noget enkelt.
Vi kalder et felt Customer Category (kundekategori). Seks måneder senere beslutter forretningen, at alle i virkeligheden kalder det Customer Segment (kundesegment). Vi ændrer etiketten. Der er måske noget dokumentation, der skal opdateres, og lidt brugeroplæring, men det er ikke nogen stor arkitektonisk begivenhed. Vi må dog leve med det oprindelige API-navn, for at ændre det har langt større konsekvenser. Så det betyder måske bare, at vi skal håndtere en ændret etiket og den forvirring, der kan følge med.
Vi traf en beslutning. Vi ombestemte os. Vi gik videre.
Sammenlign nu det med en anden beslutning.
Vi laver et id for kunder. Vi beslutter, hvad det betyder, hvilket format det har, og hvilket system der opretter det. Så udgiver vi det.
Salesforce bruger det. Datavarehuset bruger det. Integrationsplatformen bruger det. Kundeportalen bruger det. Fem andre applikationer begynder at gemme det. Rapporter og datapipelines bruger det. Måske ser kunderne det på et tidspunkt.
Tre år senere siger nogen:
Vi skulle nok ikke have designet id’et på den måde.
Det er en helt anden samtale.
Forskellen er ikke, at den ene beslutning er mere teknisk end den anden.
Forskellen er reversibilitet.
Sådan kan det ske. Lad os sige, at forretningen har bygget sine nøgler af en del af kundens navn plus et tal. Det virker i årevis, for ingen har nogensinde skullet ændre et navn. Så, et år eller mere senere, ændres et navn alligevel, og lige pludselig passer nøglerne ikke til det mønster, resten af dataene forventer. Det er en af grundene til, at nøgler ikke bør bære nogen betydning i sig selv.
Arkitektur skaber tyngdekraft
Sektion kaldt “Arkitektur skaber tyngdekraft ”En arkitektonisk beslutning har det med at samle ting omkring sig. Jeg tænker på det som tyngdekraft.
Vælg en objektmodel, og der bygges automatisering omkring den.
Vælg en nøgle, og andre systemer begynder at gemme den.
Vælg, hvor masterdata bor, og integrationer begynder at flyde til og fra det sted.
Vælg en delingsmodel, og forretningsprocesser begynder at afhænge af, hvem der kan se hvad.
Vælg et integrationsmønster, og systemer begynder at afhænge af dets timing og opførsel.
Jo længere de beslutninger eksisterer, desto mere tyngdekraft får de. Til sidst betyder det at ændre den oprindelige beslutning, at du skal ændre alt det, der har samlet sig omkring den.
AI mærker også den tyngdekraft. Et AI-værktøj arbejder ud fra det, der allerede er i systemet: når et centralt designelement først er der, behandler hver AI-interaktion derefter elementet som en kendsgerning og bygger videre på det, og videre, og videre. Beslutningen giver genlyd fremad gennem mange flere beslutninger, og intet menneske går nogensinde tilbage og tager den oprindelige op igen. Hver generering lægger mere til tyngdekraften.
Derfor betyder det noget, at datamodellen er »skelettet«. Vi er ikke forsigtige, fordi forandring er dårligt. Vi er forsigtige, fordi afhængigheder gør forandring dyr.
Stil to spørgsmål
Sektion kaldt “Stil to spørgsmål ”Når jeg kigger på en designbeslutning, stiller jeg to spørgsmål:
Hvor svært er det at omgøre?
Hvor meget kommer til at afhænge af det?
De hænger sammen, men de er ikke ens. Noget kan være teknisk nemt at ændre, men have hundredvis af forbrugere. Folk plejede at omdøbe standardobjekter for tydelighedens skyld, for eksempel konto (Account) til »Kunde«. Nemt at gøre. Så ville et andet system bruge konti til partnere, og det kunne det ikke. Noget andet har måske kun få forbrugere, men kræver en enorm migrering at ændre, som API-navnet på et objekt, der refereres til mange steder internt. Ingen udenfor ser det, men et forkert navn bliver ved med at forvirre teamet. Begge dele fortjener opmærksomhed.
Tænk på nogle almindelige databeslutninger:
- Hvilket Salesforce-objekt repræsenterer dette forretningsbegreb?
- Hvad er det unikke id?
- Hvilket system er system of record (kildesystem)?
- Kopieres disse data ind i Salesforce, eller tilgås de et andet sted?
- Er det ét objekt eller flere relaterede objekter?
- Hvem ejer dataene, og hvor længe gemmer vi dem?
- Hvad er vores standardgrænser for adgang?
- Hvordan bevæger disse data sig mellem systemer?
De er meget forskellige fra at beslutte, hvor et felt skal stå på en Lightning-side. Sidedesign betyder også noget. Prisen for at tage fejl er en anden.
Tænk på sprængradiussen
Sektion kaldt “Tænk på sprængradiussen ”En anden måde at tænke på reversibilitet er sprængradius (blast radius): hvis jeg ændrer denne beslutning, hvad flytter sig så ellers?
Forestil dig, at noget, vi modellerede som et felt, i virkeligheden skal være et underordnet objekt. Det er ikke bare en ændring af skemaet. Hvad sker der med de eksisterende data? Med rapporterne, integrationerne, der forventer det felt, Apex og Flows, der refererer til det, sikkerheden, analyserne, en AI-agent, hvis handlinger afhænger af den oprindelige struktur?
Jo større radius, desto mere omhyggeligt skal vi træffe den oprindelige beslutning.
Det er også derfor, arkitekter skal se ud over deres egen del af systemet. Inde fra Salesforce kan en ændring se nem ud. Set fra virksomheden kan den påvirke tolv andre systemer.
Virksomhedsbeslutninger og Salesforce-beslutninger
Sektion kaldt “Virksomhedsbeslutninger og Salesforce-beslutninger ”En dataarkitekt tænker på to niveauer.
Inde i Salesforce beslutter vi objekter, relationer, nøgler, volumen, adgang, automatisering, og hvordan data opfører sig på platformen.
På tværs af virksomheden stiller vi bredere spørgsmål. Hvor bor Kunde egentlig? Hvem ejer Produkt? Hvilket system opretter en Ordre? Hvad er vores autoritative id? Hvilke oplysninger kopieres mellem systemer, og hvilke bliver, hvor de er?
De to niveauer skal hænge sammen. Jeg har set Salesforce-implementeringer, hvor den interne model gav perfekt mening for sig selv, men ikke passede ind i virksomheden omkring den. Det er ikke nok. Strukturerne i Salesforce skal være repræsenteret på virksomhedsniveau, og virksomhedens beslutninger skal flyde tilbage ind i Salesforce.
Arkitektur er trafik i begge retninger.
Sæt farten ned ved de dyre beslutninger
Sektion kaldt “Sæt farten ned ved de dyre beslutninger ”En fare inden for teknologi er, at de beslutninger, der er nemmest at implementere, kan ligne de beslutninger, der er nemmest at træffe. Det er ikke det samme.
Det er nemt at lave endnu et brugerdefineret objekt. Det er nemt at lave endnu et felt. Det bliver nemmere at forbinde endnu et API, og AI gør det hele endnu nemmere.
Men hvor nemt noget er at implementere, siger os næsten intet om prisen på den arkitektoniske beslutning.
Før en beslutning, der er svær at omgøre, så sæt farten ned længe nok til at spørge: Hvilket problem løser vi egentlig? Hvilke alternativer overvejede vi? Hvad antager vi? Hvad sker der, når volumen vokser, og når forretningen ændrer sig? Hvad kommer ellers til at afhænge af det her? Hvad sker der, hvis vi tager fejl?
Vi behøver ikke seks måneders gennemgang, hver gang vi laver et objekt. Men vi har brug for eftertanke i forhold til, hvad det koster at tage fejl. Hvis det er et objekt til en enkelt afdeling eller et delsystem, kan du bevæge dig hurtigere. Hvis det er referencedata, et centralt kundeobjekt eller noget, der bruges på tværs af systemer, så tag dig tid til at tænke det igennem.
Skriv ned hvorfor
Sektion kaldt “Skriv ned hvorfor ”Der er et andet problem med vigtige beslutninger: folk glemmer, hvorfor de blev truffet.
Nogen kigger på en arkitektur tre år senere og spørger: »Hvorfor i alverden skulle nogen designe det sådan her?« Nogle gange er svaret, at det var et dårligt design. Det sker. Men nogle gange var der en rigtig god grund: en begrænsning i platformen, som ikke længere findes, et lovkrav, et andet system, der ikke kunne understøtte den foretrukne løsning, en afvejning, man bevidst accepterede for at nå en deadline.
Hvis vi kun noterer hvad vi besluttede og ikke hvorfor, har den næste arkitekt ingen mulighed for at vide det.
Skriv vigtige beslutninger ned. Det behøver ikke være et dokument på 50 sider. En nyttig beslutningslog kan være meget lille:
Kontekst: Hvilket problem løser vi?
Muligheder: Hvilke realistiske alternativer overvejede vi?
Beslutning: Hvad valgte vi?
Konsekvenser: Hvad vinder vi, og hvad giver vi afkald på?
Ejer: Hvem står til ansvar for denne beslutning?
Revision: Hvilken grund eller dato skal få os til at tage den op igen?
Værdien ligger ikke i dokumentet. Værdien ligger i at bevare begrundelsen.
Og når en beslutning ændres, så slet ikke den oprindelige. Erstat den med en ny. Den beslutning, der var rigtig i 2027, er måske ikke rigtig i 2030, for volumen, forretningen, Salesforce og vores forståelse ændrer sig alle sammen. Det, jeg vil bevare, er historien: her var konteksten, her var beslutningen og hvorfor, her er, hvad der ændrede sig, og her er, hvad vi beslutter nu. Det er langt mere værd end at lade, som om vi altid kendte svaret.
Ud over eksamen: AI forkorter tiden fra beslutning til afhængighed. Et AI-værktøj kan foreslå en datamodel på få sekunder og derefter oprette objekterne, automatiseringen, integrationskoden og brugergrænsefladen oven på den. Før tog det måneders udvikling, før ret meget afhang af en tvivlsom beslutning; nu kommer afhængighederne næsten med det samme. Så gennemgå beslutningerne under resultatet, ikke kun resultatet. AI kan hjælpe: den kan opstille muligheder, udfordre antagelser og lave et udkast til beslutningsloggen. Men det er stadig arkitekten, der beslutter, og jo sværere beslutningen er at omgøre, desto mere betyder den menneskelige dømmekraft.
Ved, hvilke beslutninger der betyder noget
Sektion kaldt “Ved, hvilke beslutninger der betyder noget ”En af de færdigheder, jeg vil have dig til at udvikle, er at vide, hvor du skal bruge din opmærksomhed.
Gør ikke ethvert konfigurationsvalg til et arkitekturtopmøde.
Men træf ikke henkastet en beslutning, som organisationen skal leve med det næste årti.
Spørg:
Hvor svært bliver det her at omgøre?
Hvor meget kommer til at afhænge af det?
Hvis svarene er meget svært og rigtig meget, har du sandsynligvis fundet en arkitektonisk beslutning.
Sæt farten ned. Forstå kravet. Undersøg alternativerne. Gør afvejningerne synlige. Træf beslutningen. Og skriv ned hvorfor.
Målet med arkitektur er ikke at træffe beslutninger, der aldrig kan ændres.
Målet er at genkende de beslutninger, hvor det bliver dyrt at ombestemme sig.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvilke beslutninger der er arkitektoniske: svære at omgøre, og meget afhænger af dem.
- Hvor meget opmærksomhed hver beslutning får, i forhold til prisen for at tage fejl.
- Hvilke beslutninger der skrives ned, med kontekst, muligheder, konsekvenser, ejer og revisionstidspunkt.
- Hvordan beslutningerne i Salesforce stemmer overens med virksomhedens.
Læs mere
Sektion kaldt “Læs mere ”- Object Relationships Overview (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): i en master-detail-relation følger detaljepostens adgang og ejerskab masterposten, og sletter du en masterpost, slettes dens detaljeposter.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): en lookup-relation kan kun konverteres til master-detail, når hver post har en værdi i den; konverteringen ændrer delingsmodellen (til Controlled by Parent), og relationstypen afgør, hvilke standardrapporttyper der er tilgængelige.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelsk, kontrolleret 2026-10-09; kontrolleret igen 2026-10-12): oversigtsfelter (roll-up summary) findes kun på master-detail-relationer og skal slettes, før en master-detail-relation kan blive til en lookup-relation.