Service-Oriented Architecture CeTIF TECHNOLOGY OUTLOOK

Transcript

Service-Oriented Architecture
CeTIF TECHNOLOGY OUTLOOK
Documento riservato - © CeTIF 2006
Pagina 1 di 27
AUTORI:
Pubblicato nell’ottobre 2006
Copyright © CeTIF. Diritti Riservati.
Il presente documento è riservato ai Partner
dell’iniziativa e ai partecipanti all’evento
“SOA tra falsi miti e realtà. Integrare i
processi di business innovando e rendendo
efficiente l’architettura applicativa”.
Ogni utilizzo o riproduzione anche parziale
del presente documento e la sua
circolazione al di fuori di questi ambiti non è
consentita senza previa autorizzazione degli
autori.
Si ringrazia Oracle per la collaborazione
prestata nella fase di impostazione dei
contenuti e per aver messo a disposizione le
proprie competenze in materia di
Architetture Service-Oriented
DISCLAIMER:
CeTIF assicura che il presente documento è stato realizzato con la massima cura e con tutta la
professionalità acquisita nel corso della sua lunga attività. Tuttavia, stante la pluralità delle fonti
d’informazione e nonostante il meticoloso impegno da parte di CeTIF affinché le informazioni
contenute siano esatte al momento della pubblicazione, né CeTIF né i suoi collaboratori
possono promettere o garantire (anche nei confronti di terzi) esplicitamente o implicitamente
l'esattezza, l'affidabilità o la completezza di tali informazioni. CeTIF, pertanto, declina qualsiasi
responsabilità per eventuali danni, di qualsiasi tipo, che possano derivare dall'uso delle
informazioni contenute nel presente rapporto.
Si evidenzia, inoltre, che il presente rapporto potrebbe contenere proiezioni future o altre
dichiarazioni in chiave prospettica, circostanza che comporta rischi e incertezze. Si avvisano
pertanto i lettori che tali affermazioni sono solamente previsioni e potrebbero quindi discostarsi
in modo considerevole dagli effettivi riscontri ed eventi futuri.
CeTIF declina fin d’ora qualsiasi responsabilità e garanzia in relazione a tali proiezioni.
Pagina 2 di 27
INDICE
Executive Summary ................................................................................ 5
Introduzione ............................................................................................ 7
1. Service-Oriented Architecture ............................................................ 8
1.1 Integrazione tecnologica e organizzativa in banca...................................8
1.1 Un modello di riferimento per SOA.........................................................8
1.2 Benefici potenziali e criticità del modello .............................................10
1.3 Modelli di implementazione ..................................................................13
2. SOA Technology Outlook Model..................................................... 15
2.1 Metodologia di analisi............................................................................15
2.2 SOA Technology Outlook Map .............................................................16
2.3 SOA Technology Innovation Cycle .......................................................18
2.4 SOA Process Impact Analysis ...............................................................19
3. SOA 4 “C” Analysis ......................................................................... 20
3.1 Context ...................................................................................................20
3.2 Criteria ...................................................................................................22
3.3 Cost-saving.............................................................................................24
3.4 Coverage ................................................................................................25
Pagina 3 di 27
Pagina 4 di 27
Executive Summary
L'integrazione dei processi di business è ritenuta dalle aziende del settore finanziario un’attività
indispensabile per affrontare in modo adeguato temi di grande attualità quali l’analisi del rischio,
l’accesso ai mercati finanziari, la gestione delle relazioni con i clienti, gli adeguamenti imposti
dall’evoluzione della normativa interna (codici di condotta ed etici) ed esterna (leggi e
regolamenti), la corporate governance, l’innovazione della rete di vendita, la riprogettazione dello
sportello.
In questo contesto, l’adozione di approcci architetturali innovativi basati su SOA (Service-Oriented
Architecture) sembra poter rappresentare una valida risposta alle esigenze di integrazione
tecnologica e organizzativa in banca.
Il passaggio da un’architettura tradizionale ad una Service-Oriented Architecture può essere
definito come una sorta di disaccoppiamento o separazione tra processi di business, funzioni
applicative (a supporto di tali processi) e dati. Risulta evidente come un’architettura informatica
così ingegnerizzata possa garantire alla banca i livelli di flessibilità necessari per operare in un
mercato in rapido e continuo cambiamento.
Tali benefici sono realizzabili in modo graduale; il coefficiente di attualizzazione (definito come il
tasso di conversione dei benefici potenziali in benefici reali) e il cosiddetto time to benefit (cioè il
periodo tempo dopo il quale i benefici attesi iniziano a manifestarsi in modo misurabile), dipendono
dalle caratteristiche del processo di adozione della nuova architettura (transizione dall’architettura
corrente alla nuova architettura), dal suo stadio evolutivo (maturity model), dalla capacità, da
parte della banca, di definire aspettative adeguate alle potenzialità del modello e di tenere sotto
controllo alcuni elementi di criticità attraverso un adeguato approccio di governo, oltre che da una
serie di fattori esterni alla banca, sostanzialmente legati all’evoluzione dell’offerta in relazione al
modello architetturale di riferimento.
L’analisi condotta da CeTIF attraverso la metodologia proprietaria “Technology Outlook Model”
ha quindi prodotto risultati così sintetizzabili:
• l’impatto di SOA sulle prospettive di cambiamento e miglioramento in termine di efficienza
ed efficacia si rivela di intensità medio-alta per quanto riguarda l’infrastruttura
applicativa e l’erogazione dei servizi. Non si rileva alcun impatto diretto sull’infrastruttura
tecnologica. I contenuti, infine, risultano mediamente impattati, soprattutto per ciò che
concerne i processi di creazione e quelli di fruizione da parte dell’utenza;
• tra i fattori che possono maggiormente influire sul processo di adozione/diffusione delle
Service-Oriented Architecture si segnalano, in ordine di importanza, il mercato e la
normativa. I fattori socio-culturali, in questo contesto limitati ad eventuali fenomeni
imitativi nei confronti dei cosiddetti “early adopter” o “technology innovator”, non
sembrano invece rivestire particolare rilievo;
• per quanto riguarda il livello di adozione, si segnalano le prime realizzazioni produttive, se
pur limitate nell’ampiezza e profondità dell’approccio;
• il tasso di penetrazione delle SOA nel mercato bancario risulta ancora piuttosto limitato,
anche se questo dato può apparire penalizzato dalla scelta di non considerare le
implementazioni basate su Web Services;
•
le tendenze in atto nelle banche italiane ci inducono a ritenere ragionevole, nei prossimi 3
- 5 anni, una maggiore adozione di tali architetture nell’ambito dei processi di marketing,
commerciali e di servizio alla clientela seguiti, nell’ordine, da quelli di operation e
direzionali.
Pagina 5 di 27
Pagina 6 di 27
Introduzione
Le tecnologie dell’informazione e della comunicazione (ICT) contribuiscono allo
sviluppo delle imprese favorendone l’innovazione. Innovare significa creare nuovi
prodotti o servizi e nuovi processi, con l’obiettivo di ottenere una differenziazione
competitiva, ma anche intervenire sui processi esistenti per migliorarne l’efficienza e
comporta, oltre all’introduzione di nuove tecnologie, anche una trasformazione
dell’impresa in chiave organizzativa, di impatto tanto sui processi che sulle persone,
per ciò che concerne ruoli, responsabilità e competenze. Il processo di innovazione
tecnologica è influenzato da fattori interni ed esterni all’azienda, che ne condizionano
i risultati in termini sia di rapporto tra benefici potenziali e benefici reali che di tempo
necessario alla loro realizzazione e richiede pertanto l’adozione, da parte dell’impresa,
di specifiche pratiche di governo del processo e di attente politiche di gestione del
conseguente cambiamento organizzativo.
E’ in questo contesto che si colloca il CeTIF Innovation Center, un laboratorio di
ricerca permanente promosso dal Centro di Tecnologie Informatiche e Finanziarie
dell’Università Cattolica del Sacro Cuore per dare spazio alle tecnologie innovative e
alle loro applicazioni nel settore finanziario, analizzandole da una duplice prospettiva:
accademica, in cui è indagato il ruolo dell’evoluzione tecnologica nel settore bancario
attraverso contributi di docenti e ricercatori universitari e operativa, mediante
interventi di esperti provenienti dal settore bancario e da quello delle aziende
tecnologiche. I risultati dell’attività di ricerca condotta da CeTIF nell’ambito del
laboratorio vengono sintetizzati nel Technology Outlook, un documento di analisi
indipendente che consente di posizionare la tecnologia innovativa in esame
nell’ambito di un framework di riferimento normalizzato, orientato ad evidenziarne le
caratteristiche intrinseche, a mettere in luce i fattori esterni alla banca, che ne possano
accelerare o frenare l’adozione, a determinarne il posizionamento nell’ambito del
cosiddetto ciclo di innovazione tecnologica, a stimarne l’impatto potenziale in base a
criteri di efficienza, efficacia e rischiosità, valutando l’ampiezza e l’intensità di tale
impatto sui processi bancari, a identificare, infine, scenari e criteri di adozione in
relazione al contesto bancario e alle caratteristiche dell’offerta.
Nell’ambito del Technology Outlook con il termine di tecnologia innovativa si
intende tanto uno specifico componente (o categoria di componenti) dell’infrastruttura
tecnologica o applicativa ICT quanto una modalità di concepire l’architettura del
sistema informativo nel suo complesso (o parte di esso), che rappresenti un fattore
abilitante per il processo di innovazione della banca. In altri termini, una tecnologia è
definita innovativa non tanto sulla base di un criterio “anagrafico” bensì in relazione
alla sua capacità di “abilitare” l’innovazione nel settore bancario e solo in quanto tale
è oggetto di indagine da parte del CeTIF Innovation Center.
Pagina 7 di 27
1. Service-Oriented Architecture
1.1 Integrazione tecnologica e organizzativa in banca
L'integrazione dei processi di business è ritenuta dalle aziende del settore finanziario
un’attività indispensabile per affrontare in modo adeguato temi di grande attualità
quali l’analisi del rischio, l’accesso ai mercati finanziari, la gestione delle relazioni
con i clienti, gli adeguamenti imposti dall’evoluzione della normativa interna (codici
di condotta e etici) ed esterna (leggi e regolamenti), la corporate governance,
l’innovazione della rete di vendita, la riprogettazione dello sportello.
In relazione a ciò, le ricerche recentemente condotte da CeTIF e i risultati delle
indagini effettuate hanno confermato come il raggiungimento di un livello di
integrazione di dati e informazioni superiore rispetto a quanto fino ad oggi consentito
dagli archivi delle aziende di credito resti un obiettivo prioritario tanto nell’ambito dei
progetti attuali che in quelli che coinvolgeranno i Sistemi Informativi nei prossimi
anni. E’ tuttavia emerso, in modo altrettanto chiaro, come il raggiungimento di tali
obiettivi a livello di processi di business, sulla base di criteri di efficienza (focus sui
costi) ed efficacia (focus sui benefici), non richieda soltanto uno sforzo d’integrazione
di dati e informazioni ma anche di sistemi, piattaforme, canali e una particolare
attenzione alle implicazioni di natura organizzativa.
In questo contesto, l’adozione di approcci architetturali innovativi basati su SOA
(Service Oriented Architecture) sembra poter rappresentare una valida risposta alle
esigenze di integrazione tecnologica e organizzativa in banca. Il presente documento
si pone l’obiettivo di evidenziarne i punti di forza e di debolezza, le opportunità
potenzialmente derivanti e rischi ad essa correlati, sulla base di una metodologia di
analisi indipendente (Technology Outlook Model), sviluppata da CeTIF nell’ambito
del laboratorio di ricerca.
1.1 Un modello di riferimento per SOA
Esistono numerose definizioni di Service-Oriented Architecture (SOA), spesso
formulate per mettere in evidenza una particolare caratteristica dell’architettura.
Quella adottata da CeTIF nasce da un approccio orientato alla ricerca del più ampio
insieme possibile di elementi comuni alle diverse definizioni e può essere formulata
come segue:
“un approccio alla progettazione, sviluppo, erogazione e gestione dell’infrastruttura
applicativa sulla base del quale le risorse software sono esposte sotto forma di servizi
riutilizzabili, usufruibili da client diversi indipendentemente dalla piattaforma che
esegue il servizio, dal tipo di applicazione che utilizza il servizio, dall’ubicazione del
servizio, dal canale utilizzato per accedere all’applicazione che utilizza il servizio”
Pagina 8 di 27
Ogni singolo servizio rappresenta, in questo contesto, una funzione o componente di
business indipendente, caratterizzata da alcuni attributi fondamentali:
-
-
è auto-contenuto, cioè contiene al suo interno tutta la logica per poter
funzionare correttamente;
è auto-descritto, cioè contiene le “istruzioni per l’uso”;
è non-permanente (stateless), cioè viene attivato solo su richiesta;
è indipendente (loosely coupled), cioè non deve avere alcuna particolare
dipendenza dal “consumatore” del servizio e deve avere il minor numero
possibile di interdipendenze nei confronti di altri servizi;
è invocabile attraverso messaggi basati su protocolli standard;
è riutilizzabile in contesti diversi da quello nel quale è stato generato.
Un altro attributo importante del servizio, in relazione al contesto nel quale è destinato
ad essere esposto, è la cosiddetta “granularità”, in qualche modo riferita all’ambito e
all’ampiezza del suo campo d’azione funzionale. Come evidenziato in figura 1, è
possibile definire servizi ad alta granularità (fine-grained services), che realizzano
funzionalità non direttamente correlate ad esigenze di business (ad esempio, le
funzionalità di base per l’accesso ai dati) e servizi a bassa granularità (coarse-grained
services), composti a partire dai precedenti (service composition) per rispondere a
specifiche esigenze di business (ad esempio, la creazione di una nuova anagrafica).
Figura 1 – Composizione dei Servizi
Fonte: CeTIF, 2006
Questi servizi a bassa granularità (business services) costituiscono i componenti di
base per la mappatura dei processi di business (business process orchestration). Le
Pagina 9 di 27
funzioni di composizione, incapsulamento e gestione dei servizi si basano su questo
fondamentale attributo. Oltre alla piattaforma per la mappatura dei processi di
business e la composizione dei servizi, gli altri componenti fondamentali di una
Architettura SOA, schematicamente rappresentata in figura 2, sono un canale di
comunicazione (enterprise service bus), che riveste il ruolo di message broker e
consente l’accesso alle risorse informatiche, esposte in forma di servizio, tramite
l’instradamento di messaggi basati su specifiche standard, una piattaforma di gestione
dei servizi (service life-cycle management), una di monitoraggio e controllo (service
monitoring, business process monitoring, security) ed un sistema di accesso
multicanale per gli utenti dei servizi (multichannel service client access).
Figura 2 – Service-Oriented Architecture
Fonte: CeTIF, 2006
1.2 Benefici potenziali e criticità del modello
Il passaggio da un’architettura tradizionale ad una Service-Oriented Architecture può
essere schematicamente rappresentato come una sorta di disaccoppiamento o
separazione tra processi di business, funzioni applicative (a supporto di tali processi) e
dati (figura 3). Risulta evidente come un’architettura informatica così ingegnerizzata
possa garantire alla banca i livelli di flessibilità necessari per operare in un mercato in
rapido e continuo cambiamento. Si tratta, in sostanza, di realizzare un’infrastruttura
applicativa allineata alle esigenze della banca e, come tale, in grado di garantire una
serie di benefici di impatto diretto sul business quali:
-
Abilitare il cambiamento: la riorganizzazione delle funzionalità
applicative in singole componenti di business (servizi) e la conseguente
modellazione dei processi bancari mediante tali componenti consente di
riallineare (mappare) facilmente e rapidamente applicazioni e processi in
Pagina 10 di 27
-
-
-
-
relazione ai cambiamenti di contesto, con evidenti benefici in termini di
flessibilità e time to market;
Facilitare l’integrazione: la composizione dei processi bancari in forma
modulare, mediante l’utilizzo di componenti di business accessibili
(servizi), consente una facile integrazione ed estensione di tali processi
nei confronti di clienti, partner commerciali e fornitori, in un’ottica di
azienda estesa;
Migliorare i livelli di controllo: la modellazione dei processi bancari
mediante componenti di servizio consente un agevole monitoraggio dei
flussi (dati e transazioni) per la conseguente ottimizzazione del rapporto
tra performance e costi di processo;
Abbattere i costi per nuovi prodotti e servizi bancari: l’architettura
modulare e gli elevati livelli di standardizzazione consentono il riutilizzo
di componenti (di servizio) esistenti ed uno sviluppo più semplice ed
economico di nuove componenti, con il conseguente abbattimento dei
costi per il rilascio di prodotti e servizi;
Ridurre i rischi operativi connessi con l’infrastruttura applicativa:
l’elevato livello di riutilizzo di componenti di servizio già in produzione e
la conseguente diminuzione del tasso di sviluppo di nuove funzionalità
applicative ed interfacce, conferiscono stabilità all’ambiente applicativo e
consentono di ridurne i rischi operativi.
Figura 3 – Architettura tradizionale e SOA
Fonte: CeTIF, 2006
Pagina 11 di 27
Si tratta di benefici realizzabili in modo graduale, per i quali tanto il coefficiente di
attualizzazione (definito come il tasso di conversione dei benefici potenziali in
benefici reali) quanto il cosiddetto time to benefit (cioè il periodo tempo dopo il quale
i benefici attesi iniziano a manifestarsi in modo misurabile), dipendono dalle
caratteristiche del processo di adozione della nuova architettura (transizione
dall’architettura corrente alla nuova architettura), dal suo stadio evolutivo (maturity
model), dalla capacità, da parte della banca, di definire aspettative adeguate alle
potenzialità del modello e di tenere sotto controllo alcuni elementi di criticità
attraverso un adeguato approccio di governo, oltre che da una serie di fattori esterni
alla banca, sostanzialmente legati all’evoluzione dell’offerta in relazione al modello
architetturale di riferimento.
Un primo elemento di criticità è legato alla conoscenza documentata (mappatura)
dei processi bancari correnti. Abbiamo visto che una delle principali attività nel
processo di transizione ad una Service-Oriented Architecture (figura 3) consiste
nell’estrazione del processo di business dalla logica applicativa, per la sua successiva
modellazione mediante componenti di servizio. Nonostante le banche siano da
qualche tempo stimolate a mappare i propri processi con il duplice obiettivo di
migliorare la conoscenza organizzativa ed effettuare una verifica delle proprie
modalità di funzionamento, anche in relazione a richieste di carattere normativo, sono
ancora pochi gli istituti di credito che hanno adottato un modello organizzativo per
processi; nella maggior parte delle banche italiane l’attività di mappatura si è limitata
ad alcuni ambiti, primi fra tutti il processo del credito (in relazione alla direttiva di
Basilea II), finanza (in relazione al tema della Business Continuity), incassi e
pagamenti (sempre in relazione a Business Continuity e, più recentemente, SEPA –
Single Euro Payment Area).
Un secondo e non meno importante elemento di criticità è rappresentato
dall’architettura di accesso ai dati. Il raggiungimento di un elevato livello di
separazione (disaccoppiamento) tra applicazioni e dati, in una logica di superamento
del modello basato sui cosiddetti application silo e la realizzazione di un elavato
livello di integrazione dei dati aziendali, sono dei presupposti imprescindibili per la
realizzazione di una Service-Oriented Architecture. In questo contesto, le
problematiche di ridondanza, qualità e coerenza dei dati possono rappresentare dei
seri ostacoli al processo di transizione, così come quelle di contesto, significato,
accuratezza e locazione, non adeguatamente indirizzate neppure da tecnologie
emergenti quali XML e SOAP. Il successo nell’implementazione di un modello
architetturale di tipo Service-Oriented non può pertanto prescindere dalla
realizzazione di uno strato di servizi di accesso ai dati ad alta granularità (e come tali
riutilizzabili per la composizione di servizi di business) che sia coerente con i criteri e
i vincoli esposti e si inquadri in una più ampia strategia di gestione dei dati aziendali
(Data Management Strategy).
Pagina 12 di 27
Un ulteriore elemento di criticità è rappresentato da alcune false aspettative nei
confronti dell’adozione di una Service-Oriented Architecture; prima fra tutte, la
convinzione, relativamente diffusa, che sia possibile realizzare un ambiente
applicativo destinato a sostituire completamente quello corrente. In realtà, il processo
di transizione di un’applicazione da un’architettura tradizionale ad una di tipo serviceoriented, ove possibile, è piuttosto lento e costoso (tempi e costi sono spesso
sottostimati); inoltre, molte applicazioni non si prestano ad una separazione tra logica
di business, logica applicativa e strutture dati; infine, molti fornitori di applicazioni
pacchettizzate non ritengono necessario adottare questa architettura in forma estesa e
per l’intero portafoglio applicativo. E’ molto probabile, quindi, che nei prossimi 5 –
10 anni siano destinati ad emergere e prevalere gli ambienti eterogenei, spesso nati da
un approccio misto di tipo buy, build & compose, nei quali le applicazioni basate su
architettura tradizionale si troveranno a convivere e ad integrarsi, secondo logiche più
tradizionali, con architetture di tipo service-oriented. Un’altra falsa convinzione,
anch’essa piuttosto diffusa, è che l’adozione di una Service-Oriented Architecture
consenta di realizzare “tout-court” un ambiente di tipo plug & play, nel quale nuove
componenti applicative possano essere inserite ed integrate (cioè riutilizzate) in modo
del tutto trasparente. In realtà, questa attesa si scontra con il problema, in parte ancora
irrisolto, degli standard in grado di garantire l’interoperabilità tra i diversi strati
dell’architettura.
Vale infine la pena di ricordare che l’estensione dei processi di business oltre i confini
“interni” della banca, secondo una logica di azienda estesa, che abbiamo visto essere,
in prospettiva, uno dei benefici derivanti dall’adozione di architetture di tipo serviceoriented, aumenta significativamente la complessità di gestione e controllo di tali
processi e solleva, nei confronti del management della banca, la necessità di porre in
essere adeguamenti organizzativi e modifiche nelle politiche di governo.
1.3 Modelli di implementazione
Come abbiamo già evidenziato, la transizione verso una Service-Oriented
Architecture avviene in modo graduale, secondo modalità operative che sono proprie
di ogni singola banca ed è influenzata da numerosi fattori, interni ed esterni, che ne
condizionano tempistica ed estensione. E’ tuttavia possibile identificare, grazie anche
alle esperienze di questi ultimi anni, alcuni elementi comuni ai diversi stadi di
sviluppo del processo, sulla base dei quali costruire un modello di approccio
incrementale (maturity model).
Innanzitutto (figura 4), l’enunciazione di una proposizione di valore (core value
proposition) che definisca e comunichi in modo chiaro le aspettative di business della
banca (quali, ad esempio, abilitare il cambiamento, facilitare l’integrazione,
migliorare i livelli di controllo). In secondo luogo, il disegno di un’architettura di
Pagina 13 di 27
riferimento di lungo termine che sia allineata alle aspettative di business enunciate
(con riferimento alla figura 2). In terzo luogo, la definizione di una serie di obiettivi
strategici, specifici di ogni singolo stadio di sviluppo, che guidino la banca nella
conduzione delle attività mantenendo il focus sulla core value proposition. Quindi,
l’identificazione di approcci tattici che consentano di rilasciare risultati nel breve
periodo senza perdere di vista gli obiettivi strategici dello stadio. Infine, la definizione
di un approccio di governo alla SOA che sia coerente con le specifiche caratteristiche
e necessità dello stadio.
Figura 3 – SOA Maturity Model
Fonte: CeTIF, 2006
Pagina 14 di 27
2. SOA Technology Outlook Model
2.1 Metodologia di analisi
Come abbiamo evidenziato in apertura, il Technology Outlook Model si basa su una
metodologia sviluppata da CeTIF e consente di posizionare la Service-Oriented
Architecture nell’ambito di un framework di riferimento normalizzato, orientato a:
1. Evidenziarne le caratteristiche tecnologiche intrinseche e mettere in luce i
fattori esterni alla banca, che ne possano accelerare o frenare l’adozione
(Technology Outlook Map);
2. Determinarne il posizionamento nell’ambito del cosiddetto ciclo di
innovazione tecnologica (Technology Innovation Cycle);
3. Stimarne l’impatto potenziale in base a criteri di efficienza, efficacia e
rischiosità, valutando l’ampiezza e l’intensità di tale impatto sui processi
bancari (Process Impact Analysis);
4. Identificare scenari e criteri di adozione in relazione al contesto bancario e
alle caratteristiche dell’offerta (4C - Cost, Context, Criteria, Coverage).
Nei paragrafi che seguono sono esposti, in sintesi, i risultati delle analisi effettuate
mediante l’applicazione del modello.
Pagina 15 di 27
2.2 SOA Technology Outlook Map
Fonte: CeTIF, 2006
Nella Technology Outlook Map la tecnologia in esame (Service-Oriented
Architecture) viene analizzata con l’obiettivo di determinarne l’impatto potenziale su
quattro variabili interne: infrastruttura tecnologica, infrastruttura applicativa (sistemi
di sviluppo, sistemi di gestione, sistemi applicativi) o architettura applicativa nel suo
complesso, caratteristiche di erogazione dei servizi applicativi (applicazioni) da parte
della struttura ICT (intesa come l’insieme di infrastrutture tecnologiche,
organizzazione e processi) e contenuti, cioè l’insieme delle informazioni a supporto
dei processi di business della banca. Vengono inoltre presi in considerazione alcuni
fattori esterni alla banca (variabili esterne) che possono fungere da abilitatori
(enablers) o inibitori (inhibitors) nei confronti del processo di diffusione della
tecnologia: normativa, mercato, fattori socio-culturali, evoluzione tecnologica.
Non si rileva alcun impatto diretto (aggiornamento o miglioramento funzionale,
modifica in chiave fortemente evolutiva, sostituzione di un componente
infrastrutturale esistente o inserimento di un nuovo componente) sull’infrastruttura
tecnologica (sistemi di elaborazione, sistemi di comunicazione, sistemi di gestione
dati, sistemi di sicurezza). L’impatto sull’infrastruttura applicativa risulta invece
potenzialmente elevato sia per la numerosità delle applicazioni impattate che per la
profondità dell’impatto, in termini di efficienza ed efficacia, sui processi di sviluppo e
gestione delle applicazioni e su quello di gestione dell'infrastruttura applicativa nel
suo complesso. Per quanto riguarda le caratteristiche di erogazione dei servizi
Pagina 16 di 27
applicativi l’impatto di SOA, di intensità complessivamente medio-alta, risulta
particolarmente elevato su flessibilità, adattabilità, efficacia (a seguito di un processo
di radicale trasformazione tecnologica in chiave innovativa) e di intensità media su
disponibilità ed efficienza (dove la tecnologia induce cambiamenti più circoscritti, in
chiave prevalentemente migliorativa). I contenuti, infine, risultano mediamente
impattati, soprattutto per ciò che concerne i processi di creazione (dove sono
prevedibili, per effetto delle innovazioni introdotte da SOA, sostituzioni di processi
esistenti con nuovi processi così come la creazione di processi “ex novo”) e quelli di
fruizione da parte dell’utenza (dove si prevedono trasformazioni, in chiave innovativa,
dei processi esistenti).
Tra i fattori esterni alla banca che possono maggiormente influire, facilitandolo ed
accelerandolo, sul processo di adozione/diffusione delle Service-Oriented
Architecture si segnalano, in ordine di importanza, il mercato (influenza elevata per
le sue caratteristiche di dinamicità) e la normativa (influenza medio-alta per l’elevata
frequenza degli adeguamenti richiesti). I fattori socio-culturali, in questo contesto
limitati ad eventuali fenomeni imitativi nei confronti dei cosiddetti “early adopter” o
“technology innovator”, non sembrano invece rivestire particolare rilievo.
Pagina 17 di 27
2.3 SOA Technology Innovation Cycle
Fonte: CeTIF, 2006
I due grafici del Technology Innovation Cycle evidenziano, rispettivamente, il
posizionamento della tecnologia in esame (Service-Oriented Architecture) nell’ambito
del ciclo di innovazione tecnologica delle banche (italiane) che l’hanno adottata ed il
suo stadio di diffusione nell’ambito del mercato bancario (italiano).
Il posizionamento sullo stadio iniziale della fase di sviluppo sta ad indicare che ai
progetti pilota, che hanno caratterizzato il mercato negli ultimi due-tre anni, stanno
seguendo le prime realizzazioni produttive, se pur limitate nell’ampiezza e profondità
dell’approccio in relazione al modello di riferimento adottato (figura 2).
Il tasso di penetrazione delle SOA nel mercato bancario risulta invece ancora piuttosto
limitato, anche se questo dato può apparire penalizzato dalla scelta, qui effettuata, di
non considerare le implementazioni basate su Web Services come aderenti “tout
court” al modello architetturale SOA di riferimento (figura 2).
Pagina 18 di 27
2.4 SOA Process Impact Analysis
In questa sezione viene analizzato l’impatto potenziale delle Service-Oriented
Architecture sui principali processi bancari, raggruppati nelle seguenti categorie:
-
Processi direzionali
Processi di operation
Processi di marketing, commerciali e di servizio alla clientela
Processi di supporto
Nonostante risulti del tutto evidente la trasversalità dell’approccio basato su ServiceOriented Architecture ed il suo impatto, potenzialmente elevato, su tutti i principali
processi bancari, le tendenze in atto nelle banche italiane ci inducono a ritenere
ragionevole, nell’ambito di una finestra di 3 – 5 anni, una maggiore adozione di tali
architetture nell’ambito dei processi di marketing, commerciali e di servizio alla
clientela seguiti, nell’ordine, da quelli di operation e direzionali.
Fonte: CeTIF, 2006
Ricerche recentemente condotte, in relazione agli obiettivi strategici delle banche
italiane per il prossimo biennio, individuano infatti come prioritaria la revisione di
alcuni processi commerciali quali lo sviluppo della rete e dei canali di contatto
(incluso lo sportello tradizionale), il rinnovamento e potenziamento degli strumenti di
supporto nella relazione con la clientela, il rinnovamento dell’offerta. A ciò si
aggiunga lo sforzo, ancora in corso o solo recentemente completato, di revisione dei
processi nelle aree del credito (in relazione alla direttiva di Basilea II), della finanza
(in relazione al tema della Business Continuity), degli incassi e pagamenti (sempre in
relazione a Business Continuity e SEPA – Single Euro Payment Area). Seguono, in
ordine di importanza, alcuni processi direzionali appartenenti all’area dei controlli
interni (internal audit, compliance, risk management), anch’essi impattati dalla
direttiva di Basilea II e susseguente normativa emessa dell’Autorità di Vigilanza.
Pagina 19 di 27
3. SOA 4 “C” Analysis
La presente sezione ha l’obiettivo di analizzare le opportunità e i benefici potenzialmente
collegati all’adozione di architetture SOA attraverso la descrizione delle seguenti variabili:
• il contesto di adozione e i relativi driver (context);
• i criteri di adozione (criteria);
• le opportunità di riduzione dei costi offerte da SOA (cost-saving);
• le tipologie di offerta in ambito SOA da parte dei vendor (coverage).
3.1 Context
PRESSIONI DEL MERCATO
Contesto
Strutturale del settore
Flessibilità
Reattività
Nuovo Contesto
Normativo
Adattabilità
Nuovo Contesto
Economico
Integrazione
Efficienza
Nuove Caratteristiche
Della Domanda
Efficacia
Controllo
Presidio
Reazione della Banca alle Pressioni del Mercato
Strategia e Modelli di Business
Infrastruttura Tecnologica e Applicativa
A b i l i t a t o r i
S t r u t t u r a l i
Fonte: CeTIF 2006
Il contesto all’interno del quale valutare l’adozione di architetture Service-Oriented è
influenzato da diverse variabili. Tali variabili impongono alla banca di reagire alle
pressioni del mercato attraverso l’implementazione di infrastrutture tecnologiche e
applicative con caratteristiche come quelle indicate in figura
(flessibilità,
integrazione, controllo). Tra i fattori esogeni rivestono un ruolo primario:
Il contesto strutturale del settore: le banche fanno parte di un ecosistema di
business dove operano un elevato numero di attori, legati tra loro da reti di relazioni
complesse. Tali interazioni (di forma cooperativa, collaborativa e competitiva)
allargano il concetto di creazione di valore e di erogazione di un servizio a un sistema
più ampio che esula i confini della banca e impone strategie e modelli di business di
maggiore dinamismo, flessibilità e adattabilità al cambiamento. L’integrazione tra gli
attori sopraccitati diventa dunque fonte di vantaggio competitivo e abilitatore delle
strategie aziendali.
Pagina 20 di 27
Il nuovo contesto normativo: la normativa rappresenta ad oggi un driver di costante
evoluzione per il settore bancario. Le istituzioni impongono regolamentazioni a
livello nazionale e internazionale che spingono le banche a destinare ingenti
investimenti alle attività di compliance. In particolare i progetti relativi a Basilea II e
all’introduzione di nuovi standard contabili (IAS) hanno imposto spese IT di assoluta
rilevanza, presupponendo una dettagliata mappatura dei processi e il ripensamento di
diverse logiche operative. In altre parole le banche sono sempre più coinvolte in
progetti dalle scadenze pressanti che richiedono la capacità di rispondere
efficacemente ai cambiamenti di contesto. Basilea II in particolare impone alla banca
una puntuale misurazione dei dati relativi alle singole attività operative che
compongono il processo, con l’obiettivo di allocare un adeguato capitale a garanzia
dell’esposizione al rischio.
Il nuovo contesto economico: l’economia italiana segue un andamento discontinuo,
alternando nel medio periodo fasi repentine di crescita e di rallentamento, la cui
incidenza e complessità è amplificata dal progressivo processo di
internazionalizzazione che il mercato sta sperimentando. Le scelte del management
vengono dunque prese in un contesto decisionale ambiguo, poco strutturato e
caratterizzato dai cosiddetti “segnali deboli”, ovvero mutamenti inizialmente
impercettibili, ma che con il passare del tempo condizionano enormemente il settore
e, di conseguenza, al banca e relativi vincoli sulla spesa IT: la tecnologia deve infatti
garantire l’adattabilità della banca alle scelte imposte dal contesto economico.
Le nuove caratteristiche della domanda: La clientela richiede una sempre maggiore
autonomia nell’esecuzione dell’operatività bancaria e la possibilità di accedere ai
servizi senza alcun vincolo di spazio o di tempo. L’abbattimento delle barriere fisiche
tra banca e cliente, reso possibile grazie alle tecnologie dell’informazione e della
comunicazione, ha consentito di formulare un’offerta innovativa, riducendo i costi di
transazione e i costi di coordinamento con risorse informative esterne e soprattutto
velocizzando la raccolta di dati e informazioni sui comportamenti della stessa.
Tuttavia, essa ha anche generato nuovi problemi, obbligando il settore bancario a una
tempestiva risposta. Tra questi, la necessità di un’integrazione coerente a livello di
informazioni e specifiche sul cliente e sulle transazioni che questo effettua
indipendentemente dal canale utilizzato.
Pagina 21 di 27
3.2 Criteria
Canali
ATM
CALL CENTER
INTERNET
MOBILE
POS
Integration Layer
Front
End
SERVIZI BANCARI
SISTEMI E STRUMENTI
TRASVERSALI
SERVIZI BANCARI
SERVIZI BANCARI
Integration Layer
CORE BANKING
Back
End
CRM, CONTROLLO, PIANIFICAZIONE
Sistemi di Controllo e Misurazione
SPORTELLO
FINANZA, BUDGET, TESORERIA
ALTRI SISTEMI
Fonte: CeTIF 2006
Una volta specificati i fattori che descrivono il contesto di adozione di SOA1, è
opportuno specificare i criteri che i driver sopra citati impongono di seguire
nell’adottare la nuova architettura IT.
Una visione concettuale di SOA (come architettura multilivello) potrebbe essere
costituita da quattro elementi principali, ovvero i canali, il front end, il back end
(livelli) e i sistemi di controllo e misurazione (inseriti “verticalmente” rispetto ai
livelli). I livelli sono interconnessi da layer di integrazione.
L’evoluzione verso un’architettura orientata ai servizi dipende dai criteri attraverso i
quali raggiungere gli obiettivi determinati dal contesto, ovvero:
1. Flessibilità e velocità nel rispondere ai cambiamenti del modello di business;
2. Integrazione a livello infrastrutturale e standardizzazione;
3. Interconnessione tra i livelli e ottimizzazione dei sistemi trasversali;
4. Sistematicità dei controlli ed estrazione dinamica dei dati a supporto del
business.
Flessibilità e velocità nel rispondere ai cambiamenti del modello di business
I mutamenti del contesto impongono una forte capacità di adattamento da parte del
business. L’orientamento ai servizi nella definizione delle architetture e, più in
generale, un approccio SOA in fase di progettazione applicativa, persegue l’aderenza
1
Cfr. paragrafo 5.1 - Context
Pagina 22 di 27
delle applicazioni ai processi di business, riflettendone la struttura e il modello. Al
modificarsi di quest’ultimo, gli appropriati cambiamenti dell’IT vengono implementati
più velocemente, in modo tale da rispettare un time to market adeguato alle strategie
aziendali. Quanto affermato presuppone una profonda conoscenza dei processi di
business, auspicando attività collaborative tra le diverse aree funzionali. I vantaggi che
è possibile ottenere non si manifestano solo in ambito progettuale, ma anche in fase di
estensione e sviluppo di nuovi prodotti e servizi una volta a regime, dove le
componenti di servizio vengono riconfigurate e/o ricomposte in un’ottica di riutilizzo.
Integrazione a livello infrastrutturale e standardizzazione
L’approccio Service-Oriented prevede che dati e applicazioni siano gestiti attraverso
componenti modulari e disegnate in base alle logiche di business. Questo permette
l’integrazione di elementi eterogenei, interfacciando applicazioni create internamente
con quelle fornite da diversi vendor. La necessità di provvedere all’implementazione di
componenti mancanti può dunque essere affrontata con modalità differenti a seconda
dell’opportunità, ricorrendo per esempio a packaging e soluzioni di mercato.
La ricerca di standardizzazione nelle tecnologie adottate fa quindi riferimento alla
possibilità di renderne più semplice l’interfaccia, garantendo in modo dinamico la
scalabilità dell’architettura e la riduzione dei costi di sviluppo.
Interconnessione tra i livelli e ottimizzazione dei sistemi trasversali
I processi di business sono realizzati e supportati attraverso i diversi livelli di cui
l’architettura SOA si compone, e interconnessi attraverso tecnologie di integrazione
basate su linguaggi text based. Tale prospettiva consente l’ottimizzazione dei processi
(e delle diverse fasi che li compongono) attraverso il supporto dell’IT ai soggetti
coinvolti (dalla “fabbrica” agli utenti interni ed esterni). La modularità dei servizi
consente inoltre di implementare sistemi ad essi trasversali, supportando opportune
combinazioni e profondità di requisiti specifici di sicurezza, condivisione e
comunicazione di dati, ecc.
Sistematicità dei controlli ed estrazione dinamica dei dati a supporto del business
L’architettura SOA presenta caratteristiche tali per cui è possibile estrarre in modo
dinamico i dati relativi alle applicazioni che abilitano le singole fasi che compongono il
processo di business e sintetizzarli in forme aggregate per il supporto alle attività
operative e strategiche.
I dati di sintesi così ottenuti presentano un livello di dettaglio e un contenuto altamente
personalizzabili, in modo semplice e rapido. Tali attività di monitoraggio hanno dunque
una duplice valenza: consentono innanzitutto di migliorare l’efficienza dei processi
riducendo i rischi operativi; i dati ottenuti possono inoltre essere utilizzati nelle
misurazioni per la stima del capitale di vigilanza necessario a presidiare i rischi
sopraindicati. In secondo luogo è possibile fornire al top management dati di qualità a
supporto delle attività di governance e di business intelligence.
Pagina 23 di 27
3.3 Cost-saving
L’analisi (necessariamente non quantitativa) dei costi di adozione di SOA non può
essere effettuata prescindendo dai singoli contesti in cui le banche operano.
L’implementazione di SOA coinvolge un numero elevato di variabili (infrastruttura
preesistente, livello delle competenze interne, estensione dell’approccio orientato ai
servizi, ecc.) tali per cui risulta impossibile generalizzarne le categorie.
Nell’economia della trattazione può invece essere utile analizzare i benefici legati a una
riduzione dei costi di sviluppo, di manutenzione e di utilizzo a regime dell’architettura
orientata ai servizi.
Costi di Sviluppo: la modularità dell’approccio SOA garantisce che ogni progetto
abbia ambiti e responsabilità precise, il cui perimetro è definito dal servizio che si
intende implementare. Tali realizzazioni si rivelano più rapide e meno costose in
termini di effort grazie alla possibilità di riutilizzo delle componenti già sviluppate. Il
servizio erogato tramite la riconfigurazione di “moduli già esistenti” presenta inoltre
ridotte possibilità di fallimento, trattandosi della ricomposizione di prodotti già
rilasciati e testati.
La standardizzazione delle metodologie e la loro diffusione univoca consentono di
ottimizzare gli sforzi delle risorse impiegate e migliorare le dinamiche di
coordinamento inter e intrafunzionale.
Costi di manutenzione: la mancanza di interdipendenza tra i diversi servizi erogati
consente di modificare e/o aggiornare singole parti del sistema informativo senza
dovere coinvolgere le restanti. L’utilizzo di standard di mercato permette interventi
rapidi e a basso costo, anche utilizzando competenze esterne all’azienda.
L’introduzione di package, che SOA rende facilmente integrabili nell’architettura,
garantisce un ricorso strategico all’outsourcing, specialmente in una prospettiva di
scelte best of breed, dove le modifiche all’infrastruttura IT hanno la possibilità di
posizionarsi dinamicamente in un livello intermedio tra make e buy.
Costi di utilizzo a regime: l’aderenza dei servizi ai processi di business ottimizza le
performance delle risorse coinvolte, riducendo gli errori nell’operatività e le
inefficienze dovute ai ritardi e alle ridondanze che tipicamente contraddistinguono le
architetture tradizionali. Tale vantaggio è però controbilanciato dalla maggiore
complessità di gestione e controllo dei processi, che necessitano un riadeguamento
nelle strutture organizzative e nelle competenze a essi preposte.
Pagina 24 di 27
3.4 Coverage
Visione architetturale
SERVICE CLIENT
BUSINESS
PROCESS
MONITORING
BUSINESS PROCESS ORCHESTRATION
ENTERPRISE SERVICE BUS
INTERFACCE
INTERFACCE
INTERFACCE
SECURITY
SERVICE COMPOSITION
SERVICE
LIFE CYCLE
MANAGEMENT
SERVIZI A BASSA GRANULARITA’
SERVIZI AD ALTA GRANULARITA’
PIATTAFORME APPLICATIVE “CORE”
Soluzione
Tecnologica
ALTRI SERVIZI
Servizio o processo
di business
Fonte: CeTIF 2006
L’offerta del mercato relativa alla SOA, non trattandosi propriamente di una tecnologia,
è decisamente ampia e variegata. Superate gli iniziali fraintendimenti che portavano a
identificare SOA con “strati” di interfaccia applicativa o con presentation layer basati
su tecnologia web, i vendor presentano alle banche un ventaglio completo di
opportunità affinché l’organizzazione possa inserire le politiche relative alle scelte IT in
un piano strategico organico e libero dai particolari vincoli costituiti da tecnologie
proprietarie.
Come si diceva, SOA è innanzitutto una vision relativa alle modalità di progettazione
dell’architettura; l’offerta per il settore bancario è indirizzata proprio a favorire la
realizzazione di tale concetto, sia dal punto di vista delle tecnologie abilitanti, sia delle
competenze da sviluppare e impiegare in ambito progettuale.
E’ possibile affermare che il successo dei vendor in ambito SOA è sempre più
dipendente dalla capacità di rendere la propria offerta (anche a livello progettuale)
integrabile con le tecnologie (numerose ed eterogenee) che caratterizzano i sistemi
informativi bancari, senza pretendere di sostituirle con un nuovo “pacchetto completo
SOA”. In altre parole l’orientamento ai servizi deve essere un modo di ripensare la
propria architettura: le aziende hanno dunque il compito di creare tecnologie abilitanti e
supportare la banca nella propria strategia di implementazione, che, come abbiamo
visto, deve necessariamente seguire un’evoluzione da un livello embrionale a
strutturato, senza avere la (falsa) pretesa di passare da un’architettura tradizionale a una
Pagina 25 di 27
orientata ai servizi, con una semplice implementazione di soluzioni tecnologiche.
Proprio nella prospettiva appena descritta è possibile classificare la “copertura” da parte
dei vendor in tre classi di proposta:
Soluzioni Tecnologiche: le strategie IT, a seconda dello stadio evolutivo
dell’architettura in questione, prevedono l’inserimento di soluzioni tecnologiche
abilitanti sia per la ricomposizione e l’orchestrazione dei servizi, sia per l’interfaccia tra
le diverse applicazioni.
Inoltre vi è l’indubbia efficacia dei “pacchetti”, ovvero insieme di applicazioni che,
specie per attività non-core possono essere inseriti nella propria architettura in modo
rapido ed efficiente. La modularità dell’approccio orientato ai servizi rende le soluzioni
di mercato particolarmente indicate a “colmare” le lacune (anche in termini di
efficacia) dell’architettura bancaria.
Servizio o processo di business: l’opportunità offerta da SOA di ricomporre i singoli
servizi è strettamente dipendente dal fatto che essi vengono modellati ed erogati in
funzione dei processi di business. Essendo tali servizi indipendenti l’uno dall’altro, è
possibile che la banca possa esternalizzare un intero processo di business,
considerandolo, sulla base di opportuni livelli di erogazione e performance misurati e
prestabiliti, come un qualsiasi “modulo” dell’architettura SOA.
Visione architetturale: il supporto del vendor si concretizza ad un livello più alto
rispetto ai precedenti. La banca si avvale della consulenza in termini progettuali e in
fase di realizzazione dell’architettura. In tale contesto si impone una conoscenza
profonda e documentata dei processi bancari, il perseguimento di elevati livelli di
disaccoppiamento tra applicazioni e dati e l’analisi dei criteri e dei vincoli sulla base
dei quali definire un percorso di adozione di SOA. Pertanto questo tipo di offerta
impone al vendor profonde conoscenze di tipo non solo tecnologico, ma anche di
business.
Pagina 26 di 27
CeTIF
Università Cattolica del Sacro Cuore
Largo Gemelli, 1 - 20123 Milano
Tel. + 39 02 72342590
Fax. + 39 02 43980770
E-mail: [email protected]
www.cetif.it
Pagina 27 di 27

Service-Oriented Architecture CeTIF TECHNOLOGY OUTLOOK

Transcript

Documenti analoghi

Naturalmente commerciale

Enzo Rocca Biografia È Vice Direttore Generale del Credito

assicurazione bnp

PSP: normativa, business e tecnologia per i nuovi attori dei pagamenti

commenti pagella prossimi passi

borsa TaylorMade

COMUNICATO STAMPA

Innovare le strategie di Customer Relationship Management in