Come strutturare un Platform Team con le Team Topologies

Panoramica

• L’ascesa del platform engineering: Platform team dedicati attirano sempre più l’attenzione delle aziende di software.
• La sfida della struttura: Strutturare efficacemente i platform team è un punto dolente.
• Team topologies come soluzione: Le team topologies potrebbero rappresentare la chiave per superare questi problemi di strutturazione.

L’ingegneria della piattaforma (platform engineering) ha ormai assunto una funzione critica nelle aziende software moderne: Gartner prevede che l’80% delle grandi aziende di ingegneria avrà team di piattaforma dedicati entro il 2026. Tuttavia, avere un team di piattaforma non è sufficiente; la vera sfida sta nel strutturarlo correttamente. Molti team di ingegneria faticano a bilanciare autonomia e allineamento, trasformandosi spesso in silos isolati o colli di bottiglia che, a causa del sovraccarico di lavoro, rallentano lo sviluppo anziché accelerarlo.

Con la crescita di queste organizzazioni, la complessità delle loro internal platform cresce esponenzialmente. Senza una struttura ben definita, però, i platform team rischiano di trasformarsi in supporter reattivi anziché in facilitatori proattivi. Questo disallineamento porta a inefficienze, sviluppatori frustrati e release più lente del software.

È qui che entrano in gioco le topologie di team (team topologies). Le team topologies rappresentano un approccio strategico alla progettazione dei platform team che garantisce la loro perfetta integrazione con i flussi di lavoro degli ingegneri e ne massimizza l’impatto.

Questo articolo esplorerà le team topologies, inclusi i tipi di team e come interagiscono tra loro. Discuteremo il ruolo dei team di piattaforma e perché sono essenziali nelle aziende software moderne. Esploreremo anche alcune best practice per strutturare e ottimizzare un team di piattaforma che possa aiutare gli sviluppatori, riduca il carico cognitivo e acceleri la distribuzione del software.

Cosa sono le Team Topologies?

Le team topologies sono un framework concettuale per sviluppare strutture organizzative e raggiungere interazioni tra team software per una distribuzione rapida, affidabile e adattabile. Eliminano i silos esistenti nello sviluppo software, migliorando la produttività, ottimizzando l’allocazione delle risorse e incrementando il time-to-market. 

Questo approccio è stato originariamente introdotto da Matthew Skelton e Manuel Pais nel loro libro “Team Topologies: Organizing Business and Technology Teams for Fast Flow”, che identifica quattro tipologie di team fondamentali e modalità di interazione per ottimizzare l’erogazione di prodotti e servizi. Il framework delle team topologies segue un approccio incentrato sul team e fornisce un metodo sistematico per progettare team che ottimizzano la collaborazione, riducono gli attriti e accelerano lo sviluppo del software.

I team di platform engineering tradizionali sono tipicamente strutturati attorno a funzioni specifiche come infrastruttura, sicurezza e operazioni. Sebbene questo approccio offra un certo livello di specializzazione, spesso porta a compartimentazioni operative (silos) e barriere comunicative, rallentando la collaborazione e l’innovazione. 

Le team topologies, d’altro canto, introducono una struttura più dinamica e integrata, con ruoli e interazioni ben definiti. Se contestualizzate al platform engineering, le team topologies sono progettate per aiutare le organizzazioni a strutturare i propri team di prodotto e di piattaforma per supportare al meglio gli obiettivi aziendali e influire sull’agilità, sulla produttività degli sviluppatori e sui requisiti architetturali dell’azienda, scalando iniziative come DevOps, l’adozione del cloud o la distribuzione di microservizi.

I quattro principali tipi di team

Esistono quattro team topologies fondamentali che le organizzazioni dovrebbero considerare quando formano team o cercano di migliorare la produttività degli sviluppatori e la distribuzione del software, ciascuna con uno scopo specifico:

• Team allineati al flusso di lavoro (Stream-aligned teams)

Questo team è dedicato a un singolo prodotto, offrendo valore end-to-end ai clienti e mantenendo un flusso continuo di aggiornamenti software. Costituisce il fondamento dello sviluppo software ed è direttamente allineato a uno specifico dominio aziendale, fornendo funzionalità rivolte al cliente o business-critical. Di conseguenza, altri tipi di team sono in genere strutturati attorno a loro. Questo team spesso gestisce l’intero ciclo di vita dello sviluppo, dalla progettazione al deployment, e lavora in modo indipendente per ridurre al minimo le dipendenze dagli altri team.

Sebbene molte aziende software abbiano adottato team allineati ai flussi, alcune continuano a organizzare i propri team per funzione, come ad esempio ingegneria, progettazione e controllo qualità, anziché dare priorità alla delivery end-to-end. Per migliorare sia la velocità che la qualità, questi team possono collaborare con i team di supporto, come i team che si occupano di sottosistemi complessi, di abilitazione e di piattaforma, per migliorare la delivery e l’efficienza.

• Team abilitanti o di supporto (Enabling teams)

Questo team aiuta i team allineati ai flussi ad adottare nuove tecnologie, strumenti o best practice senza sostituirsi al loro lavoro. Fungono da mentori e consulenti, colmando le lacune di conoscenza, aiutandoli a superare gli ostacoli e garantendo che i team di prodotto possano sfruttare efficacemente tecnologie complesse. In altre parole, questo team funge da ponte per colmare le lacune di competenze condividendo la propria esperienza attraverso formazione, coaching e mentoring.

Sono spesso composti da specialisti in specifici ambiti tecnici o di prodotto e si concentrano su ricerca e sperimentazione. I team di supporto forniscono raccomandazioni informate su strumenti, framework e scelte di ecosistema che hanno un impatto sullo stack degli strumenti. Il loro obiettivo principale è aumentare l’autonomia dei team allineati ai flussi, aiutandoli a sviluppare le proprie capacità, concentrandosi sulla risoluzione dei problemi piuttosto che sulla proposta di soluzioni.

• Team di sottosistemi complessi (Complicated subsystem teams)

Questo team si occupa di aree del sistema altamente specializzate e computazionalmente complesse che richiedono una profonda competenza tecnica, come modelli di apprendimento automatico, algoritmi avanzati o manutenzione di sistemi legacy. I membri di questo team possiedono spesso competenze specialistiche in settori come microservizi, algoritmi o intelligenza artificiale. Il loro lavoro è troppo complesso per essere gestito in modo indipendente dai team stream-aligned.

Grazie alle competenze e alle capacità del complicated subsystem team, i team stream-aligned non hanno bisogno di sviluppare funzionalità complesse al di fuori delle loro responsabilità principali, riducendo così il carico cognitivo. Sebbene sia essenziale, l’integrazione di specialisti dentro ogni team stream-aligned che interagisce con questi sottosistemi non è né conveniente in termini di costi né in linea con i loro obiettivi primari.

• Team di piattaforma (Platform teams)

Questo team dedicato e interfunzionale sviluppa, crea, gestisce e supporta strumenti, servizi e infrastrutture interni che aiutano i team stream-aligned a operare con facilità e autonomia. Mentre i team stream-aligned mantengono la piena autonomia nella creazione, nell’esecuzione e nella manutenzione delle applicazioni in produzione, i platform team forniscono servizi interni ai team stream-aligned per astrarre qualsiasi complessità sottostante. Questa ottimizzazione non solo migliora la produttività degli sviluppatori ottimizzando la developer experience, ma avvantaggia anche gli utenti finali garantendo un’esperienza coerente tra diversi prodotti e interazioni con gli utenti, accelerando così la distribuzione di valore al cliente da parte dei team di prodotto.

Perché c’è bisogno dei Platform Team

Uno dei costi nascosti più significativi dell’adozione del cloud è il carico cognitivo. In passato, i team operativi gestivano reti, database e sicurezza, mentre gli sviluppatori si concentravano sulla scrittura del codice applicativo. Con la crescente complessità delle infrastrutture moderne, ci si aspetta che gli sviluppatori gestiscano l’infrastruttura, le pipeline di deployment, la sicurezza, la conformità e gli stack di osservabilità, il tutto mentre sviluppano nuove funzionalità. Questo carico cognitivo rallenta lo sviluppo, aumenta il rischio di errori e, in definitiva, influisce sui risultati aziendali.

Molte aziende hanno tentato di risolvere questo problema formando team DevOps, ma con l’aumento delle responsabilità da parte dei team applicativi per il codice infrastrutturale, il confine tradizionale tra i vari ruoli si è assottigliato. Come spiega Manuel Pais nel suo libro: 

“La vera sfida non è solo spostarsi a sinistra (shifting left) o rendere i team più autonomi, ma fornire le giuste protezioni in modo che gli sviluppatori non siano sopraffatti dal gran numero di cose che devono gestire.”

I platform team cercano di risolvere questo problema alleggerendo la complessità, fornendo soluzioni standardizzate e paved roads, e semplificando l’adozione delle best practice. Invece di trasformare ogni sviluppatore in un architetto cloud, gli sviluppatori possono affidarsi ai platform team per astrarre la complessità creando Internal Developer Platform (IDP) altamente curate, con accesso a strumenti self-service, componenti riutilizzabili, conoscenze e ambienti preconfigurati affidabili.

Il ruolo dei platform team va oltre la gestione dell’infrastruttura, fungendo da team di prodotto interni che creano e gestiscono servizi rivolti agli sviluppatori. Il loro focus è offrire la piattaforma come prodotto, garantendo che i clienti interni e i team di ingegneria abbiano tutto il necessario per distribuire ed eseguire il software in modo ottimale.

Best Practice per strutturare un Platform Team

Un platform team ben strutturato non si limita a fornire l’infrastruttura; crea un’esperienza di sviluppo fluida e consente ai team di ingegneria di sviluppare e distribuire software più velocemente e con meno ostacoli.

In sostanza, un platform team dovrebbe fungere da tessuto connettivo tra le aziende che si occupano della distribuzione del software e dell’infrastruttura, stabilendo una responsabilità condivisa. Dovrebbe includere persone con competenze in ingegneria del software, infrastruttura e operations/automazione.

Esaminiamo alcune best practice da tenere in considerazione quando si struttura un platform team:

Designazione di un Platform Owner

Un platform owner con solide competenze di gestione del prodotto aiuta a definire la visione della piattaforma, a comprendere le esigenze degli utenti e a dare la giusta priorità allo sviluppo.

Trattare la piattaforma come un prodotto

La maggior parte delle aziende considera il platform engineering come una funzione di supporto dietro le quinte piuttosto che un servizio interno. Un platform team di successo adotta una mentalità orientata al prodotto, dando priorità alle esigenze degli sviluppatori, raccogliendo feedback, ripetendo più volte i procedimenti per arrivare alla soluzione e migliorando costantemente la propria offerta.

Ciò significa applicare alla internal developer platform gli stessi principi utilizzati nei prodotti rivolti al cliente, ovvero la ricerca utente, le roadmap, il versioning e i test di usabilità. L’obiettivo è creare componenti riutilizzabili, sicuri e ben astratti che semplifichino lo sviluppo, mantenendo al contempo i necessari limiti di sicurezza, conformità e affidabilità. Inoltre, il platform team dovrebbe adeguare la propria portata, le competenze, le dimensioni e il proprio ambito di applicazione con l’evolversi del ciclo di vita del prodotto.

Iniziare e restare contenuti con MVP e TVP

Non ha senso cercare di costruire la piattaforma perfetta da zero. Dato che potrebbero esserci funzionalità che gli sviluppatori non desiderano né necessitano, è molto più consigliabile iniziare con una versione minimale, ben focalizzata e iterativa che fornisca valore fin da subito grazie al feedback continuo: questo è il metodo del Prodotto minimo funzionante o Minimum Viable Product (MVP). Allo stesso modo, l’approccio Thinnest Viable Platform (TVP) garantisce di non sprecare risorse interne utili allocandole correttamente durante l’intero ciclo di vita della piattaforma.

Focalizzarsi sull’esperienza di sviluppo e sulle capacità self-service

Un platform team ben strutturato ottimizza la developer experience (DevEx) riducendo gli attriti nel processo di sviluppo. Invece di costringere i team a interagire con livelli infrastrutturali complessi, i platform team offrono funzionalità self-service, aiutando gli sviluppatori a ottenere ciò di cui hanno bisogno on-demand, senza dover attendere approvazioni o interventi manuali.

Offrono ambienti di test, staging e produzione standardizzati che aiutano gli sviluppatori ad avviare e gestire le risorse senza dover attendere operazioni manuali. Utilizzando internal developer portal, i platform team offrono un approccio unificato per la registrazione, il monitoraggio, l’autenticazione e l’individuazione dei servizi.

Promuovere collaborazione e cultura dell’apprendimento

Incoraggiare la comunicazione e il feedback tra il platform team e i suoi utenti è essenziale per migliorarsi continuamente. Le Comunità di Pratica (CoP) possono rappresentare un importante punto di accesso a questo tipo di cultura dell’apprendimento.

Definire metriche chiare per definire il successo

Come qualsiasi team focalizzato sul prodotto, i platform team devono definire e monitorare le metriche chiave delle prestazioni per misurarne l’impatto e garantire un miglioramento continuo. Senza chiari indicatori di successo, i team potrebbero avere difficoltà a dimostrare il proprio valore o a identificare le aree che necessitano di ottimizzazione. Pertanto, i platform team dovrebbero essere in grado di osservare il tempo impiegato dai nuovi ingegneri per passare dalla configurazione alla prima implementazione, per valutare l’usabilità e l’impatto degli strumenti della piattaforma nel ridurre le difficoltà di onboarding.

Dovrebbero comprendere l’impatto degli incidenti correlati alla piattaforma sui team di sviluppo ed evidenziare le aree di miglioramento in termini di uptime del sistema, resilienza e tolleranza agli errori. 

Altri parametri preziosi possono includere il tasso di adozione, l’affidabilità, la velocità di sviluppo, la facilità d’uso e la soddisfazione. Monitorando costantemente queste metriche, i platform team possono apportare miglioramenti basati sui dati, affrontare i punti critici e creare una internal platform che migliori la produttività degli sviluppatori e la distribuzione del software.

In sintesi

Il platform engineering non riguarda più solo la gestione dell’infrastruttura, ma anche l’aiutare gli sviluppatori a creare e distribuire software in modo efficiente, garantendo al contempo sicurezza, affidabilità e conformità. Applicando un approccio basato sulle team topologies, le aziende possono strutturare i platform team per ridurre al minimo il carico cognitivo, promuovere la collaborazione, accelerare i risultati aziendali e fornire strumenti interni di grande impatto. Filtrare il platform engineering attraverso la lente delle team topologies può offrire un modo strutturato di valutare se i team sono pronti per il successo e se sono ben allineati con gli obiettivi dell’azienda.

Per approfondire la creazione di un platform team ben strutturato e il suo allineamento con le esigenze della vostra azienda, scaricate questo documento e scoprite come creare una piattaforma scalabile e di facile utilizzo per gli sviluppatori, che acceleri la distribuzione del software mantenendo l’eccellenza operativa.