La forza gravitazionale della Soa attrae le società specializzate nelle soluzioni di integrazione applicativa. Un altro noto brand, webMethods (www.webmethods.com ), [da poche settimane acquisita da Software AG ndr] è passata dallo storico livello di offerta di soluzioni di Eai (Enterprise application integration) e B2B all’integrazione e governance delle diverse componenti della Soa nelle applicazioni di business.
ZeroUno ha intervistato Augusto Davico, country manager e Francesco Maselli, direttore tecnico della filiale italiana dopo l’annuncio che nella sua Soa Governance WebMethods integrerà la gestione del ciclo di vita dei servizi Soa e il repository dei metadati semantici, con le acquisizioni di Infravio e Cerebra. Quartier generale a Fairfax (Virginia), filiali in Usa, Europa, Asia Pacifico e Giappone, in 10 anni 1400 clienti acquisiti, webMethods fattura 200 milioni di dollari con 1000 dipendenti. Il logo dice “Get there faster”: nuovi servizi in minor time to market. “Ogni giorno vanno in produzione due progetti; un cliente ogni tre giorni; una soluzione webMethods porta (grandi) progetti al Roi dopo 10 mesi e richiede una persona contro le quattro di un progetto Ibm”, sostiene Davico.
La premessa concettuale di Maselli è che “Soa significa processi operativi non più basati su silos di applicazioni ma sulla (ri)combinazione di molti servizi elementari: ognuno è un asset da disegnare, adattare e gestire fino alla performance, riusabilità e qualità di servizio, perché si componga con altri a costituire un portafoglio di servizi visibili al business”.
Nascono interdipendenze tra servizi elementari di un ordine di grandezza superiore a quelle nel vecchio pacchetto applicativo, governabili solo catalogandole e amministrandole su tutto il loro ciclo di vita: è l’imperativo della Soa governance, indirizzato da webMethods Fabric (wMf), infrastruttura per servizi Soa. wMf combina tecnologie di integrazione aziendale (Enterprise service bus) e di Business process management (per esempio Business activity monitoring per processi event driven), per fondere in processi di livello enterprise i servizi al business (vedi figura).
webMethos Fabric, infrastruttura per servizi Soa
Il wMf descritto governa fin qui solo Management e Monitoring, cioè il run time dei servizi elementari. E Davico sottolinea che oltre all’uso consapevole di wMf dei clienti webMethods, c’è quello inconsapevole di quelli Oracle e Sap, grazie ad accordi corporate (con royalties a webMethods) per l’utilizzo di wMf come adapter all’interno di Fusion e Netweaver, in attesa della soluzione originale (nel caso di Netweaver rischedulata al 2013).
Ciclo di vita dei servizi Soa
Il run time è solo un segmento del ciclo di vita dei servizi elementari da governare per la Soa d’impresa. Occorre gestire tre “time” (design, run e change, rispettivamente di competenza degli sviluppatori, dei tecnici IT e degli utenti business) e webMethods lo fa grazie alle soluzioni Infravio governando Registry (che in ambito Soa è lo strumento software che raccoglie ed espone metadati sui servizi di business disponibili) e Repository (contenitore di web service). Nel Design time verrà ottimizzata la condivisione d’impresa dei servizi elementari (interrogazioni semplici non correlate tra di loro, per esempio la semplice richiesta di dove si trova un dato), grazie al Registry con la rubricazione automatica di quelli candidati alla condivisione a livello di run time.
Nel Change time, l’utente dovrà avere la possibilità di capire l’impatto sul business di un determinato cambiamento (il sistema dovrà quindi abilitare la definizione di scenari del tipo “what if”). Cruciale associare a design time Registry e Repository (attributi/proprietà di ogni servizio, per esempio componenti costitutive, configurazioni, regole di business o norme associate). Evidente il Roi della gestione design/change time per grandi aziende, dove complessità e rischi aumentano con il crescere del numero di servizi e di interdipendenze, così come per servizi condivisi negli scambi con partner, clienti o fornitori, dove è la Soa governance ad agire da filtro sul servizio in base al profilo del corrispondente.
Un repository semantico
Serve che attributi/proprietà dei servizi elementari siano descritti da “dati sui dati” comprensibili nei vari contesti, dove sono costruiti e dove l’informazione è consumata: cioè un repository di metadati con tecnologia semantica e le tassonomie adatte agli ambienti fruitori. È il tassello di Cerebra (in figura 1 Metadata Library), condiviso dagli ambienti di pianificazione (design time), operativo (run time) e utenza (change time) dove i servizi elementari vengono combinati e abilitano sia l’accennata analisi predittiva (come e dove si ripercuota un cambiamento ipotizzato in un punto, in base a una data orchestrazione di wMf), sia la ricerca della risorsa informatica più idonea sulla base di criteri di performance a run time prestabiliti. “Che l’acquisizione di Cerebra sia vincente – dice Davico – lo dimostrano acquisizioni simili seguite a ruota, da Ibm e Bea (Flashline)”.
Qualche tempo fa si è tenuto a Roma il Soa Executive Summit, evento organizzato da Ibm e dedicato ai Cio, che hanno potuto incontrare esperti ed analisti It con i quali scambiare opinioni sulle opportunità offerte alle imprese e ai dipartimenti S.I. dalla Service oriented architecture e sullo stato di sviluppo delle tecnologie inerenti. Nell’occasione abbiamo potuto incontrare Tom Rosamilia, General Manager, Application & Integration Middleware, Ibm Software Group, quindi anche dei prodotti della famiglia WebSphere, sui quali poggia l’offerta integrata Ibm in ambito Soa. Tra gli argomenti discussi, uno in particolare merita attenzione, ed è il ribadito impegno di Ibm, presente come è intuibile in numerosi comitati di standardizzazione, per lavorare su progetti che mirino a standardizzare non solo le interfacce che incapsulano i servizi Web (che secondo Rosamilia si vanno di fatto ‘coagulando’ nell’ambiente Java), ma le funzionalità di business fornite dai servizi stessi. In altre parole, si tratta di fare in modo che un certa funzionalità realizzata da un servizio Web venga eseguita con una procedura uniforme, in modo che l’azienda utente X possa usare in una sua applicazione composita un servizio pubblicato dalla società Y piuttosto che dalla software house Z senza problemi in quanto entrambi operanti appunto secondo uno modello procedurale standardizzato. L’idea, che di fatto costruirebbe un ‘ponte’ tra le attività di analisi e di ottimizzazione dei processi di business, sulle quali Ibm è fortemente impegnata, e le tecnologie abilitanti questi stessi processi, è certamente lungimirante anche se, a nostro parere, alquanto ambiziosa. Infatti non è affatto detto che il rendere i servizi funzionalmente intercambiabili in applicazioni composite entri negli interessi dei vendor di applicazioni business. In ogni caso, Ibm va avanti: secondo Rosamilia uno strumento di base per realizzare quest’idea, già esiste, ed è il Bpel (Business Process Execution Language). E, spiega ancora Rosamilia, Ibm ha istituito una sorta di steering committee per capitalizzare le sinergie che si vanno necessariamente creando tra lo sviluppo della propria architettura middleware di riferimento, cioè WebSphere, e i grandi Isv che stanno rendendo ‘Soa enabled’ le loro applicazioni business al fine appunto di giungere “a web services che parlino una stessa lingua non solo per la tecnologia ma anche per il business”. (G.C.B.)
Risale al 7 novembre 2006 il completamento dell’acquisizione di Mercury da parte di Hp (www.hp.com ) – un boccone da 4,5 milioni di dollari. È “la più grande acquisizione nella storia Hp, che nel vasto portafoglio di soluzioni Openview” fa confluire le capacità Mercury di It Governance e di gestione e delivery applicativa, e “crea una nuova struttura Hp software nel mercato nell’Ottimizzazione della Tecnologia per il Business (Bto)”.
A questo punto rischia di passare inosservata un’altra acquisizione, più piccola, quella di Systinet da parte di Mercury stessa (nel gennaio del 2006), che merita invece attenzione: Hp ha guardato oltre al beneficio contabile indotto da una Mercury lanciata a un fatturato 2007 di 1 miliardo di dollari (con una decennale crescita annua al ritmo del 31%). Ce ne convince la recente intervista a Roman Stanek, fondatore della startup Systinet, diventato vice presidente della divisione prodotti Mercury, ma rimasto “guru della Soa”. La domanda centrale è come l’offerta Systinet va ad integrare la linea di prodotti Mercury. Stanek è sintetico: Systinet si può vedere come “il catalogo dei servizi disponibili in ambiente Soa” lungo tutto il loro ciclo di vita, dallo sviluppo alla produzione al ritiro. E’ un framework per far funzionare la “Governance olistica”, necessaria a combinare e governare il grande “lego” in cui le applicazioni di business si trasformano sotto l’ombrello Soa.
Il rischio “inerente” ad iniziative Soa
C’è infatti un binomio agilità – fragilità, che colloca la Soa a cavallo fra promessa di flessibilità (trasformabilità processi) e di razionalizzazione (un unico processo riutilizzabile può sostituire più processi ripetitivi, contenendo, ad esempio, i costi di compliance), e rischio inerente, che impone un risk management specifico; un’inchiesta dell’Economist (5/2006) indica, fra le “iniziative a rischio” per un’impresa, Soa/Servizi Web al 29%, seconda dopo sicurezza al 36% e davanti ad outsourcing al 28%.
La diagnosi “filosofica” di Stanek rimanda ad una robusta sottostima degli effetti Soa sul disegno e la gestione dei processi aziendali, proprio in quanto abilita e costringe chi sviluppa e chi gestisce a “navigare” attraverso le attività distribuite d’impresa. Il suo successo ha bisogno di organizzazione e best practice e, a monte, di “uno stato mentale”: una cultura nuova ed aperta ad una larga e diffusa condivisione, il che richiede tempo. Gli elementi del “rischio Soa”? Anzitutto il “single point of failure” (una componente malfunzionante contagerà tutte le applicazioni che la condividono; e toccare un servizio elementare richiede la conoscenza preliminare e approfondita di tutti i processi aziendali che lo incorporano, nonché la previsione delle ripercussioni): sicché, in applicazioni costruite per componenti sono ancor più cruciali governance di qualità (test) e performance, e (livello di) qualità dei servizi. Poi c’è la “mancanza di framework” di governance: la non definizione o il non rispetto di “regole della casa” (quali la segregazione di ruoli o il chi può far cosa), se in un ambiente a silos potevano far danni limitati, sono inaccettabili in un pool condiviso. O l’insufficiente rigore nella governance: occorre un severo controllo dei cambiamenti apportati ai singoli servizi elementari. O infine il proliferare di “servizi non conformi (rogue)”, magari utili ma sviluppati bottom-up e ingestibili da una governance olistica, in quanto non a catalogo.
La Bto estesa alla Soa
Hp-Mercury propone (con le soluzioni e le tecnologie di Systinet), di ridurre il rischio intrinseco Soa con una strategia di governance olistica, estesa a tutto il ciclo di vita dei servizi. L’infrastruttura aiuta ad ottimizzare la qualità dei servizi sviluppati e a gestirli in produzione con un’ottica di Bto (Business Technology Optimization), misurata sui risultati di business. In particolare, offre diversi punti di partenza con un approccio flessibile e incrementale: è “configurabile” per una nuova iniziativa Soa, o per un dispiegamento parziale di alcuni servizi, o per la messa in produzione di servizi Soa su vasta scala. (R.M.)
HP-MERCURY: MITIGARE IL RISCHIO INSITO NELLA SOA
STANDARD SOA: UN PONTE PONTE TRA IT E BUSINESS
