Issue 10077
L’ADR non è l’architettura
Documentare una decisione aiuta, ma non sostituisce owner, mandato e review.
· 5 min
Obiettivo
Trattare l'ADR come memoria di una scelta già presa, non come sostituto del mandato o della review.
Prima la scelta, poi la sua memoria
Quando qualcuno dice «mettiamolo in un ADRGlossarioADRUn record durevole di una decisione architetturale e del ragionamento che l’ha guidata.Apri la voce completa», verifica innanzitutto se esiste davvero una decisione da registrare. Un ADR utile racconta il contesto, la scelta effettuata, le alternative considerate, i criteri applicati, l’owner e le conseguenze attese. Non conferisce però il mandatoGlossarioMandatoL'autorizzazione esplicita a occuparti di un risultato, con confini su cosa puoi decidere e cosa puoi solo rendere visibile.Apri la voce completa per decidere e non sostituisce una review quando questa è necessaria. Se owner o criteri mancano, non perfezionare il documento: porta il vuoto decisionale nella conversazione giusta. Chiedi chi possiede la decisione, quali qualità di sistema contano e quale sede deve validare i compromessi. Dopo la scelta, usa l’ADR per rendere comprensibile il ragionamento anche a chi non era nella stanza.
Documentare presto senza fingere di aver deciso
Scrivere presto una bozza rende esplicite ipotesi, alternative e domande aperte: migliora la discussione e riduce il rischio di perdere il contesto. Il costo nasce quando la bozza assume l’aspetto di una decisione approvata. Il team può interpretarla come mandato, implementare prematuramente e scoprire troppo tardi che sicurezza, operations o product non erano allineati. Aspettare troppo, al contrario, espone alla perdita delle motivazioni e a discussioni ripetute. Il compromesso pratico è distinguere chiaramente gli stati: una nota può essere «proposta» o «in review», mentre l’ADR diventa «accettato» solo quando owner, criteri e sede decisionale sono espliciti. Questa disciplina aggiunge un piccolo costo di processo, ma riduce ambiguità, rilavorazioni e decisioni senza responsabilità.
Il database scelto da un documento
Un programma enterprise deve scegliere il database per un nuovo servizio ordini. Il team prepara un ADR a favore di una tecnologia gestita e avvia l’implementazione, ma non è chiaro se la decisione appartenga al product owner, alla piattaforma o all’architecture board. Due settimane dopo, operations segnala vincoli di supporto regionale e finance evidenzia un modello di costo non valutato. Il problema non è che l’ADR fosse scritto male: mancavano owner, criteri e review. Il Solution Architect riconvoca la conversazione con i responsabili corretti, concorda i criteri — disponibilità, residenza dei dati, competenze operative e costo — e chiarisce chi decide. Solo dopo aggiorna l’ADR con la scelta, le alternative scartate e le conseguenze. Il documento diventa così memoria verificabile, non una scorciatoia per ottenere approvazione.
Per approfondire
Fonti autorevoli per approfondire il ruolo degli ADR e la separazione tra decisione, responsabilità e documentazione. • Documenting Architecture Decisions — Michael Nygard, Cognitect — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • Architecture Decision Records — Thoughtworks Technology Radar — https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records