Issue 10066
· 5 min
Il costo come requisito architetturale
Se non lo rendi esplicito, lo stai solo spostando nel tempo o tra team.
Obiettivo
Valutare il costo come vincolo architetturale esplicito, collegando TCO, cost of change, resilienza, capacità e dipendenze ai trade-off tecnici.
practice
Rendere il costo parte della decisione
Quando valuti un’opzione architetturale, non fermarti al budget iniziale o al costo infrastrutturale. Tratta il costo come un requisito esplicito: quanto costa costruire, quanto costa operare, quanto costa cambiare, quanto costa proteggere la resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa e quanto dipendi da fornitori o team specifici. In pratica, questo significa chiedere a ogni proposta di mostrare il suo cost envelope: quali sono le assunzioni, quali variabili lo fanno crescere, quali soglie fanno cambiare la convenienza. Se il team non ha ancora numeri precisi, usa ordini di grandezza e scenari. È molto più utile dire “oltre X transazioni o Y team questa soluzione cambia classe di costo” che fingere una precisione che non esiste. Il punto non è scegliere sempre la soluzione più economica. Il punto è capire quale prezzo stai pagando per ottenere una certa capacità architetturale, e chi lo pagherà nel tempo.
trade-offs
Il vero trade-off non è costo contro qualità
Di solito il trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa reale è tra spesa oggi e costo complessivo domani. Una soluzione più economica in avvio può diventare costosa da operare o da modificare; una più robusta può richiedere più investimento iniziale ma ridurre incidenti, interventi manuali e attrito organizzativo. I punti da esplicitare sono almeno quattro: costo di run, costo di change, burden operativo e dipendenze. Se aumenti resilienza, spesso aumenti anche complessità e costo operativo. Se riduci lock-in, potresti pagare in efficienza o integrazione. Se ottimizzi per velocità di delivery, potresti introdurre costi futuri di mantenimento più alti. La domanda utile non è “questa architettura costa poco?”, ma “quale costo stiamo scegliendo di assorbire, e quale rischio stiamo accettando in cambio?”.
enterprise-example
Esempio: piattaforma digitale con crescita non lineare
Un’organizzazione enterprise lancia un nuovo servizio digitale e deve scegliere tra una piattaforma gestita standard e una soluzione più personalizzata su stack proprietario. La prima ha un costo iniziale contenuto e accelera il go-live, ma introduce limiti su scaling, osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa e personalizzazione dei flussi. La seconda costa di più all’inizio, ma offre più controllo su performance, resilienza e roadmap. Nel meeting architetturale, la discussione cambia quando il team porta un cost envelope: traffico atteso, numero di team che dovranno intervenire, costi di licensing, effort operativo, impatto di un outage e costo di un eventuale refactoring. A quel punto emerge che la scelta “più economica” nei primi sei mesi potrebbe diventare più cara dopo il primo anno, quando aumentano volumi, integrazioni e richieste di change. Questa è la situazione tipica in cui il costo va trattato come requisito: non per bloccare l’evoluzione, ma per evitare che una decisione tecnicamente elegante crei un debito economico poco visibile.
references
Per approfondire
Riferimenti esterni autorevoli per approfondire come documentare le decisioni e leggere il costo come proprietà del design. • Documenting Architecture Decisions - Michael Nygard - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions • Architecture Tradeoff Analysis Method (ATAM) - SEI Carnegie Mellon University - https://insights.sei.cmu.edu/blog/the-architecture-tradeoff-analysis-method-atam/ • Cloud FinOps Framework - FinOps Foundation - https://www.finops.org/framework/
Da ricordare
Se il costo non è un requisito architetturale esplicito, finirà per emergere come sorpresa operativa, vincolo di cambio o dipendenza difficile da correggere.
Per la prossima riunione
Nel tuo prossimo architecture review, quale costo oggi è implicito e dovresti rendere esplicito: run cost, change cost, burden operativo o lock-in?
Una domanda per te