Issue 10022
Quando nessuno vuole decidere, l’architetto deve rendere la scelta esplicita
Trasformare allineamento generico in opzioni, conseguenze e ownership chiara
· 5 min
Obiettivo
Riconoscere ownership bloccata, chiarire i diritti decisionali e trasformare l’evitamento in una scelta concreta con opzioni, conseguenze e un owner esplicito.
Cosa fare quando il gruppo chiede “più allineamento” ma nessuno firma
In molte decisioni architetturali il problema non è la mancanza di opzioni, ma la mancanza di ownership. Come Solution Architect, il tuo lavoro non è forzare il consensoGlossarioConsensoUn impegno condiviso sufficiente a sostenere una decisione, non necessariamente una preferenza unanime.Apri la voce completa: è rendere il blocco visibile e portare la conversazione su tre domande concrete. Quali opzioni sono davvero realistiche? Che conseguenze porta ciascuna opzione? Chi ha il diritto e il dovere di decidere? Un formato semplice aiuta molto: presenta due o tre alternative, indica per ognuna impatti su costo, rischio, tempi e operatività, e chiudi con una raccomandazione chiara. Se la decisione è reversibile, proponi un esperimento controllato con criteri di revisione. Se è poco reversibile, chiedi un owner esplicito e una data entro cui decidere. Il punto chiave è distinguere consenso e responsabilità. Il consenso può ridurre attrito, ma non sostituisce un decision owner. Una buona decisione architetturaleGlossarioDecisione architetturaleUna scelta progettuale significativa il cui contesto e i cui effetti devono restare comprensibili nel tempo.Apri la voce completa non deve solo essere “accettata”: deve avere un perché, un responsabile, criteri per rivederla e conseguenze dichiarate.
Il trade-off vero: velocità di decisione contro comfort politico
Rendere esplicita la decisione ha vantaggi netti: evita il loop infinito dei meeting, riduce l’ambiguità e chiarisce chi si assume il rischio. Però ha anche un costo organizzativo. Quando chiedi un owner, stai togliendo la possibilità di restare nel vago. Questo può creare tensione, soprattutto se gli stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa preferiscono una neutralità apparente. Il trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa da gestire è questo: una decisione lenta e condivisa solo in superficie spesso protegge le relazioni nel breve periodo, ma accumula rischio tecnico e ritarda il delivery. Una decisione con ownership chiara può essere meno comoda, ma rende possibile l’esecuzione. In pratica, stai scegliendo tra comfort relazionale e affidabilità del percorso decisionale. La regola utile è semplice: se il costo di rimandare è basso e l’opzione è reversibile, puoi permetterti un esperimento. Se invece il ritardo aumenta il rischio o blocca altre scelte, serve una decisione esplicita, anche se non perfettamente consensuale.
Esempio realistico in un programma enterprise
Immagina un programma di modernizzazione in una banca: il team deve decidere se integrare un nuovo servizio tramite API sincrone o tramite eventi asincroni. Architettura, sicurezza e operations discutono da settimane. Tutti concordano che entrambe le soluzioni siano possibili, ma nessuno vuole essere l’owner della scelta perché teme impatti su SLA, compliance e supporto. Qui l’architetto può cambiare la forma della conversazione. Porta una sintesi con due opzioni, i relativi impatti e una raccomandazione motivata: ad esempio, eventi asincroni per ridurre couplingGlossarioCouplingIl grado in cui un componente dipende dalla conoscenza, dal timing o dai cambiamenti di un altro componente.Apri la voce completa e migliorare resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa, ma con costi maggiori di osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa e gestione della coda. Poi identifica il decision owner corretto, per esempio il responsabile del prodotto tecnico o il service owner, e chiede un sì/no entro una data precisa. Se la scelta è troppo rischiosa per essere definitiva, propone una prova limitata su un solo flusso, con criteri di successo chiari. Così il gruppo smette di discutere in astratto e decide su evidenze e conseguenze, non su preferenze personali.
Per approfondire
Fonti esterne autorevoli per approfondire il tema dei diritti decisionali e della documentazione delle decisioni architetturali. • DACI decision-making framework - Atlassian - https://www.atlassian.com/team-playbook/plays/daci • Documenting Architecture Decisions - Michael Nygard - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions