Il Test di Reversibilità
Disponibile anche in 28 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modulo 3 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: Il modello dati è lo scheletro · Successivo: L’architettura è l’arte dei trade-off
La domanda a cui risponde questo modulo: Come si distingue una decisione architetturale da una ordinaria?
Gli architetti prendono molte decisioni.
Ma non tutte sono decisioni architetturali.
È una distinzione importante. Se trattiamo ogni decisione come architettura, passeremo tutto il tempo a discutere di cose relativamente facili da cambiare. Se non riconosciamo le decisioni che sono davvero architetturali, oggi possiamo prendere in cinque minuti una decisione che richiederà cinque anni per essere sciolta.
Allora come facciamo a capire la differenza?
Mi piace porre una domanda semplice:
Quanto sarà difficile tornare indietro su questa decisione più avanti?
Lo chiamo Test di Reversibilità.
Più una cosa è difficile da invertire, e più altre cose ne dipenderanno, più attenzione architetturale merita.
Alcune decisioni costano poco da cambiare
Sezione intitolata “Alcune decisioni costano poco da cambiare ”Cominciamo da qualcosa di semplice.
Chiamiamo un campo Categoria cliente. Sei mesi dopo, il business decide che in realtà tutti lo chiamano Segmento cliente. Cambiamo l’etichetta. Forse c’è un po’ di documentazione da aggiornare e un po’ di formazione per gli utenti, ma non è un grande evento architetturale. Dovremo però convivere con il nome API originale, perché cambiarlo ha conseguenze molto più ampie. Quindi può voler dire solo gestire un cambio di etichetta, e la confusione che può portare con sé.
Abbiamo preso una decisione. Abbiamo cambiato idea. Siamo andati avanti.
Ora confrontala con una decisione diversa.
Stiamo creando un identificatore per i clienti. Decidiamo cosa significa, che formato usa e quale sistema lo crea. Poi lo pubblichiamo.
Salesforce lo usa. Il data warehouse lo usa. La piattaforma di integrazione lo usa. Il portale clienti lo usa. Altre cinque applicazioni iniziano a memorizzarlo. Report e pipeline di dati lo usano. Forse alla fine lo vedono anche i clienti.
Tre anni dopo, qualcuno dice:
Probabilmente non avremmo dovuto progettare l’identificatore così.
È una conversazione molto diversa.
La differenza non è che una decisione sia più tecnica dell’altra.
La differenza è la reversibilità.
Ecco come può succedere. Diciamo che il business ha costruito le sue chiavi con una parte del nome del cliente più un numero. Funziona per anni, perché nessuno ha mai dovuto cambiare un nome. Poi, un anno o più dopo, un nome cambia davvero, e all’improvviso le chiavi non corrispondono più allo schema che il resto dei dati si aspetta. È uno dei motivi per cui le chiavi non dovrebbero avere alcun significato intrinseco.
L’architettura crea gravità
Sezione intitolata “L’architettura crea gravità ”Una decisione architetturale tende ad accumulare cose intorno a sé. Io la penso come gravità.
Scegli un modello a oggetti, e ci si costruisce intorno l’automazione.
Scegli una chiave, e altri sistemi iniziano a memorizzarla.
Scegli dove risiedono i dati master, e le integrazioni iniziano a scorrere verso di loro e da loro.
Scegli un modello di condivisione, e i processi di business iniziano a dipendere da chi può vedere cosa.
Scegli un pattern di integrazione, e i sistemi iniziano a dipendere dai suoi tempi e dal suo comportamento.
Più a lungo esistono quelle decisioni, più gravità sviluppano. Alla fine, cambiare la decisione originale significa cambiare tutto ciò che vi si è accumulato intorno.
Anche l’IA sente questa gravità. Uno strumento di IA lavora a partire da ciò che è già nel sistema: una volta che un elemento chiave del progetto è lì, ogni interazione con l’IA successiva tratta quell’elemento come un fatto e continua a costruirci sopra, e a costruirci sopra, e a costruirci sopra. La decisione si riverbera in avanti attraverso molte altre decisioni, e nessun essere umano torna mai a rivedere quella originale. Ogni generazione aggiunge gravità.
Ecco perché conta che il modello dati sia “lo scheletro”. Non siamo prudenti perché il cambiamento sia un male. Siamo prudenti perché le dipendenze rendono il cambiamento costoso.
Poni due domande
Sezione intitolata “Poni due domande ”Quando esamino una decisione di progetto, pongo due domande:
Quanto è difficile tornare indietro?
Quanto ne dipenderà?
Sono collegate, ma non identiche. Una cosa può essere tecnicamente facile da cambiare ma avere centinaia di consumatori. Un tempo si rietichettavano gli oggetti standard per chiarezza, per esempio Account come “Cliente”. Facile da fare. Poi un altro sistema voleva usare gli Account per i Partner, e non poteva. Un’altra cosa può avere solo pochi consumatori ma richiedere una migrazione enorme per essere cambiata, come il nome API di un oggetto a cui si fa riferimento in molti punti interni. Nessuno all’esterno lo vede, ma se è sbagliato continua a confondere il team. Entrambe meritano attenzione.
Pensa ad alcune decisioni comuni sui dati:
- Quale oggetto Salesforce rappresenta questo concetto di business?
- Qual è l’identificatore univoco?
- Quale sistema è il system of record?
- Questi dati vengono copiati in Salesforce o si accede a essi altrove?
- È un oggetto solo o più oggetti correlati?
- Chi possiede i dati, e per quanto tempo li conserviamo?
- Quali sono i nostri confini di accesso predefiniti?
- Come si muovono questi dati tra i sistemi?
Sono molto diverse dal decidere dove compare un campo in una pagina Lightning. Anche il design della pagina conta. È il costo dell’errore a essere diverso.
Pensa al raggio d’impatto
Sezione intitolata “Pensa al raggio d’impatto ”Un altro modo di pensare alla reversibilità è il raggio d’impatto: se cambio questa decisione, cos’altro si muove?
Supponiamo che qualcosa che abbiamo modellato come campo debba in realtà diventare un oggetto figlio. Non è solo una modifica allo schema. Cosa succede ai dati esistenti? Ai report, alle integrazioni che si aspettano quel campo, all’Apex e ai Flow che vi fanno riferimento, alla sicurezza, alle analisi, a un agente IA le cui azioni dipendono dalla struttura originale?
Più ampio è il raggio, più attentamente dovremmo prendere la decisione originale.
È anche per questo che gli architetti devono guardare oltre la propria parte del sistema. Da dentro Salesforce, una modifica può sembrare facile. Dal punto di vista dell’azienda, può toccare altri dodici sistemi.
Decisioni aziendali e decisioni Salesforce
Sezione intitolata “Decisioni aziendali e decisioni Salesforce ”Un Data Architect pensa su due livelli.
Dentro Salesforce decidiamo oggetti, relazioni, chiavi, volumi, accessi, automazione e come si comportano i dati sulla piattaforma.
A livello aziendale poniamo domande più ampie. Dove risiede davvero il Cliente? Chi possiede il Prodotto? Quale sistema crea un Ordine? Qual è il nostro identificatore autorevole? Quali informazioni vengono copiate tra i sistemi, e quali restano dove sono?
I due livelli devono collegarsi. Ho visto implementazioni Salesforce in cui il modello interno aveva perfettamente senso di per sé ma non si adattava all’azienda intorno. Non basta. Le strutture Salesforce devono essere rappresentate a livello aziendale, e le decisioni aziendali devono tornare in Salesforce.
L’architettura è un traffico a doppio senso.
Rallenta sulle decisioni costose
Sezione intitolata “Rallenta sulle decisioni costose ”Un pericolo della tecnologia è che le decisioni più facili da implementare possono sembrare le più facili da prendere. Non sono la stessa cosa.
Creare un altro oggetto personalizzato è facile. Creare un altro campo è facile. Collegare un’altra API è sempre più facile, e l’IA rende tutto ancora più facile.
Ma la facilità di implementazione non ci dice quasi nulla sul costo della decisione architetturale.
Prima di una decisione difficile da invertire, rallenta abbastanza da chiederti: Quale problema stiamo davvero risolvendo? Quali alternative abbiamo considerato? Cosa stiamo dando per scontato? Cosa succede quando il volume cresce, e quando il business cambia? Cos’altro dipenderà da questo? Cosa succede se sbagliamo?
Non servono sei mesi di revisione ogni volta che creiamo un oggetto. Serve una riflessione proporzionata al costo dell’errore. Se è un oggetto per un solo reparto o sottosistema, puoi muoverti più in fretta. Se si tratta di dati di riferimento, di un oggetto cliente chiave o di qualcosa usato da più sistemi, prenditi il tempo di pensarci bene.
Scrivi il perché
Sezione intitolata “Scrivi il perché ”C’è un altro problema con le decisioni importanti: le persone dimenticano perché sono state prese.
Qualcuno guarda un’architettura tre anni dopo e chiede: “Perché mai qualcuno l’avrebbe progettata così?”. A volte la risposta è che era un cattivo progetto. Succede. Ma a volte c’era un’ottima ragione: un limite della piattaforma che non esiste più, un requisito normativo, un altro sistema che non poteva supportare l’approccio preferito, un trade-off accettato consapevolmente per rispettare una scadenza.
Se registriamo solo cosa abbiamo deciso e non perché, chi verrà dopo non ha modo di saperlo.
Per le decisioni importanti, mettilo per iscritto. Non serve un documento di 50 pagine. Un registro delle decisioni utile può essere molto piccolo:
Contesto: Quale problema stiamo risolvendo?
Opzioni: Quali alternative realistiche abbiamo considerato?
Decisione: Cosa abbiamo scelto?
Conseguenze: Cosa guadagniamo, e a cosa rinunciamo?
Responsabile: Chi risponde di questa decisione?
Revisione: Quale motivo o data dovrebbe spingerci a rivederla?
Il valore non è il documento. Il valore è conservare il ragionamento.
E quando una decisione cambia, non cancellare l’originale. Sostituiscila. La decisione giusta nel 2027 potrebbe non esserlo nel 2030, perché i volumi, il business, Salesforce e la nostra comprensione cambiano tutti. Ciò che voglio conservare è la storia: ecco il contesto, ecco la decisione e il perché, ecco cosa è cambiato, ed ecco cosa decidiamo ora. Vale molto di più che fingere di aver sempre saputo la risposta.
Oltre l’esame: l’IA accorcia il tempo tra la decisione e la dipendenza. Uno strumento di IA può proporre un modello dati in pochi secondi, poi creare sopra gli oggetti, l’automazione, il codice di integrazione e l’interfaccia utente. Una decisione discutibile richiedeva mesi di sviluppo prima che molto ne dipendesse; ora le dipendenze arrivano quasi subito. Quindi rivedi le decisioni sotto il risultato, non solo il risultato. L’IA può aiutare: può elencare opzioni, mettere in discussione le ipotesi e redigere il registro delle decisioni. Ma decide sempre l’architetto, e più la decisione è difficile da invertire, più conta il giudizio umano.
Sapere quali decisioni contano
Sezione intitolata “Sapere quali decisioni contano ”Una delle abilità che voglio che tu sviluppi è sapere dove investire la tua attenzione.
Non trasformare ogni scelta di configurazione in un vertice di architettura.
Ma non prendere alla leggera una decisione con cui l’organizzazione convivrà per il prossimo decennio.
Chiediti:
Quanto sarà difficile tornare indietro?
Quanto ne dipenderà?
Se le risposte sono molto difficile e molto, probabilmente hai trovato una decisione architetturale.
Rallenta. Capisci il requisito. Esplora le alternative. Rendi visibili i trade-off. Prendi la decisione. E scrivi il perché.
L’obiettivo dell’architettura non è prendere decisioni che non possano mai cambiare.
L’obiettivo è riconoscere le decisioni su cui cambiare idea costerà caro.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Quali decisioni sono architetturali: difficili da invertire, con molto che ne dipende.
- Quanta attenzione riceve ogni decisione, in proporzione al costo dell’errore.
- Quali decisioni vengono messe per iscritto, con contesto, opzioni, conseguenze, responsabile e momento di revisione.
- Come le decisioni Salesforce si allineano a quelle dell’azienda.
Per approfondire
Sezione intitolata “Per approfondire ”- Object Relationships Overview (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): in una relazione master-dettaglio l’accesso e la titolarità del dettaglio seguono il master, ed eliminare un master ne elimina i dettagli.
- Considerations for Object Relationships (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): una relazione di ricerca si converte in master-dettaglio solo quando ogni record vi ha un valore; la conversione cambia il modello di condivisione (in Controlled by Parent, controllato dal record principale), e il tipo di relazione decide quali tipi di report standard sono disponibili.
- Roll-Up Summary Field (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): i campi di riepilogo roll-up esistono solo sulle relazioni master-dettaglio, e vanno eliminati prima che una master-dettaglio possa diventare una relazione di ricerca.