Arrivi dopo le promesse

Date e slogan già comunicati non sono automaticamente vincoli: rendili ipotesi verificabili prima di tradurli in architettura.

Obiettivo

Trattare date e slogan già comunicati come ipotesi da rendere esplicite, non come requisiti architetturali.

practice

Non firmare il passato

Quando entri in un programma già raccontato, frasi come “go live a novembre”, “stesso perimetro” o “nessun impatto sul core” possono sembrare requisiti. Spesso sono invece impegni comunicati prima che fattibilità, dipendenze e rischi fossero verificati. Il tuo compito non è accettarli in silenzio né contestarli per principio: è renderli espliciti come ipotesi. Per ogni promessa, registra la formulazione precisa, chi può confermarla, quali evidenze la sostengono, entro quando va verificata, quale eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa la rende falsa e quale decisione prendere se non regge. Finché questi elementi mancano, non trattarla come Constraint nel disegno architetturale: trattala come debito decisionaleGlossarioDebito decisionaleUn impegno già comunicato senza owner, criterio di fallimento e possibilità di revert.Apri la voce completa da risolvere.

trade-offs

Fiducia oggi o credibilità domani

Accettare la narrazione esistente riduce l'attrito iniziale e può rassicurare sponsorGlossarioSponsorChi può sostenere o fermare il lavoro perché ne porta il rischio o il risultato, distinto da chi ha solo aperto la richiesta.Apri la voce completa e delivery team, ma sposta il rischio dentro l'architettura: scorciatoie, accoppiamenti eccessivi, testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa compressi e capacità sovrastimata diventano il prezzo nascosto della promessa. Riaprirla crea invece una conversazione scomoda e può rendere visibile un conflitto tra data, perimetro e qualità. Il guadagno è una decisione più credibile e attribuibile. Non tutte le promesse vanno invalidate: alcune possono diventare veri vincoli, purché abbiano un owner consapevole delle conseguenze e una base di evidenza sufficiente. Il compromesso corretto non è tra ottimismo e pessimismo, ma tra impegno informato e rischio implicito.

enterprise-example

Un go live già annunciato

Un'azienda assicurativa ha comunicato il lancio a novembre di un nuovo portale intermediari, mantenendo invariati perimetro e sistemi core. Il Solution Architect entra quando la data è già nei materiali per la rete commerciale. Invece di progettare subito per rispettare lo slogan, scompone la promessa: disponibilità delle API del core, completamento della migrazione anagrafica, finestra dei test end-to-end e capacità del team operativo. Emerge che le API definitive arriveranno troppo tardi. Lo sponsor può allora scegliere in modo esplicito: ridurre il primo perimetro, introdurre temporaneamente un adapter con costo di dismissione, spostare la data oppure accettare un rischio operativo quantificato. La data non viene ignorata, ma smette di essere un requisito invisibile e diventa parte di una decisione tracciabile.

practice

Una verifica in quattro mosse

Porta in workshop una tabella con quattro domande per ogni impegno già comunicato: chi ne è owner, quale evidenza lo rende credibile, quale soglia indica che non è più sostenibile e quale opzione di revisione è autorizzata. Collega poi le risposte alle decisioni architetturali coinvolte, per esempio integrazione temporanea, riduzione del perimetro, requisiti di resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa o sequenza della migrazione. Chiudi l'incontro assegnando owner e data di verifica. In questo modo la conversazione non diventa un generico “non ce la faremo”, ma una scelta concreta fra alternative, conseguenze e responsabilità.

references

Per approfondire

Fonti autorevoli per strutturare ipotesi e decisioni architetturali in modo verificabile. • Documenting Architecture Decisions - Michael Nygard, Cognitect - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • Architecture Decision Records - Architectural Decision Records organization - https://adr.github.io/

Da ricordare

Una promessa già comunicata diventa un vincolo architetturale solo quando ha owner, evidenza, criterio di fallimento e una decisione esplicita su cosa fare se non regge.

Per la prossima riunione

Quale promessa del programma sto trattando come Constraint senza averne ancora verificato owner, evidenze e conseguenze architetturali?

Una domanda per te