MISTERO SOA Le applicazioni orientate ai servizi

MISTERO SOA
Le applicazioni orientate ai servizi:
suggerimenti, spiegazioni e scenari per il loro utilizzo
nelle imprese
a cura della redazione di Computerworld Italia
ICT e R&S >> Applicazioni, linguaggi e sistemi operativi
www.intesasanpaoloimprese.com
Sommario
L'ABC della SOA..................................................................................... 4
E' questione di maturità?......................................................................... 8
Quando i web services sposano i sistemi legacy........................................ 10
Glossario............................................................................................. 11
Pagina 2 di 11
www.intesasanpaoloimprese.com
Introduzione
Spiega un esperto di tecnologia: “La Service Oriented Architecture (SOA) non è una nuova
tecnologia rivoluzionaria che richiederà di spezzare, rimpiazzare o ristudiare tutto ciò che già si
conosce. SOA è piuttosto un passo evolutivo in un percorso di interoperabilità, rappresentando
una buona notizia per un qualsiasi dirigente business o dei sistemi informativi che sogni di
avere a disposizione un framework tecnologico sufficientemente flessibile da poter andare
incontro ai processi di business del mondo reale”. Bello, ma di cosa si tratta in realtà nel
dettaglio? Quando conviene adottare un'architettura orientata ai servizi? Il dossier di questo
mese parte quindi con una serie di ‘Domande e risposte’ sui suoi concetti di base, per non dare
per scontato nulla sull'argomento.
Proseguendo, attualmente le argomentazioni che spingono verso l’adozione delle Service
Oriented Architecture sono molteplici: di volta in volta gli analisti sottolineano l’utilità delle SOA
come forma di integrazione ‘leggera’ fra aziende e fra sistemi informativi, come strumento per
gestire in modo più flessibile i processi, come abilitatore di strategie multicanale e via dicendo.
Se una SOA diventa una vera e propria topologia software dei servizi IT aziendali, nuovi o
legacy che siano, diventa però essenziale progettarla e realizzarla in un modo molto più
organizzato di quanto non siano oggi le attività di sviluppo e di gestione del parco applicativo
d’impresa. Vediamo perché.
Infine, il tema integrazione per quelle realtà dotate di sistemi consolidati da tempo. Di fatto
mainframe e sistemi legacy hanno posto ai responsabili IT molti grattacapi nel decennio
passato, per far fronte alle necessità di aggiornamento del software, ma anche per le nuove
richieste del business e di servizi per il web. Il reparto IT si è trovato nella condizione di dover
affiancare i sistemi host con le componenti open più adatte a supportare le nuove applicazioni.
Malgrado la forte spinta al cambiamento, molte aziende non hanno avuto le risorse o talvolta la
necessità di rimpiazzare mainframe e altri sistemi informativi su cui avevano investito nel corso
degli anni. Una situazione che ha fatto esplodere i problemi d'integrazione.
Pagina 3 di 11
www.intesasanpaoloimprese.com
L'ABC DELLA SOA
Questa sigla riempie giornali, dibattiti e convegni. Oltre le promesse e i numeri
scarsamente controllabili, cerchiamo di capirci qualcosa
Un avvertimento: la breve introduzione che segue non è farina del nostro sacco. E’
semplicemente quello che si trova scritto o viene detto oggi nella grandissima parte degli
articoli che riguardano la SOA. E che più o meno cominciano così. “Il concetto di Service
Oriented Architecture è ormai nell’agenda di tutti i CIO perché promette di fornire un modo più
rapido di costruire e adattare le funzionalità di un software e mettere in produzione nuovi e più
flessibili processi”. Gli articoli e i discorsi proseguono richiamando i numeri impressionanti
forniti da questo o quell’istituto specializzato; per esempio quelli che indicano che “tutte le
oltre 300 organizzazioni intervistate in un apposito sondaggio hanno già avviato iniziative sul
fronte SOA o dicono di averle programmate entro un massimo di due anni”.
Puntualmente ricordano che “un approccio di tipo SOA permetterà finalmente di abbattere le
barriere che ancora separano l’IT dal business aziendale” e per dar più forza a queste
promesse ricorrono un’altra volta alla forza dei numeri che indicano, a favore del modello SOA,
una riduzione del 25% dei costi di sviluppo di cui potranno avvantaggiarsi le maggiori 2000
aziende nei prossimi 3 anni”. E così via, per pagine e pagine.
Sono solo alcuni degli stereotipi che, conditi dell’enfasi necessaria, oggi accompagnano la SOA.
Altrettanto è accaduto con il web e ancora prima con il client-server, l’object oriented e così via
a ritroso. Tante attese, promesse più o meno mantenute, qualche disillusione.
Se qualche lezione possiamo dire di avere appreso dal passato, è proprio quella di non dare
niente per scontato. Per questo allora meglio partire chiarendoci le idee almeno sui concetti di
base e lasciando perdere promesse, frasi apodittiche e scenari futuribili.
Ecco perché abbiamo scelto, tra le tante cose che si potevano pubblicare sull’argomento, di
iniziare il dossier con questa serie di ‘Domande e risposte’ sui concetti di base. Sono le cose di
cui più spesso sentiamo parlare in giro, a volte dando per scontati concetti, sigle e conclusioni
che scontati non sono affatto.
Cos’è una Service Oriented Architecture (SOA)?
Service Oriented Architecture è un’espressione ambigua perché descrive due cose diverse. Le
prime due parole indicano un metodo di sviluppo software. La terza indica l’insieme delle
tecnologie e applicazioni software di un’azienda. Per ‘SOA’ quindi si intende una strategia
mirata a sviluppare tutte le applicazioni software dell’azienda usando metodi di
programmazione orientati ai servizi.
Cos’è un servizio?
I servizi sono ‘pezzi’ di software costruiti in modo da essere integrati facilmente con altri
componenti. L’idea è semplice: la tecnologia deve essere disponibile in ‘pezzi semplici’ di
codice software condivisibili e utilizzabili in diverse parti dell’azienda. Questo si può ottenere
‘confezionando’ il codice in un complesso ‘guscio’ che descrive ciò che fa il componente, e
come connettersi a esso. E’ un concetto che risale agli anni ‘80, quando si parlava di
programmazione object oriented.
La differenza è che stavolta gli ‘oggetti’ software sono molto più grandi e sofisticati. Nella
compagnia telefonica Verizon il servizio ‘get CSR’ (richiedi il record dei servizi al cliente) è un
complesso pacchetto di operazioni software ed estrazioni di dati che usa l’infrastruttura
d’integrazione di Verizon per accedere a 25 sistemi in quattro data center sparsi negli USA. In
precedenza, ogni volta che Verizon implementava una nuova applicazione o funzione di CRM,
gli sviluppatori dovevano creare delle interfacce per tutti i 25 sistemi.
Ora il servizio ‘get CSR’ risiede in un repository centrale nella intranet di Verizon, e gli
sviluppatori possono semplicemente usare il protocollo SOAP e costruire un link singolo
all’interfaccia che ‘avvolge’ il servizio: in tal modo i 25 sistemi iniziano a ‘marciare’ insieme
Pagina 4 di 11
www.intesasanpaoloimprese.com
Le cinque promesse che spingono
verso un'architettura SOA
inviando i dati dei clienti alla nuova applicazione e
risparmiando mesi di lavoro di sviluppo ogni volta.
Qual è la differenza tra SOA e web services?
Ci sono molti modi di collegare i servizi: interfacce
sviluppate internamente, software di integrazione EAI,
ecc. Dal 2001 però viene sempre più usato un insieme di
meccanismi software di comunicazione detti web
services, e basati sul World Wide Web. La SOA quindi è
una strategia generale per lo sviluppo di tutte le
applicazioni software di un’azienda con la metodologia
service-oriented. I web services invece sono un metodo
di collegamento, cioè un insieme di meccanismi standard di comunicazione basati sul www.
1 Raggiungere maggior flessibilità nei
processi aziendali
2 Costi ridotti nell’integrazione delle
applicazioni esistenti
3 Costi ridotti nello sviluppo di nuove
applicazioni
4 Minor tempo per sviluppare nuove
applicazioni
5 Minor tempo per mantenere le
applicazioni esistenti
Come faccio a capire se per la mia azienda è utile una strategia fondata sulla SOA?
La SOA va ben al di là del solo sviluppo software. Richiede una visione unificata a livello
aziendale dell’architettura IT e del metodo di sviluppo, uno staff centrale di project manager,
architetti e programmatori, e un repository centrale per i servizi, che devono essere ben
documentati. Ma soprattutto la necessità per l’IT di capire nel dettaglio e riprodurre i processi
di business aziendali. Perciò la condivisione, e soprattutto la governance, sono fondamentali:
occorre facilitare il riuso, evitare che lo stesso servizio sia sviluppato più volte per settori
aziendali diversi, e fissare dei livelli di performance. A tale scopo, molte aziende hanno creato
un ‘team SOA’, che decide – in concerto con le varie aree aziendali – quali processi supportare
con i servizi, e mette a punto i meccanismi di governance.
Finora le migliori strategie SOA sono in aziende con alti budget IT e business basati sulle
tecnologie, come le telecom e i fornitori di servizi finanziari. Non a tutti, però, conviene una
strategia SOA. Le realtà piccole, o fortemente decentralizzate, o che hanno già avviato serie
strategie di integrazione applicativa o hanno puntato tutto su una grande suite software
integrata, devono soppesare seriamente vantaggi e svantaggi. Il problema principale è che una
strategia SOA non si può portare avanti per piccoli passi: lo sviluppo di un singolo servizio
dev’essere sempre coerente con il piano architetturale generale, che a sua volta deve tener
conto della strategia di business aziendale.
Quali sono i vantaggi di una SOA?
Una SOA è prima di tutto uno strumento per ridurre complessità e ridondanze. E’ difficile che
possa essere utile se la vostra azienda non è grande e/o complessa. Dev’essere ben chiaro che
il metodo di sviluppo service-oriented, in sé, non porta benefici. Secondo gli esperti, una buona
soluzione service-oriented richiede più lavoro dell’integrazione applicativa tradizionale, quindi
per essere conveniente deve eliminare sforzi e costi da qualche altra parte, per esempio
consolidando o eliminando insiemi di applicazioni ridondanti e poco integrate. Per avere il
quadro completo dei benefici possibili di una SOA, comunque, bisogna considerare due livelli: i
vantaggi tattici dello sviluppo orientato ai servizi e quelli complessivi di una strategia
architetturale enterprise.
Nel primo caso, i benefici sono di tre tipi: riuso del software, aumento della produttività,
maggiore flessibilità dei sistemi IT. Se prendiamo una compagnia telefonica con quattro
divisioni, ciascuna con il suo sistema di gestione ordini, questi sistemi avranno alcune funzioni
simili, come il controllo crediti e la ricerca dei record dei clienti, ma spesso non condivisibili.
Con lo sviluppo service-oriented si può creare una versione di ‘controllo del credito’
condivisibile da tutti i sistemi.
Il servizio può essere composto di codice totalmente nuovo, o preso da alcuni o tutti i sistemi:
non conta il grado di complessità, conta solo che la prossima volta che un’applicazione
necessiterà della funzione ‘credit check’, basterà creare un link al servizio.
I punti critici sono due. Uno è assicurare il riuso: occorrono appositi meccanismi di governance.
L’altro è dimensionare il servizio (granularità), che va accuratamente definito proprio per
facilitare il riuso.
E’ una delle maggiori difficoltà di una strategia SOA: allo stato attuale, dice Gartner, solo una
quota tra il 10% e il 40% dei servizi viene realmente riutilizzata.
Pagina 5 di 11
www.intesasanpaoloimprese.com
Quanto agli aumenti di produttività, il riuso dei servizi
significa maggiore velocità dei progetti di sviluppo,
nonché risparmi sui costi d’integrazione (almeno del
1 Definire che cosa è una SOA e
30%, secondo Gartner). Nel caso di Verizon e del suo
imparare a progettarla
servizio per il processo di gestione degli ordini di nuove
2 Passare alla nuova architettura e alle
linee telefoniche, “con l’integrazione punto-a-punto ci
nuove metodologie lavorando nel
voleva un team di progetto centrale per scrivere
business corrente
3 Riarchitettare l’ infrastruttura per
l’interfaccia generale, e poi dei team locali per ciascuno
supportare la SOA
dei sistemi da integrare – spiega il vice president
4 Cambiare le metodologie di sviluppo
Shadman Zafar -; con il servizio phone-line abbiamo
per adeguarle alla SOA
bisogno di un solo team che deve fare solo un lavoro di
5 Cambiare le strategie di governance
per supportare la SOA
testing”.
Anche se i servizi non vengono riutilizzati, possono
ugualmente convenire. Un esempio è ProFlowers.com, che ha spezzato la gestione ordini in
diversi servizi, su ciascuno dei quali si può intervenire senza toccare gli altri per gestire i picchi
di domanda. Il sistema monolitico precedente richiedeva un enorme lavoro di riscrittura del
codice, il nuovo invece ricolloca la capacità di storage ai vari servizi in funzione del bisogno ed
è molto più flessibile: ha eliminato le indisponibilità di sistema dovute ai sovraccarichi.
Passando ai benefici di una strategia architetturale a livello enterprise, uno è il miglior
allineamento con il business. Le persone del business possono ‘vedere’ come i loro processi e
attività sono riprodotti dalle tecnologie in modo molto più immediato delle complesse
applicazioni software tradizionali. Tra qualche anno, saranno forse in grado anche di comporre
da soli i servizi a disposizione, senza ricorrere a tecnici. Un altro vantaggio è la possibilità di
‘vendere’ meglio al business il concetto di architettura enterprise, che per le valenze molto
tecniche e i ritorni difficili da definire è sempre stato piuttosto malvisto fuori dal dipartimento
IT. Ora invece concetti come il riuso e la tecnologia ‘cablata’ sui singoli processi lo rendono
molto più ‘vendibile’. Sempre a patto di ricordare che una strategia SOA non conviene a tutti.
I cinque maggiori ostacoli
all'adozione di una SOA
Come bilanciare i tempi lunghi di pianificazione di una SOA con la necessità di
portare velocemente valore al business?
La pianificazione di un’architettura richiede tempo. Lo sviluppo service-oriented invece si basa
su concetti e standard tecnologici ben conosciuti (SOAP, HTTP, ecc.) e può essere molto più
veloce. Le due cose però, dicono gli esperti, devono andare in parallelo. E’ importante mettere
a punto piccoli servizi e nel contempo portare avanti il piano architetturale, la mappatura dei
processi e lo sviluppo di servizi enterprise su tutta l’impresa. Concentrarsi soltanto su una
strategia pluriennale può far fallire tutto, perché occorre anche presentare dei risultati nel
breve termine.
Come scegliere i servizi che possono produrre il massimo valore per la mia azienda?
Nel dubbio, iniziate dai processi che riguardano direttamente i clienti o le vendite, e/o da quelli
che toccano direttamente un punto critico del vostro business. “I processi rivolti all’esterno
sono quelli che apportano il maggior valore, e di solito cambiano molto spesso – spiega Daniel
Sholler, vice president di Gartner -: un 10% di miglioramento qui porta più valore di un
progresso del 50% in aree back office. Non sempre SOA dà più valore di un buon pacchetto,
ma se si deve comunque sviluppare, è meglio farlo in modalità service-oriented”.
Che impatto ha la SOA sulla funzione IT?
Una SOA richiede e crea centralizzazione: il lavoro di sviluppo va attentamente controllato e
guidato. Man mano che il portafoglio di servizi cresce, il processo di sviluppo inizia ad
assomigliare a una catena di montaggio, e la produttività dei programmatori aumenta. Un
approccio SOA poi richiede molte competenze e professionalità nuove, per cui occorre un forte
investimento in formazione. Secondo una recente ricerca di CIO e Computerworld USA, solo il
25% delle aziende ritiene di disporre già delle competenze più adatte a implementare una
SOA.
Pagina 6 di 11
www.intesasanpaoloimprese.com
E' QUESTIONE DI MATURITÀ?
Diversi approcci alla
implementazioni SOA
qualità
dei
processi
possono
applicarsi
anche
alle
Dal punto di vista delle metodologie di sviluppo, affrontare le SOA e i web services significa
gestire in maniera più rigida il processo di creazione del codice. Ragionando a livello di singoli
servizi da veicolare in rete e non di applicazioni monolitiche ciò che conta sono le interfacce:
ogni servizio mostra la sua, che deve essere consistente con quella degli altri. Bisogna essere
‘disciplinati’ nella programmazione, restando aderenti alle specifiche di progetto e ai flussi di
processo che si sono definiti all’inizio dell’implementazione.
Non stupisce quindi che negli ultimi tempi, quando si tratta di architetture orientate ai servizi,
si parli molto più che in passato dei modelli e dei processi che possono portare ‘qualità’, in
senso lato, nell’implementazione del software. Per le SOA stanno in particolare avendo una
certa diffusione i ‘maturity model’ che valutano la ‘maturità’ dell’azienda utente in quanto a
implementazione e diffusione delle architetture orientate ai servizi. Sono modelli - proposti da
fornitori di settore, analisti e consulenti - tutti buoni per capire dove si è rispetto a dove si
vuole arrivare e per dare una certa disciplina allo staff IT. Con una premessa importante, però:
i maturity model e le SOA possono certamente essere collegati, ma non bisogna mai
dimenticare che modelli di questo genere nascono soprattutto per valutare i processi, mentre
chi lavora sulle SOA è interessato soprattutto alla valutazione delle architetture software e
delle loro implementazioni.
La triade della qualità
Tre approcci riconosciuti dal mercato alla qualità dei processi si dividono in questo momento
l’attenzione delle software house e dei dipartimenti IT: CMMI, CobiT e ITIL.
Il Capability Maturity Model Integration (CMMI) parte dal presupposto che la qualità di un
sistema, e quindi anche di un’architettura software, dipende dalla qualità del processo usato
per implementarlo. In questo senso è un modello di riferimento che permette a un’impresa di
collocare la qualità di un suo processo o dell’impresa nella sua globalità in una ipotetica scala,
dando in più le indicazioni necessarie per migliorare. Nella visione ‘a stadi’ del CMMI si valuta il
livello di maturità globale dell’azienda o di una sua parte, in una scala a cinque step (Initial,
Managed, Defined, Quantitatively Managed, Optimizing).
Il modello si può applicare anche alla implementazione di una SOA? Sì, tanto che alcuni
fornitori IT ne hanno creato un derivato specifico battezzato proprio SOA-MM (SOA Maturity
Model). Ma non è, come dicevamo in precedenza, il solo. CMMI nella parte di sviluppo del
software riprende concetti già collaudati dagli anni Settanta, quando i linguaggi e gli strumenti
di programmazione erano complessi e prima di scrivere codice veniva fatta un’analisi
funzionale e tecnica molto accurata.
E’ ben diverso l’approccio di CobiT: la metodologia Control Objectives for Information and
related Technology è incentrata sul controllo ex-post più che sull’analisi preventiva delle
implementazioni. CobiT, spiega Paolo Pasini, Vice Direttore Area Sistemi Informativi di SDA
Bocconi, “Spinge a ragionare in una logica di produzione dei servizi applicativi, a crearne un
catalogo in una logica di mercato: chi li ‘comprerà’ in azienda? Ciascuna delle sue aree diventa
un’area di misurazione di quello che faccio e genera i suoi indicatori chiave”. Per chi guarda
alla implementazione delle SOA il fulcro di CobiT è infatti rappresentato da un sottoinsieme
della parte di Framework, la quale prevede una trentina obiettivi di controllo ad alto livello.
Alcuni di essi sono collegabili all’infrastruttura IT e a come essa rispecchi e supporti i processi
aziendali. Dato che non tratta direttamente lo sviluppo software, non fornisce roadmap
immediate per il miglioramento continuo dei processi informatici: il modello va ‘digerito’ e
declinato in base alle proprie peculiarità.
Pagina 7 di 11
www.intesasanpaoloimprese.com
L'IT che cambia
Con le società che si affidano sempre più a
implementazioni SOA, la gestione di servizi
applicativi di qualità si sta facendo disciplina critica
per l'IT. "E' una battaglia che è in corso, poiché si
deve continuare a mantenere la connessione tra le
esigenze di business e quello che realmente il
software fa, e tali esigenze cambiano sempre",
spiega Jason Bloomberg, senior analyst di ZapThink.
Certamente l'idea che sta dietro una SOA è quella di
costruire un'infrastruttura che abiliti composizioni di
servizi software in genere poco connessi tra loro
per, ad esempio, scambiarsi dati o coordinare
funzioni di business. E le imprese stanno iniziando a
comprendere il concetto che vi si cela dietro. Nel
2010 almeno il 65% delle grandi organizzazioni
avranno infatti più del 35% dei propri portafogli
applicativi basati su SOA, contro meno del 5% che
c'erano nel 2005, prevede Gartner.
Nel frattempo le aziende stanno scoprendo che il
testing non è la sola area dell'IT che potrebbe
richiedere un cambiamento. Progettazione,
implementazione e gestione delle applicazioni
basate su servizi sono infatti qualcosa di molto
differente rispetto al lavorare con le applicazioni
tradizionali su più livelli. Per gestire tali
cambiamenti, i professionisti stanno quindi
estendendo i rispettivi set di strumenti con software
che diano una visione più chiara dei dettagli, ad
esempio a livello di transazioni, mentre chi si occupa
di rete sta prendendo in considerazione l'utilizzo di
appliance che possano occuparsi dei carichi
elaborativi su XML (Extensible Markup Language). E
sul mercato sono in tal senso diverse le proposte
che offrono strumenti di testing e validazione SOA,
gestione delle policy e loro applicazione, nonché
apparati per la sicurezza e l'elaborazione XML.
L’Information Technology Infrastructure
Library, o ITIL, è un approccio alla qualità
dell’IT che oggi gode di una popolarità simile a
quella di CMMI, anche perché un po’ tutti i
produttori di software per il system o il
business service management stanno
inserendo le best practice ITIL nelle proprie
piattaforme. ITIL è in effetti proprio questo: un
insieme di best practice e linee guida che
coprono vari aspetti dell’Information
Technology in azienda e che,
conseguentemente, possono essere adattate
anche all’implementazione delle SOA. Il
framework ITIL è diviso in otto macrosezioni,
ciascuna delle quali può avere un collegamento
con i processi di implementazione di
middleware.
Cambiare pesa
Le esperienze mostrano che tutti i modelli
indicati comportano, in diversa misura, un
cambiamento culturale nello staff IT, specie se
questo non ha sperimentato in passato
metodologie particolarmente attente alla
qualità dei processi informatici.
Proprio la resistenza al cambiamento è
l’ostacolo più frequente alla diffusione di questi
approcci: è facile pensare che seguire certe
prassi, per quanto positive, non è
indispensabile quando si hanno persone
qualificate o tecnologie ad alto livello. E’
altrettanto facile impuntarsi sul fatto che le
prassi siano un limite alla creatività o alla velocità di risposta alle esigenze degli utenti esterni
o interno. Per tutti questi motivi ci vuole una forte sponsorship dei vertici che attraversa il
middle management e arriva sino ai singoli.
Pagina 8 di 11
www.intesasanpaoloimprese.com
QUANDO I WEB SERVICES SPOSANO I SISTEMI LEGACY
Le opportunità per riutilizzare dati e logica di business su host negli ambienti
orientati ai servizi
Con lo sviluppo delle service oriented architecture (SOA) basate su web services, l'integrazione
sta diventando una componente strutturale delle nuove infrastrutture aziendali, ed è naturale
che molti responsabili IT guardino in questa direzione per integrare i dati da host mainframe.
I modi d'integrazione possono essere differenti anche se il più tipico, che non richiede
interventi sulle applicazioni originali, prevede l'utilizzo dello 'screen scraping' (cattura di
schermo). Un tool commerciale permette di esporre la logica delle applicazioni legacy come
componente COM (Component Object Model), Java, .Net o web service. Componenti che
possono essere usati in applicazioni web o sfruttati, per esempio, nell'ambito del CRM
(Customer Relationship Management).
Gli adattatori permettono agli utenti azioni 'punta e clicca' per collegare le funzioni legacy
come componenti SOA. L'esposizione dei servizi legacy come web services consente inoltre il
riuso delle funzioni, per esempio, per riproporre visure specifiche dei dati clienti a operatori
diversi nell'ambito delle vendite o della contabilità.
Altre componenti tecnologiche utilizzabili vengono impiegate da alcune realtà utenti per
integrare dati CICS verso applicazioni client, come per esempio un foglio elettronico. I dati
possono così essere utilizzati dagli operatori di un call center per avere informazioni in tempo
reale sullo stato dei clienti, mentre il foglio elettronico consente di impostare calcoli su tasse e
sconti. In passato queste elaborazioni avrebbero richiesto la scrittura di codice COBOL
dedicato.
Comprimere i tempi
Usare i web services per accedere a dati e logica applicativa su sistemi legacy può
drasticamente ridurre il tempo necessario per integrare i dati con le nuove applicazioni.
Secondo gli osservatori i tool sul mercato sono in grado di ridurre da sei a dieci volte il tempo
di un progetto d'integrazione a livello d'impresa. La necessità d'integrare a livello globale i
processi di ammortamento ha portato alcune realtà a creare un'interfaccia web services al
mainframe per il call center. Questo approccio non solo ha permesso l'integrazione, ma ha
consentito di rendere più semplici i processi di migrazione. Il livello di astrazione consente
infatti all'impresa portare avanti una strategia incrementale di aggiornamento.
Secondo un analista di Forrester Research la capacità di gestire migrazioni mentre i sistemi
continuano a erogare servizi è il motivo principale che rende i web services interessanti. "Le
aziende sanno che possono essere necessari degli anni per rimpiazzare totalmente i sistemi
esistenti. Con i web services è possibile isolare le componenti funzionali e quindi facilitare la
sostituzione". Secondo Forrester ci sono però alcune applicazioni che non traggono vantaggio
dall'esposizione come servizio: "Per esempio quelle che operano in tempo reale. Non è inoltre
possibile gestire in questo modo dei numeri elevatissimi di transazioni al secondo".
L'integrazione dei dati legacy attraverso le interfacce dei web services non elimina la necessità
di dover inserire nel processo dei sistemi per la trasformazione dei dati. In ogni caso,
comunque, i web services costituiscono un punto di arrivo per l'integrazione legacy.
Pagina 9 di 11
www.intesasanpaoloimprese.com
GLOSSARIO
ASP
Application Service Provider. Fornitore che consente l'utilizzo di un'applicazione da remoto
residente all'interno del suo data center e pagabile in diverse modalità: canone fisso, a
tempo, pay per use.
CUSTOM SOFTWARE
Con tale denominazione si intendono quelle applicazioni che vengono sviluppate o
modificate ad hoc per le esigenze di un'impresa
ENTERPRISE RESOURCE PLANNING
Un insieme di moduli software, completo di funzionalità specifiche, che consente
all'azienda di integrare in tempo reale i dati e di gestire funzioni e processi operativi
LEGACY
Quei sistemi informativi (hardware, applicazioni) che vengono utilizzati da diverso tempo in
un'impresa senza essere aggiornati o sostituiti, svolgendo ancora diverse funzioni
importanti pur mancando in certi casi di compatibilità e integrazione con i sistemi più
moderni
SERVICE ORIENTED ARCHITECTURE
Approccio software che permette l'utilizzo di componenti applicativi riutilizzabili,
componibili e integrabili, programmati anche per svolgere solo una particolare funzionalità.
Tra questi ci sono anche i cosiddetti web services.
Pagina 10 di 11
www.intesasanpaoloimprese.com
.
Documento reperibile, assieme ad altre monografie, nella sezione Dossier del sito
http://www.intesasanpaoloimprese.com/
Documento pubblicato su licenza Nuov@ Periodici Italia
Pagina 11 di 11
www.intesasanpaoloimprese.com