Hybrid Integration Platform: i nuovi abilitatori del business digitale

I l tema dell’integrazione applicativa è contestuale alla presenza di più di un’applicazione in azienda e nel tempo è stato affrontato in modi differenti, come ha spiegato Stefano Mainetti, co-direttore scientifico dell’Osservatorio Cloud & ICT as a service della School of Management del Politecnico di Milano, introducendo due recenti eventi organizzati da ZeroUno: “Siamo passati da un’integrazione diretta (con connettori che consentono alle diverse applicazioni di comunicare, utilizzando protocolli di rete come TCP o HTTP) alla realizzazione di interfacce dedicate (EDI ecc.) che, seppure motivate da logiche di business, complicano l’interfaccia applicativa con impatti negativi su fruibilità e agilità. Si è poi cercato di razionalizzare questa ‘spaghetti integration’ con middleware di servizi: dall’ESB-Enterprise Service Bus fino a un nuovo paradigma architetturale, la SOA-Service Oriented Architecutre”. Ma tutto questo oggi non è più sufficiente (né facilmente gestibile) perché ci troviamo a dover affrontare una radicale trasformazione del modello di impresa dove le parole chiave sono: digitale, rapidità, riusabilità, sicurezza. “La SOA – ricorda Mainetti – è un’ottima soluzione di ingegneria del software, ma è troppo ingombrante, costosa e soprattutto non in grado di rispondere a quell’essenziale requisito della rapidità che può determinare, da solo, la riuscita di un progetto d’impresa”. Se ci troviamo a dover affrontare le sfide di un mondo che Dario Pagani, Executive President Information & Communication Technology di Eni, definisce in “versione beta”, dove le applicazioni vengono aggiornate continuamente, è evidente che anche l’integrazione deve avvenire con la stessa rapidità, riducendo la complessità che si era venuta a creare con le precedenti architetture.

La risposta per semplificare questa complessità viene da nuovi ambienti di integrazione che, addirittura, è possibile utilizzare a consumo come l’iPaaS (integration Platform as a Service) e dalla diffusione delle API, che rappresentano un insieme di funzionalità esposte da un’applicazione, in pratica una modalità standard per l’interrogazione e l’accesso ai dati.Le API sono, da un lato, una tecnicalità che permette di fare in modo più rapido quello che si è sempre fatto, ma dall’altro, sottolinea Mainetti, “aprono un potenziale potentissimo di cambiamento dei modelli di business perché esponendo API si abilitano processi tipici della trasformazione digitale: ci si integra facilmente in una catena estesa con i fornitori e i business partner; si concretizzano i modelli basati sulla multicanalità rendendo disponibili i servizi applicativi su tutti i device; o, ancora, si abilita la nascita di nuovi soggetti economici perché si rende possibile lo sviluppo di nuovi servizi a terze parti”. Ed ecco che le API si trasformano da “banale” tecnicalità a strumento di trasformazione; ma per non ricadere nella confusione della “spaghetti integration” (le API a loro volta evolvono e quindi diventa indispensabile, per esempio, gestirne il versioning) si sono sviluppate le piattaforme di API management.

In un mondo in “versione beta”, dove le applicazioni vengono aggiornate continuamente, è evidente che anche l’integrazione deve avvenire con la stessa rapidità, riducendo la complessità che si era venuta a creare con le precedenti architetture

E ancora, assistiamo all’emergere dell’iSaaS, piattaforme cloud per abilitare quella che Gartner ha definito Citizen Integration ossia la possibilità per alcuni utenti business (o consumer) di occuparsi essi stessi dell’integrazione di alcune applicazioni, già fruite in cloud (per esempio MailChimp, sistema di email marketing, e il CRM Salesforce). Si tratta di integrazioni che Gartner stessa definisce “basiche”, non complesse e pacchettizzate, ma che possono abilitare lo sviluppo rapido di nuovi servizi: proprio quello che oggi il business richiede, ma che per concretizzarsi deve anche vedere una trasversalità delle competenze digitali in tutta l’azienda, possibile, per esempio, se si attuano modelli organizzativi dove l’IT si “liquefa” nelle linee di business (vedi articolo Percorsi, modelli e competenze di un dipartimento IT sempre più “liquido” e innovatore).Le piattaforme di integrazione diventano dunque strumenti strategici per il digital business e stiamo assistendo a una loro rapida evoluzione proprio in funzione dell’assunzione di questo ruolo (figura 1).

Verso una hybrid integration platform

Nel corso di un Webinar organizzato da Gartner qualche mese fa, Massimo Pezzini, VP & Gartner Fellow, ha sottolineato come il mercato delle piattaforme di integrazione sia già grande e diventerà ancora più ampio con una crescita costante che traguarderà il 2020 (figura 2), ma soprattutto ha evidenziato come l’evoluzione dei diversi approcci all’integrazione stia portando alla definizione di Hybrid Integration Platform (HIP) che sono la combinazione di tre elementi:

• piattaforme di integrazione di dati e applicazioni on premise;
• iPaas e iSaas;
• piattaforme di API management

“La combinazione di questi tre elementi – ha spiegato Pezzini – fornisce alle imprese tutte le funzionalità di integrazione di cui esse necessitano per rispondere alle sfide della digitalizzazione. Sono molte le aziende che stanno utilizzando componenti di soluzioni provenienti da diversi vendor e assemblandoli, ma si sta sviluppando un mercato specifico di queste piattaforme ibride”.Gartner e Forrester, che ha recentemente rilasciato un report sull’evoluzione delle piattaforme di integrazione ibride (Vendor Landscape: Integration-Platform-As-A-Service And Hybrid Integration, aggiornato a gennaio 2017), evidenziano che attualmente nel segmento iPaaS/iSaaS si sta assistendo a un considerevole ampliamento del numero dei vendor, ma entrambi gli analisti prevedono che, entro 4-5 anni, si avrà un processo di consolidamento con conseguenti acquisizioni e fusioni.L’altro trend evidenziato da entrambi gli analisti è il processo di convergenza verso piattaforme ibride che vede coinvolti sia i tradizionali vendor di soluzioni di integrazione on premise sia quelli di piattaforme iPaaS, ma anche delle soluzioni iSaaS, con un ingresso nel mercato enterprise di operatori che tipicamente si rivolgono a una fascia di utenza con minori competenze tecniche. Gartner mette poi in evidenza un altro fenomeno: molti software vendor stanno incorporando funzionalità di integrazione nella loro offerta tradizionale, per cui l’analista prevede l’emergere di player di iBPM suite, Mobile App Development Platform ecc.

Nella figura 3 vediamo quali sono le funzionalità che Gartner ha identificato per una HIP, mentre nel riquadro delle pagine successive possiamo leggere le considerazioni specifiche sull’offerta che derivano da The Forrester Wave: Hybrid Integration for Enterprise. In alcuni articoli, ci focalizzeremo invece sulle caratteristiche e l’offerta dei due componenti più innovativi di una HIP: iPaaS e iSaaS e API Management.

Quali criteri per scegliere una piattaforma di integrazione

Sulla base di quali criteri, gli Enterprise Architect possono compiere la scelta della soluzione più adatta alle proprie esigenze? Per rispondere alla domanda, ci viene in aiuto il primo dei due studi di Forrester nel quale l’analista precisa che sono cinque i fattori primari da considerare per definire una shortlist di soluzioni di integrazione adatte alla propria realtà: il modello di deployment (on premise, cloud, ibrido); il modello di pricing; la disponibilità per la propria area geografica; l’offerta di servizi gestiti da parte del vendor (o di suoi partner); i componenti tecnici della soluzione. Forrester suddivide l’analisi di questi fattori in 2 step:

STEP 1 – Valutazione delle esigenze di integrazione

• Scelta tattica o strategica – L’adozione di una piattaforma ibrida (HIP) implica una completa revisione degli investimenti effettuati per middleware ESB o altre soluzioni di EAI – Enterprise Application Integration: si tratta quindi di una scelta che deve prevedere un disegno strategico di revisione architetturale del parco applicativo e dei modelli di deployment (per esempio spostamento verso il cloud). Una piattaforma iPaaS può essere invece tatticamente adottata per integrare una parte del parco applicativo.
• Modello di deployment – Le soluzioni di integrazione in cloud hanno differenti opzioni di deployment: unicamente in cloud pubblici, o, anche, in private cloud oppure on premise. Se si opta inizialmente per una scelta tattica di iPaaS per alcune applicazioni, ma si prevede di avere necessità di una piattaforma ibrida, bisogna valutare attentamente quelle iPaaS che consentono una facile migrazione verso piattaforme ibride.
• Modello di pricing – Per quanto riguarda le iPaaS, sono sostanzialmente due i modelli di pricing tra i quali orientarsi: technical based, ossia con pagamento calcolato per transazione o per evento; user based, calcolato su postazione. È una questione da valutare attentamente perché nel secondo modello molti vendor, sostiene Forrester, in fase di offerta propongono simulazioni di costo solo su piccole configurazioni (uno o due postazioni) quindi è importante capire bene quali sono le proprie esigenze.
• Disponibilità della piattaforma per la propria area geografica – Indispensabile per essere certi che vengano rispettati tutti i regolamenti (compliance) in termini di trattamento dei dati cui si deve sottostare.
• Managed services – L’integrazione è comunque un tema complesso e può essere necessario potersi appoggiare a un vendor che la offra come servizio gestito.

STEP 2 – Verifica tecnologica

Il secondo step consiste nella verifica delle differenze tecnologiche tra piattaforme, che si sostanzia prima di tutto nella disponibilità di connettori per le diverse applicazioni. L’importanza di specifici connettori, afferma Forrester, è diminuita grazie al fatto che i software vendor sviluppano API Rest o Soap (interfacce standard: per sistemi di ipertesto distribuiti, nel primo caso ossia Representional State Transfer; basate sullo scambio di messaggi, nel caso del Simple Object Access Protocol). Ma, sostiene sempre la società di analisi, l’utilizzo di interfacce standard non offre le stesse garanzie in termini di performance e di time to deliver dei connettori nativi. Quindi nella scelta della piattaforma di integrazione, l’Enterprise Architect deve valutare bene se sono sufficienti interfacce standard o se la piattaforma deve disporre di connettori specifici come:

• Connettori per applicazioni – Fondamentali nel mondo on premise perché ogni soluzione pacchettizzata, prima che venissero sviluppate API specifiche, aveva la propria modalità di connessione (per esempio tramite iDoc e Abap per SAP/R3, tramite l’accesso diretto alle tabelle del database per l’ERP Oracle ecc). E se queste soluzioni sono presenti in azienda bisogna tenerne conto.
• Connettori per database – Anche in questo caso, l’evoluzione dell’ODBC (Open DataBase Connectivity, ossia la connessione attraverso API standard del client al DBMS) ha ridotto l’importanza di connettori specifici; ciò non toglie che questi ultimi possono migliorare le performance del database.
• Connettori per big data – Si tratta di connettori che consentono di ottenere migliori risultati sfruttando le funzionalità della tecnologia big data: per esempio, alcune iPaaS utilizzano MapReduce (framework software brevettato e introdotto da Google per supportare la computazione distribuita su grandi quantità di dati in cluster di compute) per ottimizzare l’aggiornamento massivo di dati (bulk updates).
• Connettori per mainframe – È una vera sfida, sostiene Forrester, utilizzare iPaaS per accedere ai dati di un mainframe ed effettuare l’integrazione applicativa in cloud. Le piattaforme iPaaS offrono l’integrazione con le applicazione su mainframe utilizzando diverse modalità, ma molto più frequentemente permettono l’utilizzo di connettori specifici per mainframe, sviluppati da terze parti. Se le applicazioni su mainframe rappresentano ancora una parte importante del parco applicativo bisogna quindi valutare attentamente questi connettori.
• Connettori per il trasporto dei dati – Molti fornitori di piattaforme di integrazione riconoscono che, in base alle applicazioni che devono essere integrate, possono essere necessarie differenti modalità di trasporto dei dati (dal file transfer al secure file transfer al guaranteed delivery messaging ecc., o modalità più recenti come il time stamping o la tracciabilità contestuale). Anche qui, bisogna valutare la necessità di connettori specifici sulla base del proprio parco applicativo.
• Connettori B2B/EDI –L’EDI (Electronic Data Interchange) continua a esistere con protocolli o formati di dati differenti, ma non è facile mantenere all’interno dei sistemi informativi le competenze specifiche richieste per questi tipi di formati e protocolli, quindi la presenza di connettori specifici può essere importante.
• Connettori IoT – Alcuni vendor oggi abilitano il supporto all’IoT attraverso MQTT (Message Queueing Telemetry Transport, protocollo di messaggistica “leggero”, posizionato in cima a TCP/IP) e AMQP (Advanced Message Queuing Protocol, standard aperto che definisce un protocollo a livello applicativo per il message-oriented middleware), ma l’IoT può richiedere, soprattutto per quanto riguarda lo streaming, supporti specifici. Molti vendor di piattaforme iPaaS dispongono anche di piattaforme per l’IoT, ma queste non sono generalmente parte integrante delle prime. Dato che, ricorda Forrester, l’IoT è destinato a crescere e potrebbe comportare un’ulteriore complessità in termini di integrazione è importante valutare attentamente questi aspetti.