WHITE PAPER UN NUOVO SOA MATURITY MODEL

Transcript

1 WHITE PAPER UN NUOVO SOA MATURITY MODEL

2 Per promuovere una capillare adozione del nuovo SOA Maturity Model, è autorizzato a copiare, distribuire e utilizzare (e anche a creare opere derivative correlate) i SOA Material a beneficio Suo e della Sua azienda, ferme restando le limitazioni di cui al presente documento. Per "SOA Material" si intendono tutte le immagini, le icone, i modelli, i libri bianchi e altri materiali forniti in relazione al nuovo SOA Maturity Model, inclusi i testi e le didascalie associati. Non dovrà eliminare alcuna nota inerente diritti d'autore o altri diritti di proprietà riservata contenuta nei SOA Material o in qualsiasi altro materiale a Lei fornito. Cov2

3 TABLE OF CONTENTS > Forward 2 > 1.0 Introduction and Motivation 3 > 2.0 What is SOA (Service-Oriented Architecture)? 5 > 3.0 The SOA Maturity Model SOA Maturity Level 1 Initial Services SOA Maturity Level 2 Architectural Services SOA Maturity Level 3 Business and Colaborative Services SOA Maturity Level 4 Measured Business Services SOA Maturity Level 5 Optimized Business Services 22 > 4.0 Conclusion 24 1

4 PREMESSA Il presente libro bianco e il modello da esso rappresentato sono stati realizzati al fine di coadiuvare le organizzazioni nella ricerca di un'agilità di business attraverso la SOA (Service Oriented Architecture). Il SOA Maturity Model illustrato nel presente documento è stato specificamente sviluppato per facilitare i manager che stentano a comunicare il valore aziendale della propria visione SOA e per consentire loro di parametrizzare l'adozione della SOA all'interno dell'organizzazione. Siamo ansiosi di ricevere il Suo riscontro e il Suo commento al presente modello, mentre continueremo a estenderne il contenuto, condividendo i successi della SOA. Buon divertimento! 2

5 1.0 INTRODUZIONE E MOTIVAZIONE In qualsiasi ambiente in cui venga messo in discussione il valore strategico dell'it e in cui tutte le organizzazioni informatiche e di sviluppo software siano spinte a ridurre i costi, rischia di svilirsi anche il dibattito sul valore aziendale strategico della tecnologia. Molta attenzione è stata dedicata ai metodi di riduzione dei costi, come, ad esempio, delocalizzazione e offshoring, mentre meno un accento meno forte è stato posto sul valore di business della nuova tecnologia. L'obbiettivo del presente documento è quello di dimostrare come un nuovo approccio alla progettazione e all'implementazione dell'information technology, nello specifico della SOA, possa costituire la base su cui le organizzazioni commerciali e tecnologiche operano di concerto per il miglioramento dell'efficienza su diversi filoni, tra cui la riduzione dei costi e la semplificazione dell'implementazione dei nuovi modelli operativi. Nello specifico, il presente documento presenta: > Un quadro di discussione che consente a un'organizzazione di comprendere quello che dovrebbe essere il cammino verso l'adozione di una SOA. > Una descrizione articolata dei benefici aziendali di una riuscita migrazione verso la SOA, suddivisa in diversi livelli di maturity di implementazione SOA. > Un significativo vocabolario e contesto intorno quale un'organizzazione potrà puntare all'allineamento tra IT e Business. > La base su cui l'organizzazione potrà sviluppare l'itinerario verso la vera agilità di business grazie a una riuscita adozione della SOA La SOA è un approccio alla progettazione e all'implementazione di sistemi informativi attraverso cui il sistema viene creato da componenti che implementano funzioni operative separate. Tali componenti, chiamati Servizi, possono essere distribuiti nell'ambito di regioni geografiche e imprese ed essere riconfigurati, secondo necessità, in nuovi processi aziendali. 1 Carr, Nicholas G., Does IT Matter?, Harvard Business School Press,

6 Quando si parla di nuova tecnologia si è sempre circondati da scetticismo. Allora, cos'è che rende la SOA diversa rispetto agli altri approcci del passato? Ecco i fattori principali: > La SOA si basa sugli standard del World Wide Web che conducono a economiche implementazioni su scala globale, con un ampio supporto da parte dei vendor. > I Servizi sono loosely-coupled e assicurano una flessibilità molto maggiore rispetto alle vecchie tecnologie per quanto riguarda il riutilizzo e il riabbinamento dei servizi necessari a creare nuove funzioni operative all'interno e all'esterno delle imprese. > Le migliori pratiche SOA creano progettazioni che integrano i processi aziendali-e migliorano la capacità di delocalizzare ed estendere i processi ai business partner. > La SOA include sistemi e processi legacy (esistenti) in modo da salvaguardare e persino incrementare l'utilità degli investimenti in essere. L'abbinamento di questi fattori fa della SOA un approccio che offre una strategia vincente per tutti i soggetti interessati, poiché: > L'organizzazione finanziaria ottiene risparmi. > L'organizzazione commerciale ottiene un miglioramento e un'espansione dei modelli di business (come illustrato dagli esempi forniti più avanti). > L'organizzazione IT ottiene successo nel supportare la propria clientela, conseguire gli obiettivi di servizio, e disponendo della flessibilità necessaria a rispondere alle domande future grazie a una maggiore agilità. > La corporate governance ottiene un migliore allineamento tra IT e business. Con le aziende che tentano di capire come ottenere i benefici della SOA, come giustificare gli investimenti necessari, da dove iniziare, e a quale visione puntare, si rende necessaria una guida. La soluzione proposta nel presente documento è l'introduzione di un SOA Maturity Model (SOA MM) per illustrare l'impatto sempre più positivo che l'adozione della SOA può avere dal punto di vista del business. Il SOA MM prende spunto da tre fattori chiave: > I successi ottenuti dal Capability Maturity Model (CMM) e dal recente CMM Integration (CMMI SM ) del Software Engineering Institute (SEI) nel fornire un quadro comune per la definizione la valutazione del miglioramento dei processi nelle aree software e in altri ambiti di progettazione. 2 Software Engineering Institute, Capability Maturity Model Integration, 3 Heffner, Randy, Your Paths to Service-Oriented Architecture, Forrester Research, Dec

7 > Documenti quali quello di Randy Heffner del Forrester Research che illustrano i vari percorsi di successo intrapresi dalle aziende che hanno introdotto la SOA. > Il successo della nostra clientela nell'implementazione dei progetti SOA. Inserendo la SOA in un contesto analogo al Capability Maturity Model, possiamo illustrare gli obiettivi, le caratteristiche e i presupposti fondamentali ai fini del successo della SOA, procedendo attraverso i seguenti livelli successivi: New Cost Business Business Business Functionality Reduction Responsiveness Transformation Optimization Il SOA MM include gli obbiettivi, la definizione del campo di applicazione e i benefici di business per ciascun livello, gli standard industriali più importanti, le pratiche principali e i fattori critici di successo, dal punto di vista tecnologico e organizzativo. Il SOA MM fornisce pertanto una guida utile per stabilire una visione della SOA e un punto di riferimento per misurare i progressi compiuti. Forrester Research ha riscontrato come le aziende adottino l'approccio alla SOA secondo percorsi diversi, ciascuna con benefici aziendali, capacità e requisiti di infrastruttura tecnologica diversi. Per talune aziende, l'aspetto più importante è rappresentato dall'attenzione nei confronti dell'integrazione interna e del workflow, mentre per altre l'aspetto più rilevante è costituito dall'integrazione con i partner. Perseguendo i percorsi specifici appropriati alle proprie esigenze, le aziende possono correlare i percorsi al modello di maturity, in modo da verificare le esigenze organizzative, tecnologie e gli obbiettivi, nella scalata dei livelli di SOA maturity. 2.0 CHE COSA È LA SOA (SERVICE ORIENTED ARCHITECTURE)? La SOA è un'evoluzione del computing distribuito studiata per consentire l'interazione tra componenti software, chiamati Servizi, all'interno di una rete. Gli applicativi vengono creati da un abbinamento dei suddetti servizi e, soprattutto, questi ultimi possono essere condivisi tra molteplici applicativi. Ad esempio, un applicativo di gestione risorse umane potrebbe essere creata a partire dai seguenti servizi: > Un Employee Administration Service per la gestione di assunzioni, modifiche di livello ed estinzione dei rapporti. 5

8 > Un Salary and Review Administration Service per la gestione degli stipendi e la valutazione dell'efficienza dei dipendenti secondo standard aziendali. > Un Benefits Administration Service per avviare ed estinguere i benefit e per elaborare le iscrizioni annuali. > Un IT Security and Provisioning Service per la gestione delle aggiunte e delle eliminazioni dei diritti di accesso ai dipendenti, in funzione del loro ruolo e del loro livello. > Un Payroll Service erogato in modo protetto via Internet da un fornitore esterno. > Un HR Department Portal Service che fornisce un'interfaccia utente basato su Web browser per i membri del dipartimento HR, e presenta le funzioni dei servizi di cui sopra. > Un Business Process Management Service per la gestione dei processi di approvazione e notifica. Con la SOA, le organizzazioni possono riutilizzare in misura molto maggiore gli asset esistenti e rispondere in tempi più rapidi alle richieste di modifica. Tali vantaggi sono attribuiti a diversi elementi critici della SOA: > I servizi riflettono logiche attività di business. Ciascun servizio svolge, di norma, molteplici operazioni per una specifica funzione aziendale, come ad esempio, il Payroll Service, che esegue operazioni tra cui rilascio di assegni, compilazione di modulistica fiscale, e rapporti periodici sulla tenuta dei libri paga. Da sottolineare è il fatto che tali servizi, spesso definiti course-grained, riflettono concetti di processo di business, non le funzionalità delle API fine-grained, definite dai tradizionali applicativi software pacchettizzati. > I nuovi servizi possono essere aggiunti o creati componendo i servizi esistenti senza incidere sull'implementazione di questi ultimi. Quindi, nell'esempio precedente, si potrebbe aggiungere un componente Employee Self-Service che faccia uso dei servizi esistenti, filtrando dati e operazioni in modo da utilizzare quelli appropriati alle utenze self-service. In questo modo, si rende possibile un approccio di tipo incrementale all'implementazione dei servizi. 4 Care must be taken with respect to security and service level agreements (SLA) when adding new consumers to existing services 6

9 > I servizi possono trovarsi su sistemi eterogenei all'interno di reti e aree geografiche in modo da garantire indipendenza dalle piattaforme e trasparenza di ubicazione. Non è necessario che ogni servizio sia implementato utilizzando la stessa tecnologia software o hardware, o che si trovi sulla stessa rete o ubicazione. Il Service Salary and Review Administration potrebbe essere implementato in ambiente COBOL o su server Linux/mainframe in un'ubicazione, mentre il Service IT Security and Provisioning potrebbe essere implementato in ambiente Microsoft.NET su server Windows in una ubicazione diversa. > I servizi comunicano attraverso protocolli standard garantendo ampia interoperabilità. Il più delle volte, soprattutto per la connessione di sistemi eterogenei, i protocolli si basano su standard World Wide Web. I Web services sono l'implementazione di servizi che utilizzano tali standard. Amazon ed ebay sono esempi importanti di multinazionali che hanno reso i propri applicativi chiave accessibili via Internet Web services. > I sistemi applicativi legacy possono essere integrati come servizi sfruttando gli investimenti in essere. La tecnologia SOA fornisce meccanismi ai sistemi front-end (o wrap ) in uso dietro un'interfaccia di servizi, senza alcuna modifica del sistema in uso. Inoltre, i tradizionali vendor ERP espongono con sempre maggiore insistenza le funzionalità dei propri applicativi sotto forma di Web services. > I Servizi hanno un'interfaccia e sono orientati ai messaggi. Le funzionalità offerte dai servizi sono definite da metadati che descrivono l'interfaccia al servizio e alle sue operazioni. Le informazioni vengono trasmesse sotto forma di messaggi da e verso i servizi. Nella definizione dell'interfaccia e dei messaggi, l'attenzione è rivolta al cosa faccia un servizio piuttosto che al come. Il come è interno all'implementazione del servizio. Gli applicativi SOA sono generalmente progettati per essere event-driven, rispondendo ai messaggi non appena essi arrivano. L'implementazione della SOA si basa sulla competenza, sulla metodologia e sull'infrastruttura SOA, per supportare l'applicativo SOA in modo affidabile, scalabile e protetto. Tra gli elementi fondamentali di questo nuovo approccio figurano: > Metodologie di analisi, progettazione e implementazione per coadiuvare project manager, sviluppatori e personale IT in una progettazione, assemblaggio e riutilizzo rapidi dei componenti SOA. 5 Chappell, David, Enterprise Service Bus, O Reilly,

10 > Tool di modellizzazione, configurazione, collaudo e implementazione per specificare e creare i servizi e quindi definire i processi di business che orchestrano i servizi di livello inferiore in servizi aziendali coarse grained. > Enterprise Service Bus (ESB) per assicurare comunicazioni e trasformazioni di dati affidabili, scalabili e distribuiti tra i servizi, e per fornire adapter alla tecnologia legacy e alle implementazioni dei diversi vendor. > Repository e Registro di Servizi e Policy per assicurare un luogo comune dove organizzare, comprendere e gestire le informazioni, incluso un catalogo dei servizi disponibili, definizioni delle relative interfacce e policy che governano l'impiego di tali servizi. > Tool di provisioning e gestione delle infrastrutture per assicurare la visibilità dei processi di business (BVP, Business Process Visibility) su un'infrastrutture SOA ampiamente distribuita. > Runtime Governance per definire e controllare le policy aziendali e di sicurezza e per garantire il rispetto delle norme a tutti i livelli software, in modo da riflettere i processi aziendali sottostanti. 3.0 IL SOA MATURITY MODEL L'introduzione della SOA può fornire alle organizzazioni tecnologiche e commerciali un impulso ai fini del conseguimento degli obiettivi comuni dell'azienda. Il SOA Maturity Model può indicare gli obiettivi e costituire un ausilio per comprendere in che modo la SOA possa incidere sempre più positivamente sull'impresa. La Figura 1 illustra i cinque livelli del SOA Maturity insieme all'impatto aziendale chiave, partendo dal meno al più maturo: Initial Services, Architected Services, Business Services e Collaborative Services (due diversi tipologie al livello 3), Measured Business Services, e Optimized Business Services. Sono altresì illustrati, a titolo di riferimento i corrispondenti livelli CMMI SM. 6 In very short summary: CMMI SM Performed means that needed functions are performed, CMMI SM Defined means that standard processes are defined, CMMI SM Managed means that the standard processes are implemented and managed, CMMI SM Quantitatively Managed means that the results of the processes are measured against goals, CMMI SM Optimizing means that there is a continuous improvement process implemented based on the measurements. 8

11 La Tabella 1 illustra gli attributi chiave di ciascun livello di maturity, ovvero impatto aziendale, campo di applicazione, fattori critici di successo e standard attinenti. In linea con l'approccio adottato dal SEI per il Capability Maturity Model, nella Tabella 2 vengono specificati pratiche e obiettivi chiave per ciascun livello di SOA maturity. Il conseguimento di tali obiettivi e l'implementazione di tali pratiche costituiscono il termine di misurazione atto a valutare il raggiungimento di un livello di maturity. Ogni livello di maturity ha come presupposto gli obiettivi e le pratiche dei livelli inferiori. Accade spesso che determinati obiettivi siano conseguiti, alcune pratiche implementate e alcune tecnologie utilizzate a livelli inferiori rispetto a quelli indicati nelle Tabelle 1 e 2. Tale fenomeno è da considerarsi prevedibile e dovrà essere incoraggiato in funzione delle priorità dell'impresa. I capitoli successivi prenderanno in esame ciascuno dei livelli di SOA maturity. 9

12 Tabella 1-SOA Maturity Model Maturity Level Principale beneficio di business Campo di applicazione Successo tecnologico Cruciale Technology Success Factors Fattori cruciali di successo umano e organizzativo Standard attinenti prescelti 1. Initial Services Nuove funzionalità Sperimentazione R&S, Progetti pilota, sito Web, Portale, Integrazione personalizzata, piccolo numero di servizi Standard, Integrazione legacy Sviluppatori apprendono capacità di sviluppo dei servizi Sponsorizzazione Developer Manager XML, XSLT, WSDL, SOAP, J2EE,.NET 2. Architected Services Riduzione e controllo dei costi IT Molteplici applicativi integrati Supporto per eterogeneità e sistemi distribuiti, Messaggistica affidabile, Mediazione, facilità di implementazione, Integrazione Database, Versioning, Sicurezza interna, gestione prestazioni Gruppo architettura assicura leadership, Centro di competenza SOA Sponsorizzazione CIO UDDI, WS- ReliableMessagi ng, WS-Policy, WS- Addressing, XQuery, WS- Security, SAML 3.a. Business Services Reattività di business - modifica rapida ed efficace dei processi di business Processi di business all'interno dell'unità operativa o dell'impresa Riutilizzo, facilità di modifica, disponibilità, regole dei processi di business, processi eventdriven, applicativi compositi Collaborazione tra IT e commerciale all'interno delle organizzazioni, WS-BPEL 3.b. Collaborative Services Reattività di business - collaborazione con partner aziendali e commerciali Servizi disponibili e partner esterni, Interaziendale Servizi Esterni, sicurezza interaziendale, traduzione protocolli interaziendali, transazioni di lunga durata SOA per l'intero ciclo di vita Governance, Impegno esecutivo, capacità di progettazione event-driven Sponsorizzazione Business Unit Manager RosettaNet, ebxml, WS- Trust 4. Measured Business Services Trasformazione del business da reattivo a real-time, Rispetto dei parametri prestazionali Unità operativa o impresa, Interaziendale Monitoraggio attività di business, Elaborazione flusso di eventi, Elaborazione eventi complessi, Event-driven dashboard e allarmi Continue valutazione dei processi di business e relative risposte Sponsorizzazione CFO 5. Optimized Business Services Ottimizzazione del business - reazione e risposta in automatico Unità operativa o impresa,interaziendale Automazione event-driven per l'ottimizzazione Cultura del continuo miglioramento Sponsorizzazione CEO 10

13 Tabella 2-SOA Maturity Model Obbiettivi e Pratiche chiave Maturity Level 1. Initial Services 2. Architected Services 3.a. Business Services 3.b. Collaborative Services 4. Measured Business Services 5. Optimized Business Services Obbiettivi principali 1. Apprendere la tecnologia SOA in ricerca e sviluppo ed eseguire progetti pilota. 2. Applicare la tecnologia SOA alle immediate esigenze dell'organizzazione. 3. Definire una quota iniziale di ROI per i progetti e applicarla ai progetti iniziali. 1. Istituzionalizzare l'impiego della SOA. 2. Porre in essere una leadership architetturale per la SOA. 3. Dimostrare i risultati dell'utilizzo degli standard tecnologici. 4. Prevedere l'uso delle informazioni SOA per l'ottimizzazione del business. 1. Creare una continua collaborazione tra organizzazioni di business e tecnologica per la governance SOA. 2. Supportare interi processi di business tramite SOA. 3. Dimostrare i risultati del riutilizzo dei servizi e la reattività ai cambiamenti. 1. Creare una continua collaborazione tra organizzazioni di business e tecnologica per la governance SOA. 2. Estendere i processi di business SOA alle organizzazioni esterne 3. Dimostrare i risultati dell'uso dei servizi a fini collaborativi. 1. Istituire la trasformazione da processi di business reattivi a processi di business in tempo reale. 2. Definire e soddisfare parametri prestazionali business-oriented. 1. Garantire una leadership di livello enterprise per il business e la governance della SOA. 2. Dimostrare i risultati del continuo miglioramento supportato dalla SOA. Pratiche principali 1. Creare le definizioni dei servizi. 2. Integrare la SOA in metodologia di sviluppo progetti. 3. Quantificare costi, tempi, e benefici di business dei progetti pilota. 1. Specificare gli standard tecnologici per la SOA. 2. Integrare la SOA in un processo di sviluppo su scala aziendale. 3. Fornire un centro di competenza e formazione SOA su scala aziendale. 4. Utilizzare l'integrazione incrementale. 1. Specificare le policy per l'uso della SOA nella creazione o nella modifica dei processi di business. 2. Sfruttare le funzionalità event-oriented e di mediazione delle tecnologie SOA, soprattutto per quanto riguarda il miglioramento o l'estensione dei processi di business. 1. Specificare le policy per l'uso della SOA in collaborazione con i partner aziendali e commerciali 2. Implementare la sicurezza interaziendale. 1. Raccogliere e analizzare parametri prestazionali in tempo reale orientati ai processi di business. 2. Implementare una continua valutazione e riprogettazione dei processi di business. 1. Implementare processi di business autocorregenti. 11

14 3.1 SOA MATURITY LIVELLO 1 INITIAL SERVICES Il SOA Maturity Livello 1 è costituito dagli Initial Services (vedi Tabelle 1 e 2), che rappresentano la fase iniziale di apprendimento e progettazione dell'adozione SOA. In questa fase, i progetti vengono generalmente realizzati per soddisfare l'esigenza specifica di implementare le funzionalità, collaudando, contestualmente, specifiche tecnologie e un approccio alla SOA. Questo livello di maturity prevede inoltre iniziali attività di ricerca e sviluppo volte a collaudare le tecnologie SOA in ambiente di laboratorio. Generalmente, l'introduzione iniziale della SOA è guidata dall'organizzazione preposta allo sviluppo applicativo (spesso nel quadro di un progetto di integrazione applicativa). Vengono apprese nuove capacità di sviluppo ed effettuati tentativi iniziali di quantificazione del ritorno sull'investimento. E' questo il livello in cui vengono introdotti gli standard SOA più elementari definiti dal W3C, come XML per la definizione dei formati dei messaggi, WSDL per la definizione delle interfacce dei servizi e SOAP per l'invocazione dei servizi. Un tipico esempio di progetto di Initial Services illustrato in Figura 2 consiste nel collegare il portale web della forza vendite di un'azienda direttamente a un sistema legacy di previsione vendite operante su mainframe e a un nuovo applicativo CRM esposto come Web service. In questo esempio, potrebbe essere utilizzata la seguente componente infrastrutturale SOA: > Un Servizio di integrazione a mainframe come Shadow RTE di DataDirect, che assicura l'accesso Web service basato su standard a un sistema legacy di previsione vendite ospitato all'interno di un CICS su un mainframe IBM che esegue z/os. > Una piattaforma di sviluppo altamente produttiva ottimizzata per la creazione di applicativi aziendali service-oriented, come Progress OpenEdge, volta a sviluppare e ospitare nuova logica applicativa CRM accessibile sotto forma di Web services. 7 World Wide Web Consortium, Web Services Activity, 12

15 I principali vantaggi offerti da questo progetto iniziale consistono nel garantire la necessaria funzionalità di business, consentendo, allo stesso tempo, di apprendere il modo in cui sviluppare e implementare un applicativo SOA elementare. Tale implementazione utilizzerebbe il protocollo SOAP tra il server portale e i servizi di supporto, nonché per il servizio di Sales Forecasting e Tracking, ottenendo le informazioni dall'applicativo CRM. Tuttavia, anche un applicativo iniziale elementare potrebbe giovarsi dell'utilizzo di alcuni componenti supplementari dell'infrastruttura SOA. Oltre alle conoscenze maturate grazie all'impiego precoce delle tecnologie, la ragione più importante per l'introduzione di queste avanzate tecnologie nei progetti iniziali è quella di porre in essere una tecnologia scalabile in modo tale che, non appena la SOA integri altre funzioni di business, le opportune basi risultino già in essere. Ad esempio, la Figura 3 illustra lo stesso esempio con l'aggiunta di: > Un Servizio di Runtime Governance, come quello di Actional, che assicura il meccanismo di monitoraggio e controllo necessario ad applicare policy di servizi e sicurezza in tutte le fasi di un processo di business, nell'ambito di elementi eterogenei dell'infrastruttura SOA. 13

16 > Un Enterprise Service Bus (ESB) come quello di Sonic, che assicura un modello di interazione standard per i componenti SOA, inclusi Web services e database relazionali, sotto forma di infrastruttura distribuita, scalabile e facile da implementare. L'ESB fornisce un elevato numero di adapter, grazie ai quali i servizi implementati con tecnologie eterogenee sono in grado di interscambiare messaggi, consentendo, ad esempio, a un applicativo.net di comunicare con un applicativo J2EE al livello di servizi. > Un Registro dei servizi che supporta lo standard UDDI, assicura l'archiviazione centralizzata delle definizioni dei servizi nell'ambito dei progetti iniziali, e garantisce un unico punto di riferimento grazie al quale gli sviluppatori dei servizi possono ottenere le definizioni degli stessi. 14

17 3.2 SOA MATURITY LIVELLO 2 ARCHITECTED SERVICES Il Livello 2 di SOA Maturity è costituito dagli Architected Services (vedi Tabelle 1 e 2). E' a questo livello che gli standard vengono fissati per quanto riguarda la governance tecnica dell'implementazione SOA, generalmente sotto la guida dell'organizzazione preposta all'architettura. Il principale vantaggio offerto da questo livello consiste nella riduzione dei costi di sviluppo e implementazione, grazie all'utilizzo dell'infrastruttura e dei componenti standard SOA, rispetto all'impiego di vecchie tecnologie, o a costi accumulati attraverso molteplici singoli progetti obsoleti. Tali vantaggi risultano più evidenti negli ambienti eterogenei tipici di gran parte delle imprese. Sulla base dell'apprendimento e del feedback ottenuto grazie agli Initial Service al Livello 1 di Maturity, si definiscono gli standard architetturali e le tecnologie di implementazione standard. Ad esempio, si definiscono gli standard relativi a: > I protocolli aziendali SOA da utilizzare, da scegliere tra gli standard industriali, in particolare quelli definiti da W3C, OASIS e WS-I. > Piattaforme di implementazione da utilizzare. > Policy di riutilizzo, runtime governance, compliance e sicurezza. > Processo di analisi tecnica per la definizione dei nuovi servizi e il riutilizzo di quelli esistenti. La Figura 4 illustra un esempio di implementazione SOA al Livello 2 di Maturity in un caso di trading finanziario. Il Livello 2 di Maturity prevede l'impiego dei componenti chiave già illustrati nella Figura 3, incluso il servizio runtime governance e l'enterprise Service Bus, oltre agli aspetti chiave supplementari di questo esempio: > Un Repository che estende il Registro dei Servizi fornendo l'archiviazione per gli artefatti SOA e le informazioni sulle policy. Il supporto per l'intero ciclo di vita (lifecycle support) come controlli degli accessi, versioning e tool di implementazione costituisce un'altra importante caratteristica da prendere in considerazione in questa sede. L'impiego di un repository dotato di supporto di sviluppo e runtime è parte integrante del Livello 2 di Maturity-Architected Services. > Un servizio Runtime Governance modificato che identifica servizi e dependency, assicurando un'opportuna base per l'identificazione, la diagnosi e la soluzione automatica degli errori a livello di sistema e applicativo. 8 OASIS, OASIS Committees by Category: Web Services and SOA, 9 WS-I, Web Services Interoperability Organization, 15

18 > Un Servizio Message Transformation che consente l'integrazione dei servizi con differenze nei contenuti o nei formati previsti dei messaggi. Ciò avviene spesso tramite l'invocazione delle trasformazioni XLST applicate a un messaggio XML. In questo esempio, assistiamo a una funzione di mediazione sotto il controllo dell'esb. > Un Servizio Single Sign-On che supporta l'autenticazione e l'autorizzazione degli utenti all'interno dell'organizzazione. Tale servizio, generalmente fornito da un vendor, può basarsi sullo standard OASIS SAML per lo scambio delle informazioni di autenticazione e autorizzazione. 3.3 SOA MATURITY LIVELLO 3 BUSINESS SERVICES E COLLABORATIVE SERVICES L'interesse del SOA Maturity Livello 3 è concentrato sulla collaborazione tra organizzazioni tecnologiche e aziendali, per fare in modo che l'impiego della SOA garantisca un'evidente reattività di business. Il valore chiave della SOA è il legame tra processi aziendali e processi digitali, come illustrato in Figura The Big Strategic Impact Of Organic Business And Service-Oriented Architecture, Forrester Research, Inc., June

19 Figura 5-La fonte di energia della SOA (adattata rispetto a Forrester Research) Il SOA Maturity Livello 3 è definito con due percorsi complementari al conseguimento dei suddetti obiettivi: uno, Business Services, orientato al miglioramento dei processi operativi interni e uno, Collaborative Services, orientato al miglioramento dei processi collaborativi con i partner esterni, (vedi Tabella 1 e Tabella 2). Ovviamente, per ricavare il massimo vantaggio dalla SOA, possono essere applicati entrambi, ma il Livello 3 di Maturity può essere conseguito anche attraverso uno dei due percorsi, dal momento che entrambi garantiscono il miglioramento della reattività di business da parte dell'azienda. La Figura 6 illustra un esempio di implementazione SOA al Livello 3 di Maturity per il trading finanziario. La chiave per questi Business Services è rappresentata da: > Business Process Management (BPM)-la gestione di processi di lunga durata che coinvolgono messaggi sequenziali tra servizi. La gestione può avvenire, ad esempio, tramite Sonic Orchestration Server, che è in grado di gestire lo stato di ciascun processo insieme ai risultati intermedi. 17

20 Nella Figura 7, prosegue l'evoluzione dei Business Services con l'aggiunta di: > Netto miglioramento dei processi di business. Uno dei principali vantaggi offerti dalla SOA è la sua capacità di rendere possibili le modifiche dei processi di business attraverso la riconfigurazione dei servizi. In questo esempio, un nuovo Compliance Service necessario ai fini del rispetto delle normative viene inserito nel flusso di messaggi tra l'order Management Service e il Trading Service, senza alcuna modifica alle implementazioni dei servizi esistenti. > Riutilizzo dei servizi. In questo esempio, il riutilizzo viene illustrato attraverso un applicativo multi-channel (ad esempio, l'accesso viene fornito allo stesso applicativo attraverso diversi metodi di comunicazione al cliente), in cui l'order Management Service viene condiviso sia dal Call Center Service sia dall'online Service. L'interesse alternativo nel Livello 3 di Maturity è rappresentato dai Collaborative Services, con l'accento posto sul collegamento ai partner esterni. La Figura 8 illustra un esempio in cui la società di trading si è espansa in una nuova azienda di transazioni Forex offerte via Internet. 18