Spaghetti Integration
Nell’ impresa moderna, la gestione dei dati associati al business e' distribuita su un numero variabile di sistemi informativi aziendali (EIS - Enterprise Information Systems).
Si definisce EIS qualsiasi sistema aziendale che comprende dati, informazioni e processi necessari all'azienda per la gestione del proprio business.
I sistemi EIS:
- Gestiscono aree indipendenti e separate di informazioni aziendali (CRM, OM, Marketing, ERP, Finance, Billing, Portal, SelfCare...)
- Tendono ad espandersi in modo spesso disordinato e scorrelato
- Sono estremamente eterogenei tra loro in termini di: rappresentazione dei dati, modellizzazione dei processi aziendali, interfacce.
I primi tentativi di integrazione, originati dalla necessita' di stabilire una interconnessione ad-hoc point-to-point tra sistemi, hanno portato a un modello di integrazione povero e inutilmente complesso, soprannominato Spaghetti Integration.
Riassumendo, gli aspetti negativi della Spaghetti Integration sono:
- Specifiche di integrazione definite in modo disordinato dai referenti dei singoli sistemi (gruppi di lavoro differenti) e non seguendo direttive comuni
- Molteplicità di protocolli e dI tecnologie utilizzate
- Lentezze nello sviluppo e nella manutenzione delle integrazioni per i flussi Enterprise (processi dati che impattano su diversi sistemi della architettura IT)
- Difficoltà nel controllo di processi e flussi che attraversano la catena dei sistemi
- Impossibilità di avere una governance centralizzata.
Enterprise Application Integration
L’ Enterprise Application Integration (EAI), il cui Il concetto chiave e' la centralizzazione delle comunicazioni e delle funzionalita', e' il primo approccio alla soluzione per una integrazione corretta ed efficente.
Questo approccio, la cui diffusione ha inizio nella seconda metá degli anni 90, prevede un layer applicativo centrale (Middleware) che funge da intermediario nelle comunicazioni tra i sistemi e fornisce servizi MOM (Message Oriented Middleware) di piattaforma di base (messaging, load balancing, fault tolerance, transazionalita'...).
I sistemi risultano in questo modo debolmente accoppiati, in quanto non devono piu' comunicare direttamente l'uno con l'altro, ma unicamente tramite un Broker di integrazione preposto al routing dei messaggi (modello hub-and-spoke).
Al fine di razionalizzare il numero e il tipo di connessioni tra i sistemi e, conseguentemente, le attivita' aziendali, i principi cardine dell'EAI sono i seguenti:
Integrazione dei processi di business
- Transazioni di business che coinvolgono molteplici EIS devono essere trattate come unita' logiche
- Per l'implementazione di tali transazioni di business, deve essere possibile definire Workflow complessi che coinvolgano molteplici EIS
- Eventi di business devono poter scatenare azioni globali che si estendano oltre il dominio del singolo EIS
Integrazione delle applicazioni
- Le funzionalita' di business implementate da un'applicazione devono essere esposte e rese disponibili alle altre applicazioni
Integrazione dei dati
- I dati devono essere condivisi e distributi attraverso molteplici EIS differenti
- Devono essere garantiti l'allineamento e la consistenza dei dati
Con l'adozione da parte delle imprese di metodologie e tecnologie di integrazione EAI, si riscontrano i seguenti benefici:
- Razionalizzazione dei flussi e degli sviluppi
- Maggiore disponibilita' delle informazioni distribuite attraverso le isole applicative aziendali
- Risposte piu' rapide alle nuove opportunità di business con conseguente riduzione del Time-to-Market
- Maggiore efficienza e migliore qualità dei servizi offerti
- Maggiore controllo sui processi di business
- Un supporto piu' efficace ai processi decisionali aziendali
- Un aumento dell'efficienza dei processi aziendali nel loro complesso.
Da EAI a SOA (Service Oriented Architecture)
L'approccio EAI si e' dimostrato vincente nel fornire soluzioni efficienti di integrazione, ma esistono alcune limitazioni nell'architettura EAI che ne limitano la capacita' di fornire una soluzione completa al problema dell'integrazione aziendale:
- Architettura monolitica: soluzione server-centrica, centralizzazione dei processi di integrazione, architettura Hub-and-Spoke
- API proprietarie, formati chiusi/non-standard
- Modalitá di integrazione vincolata alle caratteristiche del MOM utilizzato
- Architettura chiusa verso il mondo esterno (business partner, clienti), difficilmente accessibile dalla extranet
- Soluzione che lega le aziende a prodotti specifici e soluzioni proprietarie non standard offerte dai vendor EAI
- I progetti di integrazione in StartUp hanno una lunga durata (20+ mesi) per introdurre il middleware nella architettura generale ed adeguare tutti i sistemi.
A partire dai primi anni 2000 all'interno delle aziende con una IT complessa ed evoluta, si è iniziato a parlare di integrazione di sistemi e processi mediante un approccio a servizi, ma solo qualche anno più tardi si realizzeranno soluzioni di buon livello.
La SOA (Service Oriented Architecture) separa le funzionalita' di un EIS raggruppandole in un insieme di componenti ad alto livello che espongono "porzioni" di logica di business sotto forma di servizi accessibili attraverso interfacce documentate e tecnologie standard. Quindi non più una metodologia di integrazione basata su un middleware tecnologico unico che veicola le informazioni, ma un approccio più Open, basato sul rispetto degli standard, quali XML, JSON, Web Services, Http/SOAP, REST, J2EE, etc., che consente il disaccoppiamento (decoupling) dei protocolli di comunicazione e la fruizione di servizi che implementano workflow di processi più o meno complessi.
La messa in opera della SOA in un contesto IT Enterprise prevede, oltre alla adozione di best practices e standard, la messa in campo di alcuni moduli applicativi fondamentali di cui il più importante è l'ESB (Enterprise Service Bus).
L'ESB rappresenta una nuova tipologia di BUS che combina Web Services, messaggistica e servizi di integrazione di base quali la trasformazione dati, il disaccoppiamento dei protocolli e il content-based routing (routing su base contenuto).
La sua architettura lo rende indipendente dagli Application server, MOM e protocolli utilizzati, pertanto risulta particolarmente adatto a costituire in modo progressivo la struttura portante di una nuova integrazione orientata ai servizi che nel contempo preservi, interoperando con esse, le risorse IT pre-esistenti quali applicazioni legacy e piattaforme di middleware eterogenee.
L'ESB permette di adottare una strategia di integrazione progressiva che fornisce la possibilita' di costruire, in maniera incrementale e a costi minori, una rete di integrazione aziendale.
Altri strumenti abilitanti per una architettura SOA completa sono:
- BPM (Business Process Management), design e orchestration dei servizi come workflow
- BAM (Business Activity Monitoring), monitoring dei servizi e dei processi di business
- Service Registry, registro dei servizi esposti dall'ESB con definizione dei contratti di protocollo (wsdl).
Una architettura IT orientata ai servizi, flessibile e disaccoppiata, riduce i tempi e i costi di manutenzione dei progetti, nonche' le necessita' di customizzazione ed evoluzione degli stessi a fronte di nuovi requisiti di integrazione.
I principali vantaggi per l'azienda sono:
- Razionalizzazione delle informazioni e dei processi nell'area aziendale
- Riutilizzo delle funzionalità/servizi
- Aumento della efficenza/qualita' del servizio
- Centralizzazione della Governance
- Drastica diminuzione del Time-To-Market
- Riduzione del TCO (Total Cost of Ownership) grazie alla dismissione progressiva di middleware vendor locked.
Comparativa sui costi
Il grafico illustra le differenze di costo dei diversi approcci nelle varie fasi di vita di un progetto software.
Risulta evidente come un' approccio Custom point-to-point abbia dei bassissimi costi iniziali per realizzare le prime integrazioni tra i sistemi ma poi con il passare del tempo aumenta la complessità di manutenzione ed evoluzione con conseguente aumento di costi e tempi.
Un approccio di tipo EAI invece, similmente a quello basato sull'utilizzo da parte dei sistemi di Web Services standard ma senza una infrastruttura ESB, ha dei costi di realizzazione iniziale medi, garantisce successivamente dei costi abbastanza contenuti nella manutenzione della infrastruttura ma necessita di un effort con dei picchi molto alti per la realizzazione di nuovi flussi Enterprise o la modifica di processi già esistenti,
Utilizzando i paradigmi e gli strumenti SOA invece si rileva un impegno considerevole nell'introduzione e sviluppo iniziale della infrastruttura di base, ma un progressivo risparmio nelle fasi successive dovuto alla capacità di riutilizzo dei servizi (Service Reusability) e della loro orchestrazione (Service Orchestration).
La SOA di ultima generazione
Nel periodo che va dal 2004 al 2010, un po' tutte le aziende medio-grandi, con a disposizione un parco di sistemi informatici importante, ha intrapreso un percorso di adeguamento dell'architettura dei sistemi ai paradigmi della SOA.
Nel tempo la Service Oriented Architecture è diventata quasi un tormentone, passando da essere un "must have" ad una locuzione passata un po' di moda.
Questo ciclo di vita è stato storicamente percorso da gran parte delle proposte tecnico/informatiche che, da essere spinte commercialmente, adottate con grandi sforzi economici e pubblicizzate oltremodo in alcuni casi anche in contesti non idonei, diventano soluzioni un po' dimenticate, anche se mai completamente portate a termine per arrivare a beneficiarne dei vantaggi.
In un mondo IT che almeno in apparenza evolve a grandi velocità, diventa fondamentale per continuare ad attrarre investimenti, la proposizione continua di nuove soluzioni agganciate a slogan in voga che riescono a smuovere almeno un minimo il mercato anche in ambiti enterprise ormai consolidati.
Tuttavia di fatto la SOA resta l'approccio più valido per l'interpretazione dei requisiti di integrazione e di gestione dei processi di business anche se nel maggior parte dei contesti non è stata adottata con una pervasività ed un livello di maturità sufficiente; il termine "servizio" in ambito IT è diventato sinonimo di funzionalità offerta sulla rete in un contesto di cooperazione applicativa tra i sistemi.
Negli ultimi anni, grazie al perfezionamento degli strumenti e ad una maggiore esperienza maturata da Solution Architect e System Integrator, è aumentata la capacità di rilasciare soluzioni stabili, proponendo all'interno della infrastruttura di base della SOA anche degli "accessori" utili a migliorare le performance di risposta ai servizi.
Data Caching
Con il Data Caching la piattaforma di integrazione ESB si dota anche di funzionalità di memorizzazione in cache dei flussi dati provenienti dai sistemi client e server, in modo da velocizzare quando possibile l'accesso alle informazioni ed i tempi di riposta ai servizi.
La memorizzazione dei dati viene demandata a layer applicativi fortemente scalabili in cache chiamati InMemory DB, Data Grid Memory o Data Service Layer che si occupano anche di gestire l'invalidazione dei dati stessi, secondo delle policy pre-definite, ed il loro ricaricamento dai sistemi owner mediante interazione con i servizi di integrazione dell'ESB.
Rule Engine (motore a regole)
Un altro modulo applicativo accessorio che sempre più spesso viene affiancato ai componenti infrastrutturali della SOA è il Rule Engine: motore a regole configurabile ed estendibile in grado di interagire con i servizi ESB per la interpretazione di algoritmi complessi applicati ai dati. Avere un Rule Engine risulta molto utile quando è necessario implementare operazioni di routing numerose e complesse difficilmente configurabili all'interno dell'ESB o del BPM.
Articoli correlati:
