I primi 30 giorni non servono a disegnare

Prima della target architecture, chiarisci quali decisioni hanno un owner, quali sono ancora incerte e quali esistono solo nelle slide.

Obiettivo

Distinguere cosa puoi decidere, cosa puoi solo rendere visibile e cosa non ha ancora un owner, prima di disegnare una target architecture.

practice

Il primo deliverable è una mappa decisionale

Nei primi 30 giorni, la pressione a produrre una target architecture è quasi inevitabile. Il rischio principale, però, non è creare un diagramma imperfetto: è trasformare ipotesi e preferenze in decisioni apparentemente approvate. Prima di disegnare, elenca le scelte che condizionano davvero la soluzione, come piattaforma, confini di integrazione, modello operativo, ownership dei dati e requisiti non funzionali. Classifica ciascuna scelta in una sola categoria: già decisa, se esistono un owner e una traccia verificabile; incerta, se c'è una direzione ma mancano criteri, evidenze o condizioni di revisione; senza owner, se viene trattata come vincoloGlossarioVincoloUna condizione che limita lo spazio delle soluzioni praticabili e non può essere semplicemente ignorata.Apri la voce completa ma nessuno ha l'autorità per confermarla o fermarla. Per ogni voce registra anche evidenza, responsabile, impatto e prossima azione. Questa mappa non sostituisce 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: mostra dove il mandato esiste e dove deve ancora essere costruito. Il disegno può arrivare subito dopo, distinguendo chiaramente decisioni confermate e assunzioni.

trade-offs

Meno velocità apparente, più affidabilità decisionale

Rimandare il diagramma definitivo può sembrare una perdita di slancio e lasciare gli stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa senza l'immagine rassicurante che si aspettano. In cambio, riduce il rischio che una scelta non autorizzata diventi un impegno verso il board, il delivery team o un fornitore. La mappa richiede tempo e può far emergere conflitti organizzativi scomodi, ma rende espliciti responsabilità, dipendenze e debito decisionaleGlossarioDebito decisionaleUn impegno già comunicato senza owner, criterio di fallimento e possibilità di revert.Apri la voce completa. Attenzione anche all'eccesso opposto: non serve aspettare che ogni dettaglio sia risolto. Puoi produrre viste esplorative, purché siano dichiarate come ipotesi e riportino owner, evidenze mancanti e condizioni che potrebbero modificarle. Il guadagno non è la certezza assoluta, ma la tracciabilità delle scelte.

enterprise-example

Il vendor nominato non è ancora un vincolo

Un gruppo assicurativo avvia la modernizzazione della gestione sinistri e comunica al board il nome di una piattaforma SaaS. Al Solution Architect viene chiesta entro due settimane una target architecture completa. Durante la mappatura emerge che l'acquisto non è stato approvato, il perimetro di integrazione non è definito, il responsabile dei dati non ha accettato il modello di residenza e nessuno possiede la decisione sull'identità dei partner esterni. Trattare il vendor come un constraint produrrebbe un'architettura precisa ma fondata su un mandato inesistente. L'architetto presenta invece tre gruppi: decisioni confermate, come gli obblighi normativi; scelte incerte, come piattaforma e strategia di integrazione; decisioni senza owner, come l'accesso dei partner. Il comitato assegna gli owner e concorda le scadenze. La prima vista architetturale viene quindi costruita con parti stabili e varianti esplicite, evitando di impegnare il programma su scelte non autorizzate.

references

Per approfondire

Fonti autorevoli per approfondire la documentazione delle decisioni e l'assegnazione delle responsabilità. • Documenting Architecture Decisions — Michael Nygard, Cognitect — https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions • RACI Responsible, Accountable, Consulted, Informed — Project Management Institute — https://www.pmi.org/learning/library/raci-model-effective-project-management-8041

Da ricordare

Prima di firmare una target architecture con un diagramma, separa ciò che è deciso da ciò che è incerto o senza owner: nei primi 30 giorni, rendere visibili i diritti decisionali vale più di una precisione grafica prematura.

Per la prossima riunione

Quali elementi della target architecture che sto per presentare sono decisioni verificabili, quali sono ipotesi e quali non hanno ancora un owner con l'autorità di confermarli?

Una domanda per te