Il processo di revisione

La revisione delle architetture deve essere eseguita in modo coerente, con un approccio che non colpevolizza nessuno, ma che incoraggia ad approfondire gli argomenti. Dovrebbe essere un processo leggero (di ore, non di giorni) più simile a una conversazione che non a un audit. Lo scopo della revisione di un'architettura è identificare dei problemi critici da affrontare o aree di miglioramento. Il risultato della revisione è un insieme di azioni volte a migliorare l'esperienza di utilizzo del carico di lavoro del cliente.

Come discusso nella sezione "Architettura", ogni membro del team deve prendersi la responsabilità della qualità della sua architettura. Consigliamo che i membri del team che hanno sviluppato l'architettura usino il Canone di architettura per eseguire costantemente la revisione della loro architettura, piuttosto che fare una riunione di revisione formale. Un approccio continuo permette ai membri del team di aggiornare le risposte man mano che l'architettura evolve e migliorare l'architettura di pari passo con le funzionalità.

Il canone di architettura AWS è allineato alla modalità interna di revisione dei sistemi e dei servizi di AWS. Si basa su un insieme di principi di progettazione che influenzano l'approccio architetturale e su domande che garantiscano che le persone non trascurino aree che spesso figurano nell'Analisi della causa principale (RCA). Ogni volta che si presenta un problema significativo con un sistema interno, un servizio AWS o un cliente, ci serviamo dell'RCA per vedere se possiamo migliorare il processo di revisione utilizzato.

Le revisioni devono essere applicate a tappe fondamentali nel ciclo di vita del prodotto, all'inizio della fase di progettazione per evitare decisioni unidirezionali« [ Molte decisioni sono reversibili e quindi bidirezionali. Queste decisioni possono usare un processo leggero. Le decisioni unidirezionali sono difficili o impossibili da annullare e richiedono un'ispezione maggiore prima di essere prese. ] »  che sono difficili da modificare e prima della data di implementazione. Una volta entrato in produzione, il carico di lavoro continuerà ad evolversi man mano che si aggiungono nuove caratteristiche e si modificano le implementazioni tecnologiche. L'architettura del carico di lavoro cambia nel tempo. Devi seguire le best practice di igiene informatica per interrompere il degrado delle caratteristiche man mano che fai evolvere l'architettura. Man mano che l'architettura cambia, dovresti seguire un insieme di processi di igiene informatica tra cui la revisione Well-Architected.

Se vuoi utilizzare la revisione come snapshot una tantum o misura indipendente, dovrai assicurarti che alla conversazione partecipino tutte le persone appropriate. Spesso ci rendiamo conto che le revisioni sono il primo momento in cui il team comprende per davvero quello che ha implementato. Un approccio che funziona bene per la revisione dei carichi di lavoro di un altro team consiste in una serie di conversazioni informali sull'architettura in cui ottenere le risposte alla maggior parte delle domande. Quindi puoi fare una o due riunioni di follow up in cui puoi fare chiarezza o approfondire le aree ambigue e il rischio percepito.

Ecco alcuni elementi suggeriti per le tue riunioni:

Dopo avere completato la revisione, dovresti avere un elenco di problemi a cui assegnare delle priorità sulla base del contesto aziendale. Dovrai anche prendere in considerazione l'impatto di tali problemi sul lavoro quotidiano del tuo team. Se affronti questi problemi in anticipo puoi liberare del tempo per lavorare sulla creazione di valore aziendale anziché dedicarlo a risolvere i problemi ricorrenti. Man mano che affronti i problemi, puoi aggiornare la revisione per vedere in che modo l'architettura sta migliorando.

Il valore di una revisione è evidente dopo averne eseguita una, ma all'inizio un nuovo team potrebbe essere contrario. Ecco alcune obiezioni da gestire per istruire il team sui vantaggi di una revisione:

Eseguendo più revisioni con i team della tua organizzazione, potresti identificare delle aree tematiche. Ad esempio, potresti notare che un gruppo di team ha gruppi di problemi in un pilastro o un argomento specifico. Puoi gestire tutte le tue revisioni in modo olistico e identificare tutti i meccanismi, la formazione o le riunioni con gli ingegneri responsabili che possono aiutare a risolvere i problemi tematici.