In una “Giornata per CIO” organizzata da Gartner, Massimo Pezzini, VP Distinguished Analyst, ha offerto a un affollato uditorio un vero “corso” accelerato sulla Service Oriented Architecture (Soa), dallo stato dell’arte alle prospettive concrete di evoluzione delle business application (Ba, ossia Erp, Crm, Scm ecc.) “verso l’integrazione dei processi con quali architetture e quali tecnologie”, per riprendere il titolo dell’intervento. Un percorso articolato in tre passaggi: sostanza concettuale della Soa, best practice per orientare “per gradi” le Ba alla Soa e politiche di scelta, con carrellata su tecnologie abilitanti e vendor.
Soa, concetti e standard
Nella Soa, il servizio è qualunque software modulare con funzionalità applicative che le esponga tramite un’interfaccia formalizzata secondo specifici standard (per esempio, nel caso dei servizi Web Wsdl e Soap). Un paragone col passato? È la vecchia subroutine, capace di vivere in rete, ingaggiabile da chiunque ne conosca e indirizzi l’interfaccia. Le applicazioni distribuite si suddividono, in base al (mutuo) comportamento, in fornitrici o in consumatrici di servizi. La Soa non è altro che un’architettura client server con interfacce standard, arricchita da principi mutuati dalla programmazione a oggetti.
Il fattore differenziante è che le proprietà dell’applicazione fornitrice non esposte non riguardano l’applicazione fruitrice. È indifferente che un servizio sia sviluppato in Java o .Net, o una vecchia applicazione Cobol-Cics incapsulata, o una funzione Sap esposta con Enterprise Service Architecture (Esa). Un déja vu (con Corba e, per esempio, Com/Dcom di Ibm), ma con dieci anni di esperienza in più che hanno prodotto un patrimonio di know-how utente, di best practice nei servizi professionali e standard universali. Tra questi ultimi, i Servizi web con il Web Services Definition Language (Wsdl, il linguaggio per specificare le interfacce dei vari componenti i servizi) e il Simple Access Object Protocol (Soap, protocollo di comunicazione, una semplice richiesta e risposta in formato Xml, con estensioni di Security e Reliable Messaging). Standard significa scelta fra servizi offerti da vendor in competizione e maggior facilità di accesso agli skill: scendono i costi di software e servizi professionali, si allarga l’utenza di cui la Soa è alla portata.
Best practice per orientare “per gradi” le Business application alla Soa
Scenari indirizzabili con la Soa? Un esempio può essere la multicanalità di un processo di business, in settori come trasporti, assicurazioni o, per esempio, in una banca che vuol espandere i contatti col cliente (filiale, Internet, Call Centre, canale mobile, promotori finanziari). Alla fine, un bonifico è un bonifico e da qualunque canale, sempre quella transazione Cics/Cobol esegue. Quindi se gli applicativi di back-end sono moduli Soa, sviluppare le applicazioni che supportano i diversi canali si riduce al supporto del front-end specifico senza che sia necessario normalizzare le diverse tipologie dei dati. Benefici It: minor time to market. Benefici business: nessuna discrepanza sui dati indipendentemente dal numero dei canali. Scenario: l’integrazione di diversi sottoprocessi in uno solo con una serie di funzioni applicative integrate in un’applicazione unica ma composita. Un altro esempio classico: l’operatore di Call Centre che per dare le sue risposte “salta” tra varie applicazioni, con interfacce utenti inconsistenti e campi chiamati in modo diverso: l’idea è automatizzare l’integrazione delle informazioni dai vari processi di back-end presentandole da un portale integrato (l’applicazione composita che maschera la complessità). Di nuovo, se le applicazioni di back-end sono moduli Soa, l’applicazione composita è semplice da implementare ed economica da adattare.
Nella stragrande maggioranza dei casi (un buon 75%), non si tratta di nuovi sviluppi ma di riuso di sistemi pre-esistenti (legacy o acquistati), con la Soa che razionalizza e rende graduale lo sforzo di integrazione. Con il suggerimento implicito di Pezzini, di attuare il riorientamento alla Soa delle Ba, per facilitarne il “buy-in” aziendale. Il primo progetto Soa potrà essere guardato con diffidenza e resistenze e può convenire un approccio non invasivo, che dia rapidi risultati con un budget limitato: quindi una prima fase di “pseudo servizi” con tecnologie di integrazione superficiale delle applicazioni (wrapper, screen scraper) che lasciano intatta la Ba monolitica, ma cominciano ad integrarne la presentazione utente (incapsulando videate 3270, o interfacce native delle Ba in interfacce Soa).
Guadagnata confidenza, dimostrati i vantaggi e con risorse aggiuntive, si può passare a una seconda fase di reingegnerizzazione Soa di Ba strategiche, che ne lasci intatte le funzionalità, ma ne separi le logiche di business, di presentazione e applicativa (quest’ultima suddivisa in sottomoduli riutilizzabili), esponendo interfacce Soa nei moduli così riconfigurati. Con benefici per il Tco: abbattimento dei costi di sviluppo e integrazione di nuove funzionalità e soprattutto di manutenzione, non intaccati in prima fase. Ci sono ovvi limiti di fattibilità da valutare come i costi per le Ba sviluppate in casa. Ma se una Ba supera la seconda fase, diventa agevole ogni tipo di refresh: la sostituzione mirata di moduli o sottomoduli consente, per esempio, di migrare in economia da una piattaforma legacy a una moderna o di aggiungere funzionalità, capitalizzando sulle parti della Ba che restano valide. Il percorso descritto è tipico in merger aziendali. Nella vita reale si hanno combinazioni delle tre fasi: vecchie Ba che non si toccano; Ba che ci si può consentire il lusso di reingegnerizzare su base Soa; e nuove Ba, per esempio su Sap o Oracle, già predisposte per l’integrabilità su base Soa, che si innestano sulle vecchie applicazioni reingegnerizzate in ottica Soa.
La reingegnerizzazione Soa apre la strada a un “gigantesco esercizio di integrazione aziendale” in vista del quale certamente cambiano anche equilibri organizzativi, con una riproposizione d’assieme del contributo di valore It al Business. Pezzini suggerisce un primo passo chiave: dotarsi delle competenze necessarie e creare un Integration Competency Centre (Icc), un team ospitato dalla struttura It che con know-how, metodologie e tecnologie specifiche affronti problemi e implicazioni dell’integrazione trasversale dei processi e coordini il lavoro con le varie unità di business per progredire verso le nuove Ba orientate servizi.
Comunicazione fra consumatori e fornitori di servizi
(clicca sull’immagine per ingrandirla)
Fonte: Gartner
Tecnologie per la Soa: politiche di scelta e posizionamento dei vendor
Per realizzare una Soa servono middleware, tecnologie e tool: un Application server per sviluppare ed eseguire con alta affidabilità servizi o aggiungere nuovi servizi comprati; un “Integration server” con adapter non invasivi, per integrare/incapsulare Ba vecchie e nuove; un Portal server per realizzare le applicazioni che consumano i servizi, per esempio, in ambiente multicanale e per diversi profili utenza; un tool di Bpm per gestire l’integrazione efficace (livello analisi) oltre che efficiente (livello esecuzione) tra i processi. Serve infine un meccanismo di comunicazione fra consumatori e fornitori di servizi, che Pezzini in figura 1 chiama il Soa Backplane, di cui fa parte l’Enterprise Service Bus e che deve essere affidabile, scalabile, sicuro e performante (per applicazioni critiche, magari con tempi di risposta di pochi millisecondi).
La “buona notizia”, è che le tecnologie hanno raggiunto un grado di maturità e adozione mainstream che le rende fruibili dal cliente più conservatore. La “cattiva” è che sono tante e che si deve scegliere. Passaggio cruciale, perché condizionante il futuro, in funzione di quale delle due possibili politiche di scelta fra vendor si decida (e questa scelta è inevitabile): best-of-breed (politica di scegliere ogni volta il tool migliore sul mercato, a titolo di esempio, application server subset di Weblogic da Bea o di WebSphere da Ibm, tool di integrazione da Tibco o WebMethods, portal server Sharepoint da Microsoft, tool di Bpm da Ibm) o Application Platform Suite (Aps), politica del compro “tutto da uno solo”, che fornisca una suite dei vari server (application, integration, portal, process management) ed enterprise service bus, tra loro integrati e con meccanismi di sicurezza e di Systems Management.
Il “Quadrante Magico” dei vendor Aps ne mostra solo una dozzina, ma sono tutti i grandi nomi (un middleware complesso come Aps è alla portata di pochi budget). Nel quadrante dei Leader emergono Ibm con WebSphere, Bea con Weblogic/Aqualogic, Sap con NetWeaver, Oracle con Fusion e Fujitsu Siemens, quest’ultima con forte base installata in Area Pacific. Microsoft è un Challenger. Novell e Sun sono nei Visionari, mentre sono di nicchia Nec, Hitachi, ObjectWeb e Sybase, con Jboss avanti sul gruppo: ha un ambizioso piano di offerta di Aps su base open source (il Jems, alias JBoss Enterprise Middleware System). Altra proposta open source è ObjectWeb, consorzio francese di FranceTelecom, Bull, Inria (agenzia governativa per R&d) e altri. Si va verso un mercato oligopolistico con pochi player in violenta competizione, conclude Pezzini: la scelta di campo Aps avrà un impatto strategico di lungo termine. Ed è una scelta da decidere “in modo cosciente se farla o non farla”: chi decide di non farla accetta di subirla entro tre o quattro anni dai fornitori Erp (in pratica Sap e Oracle) che stanno componentizzando su base Soa le loro soluzioni applicative (Esa di Sap e Fusion di Oracle) in moduli, in definitiva a base Servizi Web e Xml, che immetteranno sul mercato buy. Può essere scelta valida, purché cosciente.
BEA E IBM: CONFRONTO ALL’AMERICANA
Chiediamo a Massimo Pezzini un “confronto all’americana” tra Aqualogic di Bea (estensione Soa di Weblogic, vedi articolo a pag. 28) rispetto alla Soa (nata WebSphere) Reference Architecture di Ibm (vedi ZeroUno 2/05). Pezzini vede le due architetture equivalersi in qualità e coerenza infrastrutturale, entrambe con al centro Esb, Bpm, Portal e Information Server (ad integrare dati e informazioni) – ma circa lo stesso potrebbe dire di Oracle con Fusion e Sap con Esa. Diverso il giudizio dal punto di vista dei prodotti, con Ibm decisamente avanti e Aqualogic invece “un po’ da riempire”: Process indefinito, Portal coperto con la recente acquisizione di PlumTree, Bea non ha DataBase, strumenti di System management – o di sviluppo paragonabili a Rational/Ibm, anche se si è appena affacciata con M7 ad Eclipse (www.m7.com). E Ibm ha annunciato WebSphere Esb (finora ne parlava solo come di architettura da adattare al cliente). Come strategia, Aqualogic appare una roadmap per far evolvere “in ambiente eterogeneo” l’Aps Bea, apprezzabile l’approccio blended con software open source e il valore di “rendere indipendenti” dalle proposte captive di componentizzazione dai grandi vendor, in particolare Erp. Più che a sfidare Ibm sull’infrastruttura, Bea sembra puntare ad arricchire Aqualogic di componenti specializzati sui segmenti di mercato che presidia (Sip per Voip nelle Telecomunicazioni, Rfid per la logistica). La sua forza è stata Weblogic in un mercato tutto nuovo, quando WebSphere non funzionava: ora Aqualogic insegue un’opportunità Soa certo reale, ma in cui Bea arriva quinta o sesta in un mercato già affollato dai big. Per esempio, digerita Peoplesoft, Oracle ha nei fatti Bea nel mirino non solo per la concorrenza di Oracle Fusion, ma per tutto l’indotto dell’ex-PeopleSoft, che agiva da Var per Weblogic, con Tuxedo legacy presso molti ex-PeopleSoft. (R.M.)
IL MERCATO CHE VERRA’
Massimo Pezzini illustra il suo punto di vista sull’evoluzione dell’offerta di soluzioni Soa
ZeroUno: Col mercato Aps monopolizzato dai grandi vendor, c’è ancora spazio per quelli specializzati in adapter non invasivi tipo Tibco e WebMethods?
Pezzini: Guardando ai numeri, i giochi nel mercato Aps sembrano fatti: in share di mercato vince Ibm, e non di poco, per esempio nell’application server ha una share del 45%, seguita a distanza da Bea e Oracle. In realtà permangano buone opportunità per fornitori tipo Tibco: realisticamente, la scelta delle varie aziende non riuscirà ad essere un unico Aps. Specie in grandi aziende, a fronte di un mondo ideale con Soa omogenea, la realtà sarà di isole con baricentro su un Aps e un backbone che provvede alle necessarie mappature semantiche e di struttura dati tra isole.
ZeroUno: Ma se Sap e Oracle componentizzano le loro soluzioni applicative su base Soa. I due tronconi non dovrebbero essere aperti a un’integrazione reciproca?
Pezzini: I Servizi web offrono standard tecnici che non entrano nel merito del contenuto. Di nuovo, il protocollo Wsdl disaccoppia consumo da servizio, ma non risolve l’integrazione semantica: non dice nulla sulla interpretazione delle strutture di dati nei “due tronconi” (i metadati). Di solito l’integratore terzo si fà carico di mappare le due strutture di dati nella (lunga) attesa che i due grandi vendor si accordino su uno standard di metadati. E può farlo anche con l’hardware. Recente l’acquisizione da parte Ibm di DataPower, che usa l’hardware per queste mappature; Cisco propone Application Oriented Network all’interno dei router.
ZeroUno: Rimane spazio per una concorrenza che offre componenti Soa, magari specializzati?
Pezzini: Certo. Premesso che è una predizione “spericolata”, non so se i vendor di Erp non si rendono conto di quel che stanno facendo: aprire la strada a “cloni”. Esa di Sap è un libro che per ciascuno dei servizi in elenco divulga un’interfaccia formale e le funzionalità prodotte. Cosa vieta a un vendor furbo di sviluppare componenti che offrono le stesse funzionalità e le stesse interfacce di un componente Sap, a un decimo del suo costo? Potrebbe penetrare un dato servizio “a baionetta”: è il “lato oscuro” degli standard. (R.M.)
