Principal della Chappell & Associates di S. Francisco, Ca, scrittore, conferenziere, consulente in tecnologie per il business, in visita in Italia per un Architect Day organizzato da Microsoft sul filo rosso della Service Oriented Architecture (Soa), David Chappel premette, garbatamente, la sua neutralità rispetto ai vari vendor, anche se l’incontro avviene “in casa” Microsoft.
La sfida organizzativa
David Chappell descrive l’Architettura Orientata Servizi come “la forza trainante dello sviluppo applicativo oggi”: assistiamo a una convergenza di tutti i vendor (Ibm, Microsoft, Oracle, Bea, Sap, Sun ecc.) sui servizi Web alla cui base sta il noto Simple Object Access Protocol (Soap), cioè Xml, come modo standard di esporre i servizi (vedi figura). Come l’accordo multivendor degli anni 90 su Tcp/Ip ha portato all’interoperabilità fra sistemi eterogenei rendendo possibili internet globale e intranet aziendali, la convergenza sui Servizi Web porta all’interoperabilità applicativa, aprendo la strada a un’architettura di servizi per i processi all’interno delle organizzazioni. Ma avverte Chappell: costruire un servizio Web è facile (con Java Rpc o in campo Microsoft con Asp.net oggi e con Indigo domani) e a uno sviluppatore occorre un’ora per impararlo. Ma già disegnare un’applicazione che esponga efficacemente servizi richiede un’architettura applicativa e interapplicativa ben più sofisticata di prima e uno sforzo rigoroso. Soprattutto, la vera maggior complessità si annida nell’approccio e nella gestione degli impatti indotti dall’orientamento al servizio a livello organizzativo: senza mezzi termini Chappell ha visto qui aziende “perdere la sfida dell’introduzione organizzativa della Soa”.
Soa: valore e barriere per il business
Il valore decisivo della Soa sta ovviamente nelle economie e nella nuova agilità con cui si possono costruire e/o ricombinare servizi, componendo processi di business in un mondo diventato interoperabile: una volta esposti i servizi Web standard dalle applicazioni, nuovi processi di business possono invocare servizi già disponibili; inoltre processi esistenti si possono più rapidamente modificare ricombinando servizi. Ma ci sono barriere organizzative, prima fra tutte l’organizzazione per silos, che il nuovo approccio deve scalare. Primo scoglio: la motivazione dell’unità organizzativa che possiede un’applicazione – e ne paga i costi – ad esporre servizi ed erogarli ad altre unità. Cosa ci guadagna l’ “owner” dell’applicazione? È soprattutto sull’incapacità di dimostrargli un “return of change” che Chappell ha visto naufragare sforzi organizzativi Soa, a riprova ancora del classico problema dell’allineamento di motivazione fra partner di una catena del valore, mancando il quale i partner punteranno a massimizzare prima il proprio interesse e poi quello di catena. Chappell ha visto tentare due vie estreme di riconciliazione di interessi: un (fallito) “comunismo” aziendale in cui in nome del bene superiore, e a fronte di diritti di reciprocità, la funzione erogante paga i costi del servizio senza ritorni o almeno scarica costi sui fruitori; una “dittatura” con una condivisione semplicemente imposta dal top management, che talora ha funzionato “senza infamia e senza lode”. Naturale che la formula più gettonata sia il mercato: il servizio fruito si paga, idealmente a consumo.
Ma ecco uno scoglio tecnico, in cui la palla torna dal business all’It: l’unità erogante servizi applicativi si trova catapultata nel business dei servizi software, perché le sue applicazioni si trovano ad essere usate da un insieme di applicazioni clienti: servono concettualmente dei Service level agreement, con cui l’unità garantisca disponibilità, affidabilità, scalabilità a utenti “esterni”. E non basta: un terzo scoglio è che spesso le applicazioni che devono esporre servizi sono gloriose “legacy”.
Il messaggio (destinatari uomini del business e Cio) è dunque “look before you leap”: i benefici di un mondo interoperabile e orientato ai servizi si prepagano preparandosi ad affrontare e gestire scenari in cui ogni unità deve pensare agli impatti di ospitare servizi, oltre che ai vantaggi di fruirne. Ma nel contempo Chappell “suona la campana” ai Cio: la Soa offre loro l’opportunità di essere agenti del cambiamento, promuovendo la trasformazione di business abilitata dall’interoperabilità basata sui servizi esposti. Un’occasione di leadership, fuori dal paradigma, forse comodo ma paralizzante, del “per favore tieni le luci accese e non pensare ad altro” in cui David Chappell vede prigionieri parecchi Cio Usa. E che porta alla spiacevole conclusione emersa in una battuta di John Connors, ex-Cio di Microsoft, da lui incontrato a Seattle: “Un Cio può avere solo due voti: se qualcosa va male, si becca una “F” (failed, nella scala degli esami universitari Usa). Se tutto va a meraviglia, ottiene un ”C” (medio): non riuscirà mai ad avere un “A” (eccellente), perché non sarà mai messo in condizioni di ‘super performare’”.
Cio: strategia top-down o bottom-up?
Parlando a un Cio, il primo passo che David Chappel suggerisce è di “cercar di capire se la sua azienda può scegliere un approccio top-down o se se gli convenga perseguire un approccio bottom-up”. In pratica il nostro interlocutore ha visto le aziende muoversi verso un’adozione business e organizzativa della Soa con due approcci largamente diversi. Nel top-down, il Cio parte dal business: va a spiegare al management significato e valore di esporre servizi e di costruire processi di business agili su tale base; ottiene l’approvazione del business e un budget; dallo studio dei processi di business deriva quindi quali servizi esporre, con un approccio architetturale dall’alto. Pur ideale per la soluzione architetturale, il top-down non è stato però scelto da più di un’azienda su dieci. Quasi sempre perché l’It non può che chiedere finanziamenti subito, promettendo un Roi a tre anni e “l’It non ha la credibilità col business di ottenere investimenti così a lungo termine”.
Nel bottom-up, l’It semplicemente comincia a costruire nuove applicazioni con tecnica Soa, partendo con un pilota e/o un insieme di applicazioni opportunamente scelte. È la scelta di gennaio 2005 di “una grande azienda italiana”, che Chappell non può citarci: ha rigettato l’approccio top-down, più o meno in questi termini: “Loro (il business) ci dicono cosa fare, noi decidiamo come; e abbiamo scelto la Soa”.
La dicotomia top-down o bottom-up, di rilevanza politica nell’allineamento business-It, vale solo in partenza. In uno sviluppo a spirale, top-down e bottom-up tenderanno poi ad alternarsi: con il bottom-up, dopo la prima, al massimo dopo la seconda applicazione Soa, emergeranno funzionalità comuni e centrali (come sicurezza e management) che, per evitare complessità esponenzialmente crescenti, occorrerà mettere a fattor comune per applicazioni Soa successive; a un certo punto cioè si sentirà il bisogno di una vista top-down. D’altro canto, col top-down, servirà lo stesso un prototipo sulle prime applicazioni per imparare tecnica e pratica.
Gli strati “alti” dei servizi web
Ma se si decide di partire con un pilota nella prima metà del 2006 e con investimenti seri nel successivo periodo, si può procedere serenamente? Questa un po’ la domanda a cui David Chappell ha risposto, in sostanza, “si”, pur con una serie di dettagli aggiornati sulla maturazione del complesso di standard che vanno sotto il nome di Servizi Web e sui rapporti (leggi pure anche di forza) fra gli standard body che li regolano, di cui ecco una sintesi.
David Chappell concorda che Soap, semplice protocollo di accesso stradefinito, è il mattone di base di ciò che è necessario per uno scambio di servizi interapplicativi affidabile, sicuro, persistente. Ci parla però anche di uno stato dell’arte ormai soddisfacente, in termini di comune comprensione e convergenza sottoscritta dai vendor sui protocolli “alti” nei Servizi Web (sicurezza nelle transazioni per esempio). Chappell, ci dà una regola semplice, anche se magari un po’ brutale: guardare alle specifiche prodotte dalle organizzazioni di standard (Ws-i.org. Oasis.org e Bpmi.org), e seguire quelle cui concorrono Ibm e Microsoft. Verificare quindi le specifiche passate ad Oasis.org per la manutenzione (es. Ws-Security, Bpel4Ws) e, infine, assicurarsi, attraverso il lavoro di Ws-i.org, che le specifiche siano sufficientemente precisate in modo non ambiguo per poterci costruire sopra implementazioni davvero interoperabili.
Una seconda regola pratica indicata da Chappell è la seguente: anche se i maggiori vendor hanno concordato sulle specifiche per affidabilità e sicurezza delle transazioni, non le vedremo in prodotti maggiori ancora per qualche mese.
Soa come superset di interoperabilità applicativa
(clicca sull’immagine per ingrandirla)
Fonte: Forrester
SOA SECONDO MICROSOFT
Nel corso dell’incontro con ZeroUno, David Chappell racconta di Indigo, che è “la” tecnologia per costruire Service Oriented Application su base Longhorn, il nuovo sistema operativo atteso da Microsoft nel 2006. Su Indigo ci sono “tre cose da sapere”.
Primo, Indigo fornisce interoperabilità applicativa a base Soap ma anche solo Soap, così applicazioni Indigo possono parlare solo con altre applicazioni della stessa lingua, orientata servizi: Longhorn, WebSphere, WebLogic, Netweaver, ecc. Conta che l’application server supporti i servizi Web, non interessa più l’ambiente .Net o Java, o il sistema operativo tipo Windows o tipo Unix.
Secondo, Indigo fornisce supporto esplicito ad applicazioni Soa.
Terzo, è una proposta di unificazione: oggi sia .Net che Java forniscono una varietà di meccanismi diversi per comunicare, ognuno con un impatto e proposito propri. Microsoft con Indigo prende atto che c’è un accordo completo sui servizi Web, propone di coniugare le varie modalità possibili in un unico modello, Indigo, riducendo ulteriormente la complessità. Già oggi gli sviluppatori tendono a ritenere .Net più semplice di Java; con Indigo, .Net diventerà ancora più semplice. Sarà interessante la risposta dei comitati Java. Anche se il problema è proprio che nel mondo java le tecnologie sono controllate dai comitati. Quanto spesso i comitati tendono a suicidarsi, o a farsi accorpare? Si domanda Chappell. (R.M.)
