Utilizzo dei record sulle decisioni architetturali per semplificare il processo decisionale tecnico per un progetto di sviluppo software

Darius Kunce e Dominik Goby, Amazon Web Services (AWS)

Marzo 2022 (cronologia dei documenti)

Questa guida introduce il processo ADR (Architectural Decision Record, record sulle decisioni architetturali) per i progetti di ingegneria del software. Gli ADR supportano l'allineamento del team, documentano le direzioni strategiche di un progetto o un prodotto e riducono gli sforzi decisionali ricorrenti e dispendiosi in termini di tempo.

Durante lo sviluppo di progetti e prodotti, i team di ingegneria del software devono prendere decisioni in materia di progettazione architetturale per raggiungere i propri obiettivi. Queste decisioni possono essere di natura tecnica, come la scelta di utilizzare il pattern CQRS (Command Query Responsibility Segregation, segregazione delle responsabilità delle query di comando), o legate al processo, come la scelta di utilizzare il flusso di lavoro GitFlow per gestire il codice sorgente. L'elaborazione di queste decisioni rappresenta un processo lungo e complesso, dal momento che i team devono giustificarle, documentarle e comunicarle alle parti interessate.

Durante l'elaborazione di tali decisioni architetturali, spesso emergono tre anti-pattern principali:

• Non si prende alcuna decisione, per paura di fare la scelta sbagliata.

• Non viene fornita alcuna spiegazione alla decisione adottata, motivo per cui non se ne comprendono i motivi. Questo fa sì che lo stesso argomento venga discusso più volte.

• La decisione non viene archiviata in un repository delle decisioni architetturali, quindi i membri del team non vengono informati dell'adozione di una decisione o se ne dimenticano.

È particolarmente importante affrontare questi anti-pattern durante il processo di sviluppo di un prodotto o di un progetto.

La documentazione, sotto forma di ADR, della decisione, del contesto e delle considerazioni che hanno portato ad adottarla consente agli stakeholder attuali e futuri di raccogliere informazioni sulle decisioni prese e sulle relative riflessioni. Ciò riduce i tempi di sviluppo del software e fornisce una documentazione migliore per i team futuri.

Obiettivi aziendali specifici

Gli ADR mirano a tre obiettivi aziendali:

• Allineano i membri del team attuali e futuri.

• Stabiliscono una direzione strategica per il progetto o il prodotto.

• Evitano gli anti-pattern decisionali tramite la definizione di un processo per documentare e comunicare correttamente le decisioni architetturali.

Gli ADR documentano il contesto della decisione per informare gli stakeholder futuri. Una raccolta di ADR rappresenta un'esperienza acquisita e offre una documentazione di riferimento. I membri del team o del progetto utilizzano la raccolta ADR per i progetti successivi e per la pianificazione delle funzionalità del prodotto. La possibilità di fare riferimento agli ADR riduce il tempo richiesto per lo sviluppo, le revisioni e l'elaborazione di decisioni architetturali. Grazie agli ADR, i membri dei team possono apprendere e approfondire le considerazioni espresse da altri team di sviluppo di progetti e prodotti.