Gregor Hohpe sostiene che il buon architetto non accumula potere né risposte: riduce complessità, fa emergere i trade-off e lascia decisioni più chiare di quelle che ha trovato.
Un buon architetto, secondo Gregor Hohpe, non si presenta come l’oracolo che ha sempre la risposta pronta. Fa l’opposto: rende gli altri più intelligenti, abbassa il rischio e traduce la complessità in scelte leggibili. Quando ci riesce, dice, il sistema “sembra solo funzionare”, e proprio per questo il suo lavoro passa quasi inosservato. Il problema è che molte organizzazioni premiano ancora chi moltiplica la complessità invece di chi la taglia.
L’architetto, per Gregor Hohpe, vale meno quando distribuisce risposte e più quando cambia la qualità della discussione. La sua immagine è semplice: non un oracolo, ma un amplificatore che rende il team più intelligente, rende visibili i trade-off e lascia decisioni migliori di quelle che ha trovato.
Gli architetti non dovrebbero cercare di essere le persone più intelligenti, ma dovrebbero rendere tutti gli altri più intelligenti. Come amplificatore.
Non vuoi essere una specie di oracolo, in cui le persone vengono con le loro domande e cercano risposte magiche.
Hohpe contrappone a quel modello una critica molto pratica: gli architetti peggiori, dice, si riconoscono dal linguaggio fumoso e dalla pretesa di detenere il potere decisionale. Le parole d’ordine, da cloud native a loosely coupled, per lui non bastano a giustificare la presenza di un architetto se non cambiano davvero il modo in cui il team ragiona. , ma anche la buona lo è, proprio perché alla fine tutto scorre senza attriti apparenti.
Gli architetti cattivi sono più facili da riconoscere. Sono quelli che sparano un sacco di buzzword.
La buona architettura è spesso quella in cui tutto va bene per magia e nessuno sa esattamente perché.
La sua definizione di valore è meno eroica e più operativa. Un architetto bravo, sostiene, assorbe contesto, scopre punti ciechi, mostra angoli diversi e fa emergere i compromessi impliciti che il team stava già accettando senza nominarli. Il punto non è apparire indispensabile, ma rendere la scelta più leggibile di quanto fosse prima.
Hohpe sposta il baricentro dell’architettura da una fantasia di controllo a un lavoro di riduzione del rischio. L’architetto, nel suo racconto, non serve a imporre una forma perfetta, ma a capire quali rischi contano davvero e quali, invece, sono solo abitudini organizzative travestite da prudenza.
Puoi assorbire il contesto, ciò che le persone ti spiegano, ma puoi scoprire i punti ciechi o aiutare le persone a vedere punti di vista diversi, angolazioni diverse, distillare i compromessi che stavano implicitamente facendo, ma di cui non erano consapevoli.
In una buona architettura si anticipano i rischi e li si mitiga. Se la scalabilità è un bisogno, allora ci si assicura che il sistema abbia quelle caratteristiche.
Da qui la sua distinzione più utile, tra complessità inerente e complessità auto-inferta. I sistemi distribuiti portano con sé retry, timeout, back pressure e retry storm, e Hohpe insiste che quella fisica non la si abolisce con una buona presentazione in PowerPoint.
I sistemi distribuiti hanno una complessità inerente. Devi affrontare retry e timeout, idempotenza, back pressure, retry storm. Questa è solo roba che esiste, c’è molta fisica, non puoi barare per uscirne.
Non fingere che la complessità non esista, ma rendi più facile per le persone gestirla, rendila intuitiva.
La disputa tecnica, per Gregor Hohpe, spesso comincia prima ancora della tecnologia. A far deragliare il confronto non è una differenza sostanziale sul merito, ma il fatto che due persone stiano guardando , senza rendersene conto. Per questo, dice, il compito dell’architetto non è arrivare subito con una soluzione, ma rendere condiviso il perimetro della discussione.
Ho così tante storie in cui le persone parlano di destra contro sinistra. Guardano un cilindro: uno dice che è un cerchio, l’altro che è un rettangolo.
La cosa davvero importante è avere un inquadramento comune. Così almeno capite lo spazio delle soluzioni.
Hohpe porta l’esempio classico di microservices: prima, dice, bisogna scomporre il termine. Per lui significa almeno due assi, la modularità nel design e la modularità a runtime, così il dibattito smette di essere “monolite contro microservizi” e diventa una griglia di scelte più ampia.
Hai quattro scelte. A questo punto hai ottenuto una soluzione molto più ampia: non è più monolite contro microservizi.
Io la chiamo mappare la mappa, costruire il telaio su cui discutiamo.
La mossa, nel suo racconto, è politica prima che tecnica: spostare il confronto da “la mia soluzione contro la tua” a “quale quadrante ci serve davvero”. Hohpe sostiene che così aumenta la probabilità di una decisione condivisa, perché il disaccordo resta dentro un linguaggio comune invece di frammentarsi in interpretazioni incompatibili.
Hohpe insiste su un punto semplice e difficile: il disegno non serve a rendere una decisione più elegante, serve a scoprire se due persone stanno davvero parlando della stessa cosa. Quando arrivano in stanza visioni del mondo diverse, trade-off non dichiarati e quella che lui chiama la coordinate system, la discussione verbale diventa una palude; una figura, dice, costringe a scegliere.
Io salto molto rapidamente a un disegno perché di solito arrivo solo in quei punti in cui il dibattito si è arenato, oppure c’è una decisione importante da prendere. Se le persone arrivano a una conclusione senza di me, allora non devo fare nulla, e va benissimo così.
Se non sai come appare la tua mappa del mondo, è molto difficile discutere il passato, perché non sai nemmeno su quale pianeta, di quale sistema di coordinate, ti trovi.
Il suo argomento è che gli schizzi funzionano perché rendono esplicite le relazioni che le frasi lasciano ambigue. Una linea tra due riquadri può dire molto più di una pagina di sfumature, e proprio per questo il modello visivo aiuta a far emergere il punto in cui il gruppo si sta fraintendendo.
Hohpe arriva persino a contare le possibilità di un foglio bianco come se fossero variabili tecniche. Con due pennarelli e un pezzo di carta, dice, si possono esprimere dimensione, forma, ombreggiatura, ordine, legenda, annidamento, posizione reciproca e altre dimensioni fino ad arrivare a circa 20; è lì che, nel suo racconto, affiorano i veri compromessi di progetto.
Non devi essere un artista dotato. Ho preso lezioni di disegno di design, e la verità è che è tutta pratica, tutta memoria muscolare.
Le immagini che disegniamo hanno significato, hanno semantica. Un arrow può voler dire flusso di dati, flusso di controllo, sincrono o asincrono, quindi devi saper passare avanti e indietro tra il lato strutturato e quello creativo.
L’architetto che resta aggiornato non è quello che ha accumulato più anni, ma quello che non si lascia intrappolare da decisioni vecchie di cinque, otto o dieci anni. Hohpe mette il punto proprio lì: l’esperienza tecnica può diventare una zavorra quando il contesto cambia più in fretta delle abitudini di giudizio. Il suo bersaglio non è la seniority in sé, ma la versione irrigidita della seniority, quella che continua a ragionare come se il terreno sotto i piedi fosse immobile.
Il più grande errore che vedo sul lato delle hard skill è chi era tecnico, ma cinque o dieci anni fa. Avere avuto quelle competenze può portarti a fare assunzioni sbagliate, perché la tua decisione o il tuo trade-off poteva essere buona allora, ma non lo è più.
Le competenze che devi tenere vive sono quelle di system design, capire i trade-off, gli aspetti operativi, l’osservabilità, il domain driven design. Sono tutte cose che devi continuare a fare.
La sua tesi è meno nostalgica di quanto sembri. Non dice che i fondamenti contano meno, dice che vanno riattivati nel presente, perché il costo dell’inerzia oggi è più alto. Da qui la sua insistenza su una figura che non conserva soltanto un archivio mentale, ma sa ancora leggere i sistemi, i compromessi e le dipendenze come se li vedesse per la prima volta.
Il mondo si muove troppo in fretta per fingere che non cambi nulla. Quella è una pessima assunzione nell’ambiente di oggi.
Non è più plausibile mantenere questa enorme mappa in cui tutto è dentro e tutto è aggiornato. Devi avere uno scopo, una direzione in mente, e poi andare a cercare ciò che serve davvero.
Qui entra in scena il passaggio che aggiorna davvero il ruolo dell’architetto: da cartographer a scout. Il primo pretende di fotografare tutto, il secondo torna con una mappa piccola, tardiva solo quanto basta e utile per decidere. Hohpe applica la stessa logica all’architettura enterprise, dove mantenere un grande catalogo del mondo rischia di essere una forma elegante di obsolescenza.
Nella parte finale, Hohpe sposta il mestiere dell’architetto dal disegno delle soluzioni al credito per poterle dire ad alta voce. La sua tesi è semplice e scomoda: senza credibilità, rete e giudizio sul trade-off, l’architetto finisce a produrre opinioni costose, non decisioni utili. Il valore non sta nel sembrare definitivo, ma nel saper dire quando una conclusione è solida, quando è solo moda e quando è troppo presto per pronunciarla.
Il cartografo non è più praticabile, perché le cose cambiano troppo in fretta. Serve molto di più uno scout, con uno scopo in mente, che torni con una mappa semplice ma tempestiva e utile.
Devi guadagnarti la fiducia prima di spenderla. Se vai in giro a dire a tutti che hanno torto, non aiuti nessuno e non impari più nulla.
Hohpe lega questa credibilità a un capitale più concreto: il capitale politico. L’architetto, dice, non dovrebbe usarlo per vincere ogni discussione, ma per spendere bene la propria influenza quando vede un progetto andare fuori strada. Il resto del tempo dovrebbe accumulare fiducia con consegne chiare, trasparenza e la capacità di non trasformare ogni divergenza in una guerra di posizione.
L’architetto ha poco potere diretto, ma ha molto potere di influenza. Come il giullare di corte, può dire la verità perché non ha un’agenda nascosta.
Il capitale politico si deve guadagnare prima di spenderlo, e va speso con intelligenza. Non puoi correre in giro dicendo che tutto è sbagliato.
Qual è il compito principale di un architetto?
Secondo Hohpe, il compito principale è rendere gli altri più intelligenti. L’architetto deve chiarire trade-off, svelare assunzioni e abbassare il rischio, non monopolizzare le decisioni.
Perché critica gli architetti-oracolo?
Li critica perché trasformano l’architettura in una fonte di risposte prestabilite. Per lui un buon architetto non dice “fate così”, ma aiuta il team a vedere meglio il problema.
Semplificare è sempre la scelta giusta?
No. Hohpe distingue tra complessità inevitabile, tipica dei sistemi distribuiti, e complessità inutile. La regola è semplificare fino al punto in cui il sistema resta fedele ai suoi vincoli reali.
Come si valuta una buona architettura?
Non con un ranking astratto. Hohpe dice che va valutata rispetto al lavoro che doveva svolgere, ai trade-off accettati e al contesto di business in cui è stata pensata.
Che rischio c’è nel fermarsi a competenze vecchie?
Il rischio è prendere decisioni sensate ma sulla base di vincoli superati. Per questo Hohpe insiste su rete, confronto continuo e contatto diretto con chi lavora sulle tecnologie nuove.
Building Evolutionary Architectures
Hohpe richiama il suo lavoro sulle piattaforme e sulla strategia di piattaforma mentre spiega perché la semplicità deve convivere con la complessità inerente dei sistemi distribuiti.
Sintesi assistita dall'AI del podcast di Beyond Coding, verificata sulla trascrizione originale.