Technology Radar

Pubblicazione periodica semestrale di Thoughtworks — raccontata nella sua genesi e nel suo funzionamento interno da Martin Fowler (intervistato da The Pragmatic Engineer nel novembre 2025) — che mappa tecnologie, tecniche, piattaforme e strumenti osservati sul campo dai circa 10.000 tecnologi dell'azienda nei progetti con i clienti di tutto il mondo. ¹

Origine: Rebecca Parsons, Daryl Smith e la pubblicazione di default

Il Technology Radar nasce poco più di dieci anni fa dall'ethos di Thoughtworks di coinvolgere direttamente i practitioner tecnici nella guida dell'azienda e di condividere pubblicamente i propri strumenti interni: ¹

1. Il Technology Advisory Board di Rebecca Parsons: diventata CTO di Thoughtworks, Rebecca Parsons volle creare un technology advisory board che si riunisse due o tre volte l'anno per tenerla connessa con ciò che accadeva concretamente nei progetti (includendovi anche Martin Fowler in quanto volto pubblico della società). ¹
2. L'idea e la metafora di Daryl Smith: durante uno di questi incontri, Daryl Smith (allora technical assistant di Rebecca Parsons) osservò che con tanti progetti attivi serviva un quadro d'insieme di quali tecnologie venissero usate e di quanto si rivelassero utili, così da far circolare meglio le buone idee in un'azienda che già con poche migliaia di persone faticava a diffonderle internamente. Smith propose la metafora del radar e la suddivisione nei suoi anelli (rings) concentrici — da Adopt (raccomandazione forte di adozione) fino agli anelli di sperimentazione, valutazione (Assess) e Hold (invito alla cautela su tecnologie con cui non si stanno vedendo buoni risultati). ¹
3. Rendere pubblico tutto per default: fedele all'abitudine di Thoughtworks di pubblicare all'esterno qualsiasi cosa creata per uso interno ("regalare continuamente la propria salsa segreta"), il primo radar venne reso pubblico subito dopo la riunione, suscitando un forte interesse nell'industria e trasformandosi in un appuntamento semestrale fisso. ¹

Il processo bottom-up: blip, sessioni di raccolta e gruppo Doppler

Con la crescita di Thoughtworks di un ordine di grandezza (fino a circa 10.000 persone), il meccanismo di creazione del radar si è evoluto da una riunione tra poche persone tutte operative sui progetti a un processo strutturato bottom-up: ¹

• Proposta dei blip: ogni voce o punto sul radar è chiamato blip. Chi lavora sui progetti può nominare e sottoporre un blip passando per un referente collegato per area geografica, linea di business o tecnologia, spiegando perché quella tecnologia o tecnica sia interessante. ¹
• Il gruppo Doppler e le sessioni di raccolta: i proponenti tengono un briefing ai membri di quello che oggi si chiama Doppler group (gioco di parole con il radar). Circa uno o due mesi prima del meeting ufficiale si tengono le sessioni di raccolta (blip gathering sessions) per selezionare e affinare le proposte; nella riunione plenaria il gruppo passa poi in rassegna i blip uno per uno per decidere quali inserire e in quale anello, generando una forte impollinazione incrociata tra esperienze diverse. ¹
• La nascita dei microservizi con James Lewis: per Fowler — ormai lontano dal lavoro quotidiano sui progetti dei clienti — le riunioni del radar sono anche il luogo in cui intercettare temi emergenti trasversali. Proprio attraverso il processo del Technology Radar, circa dieci anni fa, emerse il tema dei microservizi, che Fowler approfondì e codificò poi insieme a James Lewis. ¹

Costruire il proprio radar aziendale

Thoughtworks non presenta mai il proprio Radar come un dogma universale per l'intera industria ("questo è ciò che vediamo noi nei nostri progetti"), e incoraggia attivamente le aziende clienti a costruire il proprio Technology Radar interno, mettendo a disposizione anche strumenti dedicati. ¹

Fowler nota due differenze fisiologiche tra il radar di Thoughtworks e quello interno di un'azienda cliente: ¹

• Maggiore prescrittività: un radar aziendale interno può avere un tono più direttivo ("questo è ciò che pensiamo dovreste usare in azienda") rispetto a quello consultivo di Thoughtworks. ¹
• Maggiore selettività: un cliente può permettersi di ignorare intere famiglie tecnologiche che ha scelto di non adottare, mentre Thoughtworks, lavorando su ciò che usano i propri clienti in tutto il mondo, finisce inevitabilmente per imbattersi in ogni tecnologia esistente. ¹

Le voci AI e di ingegneria nell'edizione di novembre 2025

Nell'edizione del Technology Radar lanciata il giorno stesso della registrazione dell'intervista, circa un terzo o metà delle voci ruota attorno all'AI e agli LLM (vedi Harness Engineering e AI Skills e Grill-Me): ¹

1. GenAI per comprendere i sistemi legacy (in Adopt): nell'anello più esclusivo del radar (Adopt, che in questa edizione conta appena quattro voci in totale) spicca l'uso della GenAI per comprendere il codice legacy esistente. Messa a punto dai team di Thoughtworks un anno o due prima per affrontare il problema universale della modernizzazione dei sistemi legacy nelle aziende con più di qualche anno di vita (dove le persone lasciano l'azienda e la conoscenza va persa), la tecnica consiste nell'eseguire l'analisi semantica del codice, popolare con quelle informazioni un graph database e usare quel grafo in stile RAG per interrogare il sistema — chiedendo ad esempio cosa succeda a uno specifico dato e quali parti del codice lo tocchino mentre scorre attraverso il programma. I risultati sono stati così solidi da spingere Thoughtworks a raccomandare a chiunque lavori sul legacy di usare gli LLM per comprenderlo (mentre resta ancora aperta la questione se possano modificarlo in sicurezza, vedi Refactoring nell'Era AI). ¹
2. Altre tecnologie e strumenti segnalati: tra le voci in Adopt e negli anelli di sperimentazione citate nell'intervista figurano i pre-commit hooks (controlli automatici prima del commit), ClickHouse per l'analytics su database, vLLM per eseguire LLM in modo efficiente su cloud o on-premise, la sperimentazione (trialing) di Claude Code e fastMCP (framework per server MCP), affiancati nell'anello Assess da molteplici pratiche emergenti per lavorare con il non determinismo degli LLM. ¹

Vedi anche: Martin Fowler, Harness Engineering, AI Skills e Grill-Me, Non Determinismo del Software, Refactoring nell'Era AI

Fonti e Riferimenti