di Miguel Angel Dìaz, manager, Business Development, Application Development and Middleware di Red Hat

Agilità! Agilità! Agilità! È un mantra spesso ripetuto quando si parla di trasformazione digitale. Ma siamo sicuri di adottarla in modo corretto? La stiamo applicando in modo olistico dove necessario? Non credo. Quando si tratta di agilità di business, non c’è una soluzione universale, anzi, l’agilità si può ottenere con iniziative differenti, per esempio migliorando il self-provisioning o aumentando la velocità attraverso il Continous Integration e Deployment (CI/CD). E, in base alla mia esperienza, ci si limita spesso ai miglioramenti a livello di codice. E l’integrazione? Le applicazioni in silos sono rare. Interne o esterne, le applicazioni devono essere integrate con numerosi sistemi e servizi e, come a livello di codice, l’agilità può essere utile anche in questo livello intermedio.

Tra i numerosi cambiamenti che potrebbero avvenire senza il controllo dello sviluppatore dell’applicazione, sono da segnalare modifiche o connessioni con nuovi partner. In questo ambiente, tre elementi possono sfidare l’agilità di integrazione:

• Integrazione al centro dell’applicazione: spesso la funzione core di un’applicazione risiede nella connessione ad altri servizi esistenti, che sono componenti chiave dei sistemi di un’azienda e, quindi, presenti per restare. Modificare l’applicazione potrebbe quindi causare cambiamenti a livello di integrazione.
• Processi organizzativi: alcune impostazioni legacy potrebbero rappresentare un ostacolo. La gestione dell’integrazione tramite un Centro di Eccellenza dedicato, cioè tramite un team centralizzato, potrebbe causare colli di bottiglia in caso di aumento della velocità o della necessità di maggiori modifiche. I team centralizzati potrebbero non sposare la filosofia “agile”.
• Cambiamenti tecnologici: un’architettura tradizionale a livello di integrazione è ad esempio quella di un Business Service Bus (ESB). L’ESB è solitamente distribuito in modo monolitico, in cui la logica di integrazione viene centralizzata in un’implementazione più vasta, con capacità di adattamento inferiori a differenti app e requisiti. Questo potrebbe ostacolare la richiesta di modifiche veloci e frequenti, elemento sempre più importante per il successo aziendale.

Analizzando l’approccio delle aziende verso l’integrazione agile, si possono sottolineare tre pilastri chiave:  

• Integrazione distribuita: è importante che le capacità e le competenze nella gestione dell’integrazione siano distribuite su team diversi. Sarebbe opportuno che non fosse più gestita in modo centralizzato, ma accessibile ovunque necessario. Anche l’architettura di distribuzione dovrebbe essere decentralizzata, in modo tale che ogni team possa gestire l’integrazione in modo indipendente, senza i vincoli di un’architettura monolitica. L’integrazione dovrebbe essere concessa in ogni tipologia di ambiente - on-premise, cloud pubblico o ibrido e implementata da chi la necessita.
• Basarsi su API: la gestione delle API può essere un elemento chiave per raggiungere un’integrazione distribuita. Le aziende dovrebbero essere in grado di autorizzare l’utilizzo di servizi, il controllo accessi, la governance e incrementare la sicurezza essendone consapevoli: l’utilizzo di un servizio dovrebbe essere sotto controllo. Senza una gestione efficace delle API, potremmo ritrovarci in un mondo fatto di connessioni point-to-point con tutti i problemi relativi.
• Ambiente di esecuzione basato su container: i punti precedenti aiutano a costruire le basi, ma per ottenere una maggiore agilità è fondamentale sfruttare i vantaggi a livello di integrazione offerti dai container. Una piattaforma container garantisce un ambiente più robusto che permette installazioni più semplici e automatiche, scalabili in base alle necessità, oltre a fornire un livello di astrazione dall’infrastruttura sottostante. I team possono gestire le applicazioni in modo più solido nel loro ambiente ibrido.

Tuttavia, per raggiungere questi tre obiettivi non è sufficiente “containerizzare” l’ESB. Per quale motivo? Perché è importante una democratizzazione dell’integrazione che potenzi l’“integratore comune”, rendendo la capacità di integrazione accessibile anche a chi non ha molta esperienza, ma la necessita per sviluppare progetti su nuove applicazioni e servizi. In questo modo, le aziende vedranno tecnologie che non sono solo distribuite, integrate nella gestione API e su container, ma che sono semplici da utilizzare, senza la necessità di programmare linee di codici.  

Queste soluzioni sono disponibili oggi? Sì, le piattaforme cloud iPaaS (integration as a service platform) si focalizzano sugli aspetti dedicati all’integrazione di applicazioni, dati e processi, che permettono a sviluppatori e a risorse meno specializzate di connettere le proprie applicazioni tramite browser web e grazie al loro codice ridotto aiutano gli utenti a creare soluzioni in modo più veloce, riducendo la complessità con componenti e template grafici. Credo sia la direzione giusta da seguire e ci sono aziende che la stanno già percorrendo.

L’integrazione moderna e agile tra sistemi legacy e nuove infrastrutture e applicazioni può diventare molto importante per le organizzazioni che desiderano utilizzare ambienti ibridi e multi-cloud per rispondere in modo flessibile alle proprie esigenze di business.