In questo articolo presenteremo una classificazione delle strategie architetturali che è possibile utilizzare per l‘integrazione; concluderemo inoltre presentando i concetti delle architetture service-oriented che si propone oggi come il paradigma architetturale più indicato per lo sviluppo di sistemi informativi complessi adattabili a tutte le problematiche di integrazione, sia interna che esterna.
Introduzione
L‘integrazione non è un problema semplice. Coinvolge aspetti economici, tecnologici, culturali ed organizzativi.
L‘aspetto economico è evidenziato dal fatto che un‘organizzazione ha la necessità di evolversi e, allo stesso tempo, conservare i propri asset aziendali. Un‘organizzazione matura con un sistema informativo complesso sa che il cambiamento è inevitabile; è quindi suo compito gestirlo in modo da minimizzare l‘impatto economico.
L‘ambito del Business è in continuo e rapido cambiamento; la competizione è sempre più accesa. Le regole e gli standard impongono alle aziende una sempre maggiore reattività (basti pensare a standard come Basilea II, RFID, … o a regole come SOX …).
Oltre queste sollecitazioni “esterne”, ci sono quelle interne, che possono essere di varia natura.
Ad esempio può essere richiesto il raggiungimento di obiettivi di business come l‘aumento del profitto / ROI, la riduzione dei costi, la diminuzione del time-to-market, l‘ottenimento di una maggiore customer satisfaction.
Lo stimolo inoltre può venire anche dalla necessità del raggiungimento di obiettivi legati ai processi aziendali, come ad esempio la “velocizzazione” della produzione o della consegna, il miglioramento della qualità riducendo gli errori o i colli di bottiglia, l‘aumento della flessibilità dei processi aziendali, la possibilità di implementare nuove soluzioni di business in modo piu‘ veloce ed economico per consentire una sempre piu‘ facile modifica dei processi aziendali.
Infine può essere l‘area IT che si trova a dovere affrontare questi problemi: può nascere la necessità di integrare applicazioni esistenti ed infrastrutture IT corporate (a seguito ad esempio di fusioni, acquisizioni, out-sourcing, …) preservando ed ottimizzando sempre più gli investimenti; in questi interventi si affrontano molte questioni complesse. Alcuni esempi sono: eliminare la rindondanza di funzioni e/o dati, ridurre la complessità dei sistemi, ri-utilizzare le applicazioni esistenti, mantenere il controllo di efficienza ed il governo della struttura integrata per le attuali e future applicazioni aziendali e adottare un approccio il più possibile modulare per ridurre anche i rischi di installazione e aggiornamento di nuove applicazioni
Si hanno quindi obiettivi, visioni e interessi diversi che si devono riconciliare e che nascono dal fatto che le aziende necessitano di un continuo adattamento per sopravvivere e rimanere profittevoli: l‘obiettivo è di rispondere sempre più velocemente alle mutevoli sollecitazioni esterne ed interne.
Le domande che un‘organizzazione con obiettivi di questo tipo si pone sono:
- Come evolvo il mio sistema informativo in modo da avere un costo il più basso possibile?
- Come devo progettare e sviluppare un sistema oggi in modo che il costo dell‘integrazione sia basso domani?
- Come posso raggiungere gli obiettivi di business prefissati nel modo più “economico” e più flessibile possibile?
Esiste anche un ulteriore raffinamento del problema: con lo sviluppo della rete è diventato concreto il problema dell‘integrazione a livello business, cioè la creazione di processi B2B ottenuti componendo funzionalità che sono esposte da organizzazioni differenti. Possiamo quindi parlare di integrazione “interna” (normalmente legata ad una estensione dei sistemi con nuove o vecchie tecnologie) e integrazione “esterna”.
Per rispondere correttamente a queste domande occorre affrontare innanzitutto il problema dal punto di vista architetturale piuttosto che tecnologico.
In questo articolo presenteremo una classificazione delle strategie architetturali che è possibile utilizzare per l‘integrazione; concluderemo inoltre presentando i concetti delle architetture service-oriented (SOA) che, incoraggiando il riuso e l‘astrazione dei propri componenti (cioè i servizi), si propone oggi come il paradigma architetturale più indicato per lo sviluppo di sistemi informativi complessi adattabili a tutte le problematiche di integrazione (sia interna che esterna).
Strategie di integrazione
Classifichiamo le strategie di integrazione sulla base del livello architetturale su cui agiscono.
Possiamo supporre di avere un sistema informativo a “layer” che sia suddivisibile in:
- Data layer
- Business Layer
- Presentation Layer.
Le strategie di integrazione che considereremo sono classificabili , in prima istanza, con il layer su cui vanno ad agire. Possiamo quindi pensare di integrare a livello di presentazione, a livello di logica applicativa oppure a livello di dati.
La scelta del livello su cui si effettua integrazione è dettata da molti fattori: “raramente” però la scelta è stata consapevole, essendo normalmente guidata più da considerazioni di tipo tecnologico che architetturale (es: bisogna utilizzare un certo tipo di strumento prodotto e/o tool) .
La prima classificazione che possiamo fare sulle strategie di integrazione è:
- Portal Integration
- Enterprise Information Integration (EII)
- Enterprise Application Integration (EAI)
Questi tre possibili approcci architetturali sono volti ad aggiungere alle tradizionali applicazioni “verticali”, caratterizzate da scarsa integrazione reciproca e dalla presenza di information silos isolati, una dimensione di integrazione orizzontale che è in grado di portare ad ulteriori vantaggi di business mediante una maggiore efficienza generale dei processi aziendali ed inter-aziendali.
Portal Integration
La Portal Integration avviene a livello di interfaccia utente. Questo tipo di strategia è molto comune dato che è semplice da implementare, non è invasivo nei confronti delle applicazioni integrate e permette di effettuare in maniera semplice e rapida l‘aggregazione di sistemi molto eterogenei tra loro.
Quello che viene realizzato è un “accorpamento” di diverse applicazioni su un‘interfaccia comune. Un componente (nel caso di applicazioni web l‘Enterprise Information Portal o EIP) aggrega le di diverse applicazioni, che sono reponsabili di esporre la propria interfaccia in un modo che sia componibile dal portale (es: Portlets).
Il portale mostra quindi un‘interfaccia composta da tutte le applicazioni che integra.
Al contrario della integrazione a livello di business logic (che aggrega elaborazione di sistemi diversi), nel caso di integrazione a livello di portale le informazioni provenienti da sorgenti multiple e differenti vengono visualizzate in una singola finestra.
Questo avviene normalmente dividendo lo schermo in diverse zone ognuna delle quali comunica con un differente sistema.
Ad esempio, è possibile pensare di integrare un‘applicazione di customer-care ed un‘applicazione di gestione di dati bancari: l‘operatore può visualizzare sulla stessa interfaccia il conto corrente associato ad un utente (sulla “zona” dedicata all‘applicazione di customer-care) e effettuare delle operazioni sul conto corrente di questo utente sulla seconda applicazione (sull‘altra zona). In questo caso l‘eventuale mismatch semantico tra i dati esposti dalle due applicazioni viene risolto direttamente dall‘operatore.
Il portale diventa di fatto il punto centrale di accesso per insieme eterogeneo di applicazioni. Nel caso di applicazioni web (che è il caso più frequente) questo si realizza tecnologicamente ad esempio tramite normali tecniche HTML (frame, link o window open), oppure tramite Portlet.
Portlet: il componente applicativo di portale in J2EE
In ambito J2EE le Portlet sono state introdotte con le specifiche JSR 168 (la versione 1.0 rilasciata nell‘Ottobre 2003).
Tali specifiche definiscono:
- Il ruolo e le responsabilità del Portlet Container (cioè il portale)
- Il ruolo e le responsabilità de Portlet, che espongono le applicazioni integrate nel portale
- Il contratto tra il Container e le Portlet
- La gestione del ciclo di vita delle Portlet
- Le relazioni tra Portlet, Servlet e JSP
- I servizi middleware necessari alle Portlet.
Le applicazioni integrate possono essere esposte tramite Portlet installate su un PortletContainer. Una Portlet compatibile con le API definite dalle specifiche può essere installata su un Container compatibile con lo stesso livello di specifiche, di fatto garantendone la portabilità su portali differenti. Questo rende possibile anche l‘acquisto di Portlet da aziende esterne, integrabili all‘interno del proprio portale aziendale.
In conclusione questo tipo di integrazione è interessante nel momento in cui si richieda una soluzione veloce e non invasiva (e, di conseguenza, poco costosa). In alcune situazioni questo è sufficente e può essere una strategia vincente. In altri casi è necessario effettuare azioni più complesse, agendo sulla business logic o sull‘accesso ai dati.
EAI
Enterprise Application Integration (EAI): in questo caso ci si focalizza sull‘integrazione della logica applicativa; Lo scopo è la condivisione della logica di business tra applicazioni diverse o la composizione di “pezzi” di logica già sviluppati in processi nuovi
Al contrario della PI, dove sia i dati che la logica possono vivere indipendentemente, in questo caso parte della logica di business è necessariamente condivisa.
Possiamo classficare l‘integrazione EAI secondo due possibili approcci:
- Verticale (P2P – Point-to-Point)
- File batch / reinserimento dati
- Soluzioni applicative punto punto
- Centralizzata (Middleware-based)
- Application Server-based
- Programmatic Integration Server
- Integration Broker
- Enterprise Service Bus
In un‘integrazione Punto-Punto si costruiscono le singole connessioni tra le Applicazioni gestendo singolarmente i problemi di comunicazione e di mapping dei dati.
Il vantaggio principale dell‘approccio P2P è che in questo modo si crea una connessione “stretta” e sincrona tra le due applicazioni, con la possibilità di integrare all‘interno del codice (in modo mirato) non solo le necessarie conversioni dei dati, ma anche le regole di business.
Lo svantaggio principale è che tale codice può essere complesso da sviluppare e va generato per ogni coppia di applicazioni. All‘aumentare delle applicazioni da integrare crescono anche le connessioni da implementare e l‘accoppiamento tra di esse con evidenti impatti sui costi di manutenzione.
L‘adozione di tecnologie più sofisticate quali sistemi di Messaging, Gateway e Middleware di comunicazione consentono di semplificare le problematiche di comunicazione e supportano meccanismi sincroni e real-time.
Tale approccio può essere a sua volta “diretto” o “indiretto”.
L‘approccio più diretto prevede di utilizzare una semplice tecnologia di connessione e comunicazione, demandando allo strato applicativo (possibilmente ingegnerizzato), le ulteriori problematiche di integrazione (mapping, routing, transformation, …).
L‘approccio “meno diretto”, Middleware-based, prevede l‘introduzione di uno strato di Middleware più o meno evoluto. Tale strato, agendo da intermediario, centralizza sia le problematiche puntuali di comunicazione che quelle più ampie d‘integrazione.
EII
Enterprise Information Integration (EII): relativamente nuovo, almeno rispetto ai due precedenti, questo approccio è incentrato sull‘integrazione a livello dati. Si basa sul concetto che in alcune organizzazioni il problema non è legato tanto alla condivisione della logica quanto ad avere una modalità di accesso ai dati centralizzata, omogenea e condivisa. In questo caso si ritiene che l‘integrazione a livello di logica applicativa non sia necessaria: l‘obiettivo è avere applicazioni che agiscono sugli stessi dati, che devono essere quindi accessibili in maniera omogenea.
Questo si realizza mediante l‘uso di una serie di tecnologie tra le quali la più peculiare è quella “federation” (database federation), che implementa un concetto di “database virtuale”.
L‘EII ha l‘obiettivo di raggiungere un‘integrazione a livello dati che complementi gli altri approcci al problema generale dell‘integrazione, e sia in grado di assicurare:
- una vista completa e tempestiva ed univoca (!) su entità ed eventi critici a livello aziendale
- connettività , accessibilità e utilizzabilità dei dati a prescindere da specifiche piattaforme, database, formati (inclusi i dati non strutturati)
- consistenza a livello enterprise dei dati che sono a fondamento di applicazioni diverse tra loro correlate (ad esempio a fronte di replicazione).
L‘EII si concretizza nella realizzazione di uno strato di Middleware che da un lato sia accessibile ad ogni tipo di applicazione e tool mediante interfacce standard, e dall‘altro sia in grado di accedere ed agire su ogni tipo di dato e informazione, qualunque sia la natura, la forma (strutturata, semi-strutturata, non strutturata), la locazione fisica, fornendo sui dati stessi una serie di servizi che, superando il tradizionale acceso “a silos applicativi”, ne consentono un utilizzo ottimale da parte di ogni utente e ogni processo aziendale.
SOA e integrazione
Dall‘esperienza degli architetti sulle problematiche di sviluppo e integrazione è nata la definizione di una serie di best-practices che globalmente vengono indicate con il termine Service-Oriented Architecture (SOA).
SOA è un nuovo paradigma architetturale basato sui concetti di servizio e di processo.
La caratteristica fondamentale di questo approccio è un forte pragmatismo, orientato soprattutto alla produzione di sitstemi informativi complessi che siano nel contempo facilmente manutenibili, estendibili e integrabili.
Il presupposto che guida SOA è la considerazione che conviene sviluppare sistemi già pensando all‘integrazione (il cambiamento è inevitabile) piuttosto che adattarli volta per volta.
Un servizio è una funzionalità (con un preciso significato di business) che deve essere disegnato seguendo una serie di dettami architetturali.
Molti dei principi di SOA si sposano alla perfezione con le problematiche di integrazione. In effetti, questi dettami discendono direttamente dalla consapevolezza che, se il sistema che si sviluppa ha successo, in futuro occorrerà integrarlo. Oppure dal fatto che si ritiene necessario conservare gli asset dell‘organizzazione, in questo caso facendo esplicitamente integrazione.
L‘applicazione dei principi di SOA alle problematiche d?integrazione viene indicato con il termine Service Oriented Integration (SOI), che prevede lo sviluppo di Integration Services.
Un Integration Service ha lo scopo di fornire un?interfaccia a servizi di applicazioni esistenti portando a fattore comune funzionalità o dati trasversali alle applicazioni.
Per quanto riguarda EAI e SOA, si può dire che nell‘evoluzione generale dei sistemi IT verso la Service Oriented Architecture le funzionalità da integrare devono essere esposte tramite una logica a servizi.
Tali servizi, detti Functional Integration Service, possono permettere l‘accesso e l‘utilizzo di funzionalità di business da parte di qualunque altro servizio, applicazione o utente finale.
Per quanto riguarda invece EII e SOA, trova posto anche l‘emergere dell‘EII nel ruolo chiave di fornitore di Data Integration Service (o Information Service) a livello enterprise; in questo caso questi servizi sono resi disponibili alle altre applicazioni mediante l‘elemento portatante della SOA stessa costituito dall‘Enterprise Service Bus.
Conclusioni
Abbiamo introdotto una classificazione delle principali strategie adottate sino ad oggi nell‘ambito IT per l‘integrazione nei sistemi informativi complessi.
Queste strategie (PI, EAI, EII) differiscono tra loro in base al layer architetturale su cui si effettua integrazione. La PI (Portal Integration) effettua un accorpamento di diverse applicazioni in un‘unica interfaccia utente, l‘EAI (Enterprise Application Integration) prevede l?integrazione a livello di business-logic mentre l‘EII (Enterprise Information Integration) propone un approccio orientato ai dati.
Abbiamo inoltre presentato SOA / SOI come la soluzione architetturale più adattabile al cambiamento, introducendo concetti che si dimostrano essere ortogonali e trasversali alle strategie d‘integrazione presentate.
1M. Piraccini – S. RossiniSOA (I): IntroduzioneMokaByte 100, Ottobre 2005, https://www.mokabyte.it/2005/10/soa-1.htm2M. Piraccini – S. RossiniSOA (II): MetodologiaMokaByte 101, Novembre 2005, https://www.mokabyte.it/2005/11/soa-2.htm3M. Piraccini – S. RossiniSOA (III): Il maturity modelMokaByte 102, Dicembre 2005, https://www.mokabyte.it/2005/12/soa-3.htm4M. Piraccini – S. RossiniSOA (IV): roadmapMokaByte 103, Gennaio 2006, https://www.mokabyte.it/2006/01/soa-4.htm5M. Piraccini – S. RossiniSOA (V): SOIMokaByte 104, Febbraio 2006, https://www.mokabyte.it/2006/02/soa-5.htm6M. Piraccini – S. RossiniSOA (VI): ESB (I)MokaByte 105, Marzo 2006, https://www.mokabyte.it/2006/03/soa-6.htm
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242