Fantuzzi Nestore Paolo
SOA, EAI e BPM: Introduzione alle service oriented architecture
Dalle tecnologie di cooperazione tra applicazioni alla tecnologia dei servizi distribuiti; panoramica e direttive per uno sviluppo sostenibile delle soluzioni informatiche in scenari complessi.
Abstract
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.2 Un richiamo storico alle problematiche di Workflow management
1.2.1 Le motivazioni e l’attualità
1.2.2 I Workflow Management Systems (WfMS)
1.3 WfMS, analisi e modelli di riferimento
1.3.1 Uno schema di analisi del Workflow Management Systems
1.3.2 Embedded ed Autonoumus Workflow engine_
1.3.3 Il Workflow reference model (WRM)
2. Enterprise Application Integration; integrare e riutilizzare le risorse aziendali
2.1 L’integrazione tra gli assets aziendali evolve
2.1.1 Le tecnologie adottate per integrare
2.1.2 Data level; pure data integration
2.1.3 Application level; message integration_
2.1.4 Process level; Process integration
2.1.5 Service level; Service Oriented Integration
2.2 Lo scenario delle soluzioni di EAI
2.2.4 Evoluzione delle tecnologie e degli standard d’integrazione
2.2.5 L’architettura di una soluzione di EAI
2.3 L’integrazione e l’astrazione
2.4 La governance dell’integrazione?
2.4.1 L’integrazione è un ciclo aziendale
3.1 L’automazione, l’astrazione ed i processi
3.1.1 L’automazione; da tecnologia di produzione a leva di governo aziendale
3.3 Dal Workflow al Business Process Management
3.3.1 Le evoluzioni del mercato
Fase 1: Separazioni logiche dai sistemi
Fase 3: Continuous Process Improvement (CPI)
3.4 Lo scenario delle soluzioni BPM
3.4.1 Il processo come “cervello” dell’integrazione
3.5 La governance dei processi?
4 Le congiunture tecnologiche e l’opportunità di un’unica piattaforma
4.1 Lo sviluppo delle infrastrutture
4.2 La congiuntura data dall’evoluzione dei mercati
4.3 La definizione di standard universalmente riconosciuti ed adottati
4.4 Altre causali per un’unica piattaforma
4.5.1 Gli elementi della tecnologia
4.5.2 L’evoluzione delle piattaforme di mercato
4.5.3 Gli Integration Backbone Software vendor
6.1 L’origine della tecnologia
6.1.1 Dai Web services alle SOA
Web services ed applicazioni distribuite
Le tre stagioni dei Web service in azienda
6.1.2 Cosa è una Service Oriented Architecture
6.1.2 SOA ed i sistemi informativi; il caos e l’inerzia
6.1.2.1 Caos; il pericolo dei Silos orizzontali
6.1.2.2 Caos; scalabilità e volumi
6.1.2.3 La necessità di un pensiero strategico
6.1.2.4 Inerzia; rischi vs benefici
6.1.3 Evoluzione delle tecnologie e degli standard di cooperazione; le Composite Applications
L’evoluzione del Web engineering
Perché le composite applications
Come realizzare una composite application
Le infrastrutture di una composite application
6.2 L’architettura di una soluzione
6.2.2 Lo sviluppo di applicativi; dalle OOA alle SOA
6.2.2.1 MOM, CORBA ed i fallimenti delle composite application OOA
6.2.2.2 Perché SOA può riuscire?
6.2.2.3 OOA e SOA; una scelta.
6.2.3 L’integrazione; dagli adapter all’incapsulamento
6.2.4 Strutturare una soluzione SOA
6.2.4.2 La affidabilità e la disponibilità sono compromesse nei processi complessi
6.2.4.3 La soluzioni SOA differiscono dalle tradizionali applicazioni user-centric
6.2.5 Affidabilità e disponibilità dei dati in una soluzione SOA
6.2.5.1 Eliminare i Single Points of Failure (SPOF)
6.2.5.2 Un partizionamento statico non incrementa la disponibilità dei dati
6.2.5.3 Il clustered caching assicura affidabilità e disponibilità
6.2.5.4 Gestire lo stato attraverso la virtualizzazione.
6.2.5.5 Una partizione trasparente dei dati raggiunge la continua disponibilità ed affidabilità.
6.2.5.6 Una partizione trasparente permette il distribuited computing
6.2.5.8 Isolamento dal fallimento di altri servizi
6.2.6 Le performance scalabili sono vitali per le soluzioni SOA
6.2.6.1 Enormi carichi minano la scalabilità
6.2.6.2 Gestire ampi volumi di transazioni senza compromessi
6.2.6.3 Sviluppare flessibilità tramite il Data Grid
6.2.6.4 I web services richiedono performance scalabili
6.2.7 Spiegare l’architettura ai business-man
6.3.1 Le piattaforme Enterprise Service Bus (ESB)
6.3.1.1 Le piattaforme e le specifiche WS-I
6.3.2 Lo sviluppo delle applicazioni
6.3.2.1 Conoscere per decidere: il modello del SI aziendale
6.3.2.2 Un Maturity Model per valutare la predisposizione a SOA
6.3.2.5 MM Level 3 – Proactive
6.3.2.8 Costruire un ambiente SOA piuttosto che “una” soluzione
6.3.2.4 La convivenza architetturale OOA e SOA
6.3.2.5 Le problematiche applicative
6.4 Lo stato dell’arte, le organizzazioni, gli standard e le “best practices”
6.4.1 OASIS; Web Services reference model
6.4.1 I protocolli per realizzare una composite application
ASAP: Asynchronous Service Access Protocol
6.4.2 WS-Coordinator e lo stack dei protocolli (IBM e Microsoft)
6.4.2.1 Qualità of service layer
6.4.2 WS-CAF e lo stack dei protocolli (Oracle,SUN,IONA)
6.4.3 WS-I; Web Services Interoperability
6.4.3.1 La prima generazione di WS e l’interoperabilità
WS-I SSBP (Simple SOAP Binding Profile)
WS-I BSP (Basic Security Profile)
WS-I RSP (Reliable Secure Profile)
6.4.3.5 Assenze ingiustificate
6.6 Gli ISV e le piattaforme ESB
6.6.1 BPM vs ESB, il confronto tra due tipologie di piattaforme
6.6.2 Dall’orchestrazione alla coreografia
6.7 La governance dei processi e SOA
6.7.1 I progetti SOA falliscono!
6.7.2 Il ciclo di vita delle iniziative SOA
6.7.2.2 La fase di implementazione
6.7.2.3 La fase di distribuzione
6.7.2.4 La fase di gestione operativa
Benefici strategici – il cambiamento
6.7.5 Progettare una SOA Governance
6.7.5.1 Il ciclo di vita della SOA Governance
6.8 La domanda e le iniziative SOA
6.8.1 I business drivers che guidano l’adozione delle SOA
6.8.1.1 I drivers sul breve periodo – i processi “stabili” e “dinamici”
6.8.1.2 I drivers sul lungo periodo – i “Composite process”
6.8.2 Gli impatti sulle infrastrutture e la Governance IT
7 Perché monitorare e governare i processi
7.2 I processi e la catena del valore dell’azienda
7.2.2 La catena del valore di Porter
7.2.3 Value chain e differenziazione competitiva
7.2.4 Cenni alla pianificazione direzionale secondo Porter
7.2.5 La gestione del rischio ed i processi
8 I vantaggi di uno sviluppo IT focalizzato sui processi
8.1 Ottimizzare l’impiego degli assets esistenti ed accrescerne il rendimento puntuale
8.1.1.2 Le piattforme EAI/BPM ed il “Ciclo dei servizi IT”
8.1.2 Ottimizzazione assets esistenti
8.1.3 Incrementare i rendimenti, utilizzare i sistemi esistenti come “unità di processo”
8.1.4 Orchestrazione e riutilizzo
8.1.4.2 Esempio e riutilizzo asset esistenti
8.1.4.3 Disegno architetturale e reingegnerizzazione dei cicli aziendali
Gestione del rischio e TCO più attendibili
Rendimento impiego risorse umane
8.2 Diminuzione costi di manutenzione infrastrutture IT
8.2.1 La manutenzione ordinaria
8.2.1.1 Diminuzione costi di manutenzione dei sistemi
8.2.1.2 Miglioramento processo di manutenzione, accrescimento del valore.
8.2.1.3 La manutenzione straordinaria
8.3 Crescita e sviluppo delle risorse umane
8.3.2 Comprensione dei processi altrui
8.3.3 Migliore impiego delle persone
8.3.4 Più efficiente ed efficace gestione delle criticità
8.3.5 Flessibilità di processo
8.3.6 Monitoraggio e riconoscimento
8.4 Evoluzione dei sistemi di controllo nelle aziende
8.5 Qualità e performance dei cicli
8.5.1 Paperless Process Management
8.5.2 Individuare il modello attendibile del ciclo
8.5.2.1 La conoscenza di processo
8.5.2.2 Economicità della conoscenza di processo
8.5.3 Le tempistiche coinvolte
8.5.3.1 Migliori tempi di realizzazione/implementazione delle iniziative di miglioramento
8.5.3.2 Migliori tempistiche di servizio offerte agli altri cicli aziendali
8.5.3.3 Migliori tempistiche di controllo
8.5.5 La vision indotta, presidiare la crescita del valore
8.5.5.1 Prontezza tecnologica e cultura
8.5.5.2 Ricerca della soluzione a maggior valore
8.5.6 La gestione del GAP tra requisiti di business e risposte tecnologiche
8.6 Il “Ciclo dei dati” e la realizzazione di meccanismi di “Change data Capture”
8.6.2 Le piattaforme di EAI/BPM ed il “Ciclo dei dati”
8.7 L’equilibrio delle costituenti il “sistema azienda”
8.7.1 La modifica dei cicli e l’equilibrio
8.7.3 Politiche di passaggio in produzione con rischi ridotti
8.7.3.1 Esempio di “piano di attivazione”
8.8.1.1 Il coinvolgimento delle organizzazioni IT
8.8.1.3 Sezione 404 – Controlli generali dell'IT ed auditor
8.8.1.4 EAI e Sarbanes-Oxley Compliance, le best practices sono legge
8.8.1.5 Preparazione all'audit
8.8.1.6 Il vantaggio di controlli basati sui sistemi
8.8.2 IAS, IFRS e “ciclo di contabilità”
8.8.2.1 Impatto sulle procedure e sui sistemi
8.8.2.2 Impatto sull’operatività
8.8.3.1 I tre pilastri di Basilea II
8.8.4 Norme ISO, la qualità del “ciclo di trasformazione”
8.9 Partnership e collaborazioni più efficaci ed efficienti
8.9.1 La efficacia e la efficienza
8.10 Gestione della conoscenza, coltivare il sapere per supportare la creazione di valore
8.10.1 La conoscenza operativa
8.10.2 La conoscenza ed i dati
8.10.2.2 La elaborazione dei dati
8.11.1 Contenuti e la domanda IT
L’evoluzione tecnologica sta introducendo rivoluzionarie soluzioni volte a superare problematiche che sino a pochi anni fa sembravano costose e non sostenibili; un nuovo disegno architetturale pare risolvere le innate esigenze di cooperazione ed integrabilità che assillano i direttori preposti al governo dei sistemi informativi e promette di coniugare la naturale prudenza con cui vengono implementate le diverse iniziative di miglioramento (necessarie per perseguire le evoluzioni dei business aziendale) col perseguimento di direttive di sviluppo qualitativo del sistema (richieste oramai provenienti anche dal legislatore).
Inoltre le discipline e le best practices direzionali focalizzano la loro attenzione su un concetto “anziano”, il processo, rimasto sino ad ora ai confini dell’integrazione estesa (“End-to-end”) attraverso i diversi sistemi informativi; la densità informativa che caratterizza i servizi offerti da certe realtà (pubblica amministrazione, banche, assicurazioni, sanità, trasporti…) trae innegabili economie e raggiunge evidenti performance quando il processo viene integrato lungo tutti i sistemi informativi aziendali.
Il senior management sarà maggiormente coinvolto dalla pragmatica implementazione del processo desiderato, entrando finalmente nel comitato di pianificazione e sviluppo che assieme alla direzione dei sistemi informativi implementerà soluzioni in grado, a tutti gli effetti, di rendere cooperante la direzione aziendale con la “casta” poco trasparente degli addetti alle tecnologie.
Alcune tecnologie supportano meglio di altre la realizzazione di tali aspettative ed il loro impiego raggiunge una parte degli obbiettivi per le quali vengono scelte. Alcune di queste sono già presenti in azienda ed il riutilizzo di questi assets informatici è preziosa strategia di risparmio.
L’affermarsi dei più moderni aspetti del sistema informativo direzionale, come lo sviluppo di sistemi per il Corporate Performance Management (CPM) o l’Enterprise-wide Risk Management, può trarre notevole flessibilità ed economia di possesso/gestione dall’adozione di nuove opportunità tecnologiche, “process oriented”fornite, ad esempio, dalle piattaforme di Business Process Management (EAI/BPM, basate su di un “orchestratore” di componenti applicativi elementari) o dalle recenti piattaforme di Enterprise Service Bus (ESB, basate su di una “coreografia” di servizi applicativi elementari).
Nella nuova arena di competizione le evoluzioni del mercato danno luogo ad una “nuova” domanda di strumenti, di meccanismi, di sistemi e metodologie. Il Senior management e l’Executive management operano in un contesto di mercato che è genericamente mutato negli ultimi anni, nelle sue dinamiche (tempistiche ed attori coinvolti), nelle sue dimensioni (da nazionale a mondiale), negli elementi fondamentali di competizione e nelle tecnologie (le infrastrutture, i servizi, le comunicazioni, gli standard etc.). In alcuni di questi mercati si assiste anche ad una mutazione della domanda e del cliente che acquisisce consapevolezza del “valore” del prodotto/servizio. Questo “valore” non è solo espresso dal quantum economico che il cliente gli riconosce e la sua nuova concezione induce le aziende al conseguente adeguamento dell’offerta ed ispirano la conduzione strategica sulla necessità di creare “valore”.
Per queste aziende la creazione del valore diventa un fattore competitivo, differenziante; la creazione del valore non s’identifica “solo” nell’oggetto/servizio che costituisce il prodotto dell’offerta, impatta la natura dell’azienda, il suo DNA, i suoi processi.
La creazione del valore induce il Senior management ad una pianificazione più completa, ad individuare appositi progetti d’accrescimento od a valutare, anche secondo delle nuove metriche, quelli esistenti. Il sistema informativo che abilita e sostiene questi nuovi comportamenti necessita di migliori sorgenti d’informazione qualitativa; occorre una misura degli intangible assets aziendali, che nelle realtà ad alta intensità informativa si focalizzano sulla misurabilità dei processi aziendali ed extraziendali, dei suoi Workflow, delle loro performances. Questi sono i basilari requisiti del SI direzionale[1] che si stà delineando e suggerisce al Senior management di porsi come una delle più autorevoli fonti della domanda di process measurement e management. Il campo di battaglia su cui sis tanno contendendo gli spazi propositivi è focalizzato sulle piattaforme middleware, le piattaforme destinate, nella maggior parte dei casi, ad ospitare le nuove tecnologie sia per quanto concerne il supporto direzionale (SI direzionali) sia il supporto operazionale (SI operazionali).
Alcune tecnologie supportano la realizzazione di tale sistema e la loro fornitura raggiunge una parte degli obbiettivi richiesti al SI direzionale. In particolare lo sviluppo degli aspetti informativi ed informatici di un sistema di CPM può però trarre notevole flessibilità ed economie di possesso/gestione (Total Cost of Owner, TCO) dall’adozione di nuove opportunità tecnologiche.
La chiave interpretativa dell’esistente architettura del sistema informativo aziendale (AsIs) è frutto di un processo evolutivo la cui conoscenza ci porta a comprendere con quali prospettive si possono governare ed introdurre le nuove tecnologie basate sui servizi distribuiti (Web Services) e le future tendenze che già i principali software vendor (IBM, Microsoft, Oracle, BEA) stanno strutturando (le architetture SOA). Questo libro offre una visione cronologica delle architetture che hanno impattato sul concetto di “processo” ed approcciando la tematica anche dal punto di vista del Senior management (che finanzia le iniziative) ne mostra i riflessi sul business aziendale rispondendo alle domande “Mi riguarda?”, “Che vantaggi competitivi introduce?”, “Vale la pena appoggiare l’iniziativa?”, “Quanto costa e quanto costerà?”. Il testo si spinge anche nei dettagli dello stato dell’arte (descrivendo gli standard e le best practices) adottate ed aiuta il direttore dei sistemi ed i suoi collaboratori nel comprendere e nel disegnare le direttive attuative (“Cosa è?”, “Cosa fa?”, “A cosa serve?”, “Perché devo farlo?”, “Cosa rischio?”, “Come posso introdurla?”).
Le tecnologie EAI/BPM o le SOA/ESB sono tecnologie innovative che rispondono a problemi noti secondo modalità che solo negli ultimi anni sono divenute praticabili. Dagli anni 2000, infatti, alcuni prodotti di Enterprise Application Integration si sono dotati anche delle funzionalità di Business Process Management e grazie allo sviluppo delle infrastrutture e degli standard, sono divenuti piattaforme esaustive, complete, in grado di rispondere a molte delle esigenze che verranno evidenziate. Analogamente la maturità delle tecnologie SOA, ispirate a più moderni concetti di disegno dei sistemi informativi, è una conquista recente.
Queste tecnologie permettono di estendere la reale capacità di influenzare il comportamento dell’organizzazione da parte dei sistemi informativi. Qualunque organizzazione si può infatti influenzare agendo sugli elementi che la compongono, illustrati in (Figura 1).
Figura 1 - Gli elementi che compongono un'organizzazione.
Ne consegue che introdurre soluzioni che perseguono i concetti introdotti permette di influenzare direttamente alcuni delle costituenti l’organizzazione stessa. Le metriche, il controllo, i processi e le tecnologie (certamente quelle informatiche ma anche, per riflesso, quelle di produzione …) sono influenzabili e divengono driver di successo maggiormente pilotabili dal management aziendale. Altre componenti sono indirettamente coinvolte, come le persone (viene indotto un cambiamento culturale, l’adozione di nuovi comportamenti) e le strutture, queste ultime pesantemente condizionabili da voluti interventi sulle cooperazioni e le interoperabilità.
Vi sono diverse congiunture che giustificano l’interesse che le discipline d’integrazione e cooperazione stanno suscitando oramai da qualche anno e non solo tra gli addetti ai lavori. I diversi acronimi di mercato con il quale sono espresse più o meno propriamente (EAI, BPM, Web Service, SOA, ESB, BPEL...) compaiono quotidianamente sulle riviste di settore. Occorre far chiarezza.
Storicamente chi ha a che fare con sistemi informativi od applicazioni e servizi da erogare ad utenti ha sempre dovuto confrontarsi con politiche di integrazione. Dagli albori dell’informatizzazione i sistemi hanno, prima o poi, dovuto affrontare anche problematiche di interoperabilità; i primi mainframe isolati ed attentamente custoditi da pochi tecnici hanno via, via ceduto terreno a sistemi middleware più spartani, diffusi ed affidati a pragmatici operatori che desideravano collegarli tra loro e renderli interoperabili assai più dei loro illustri colleghi. La nascita d’infrastrutture e canali che offrivano “a basso costo” tali opportunità rende ora questi sistemi in grado di cooperare. Ora che la bolla speculativa della new economy ci abbandona e la sua eco induce al contenimento dei costi, il vantaggio competitivo dei grossi pacchetti informatici si perde rispetto alla orchestrazione degli applicativi esistenti. Nasce quindi una nuova famiglia di prodotti e soluzioni informatiche che a partire dai primi anni del nuovo millennio sta diffondendosi rapidamente. L’integrazione e la cooperazione sono “geneticamente” frutto dell’evoluzione dei sistemi di governo dei processi, che cogliendo le opportunità offerte dall’integrazione e dall’interoperabilità forniscono ora un nuovo modo di cooperare tra aziende, tra istituzioni, tra programmi ed utenti.
Nella prima e seconda parte del libro s’introducono e descrivono le tecnologie d’integrazione e cooperazione tra gli asset informativi, le evoluzioni che la hanno portate a divenire una costituente fondamentale delle piattaforme d’automazione dei processi aziendali ed a recuperare una dimensione tecnologica storica, quella del Workflow automation.
Diversi standard cominciano ad essere utilizzabili (WfMC, OASIS ed OMG sono le organizzazioni a cui ispirarsi) ed il perseguire la più corretta architettura è una delle decisioni più importanti per chi governa il sistema informativo aziendale; architetture a componenti od a servizi? Moduli in ambito distribuito piuttosto che fusi in monolitiche piattaforme? Basati su approcci sincroni piuttosto che asincroni? Architetture guidate da eventi piuttosto che da chiamate?
Diversi fornitori si propongono e la “software selection” a quali metriche può riferirsi? Quali sono i pro ed i contro nell’adottare una soluzione di integrazione standard (EAI) piuttosto che affidarsi a piattaforme sviluppate per la cooperazione intorno ad un abile e consolidato orchestratore delle attività (BPM)? Od è meglio seguire l’entusiasmo di una prospettiva di servizi cooperanti (SOA) in una coreografia di sostegno (ESB) che ci promette di “aprire” i confini del nostro sistema informativo?
Nella terza parte del libro si sviluppano alcuni punti di contatto tra le esigenze del business e della conduzione aziendale e le soluzioni informatiche process oriented, vale a dire quelle soluzioni che paiono abilitare effettivamente l’integrazione e cooperazione tra gli asset aziendali esistenti e quindi, in ultima analisi, abilitano all’informatizzazione End-to-end dei processi. L’attuale arena competitiva evidenzia nuovi differenzianti di competizione tra le aziende sulla base delle quali nascono innovative direttive di buona conduzione e sviluppo tecnologico a cui ricondurre una analisi sul valore degli sviluppi realtivi a questi Point Of Contact (POC). Questa rinnovata attenzione è mutuata dalle nuove prospettive di creazione del valore riconducibili ad emergenti discipline di conduzione aziendale. Si sviluppano nuovi principi di pianificazione strategica che, coltivando gli “intangible asset”, si avvantaggerebbero notevolmente nell’impiego di queste piattaforme informatiche; il concetto di “processo” acquisisce una dimensione strategica, come è sancito dalle direttive emesse dalle istituzioni di vigilanza sia in ambito assicurativo (ISVAP 577 e SOLVENCY II) che industriale (l’americana SOX) e bancario (BASILEA II).
È allora possibile descrivere nuovi scenari in cui le piattaforme di governo e sviluppo dei processi aziendali contribuiscono alla creazione di maggior valore in quanto permettono un’efficace ed efficiente attualizzazione, come le nascenti discipline di Governance. Ad esempio le emergenti soluzioni di Corporate Performance Management (CPM) sono fortemente caratterizzate dalla loro declinazione tecnologica sull’organizzazione aziendale.
È in questa prospettiva che ritroviamo la necessità di re-ingegnerizzare, governare e monitorare i processi per un impiego efficacie ed efficiente delle risorse esistenti (riutilizzo degli assets informativi) e per perseguire la qualità d’impresa sviluppando differenzianti competitivi sia su prospettive interne (corporate) che esterne (mercato, partnership, reti di collaboratori…) all’azienda.
(…)
… Questi elementi sono creati e processati in un ambiente di esecuzione il WfMS. I sistemisti dovranno attivare un servente (server) di processi o Wf engine in grado di generare una istanza del processo modellato ogni volta che la prevista combinazione di eventi scatenanti si verifica. Tale istanza può essere di tipo “long running” e perdurare per giorni, sino a quando la sequenza delle attività non è completata. Le attività automatizzate possono allora essere svolte anche dal Wf engine (come le attività di comunicazione, inoltro messaggi, transfer di dati…) e divenire dei Work items. Oppure, come anticiparo, possono essere delegate ad altri asset informativi, ed in tal caso si parla di invocazione di applicazioni esterne. Quindi un processo è concettualmente definibile come una sequenza predefinita di attività o Tasks attivata da una combinazione di eventi e da precisi elementi di input (dati e strutture dati) la quale dà origine a nuovi eventi e nuovi output.
Figure 1 - Gli elementi che costituiscono un processo.
Un processo è poi assogettato ad un controllo e sostenuto da un contesto abilitatore costituito da risorse e regole da osservare (Figure 1). Il contesto di controllo è individuato da chi detiene la paternità dell’iniziativa e del governo del processo (Owner), da un insieme di requisiti di servizio a cui il processo è vincolato (tra cui una metrica KPI che ne misura le performance) e dagli obbiettivi per i quali è stato implementato. Ad un sistema di WfMS è chiesto di fornire tutto questo.
(…)