Reversibilitetstestet
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)
Modul 3 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: Datamodellen är skelettet · Nästa: Arkitektur är konsten att göra avvägningar
Frågan den här modulen besvarar: Hur skiljer du ett arkitektoniskt beslut från ett vanligt?
Arkitekter fattar många beslut.
Men alla beslut är inte arkitektoniska beslut.
Det är en viktig skillnad. Om vi behandlar varje beslut som arkitektur kommer vi att lägga all vår tid på att diskutera saker som är relativt lätta att ändra. Om vi inte känner igen de beslut som verkligen är arkitektoniska kan vi i dag fatta ett beslut på fem minuter som tar fem år att reda ut.
Så hur ser vi skillnaden?
Jag brukar ställa en enkel fråga:
Hur svårt blir det att backa det här beslutet senare?
Jag kallar det reversibilitetstestet (the Reversibility Test).
Ju svårare något är att backa, och ju mer annat som kommer att bero på det, desto mer arkitektonisk uppmärksamhet förtjänar det.
En del beslut är billiga att ändra
Section titled “En del beslut är billiga att ändra ”Vi börjar med något enkelt.
Vi kallar ett fält Kundkategori. Sex månader senare kommer verksamheten fram till att alla egentligen kallar det Kundsegment. Vi ändrar etiketten. Det kan finnas lite dokumentation att uppdatera och lite användarutbildning, men det är ingen stor arkitektonisk händelse. Vi får dock leva med det ursprungliga API-namnet, eftersom en ändring av det får mycket större konsekvenser. Så det här kan helt enkelt innebära att hantera en etikettändring, och den förvirring som kan följa med den.
Vi fattade ett beslut. Vi ändrade oss. Vi gick vidare.
Jämför nu det med ett annat beslut.
Vi skapar en identifierare för kunder. Vi bestämmer vad den betyder, vilket format den har och vilket system som skapar den. Sedan publicerar vi den.
Salesforce använder den. Datalagret använder den. Integrationsplattformen använder den. Kundportalen använder den. Fem andra applikationer börjar lagra den. Rapporter och datapipelines använder den. Kanske ser kunderna den till slut.
Tre år senare säger någon:
Vi borde nog inte ha designat identifieraren på det sättet.
Det är ett helt annat samtal.
Skillnaden är inte att det ena beslutet är mer tekniskt än det andra.
Skillnaden är reversibilitet.
Så här kan det gå till. Säg att verksamheten har byggt sina nycklar av en del av kundens namn plus ett nummer. Det fungerar i flera år, eftersom ingen någonsin har behövt byta namn. Sedan, ett år eller mer senare, byts ett namn faktiskt, och plötsligt stämmer nycklarna inte med det mönster som resten av data förväntar sig. Det är ett av skälen till att nycklar inte ska bära någon inneboende betydelse.
Arkitektur skapar gravitation
Section titled “Arkitektur skapar gravitation ”Ett arkitektoniskt beslut tenderar att samla saker runt sig. Jag ser det som gravitation.
Välj en objektmodell, så byggs automatisering runt den.
Välj en nyckel, så börjar andra system lagra den.
Välj var masterdata bor, så börjar integrationer flöda till och från den platsen.
Välj en delningsmodell, så börjar affärsprocesser bero på vem som kan se vad.
Välj ett integrationsmönster, så börjar system bero på dess timing och beteende.
Ju längre de besluten finns, desto mer gravitation får de. Till slut betyder en ändring av det ursprungliga beslutet att du måste ändra allt som har samlats runt det.
AI känner också av den gravitationen. Ett AI-verktyg utgår från det som redan finns i systemet: när ett centralt designelement väl är på plats behandlar varje AI-interaktion därefter det elementet som fakta och fortsätter bygga på det, och bygga på det, och bygga på det. Beslutet ekar framåt genom många fler beslut, och ingen människa går någonsin tillbaka och ser över det ursprungliga. Varje generering ökar gravitationen.
Det är därför det spelar roll att datamodellen är ”skelettet”. Vi är inte försiktiga för att förändring är dåligt. Vi är försiktiga för att beroenden gör förändring dyr.
Ställ två frågor
Section titled “Ställ två frågor ”När jag tittar på ett designbeslut ställer jag två frågor:
Hur svårt är det här att backa?
Hur mycket kommer att bero på det?
De hänger ihop, men de är inte identiska. Något kan vara tekniskt lätt att ändra men ha hundratals konsumenter. Förr döpte man om standardobjekt för tydlighetens skull, till exempel konto (Account) till ”Kund”. Lätt att göra. Sedan ville ett annat system använda konton för partner, och det gick inte. Något annat kan ha bara några få konsumenter men kräva en enorm migrering för att ändras, som API-namnet på ett objekt som refereras på många ställen internt. Ingen utanför ser det, men ett felaktigt namn fortsätter att förvirra teamet. Båda förtjänar uppmärksamhet.
Tänk på några vanliga databeslut:
- Vilket Salesforce-objekt representerar det här affärsbegreppet?
- Vad är den unika identifieraren?
- Vilket system är system of record (källsystemet)?
- Kopieras de här data in i Salesforce eller nås de någon annanstans?
- Är det här ett objekt eller flera relaterade objekt?
- Vem äger data, och hur länge sparar vi dem?
- Vilka är våra grundläggande åtkomstgränser?
- Hur rör sig de här data mellan system?
Det är något helt annat än att bestämma var ett fält visas på en Lightning-sida. Siddesign spelar också roll. Kostnaden för att ha fel är annorlunda.
Tänk på sprängradien
Section titled “Tänk på sprängradien ”Ett annat sätt att tänka på reversibilitet är sprängradie (blast radius): om jag ändrar det här beslutet, vad mer rör sig?
Anta att något vi modellerade som ett fält egentligen måste bli ett underordnat objekt. Det är inte bara en schemaändring. Vad händer med befintliga data? Med rapporterna, integrationerna som förväntar sig det fältet, Apex och Flows som refererar till det, säkerheten, analysen, en AI-agent vars handlingar beror på den ursprungliga strukturen?
Ju större radie, desto noggrannare ska vi fatta det ursprungliga beslutet.
Det är också därför arkitekter måste se bortom sin egen del av systemet. Inifrån Salesforce kan en ändring se lätt ut. Sett från företaget kan den påverka tolv andra system.
Företagsbeslut och Salesforce-beslut
Section titled “Företagsbeslut och Salesforce-beslut ”En dataarkitekt tänker på två nivåer.
Inne i Salesforce bestämmer vi objekt, relationer, nycklar, volym, åtkomst, automatisering och hur data beter sig på plattformen.
Över hela företaget ställer vi bredare frågor. Var bor kunden egentligen? Vem äger produkten? Vilket system skapar en order? Vilken är vår auktoritativa identifierare? Vilken information kopieras mellan system, och vilken stannar där den är?
De två nivåerna måste hänga ihop. Jag har sett Salesforce-implementationer där den interna modellen var helt logisk i sig men inte passade företaget runt den. Det räcker inte. Strukturerna i Salesforce måste finnas representerade på företagsnivå, och företagsbesluten måste flöda tillbaka in i Salesforce.
Arkitektur är trafik i båda riktningarna.
Sakta ner för de dyra besluten
Section titled “Sakta ner för de dyra besluten ”En fara inom tekniken är att de beslut som är lättast att implementera kan se ut som de beslut som är lättast att fatta. Det är inte samma sak.
Att skapa ett anpassat objekt till är lätt. Att skapa ett fält till är lätt. Att koppla in ett API till blir allt lättare, och AI gör alltihop ännu lättare.
Men hur lätt något är att implementera säger nästan ingenting om vad det arkitektoniska beslutet kostar.
Inför ett beslut som är svårt att backa, sakta ner tillräckligt länge för att fråga: Vilket problem löser vi egentligen? Vilka alternativ övervägde vi? Vad antar vi? Vad händer när volymen växer, och när verksamheten förändras? Vad mer kommer att bero på det här? Vad händer om vi har fel?
Vi behöver inte sex månaders granskning varje gång vi skapar ett objekt. Men vi behöver eftertanke i proportion till vad det kostar att göra fel. Om det är ett objekt för en enda avdelning eller ett delsystem kan du röra dig snabbare. Om det är referensdata, ett centralt kundobjekt eller något som används mellan system, ta dig tid att tänka igenom det.
Skriv ner varför
Section titled “Skriv ner varför ”Det finns ett annat problem med viktiga beslut: folk glömmer varför de fattades.
Någon tittar på en arkitektur tre år senare och frågar: ”Varför skulle någon designa det så här?” Ibland är svaret att det var en dålig design. Det händer. Men ibland fanns det ett mycket bra skäl: en begränsning i plattformen som inte längre finns, ett regulatoriskt krav, ett annat system som inte klarade det föredragna angreppssättet, en avvägning som medvetet accepterades för att hålla en deadline.
Om vi bara dokumenterar vad vi bestämde och inte varför, har nästa arkitekt ingen möjlighet att veta.
För betydande beslut: skriv ner det. Det behöver inte vara ett dokument på 50 sidor. En användbar beslutslogg kan vara väldigt liten:
Sammanhang: Vilket problem löser vi?
Alternativ: Vilka realistiska alternativ övervägde vi?
Beslut: Vad valde vi?
Konsekvenser: Vad vinner vi, och vad ger vi upp?
Ägare: Vem står till svars för det här beslutet?
Översyn: Vilket skäl eller datum ska få oss att se över det igen?
Värdet ligger inte i dokumentet. Värdet ligger i att bevara resonemanget.
Och när ett beslut ändras, radera inte det ursprungliga. Ersätt det med ett nytt. Beslutet som var rätt 2027 kanske inte är rätt 2030, eftersom volymerna, verksamheten, Salesforce och vår förståelse alla förändras. Det jag vill behålla är berättelsen: här var sammanhanget, här var beslutet och varför, här är vad som ändrades, och här är vad vi bestämmer nu. Det är mycket mer värdefullt än att låtsas att vi alltid visste svaret.
Bortom provet: AI kortar tiden från beslut till beroende. Ett AI-verktyg kan föreslå en datamodell på några sekunder och sedan skapa objekten, automatiseringen, integrationskoden och användargränssnittet ovanpå den. Förr tog ett tveksamt beslut månader av utveckling innan mycket berodde på det; nu kommer beroendena nästan direkt. Så granska besluten under resultatet, inte bara resultatet. AI kan hjälpa till: den kan lista alternativ, utmana antaganden och skriva ett utkast till beslutsloggen. Men det är fortfarande arkitekten som bestämmer, och ju svårare beslutet är att backa, desto mer spelar det mänskliga omdömet roll.
Vet vilka beslut som spelar roll
Section titled “Vet vilka beslut som spelar roll ”En av färdigheterna jag vill att du utvecklar är att veta var du ska lägga din uppmärksamhet.
Gör inte varje konfigurationsval till ett arkitekturtoppmöte.
Men fatta inte lättvindigt ett beslut som organisationen kommer att leva med det kommande decenniet.
Fråga:
Hur svårt blir det här att backa?
Hur mycket kommer att bero på det?
Om svaren är mycket svårt och mycket, har du troligen hittat ett arkitektoniskt beslut.
Sakta ner. Förstå kravet. Utforska alternativen. Gör avvägningarna synliga. Fatta beslutet. Och skriv ner varför.
Målet med arkitektur är inte att fatta beslut som aldrig kan ändras.
Målet är att känna igen de beslut där det kommer att bli dyrt att ändra sig.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”- Vilka beslut som är arkitektoniska: svåra att backa, med mycket som beror på dem.
- Hur mycket uppmärksamhet varje beslut får, i proportion till vad det kostar att ha fel.
- Vilka beslut som skrivs ner, med sammanhang, alternativ, konsekvenser, ägare och tidpunkt för översyn.
- Hur besluten i Salesforce stämmer överens med företagets.
Utforska vidare
Section titled “Utforska vidare ”- Object Relationships Overview (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): i en master-detail-relation följer detaljpostens åtkomst och ägarskap huvudposten, och om huvudposten raderas raderas dess detaljposter.
- Considerations for Object Relationships (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): en lookup-relation kan konverteras till master-detail bara när varje post har ett värde i den; konverteringen ändrar delningsmodellen (till Controlled by Parent), och relationstypen avgör vilka standardrapporttyper som finns tillgängliga.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-09; kontrollerad igen 2026-10-12): sammanställningsfält (roll-up summary) finns bara på master-detail-relationer och måste raderas innan en master-detail-relation kan bli en lookup-relation.