Cos'è un iPaaS e quando conviene rispetto a un ESB?

L'iPaaS, integration platform as a service, è una piattaforma gestita in cloud che collega applicazioni, database e API senza costruire ogni connessione da zero: porta connettori già pronti verso i gestionali e i SaaS più diffusi e un modo per trasformare i dati che passano da un sistema all'altro. È la generazione attuale di un mestiere vecchio, e la differenza non è dove gira il software: l'ESB, enterprise service bus, centralizzava tutto in un unico bus attraversato da ogni scambio, mentre qui l'integrazione è spezzata in flussi indipendenti che si aggiungono e si tolgono uno alla volta. Prima ancora c'era l'integrazione punto a punto, cioè uno script dedicato per ogni coppia di sistemi. Accanto all'ESB e all'iPaaS c'è però una terza forma che nessuno di quei due nomi comprende: il framework di integrazione, una libreria che incorpori nel tuo codice invece di una piattaforma che acquisti, ed è lì che stanno Apache Camel e Spring Integration.

Da dove viene il vocabolario

I mattoni non sono un'invenzione dei vendor. Vengono dal catalogo degli Enterprise Integration Patterns di Gregor Hohpe e Bobby Woolf (2003): il router che smista un messaggio in base al contenuto, il traduttore che converte un formato nell'altro, il canale che collega un solo mittente a un solo destinatario, una coda in pratica, che disaccoppia chi produce da chi consuma. Ogni piattaforma di oggi implementa quel catalogo con nomi propri, e Apache Camel lo implementa in modo dichiarato. Saperlo serve a una cosa pratica: quando due fornitori descrivono la stessa funzione con due parole diverse, il pattern sottostante è lo stesso, e la scelta si sposta sul costo e sul blocco invece che sulle etichette.

Quando sceglierlo, e quando no

Conviene quando i sistemi da collegare sono molti e cambiano spesso, e quando conta sapere quale scambio è fallito stanotte senza aprire un file di log. Non conviene quando le integrazioni sono tre e stabili: lì l'iPaaS aggiunge un canone, una piattaforma da imparare e un fornitore in mezzo a un problema che due script risolvono. Quello che i confronti fra prodotti non dicono è il modello di prezzo: si paga a esecuzione, a volume di messaggi, a flusso attivo o a licenza negoziata, e i primi due crescono proprio quando il progetto riesce. Quale dei quattro c'è scritto nel contratto conta più dello sconto ottenuto. C'è poi un secondo vincolo contrattuale: i flussi vivono nel formato del fornitore, sia che li disegni in un editor sia che li esporti in un file, e non esiste un formato di interscambio fra piattaforme, quindi portarli altrove significa riscriverli, vendor lock-in nella sua forma più concreta.

Un esempio concreto

Una PMI manifatturiera ha il gestionale in sede, l'e-commerce in cloud e un CRM: gli ordini arrivano nel gestionale via file la notte, le giacenze tornano al sito con un altro processo, e nessuno sa dire perché ogni tanto un ordine sparisce. Sono tre integrazioni, non trenta, quindi la risposta giusta non è comprare una piattaforma: è dare un proprietario a ciascun flusso e un registro di cosa è passato. Il discorso cambia alla quinta o sesta applicazione, quando il numero di collegamenti cresce più in fretta del numero di sistemi ed è il momento in cui i silos di dati si consolidano.

Perché conta per chi decide

La categoria è matura, non emergente: Gartner le dedica un Magic Quadrant da anni, il che significa che il rischio non è scegliere un prodotto immaturo ma pagare una piattaforma per un problema che non hai ancora. La domanda da porsi prima del preventivo è quante integrazioni esistono davvero oggi e quante ne nasceranno nei prossimi due anni. Vale la pena notare che il Model Context Protocol sta facendo per gli agenti AI quello che questi pattern hanno fatto per le applicazioni, cioè sostituire le connessioni una a una con connettori standard: è lo stesso problema che si ripresenta su un altro piano.