Lo sviluppo di architetture Soa (Service Oriented Archtiecture) ha portato negli ultimi anni nuova vita e speranza ai reparti It, da sempre impegnati a migliorare, in termini di flessibilità, la distribuzione delle applicazioni aziendali, con costi di gestione e complessità tecnologiche sempre crescenti. Attraverso le Soa, i servizi aziendali esistenti basati su sistemi legacy possono infatti aprirsi al riutilizzo da parte di applicazioni esistenti e nuove. Tuttavia i problemi non mancano e sono da ricondurre, innanzitutto, al tema dell’integrazione, che viene ulteriormente riproposto con il diffondersi del modello as-a-service e del cloud computing.
E’ un problema tutt’altro che banale, dato che, in quest’ambito, non è sufficiente focalizzare l’attenzione sull’interoperabilità dei protocolli per l’implementazione dei servizi (Xml, Soap – Simple Object Access Protocol, ecc.), ma è necessario individuare meccanismi e tecniche sia per l’integrazione tra la rete e il sistema informativo aziendale sia per il riuso di componenti applicative già esistenti. A tale scopo gli Enterprise Service Bus, gli integration server e le suite per il Business Process Management vengono in aiuto, ma per progettare in modo adeguato l’interconnessione tra le diverse componenti tecnologiche e applicative distribuite, sono necessari tool specifici e, soprattutto, un approccio metodologico ben strutturato che tenga conto delle differenze che intercorrono tra le business application sviluppate e gestite in modo tradizionale in ambienti legacy, e governate, invece, secondo una logica “di servizio”. Deve essere chiaro fin da subito che si tratta di due modelli applicativi ben distinti.
Mainframe e Soa: due modelli applicativi differenti
In alcune recenti analisi effettuate dalla società indipendente di ricerca Lustratus Research sul tema dell’integrazione in ambito mainframe, in particolare tra le soluzioni legacy sviluppate per sistemi centrali con le applicazioni più avanzate, l’azienda punta i riflettori proprio sulla differenza dei due modelli applicativi, sottolineando, innanzitutto, i concetti di riuso, flessibilità, minor complessità di gestione e cambiamento tipici degli ambienti e delle architetture orientate ai servizi.
Pur ribadendo la validità di entrambi gli impianti applicativi (non dimentichiamo, infatti, che le applicazioni legacy su mainframe portano con sé caratteristiche di sicurezza, affidabilità e disponibilità che hanno garantito il loro successo e la loro longevità fino ad oggi, e probabilmente ancora per molti anni a venire), ciò su cui insiste la società di analisi sono le caratteristiche tecnologiche dei due modelli che, in un processo di integrazione, rappresentano il fattore di maggior criticità.
Le applicazioni legacy, storicamente, sono nate per supportare processi aziendali stabili e piuttosto rigidi/fissi (la flessibilità non era quindi un requisito fondamentale); si tratta, infatti, di soluzioni monolitiche sviluppate per indirizzare una singola tipologia di operazione/funzione. Soluzioni che possono anche funzionare contemporaneamente ma, in genere, non integrate fra loro come avviene, invece, nel modello applicativo basato sulle Soa. Quest’ultimo, infatti, prevede una serie di elementi (ciascuno dei quali specializzato nello svolgere una ben determinata funzione applicativa) perfettamente integrati tra loro attraverso vari strumenti di integrazione (portali, Enterprise Service Bus, message broker, integration broker, ecc.) che consentono di indirizzare contemporaneamente diverse esigenze funzionali e modalità operative, quindi, diversi processi di business.
Le applicazioni Soa sono progettate per essere eseguite in ambienti distribuiti; invece di progettare e sviluppare una singola applicazione monolitica per un processo aziendale, vengono realizzate diverse applicazioni (minori, generalmente più snelle) per indirizzare servizi e attività di varia natura.
A differenza del modello mainframe, servizi ed applicazioni non sono strettamente collegati tra loro ed è proprio questo aspetto su cui si basa il concetto di riutilizzo dei servizi distribuiti, che apre le porte alla flessibilità It.
Flessibilità garantita ma aumento della complessità
Tuttavia, a fronte di una maggior flessibilità garantita dal disaccoppiamento tra applicazione e servizio, non banale è la complessità che ne deriva, soprattutto in virtù del fatto che la storia delle architetture delle imprese può essere letta come un’evoluzione anziché come una rivoluzione: invece di rimuovere e sostituire i sistemi esistenti, la maggior parte delle imprese, nel tempo, ha inserito nuove capacità in ciò che già possedevano, dando vita ad ambienti eterogenei costituiti da applicazioni legacy e da tecnologie nuove basate sui servizi.
L’adozione di nuovi paradigmi per le architetture continua a introdurre elementi di complessità (anche oggi, con la virtualizzazione e il cloud computing); solo per fare un esempio, quando nelle classiche architetture client-server si verificavano periodi di inattività dei servizi, era semplice individuare il guasto e le possibili fonti si limitavano a una manciata di sistemi. Negli ambienti applicativi composti configurati per i servizi, il server per le applicazioni web è un punto centrale di coordinazione tra più sistemi client-server e i guasti possono avvenire in qualunque punto del percorso delle operazioni.
La capacità di offrire sempre nuovi servizi o versioni degli stessi servizi, inoltre, rende difficile una mappatura accurata dell’architettura applicativa.
I servizi web sono stati progettati parzialmente anche per consentire ai sistemi delle aziende di interoperare perfettamente con altri sistemi. Tradizionalmente, i sistemi informatici operavano in maniera indipendente, gestendo i propri dati (spesso inconsapevoli degli altri sistemi presenti magari nello stesso ambiente; in un mainframe potevano operare, come si diceva, anche più applicazioni in parallelo, ma ognuna “lavorava autonomamente”).
L’avvento della tecnologia basata su web e il conseguente bisogno di condividere i dati provenienti dalle fonti più disparate hanno condotto alla creazione di collegamenti comunicativi point-to-point tra le applicazioni. La Soa, perciò, sostituisce i collegamenti a codici rigidi con un approccio di abbinamento meno rigoroso; tuttavia, dal punto di vista gestionale, questo significa che è necessario prestare maggiore attenzione ai punti dove si verifica l’integrazione stessa.
Integrazione Soa-Mainframe: il cambio è anche organizzativo
Integrare gli ambienti mainframe con le architetture Soa non è banale. Innanzitutto va sottolineato che, come spesso accade, si tratta di un cambiamento sia di natura tecnologica sia di tipo organizzativo, con importanti impatti su skill e funzioni It. Risulta abbastanza evidente, infatti, che l’integrazione di un’applicazione mainframe in un ambiente Soa richiede competenze significative in entrambe le direzioni; gli sviluppatori devono essere in grado di analizzare il codice dell’applicazione legacy, tanto per cominciare, determinarne le dipendenze e i vincoli, individuare i possibili effetti collaterali prevedibili in fase di esecuzione e gestirne in modo opportuno l’utilizzo da parte degli utenti. Allo stesso modo, chi ha maggiori competenze sulle Soa deve avere ben chiare le modalità di posizionamento delle procedure mainframe fornite dai colleghi per inserirle nella posizione più appropriata nell’ambiente applicativo distribuito, incapsulandole in modo da utilizzare protocolli standard e assicurare così un’efficiente gestione e mantenimento.
È dunque evidente che l’integrazione deve avvenire prima di tutto a livello organizzativo, in particolare tra i gruppi di lavoro e i team preposti a tale percorso.
Da un punto di vista tecnologico, poi, è necessario procedere con un assessment iniziale molto approfondito, che dia una buona visibilità su criticità-potenzialità-esigenze-benefici di entrambi i modelli applicativi in modo da identificare, nel dettaglio, quali elementi dell’uno e dell’altro adottare e mantenere e come procedere all’integrazione.
A sostegno di questo tipo di percorsi, va detto, esistono ormai specifici tool che facilitano l’integrazione dei due ambienti, migliorando anche le interfacce utente nonché la user experience dei tool di integrazione mainframe, semplificando le operazioni e facilitando i processi tecnologici (anche per skill con competenze tecniche meno approfondite).
A tal proposito suggeriamo di leggere il white paper realizzato dalla società di analisi Lustratus Research: “Best of breed mainframe integration and Soa Tools”
