Una questione contrattuale: la dura vita delle piattaforme interne 🚦

La piattaforma che non c’è 🏗️

Sviluppare una Internal Developer Platform (IDP) o, più in generale, un framework destinato a più progetti, è un po’ come tentare di mettere d’accordo una band di jazzisti improvvisatori: ognuno suona il suo pezzo, ma alla fine serve armonia. E, spoiler: non basta la buona volontà.

Disciplina, costanza e una visione che vada oltre il prossimo sprint sono ingredienti fondamentali. Senza, si rischia di costruire una cattedrale nel deserto… o peggio, un castello di sabbia durante l’alta marea.

Premessa: obiettivi aziendali e identità della piattaforma

Prima ancora di adottare una IDP o un framework aziendale, è fondamentale che l’azienda abbia ben chiaro quale tipologia di prodotti intende sviluppare e quali clienti vuole servire. Senza una visione precisa degli obiettivi di business e del target, ogni scelta tecnologica rischia di essere inefficace o addirittura controproducente. La piattaforma interna deve essere progettata per supportare concretamente la strategia aziendale, non solo per seguire le mode del momento.

Se però l’azienda si trova a dover perseguire un parco molto eterogeneo di obiettivi o a servire clienti con esigenze molto diverse tra loro, può essere più efficace adottare una collezione di soluzioni modulari, come tanti pezzi di Lego da combinare all’occorrenza, piuttosto che puntare su un’unica IDP o framework ben definito. Questo approccio permette maggiore flessibilità e adattabilità, a costo di una complessità gestionale superiore.

Perché le IDP falliscono (spesso): lezioni dal campo 🏚️

Negli ultimi anni molte aziende hanno investito in piattaforme interne sperando di risolvere ogni problema con portali self-service e cataloghi scintillanti. Ma la realtà è più complessa: spesso si aggiunge solo un nuovo strato di complessità, senza vero valore per il business.

Le cause principali del fallimento

• Non inseguire le mode: Spesso si adottano IDP solo perché “lo fanno tutti”, senza una reale analisi dei bisogni interni.
• Il gap educativo: Non basta conoscere la tecnologia, serve una comprensione condivisa di cosa sia una IDP e di come automazione, integrazione e self-service debbano lavorare insieme.
• Evoluzione della stack tecnica: Integrare una IDP senza aggiornare o ripensare la propria infrastruttura spesso crea solo attriti e incompatibilità.
• Il giusto livello di astrazione: Bisogna scegliere il livello di astrazione che tutti possono comprendere e usare davvero.
• Complessità non necessaria: Ogni nuovo strato va giustificato dal valore che porta, altrimenti è meglio evitarlo.
• Coinvolgere tutti gli utenti: Una piattaforma interna deve coinvolgere tutti gli utenti finali (security, FinOps, service owner…), ascoltando le loro esigenze fin dall’inizio.

“Costruire una piattaforma interna è come organizzare una cena tra amici: tutti hanno gusti diversi, ma alla fine nessuno vuole lavare i piatti.”

Strategie per il successo

• Allineamento continuo: Il lavoro sulla piattaforma non finisce mai: serve raccogliere feedback, adattare la terminologia e rivedere i processi.
• Piccoli passi e terminologia condivisa: Piccoli passi, MVP, tanta comunicazione e una terminologia condivisa sono la chiave.
• Formazione e cultura: Investire in formazione e cultura condivisa è spesso più efficace che investire in nuovi tool.
• Framework progressivo: Sviluppare la piattaforma come un framework progressivo, che cresce per gradi e si adatta ai bisogni reali, comporta la responsabilità di gestirlo come un vero prodotto.

Modularità, questa sconosciuta 🧩

La tentazione di scrivere tutto in un unico, gigantesco monolite è forte. Ma la realtà è che ogni componente condiviso dovrebbe essere pensato come un prodotto a sé stante, con una sua identità e, soprattutto, con un preciso contratto tra le parti.

Immagina che ogni modulo sia sviluppato da un team diverso (anche se, nella realtà, spesso sei sempre tu con cappelli diversi): il contratto non è solo una formalità, ma una necessità per evitare che ogni modifica si trasformi in una valanga di effetti collaterali.

Il contratto: non solo carta, ma garanzia 🤝

Nel mondo delle piattaforme interne, il “contratto” tra componenti non è un pezzo di carta, ma un insieme di regole, interfacce e aspettative che devono essere rispettate. In pratica, un contratto definisce cosa un modulo offre (servizi, API, comportamenti) e cosa si aspetta dagli altri: è la base per la collaborazione tra team e per la stabilità dell’ecosistema.

Pro:

• Permette di lavorare in modo indipendente: ogni team può evolvere il proprio modulo senza rompere gli altri, se rispetta il contratto.
• Favorisce la chiarezza: tutti sanno cosa aspettarsi e cosa devono garantire.
• Agevola il testing e l’automazione: i contratti chiari sono più facili da validare automaticamente.

Contro:

• Può rallentare l’evoluzione: cambiare un contratto richiede coordinamento e spesso una fase di transizione.
• Rischio di rigidità: se il contratto è troppo dettagliato o vincolante, può limitare l’innovazione o l’adattabilità.

Che tu stia lavorando in GoLang, TypeScript o con la forza del pensiero, la sostanza non cambia: ogni componente deve essere affidabile, prevedibile e, soprattutto, testabile.

Automazione: la tua migliore amica 🤖

Affidarsi alla memoria o alla buona fede non basta. Serve automazione: test, validazioni, pipeline che verifichino costantemente che i contratti siano rispettati. Solo così si può dormire sonni (quasi) tranquilli, senza temere che una modifica innocente scateni il caos in produzione.

Conclusione: la filosofia del piccolo passo 🐾

Costruire una piattaforma interna di successo non è questione di tool miracolosi o linguaggi esotici. È una questione di filosofia: pensare in modo modulare, stipulare contratti chiari (anche con sé stessi) e affidarsi all’automazione. E, ogni tanto, concedersi una risata sulle proprie disavventure: perché, in fondo, anche la disciplina ha bisogno di un po’ di ironia.