SCA (Service Component Architecture) è già nei prodotti BEA

SCA fornisce un modello di programmazione per la costruzione di applicazioni e di soluzioni basate su una Service Oriented Architecture. Il modello si basa sull’idea che le funzionalità di business possono essere composte a partire da una serie di servizi, che vengono assemblati insieme per creare soluzioni che servono un particolare requisito di business. Queste soluzioni sono definite Composite Applications, e sono rappresentate graficamente da Assembly Models. Le composite application possono contenere sia nuovi servizi creati specificamente per la applicazione che servizi esistenti offerti da sistemi e applicazioni esistenti, riusati come parti della composizione. La figura seguente mostra un esempio di assembly model per una composite application.

SCA Assembly Model (cliccare sulla figura per ingrandire)

Il modello di programmazione SCA è uno standard in via di formalizzazione a cura della iniziativa Open Composite Services Architecture (OpenCSA) di OASIS. SCA standardizza le informazioni scambiate tra differenti tools, assicurando che i servizi e i componenti che costituiscono un’applicazione vengano modellati, rappresentati e descritti in modo coerente. La coerenza significa che i servizi costruiti in strumenti differenti, usando differenti paradigmi di programmazione possono facilmente essere riusati e portati velocemente in produzione, aiutando le organizzazioni a realizzare l’efficacia promessa da SOA.

BEA usa SCA come standard per facilitare lo scambio di informazioni tra i prodotti BEA, come ALSB, ALDSP, ALBPM, WLS, WLP, WLI e Tuxedo-SALT. BEA ha intenzione di utilizzare SCA anche per facilitare scambio di informazioni con prodotti di terze parti.

Ciò significa che servizi fornite da piattaforme per data services, da service bus, da strumenti per business process modeling, etc. possono essere catturati e rappresentati in un formato comune, e poi riusati facilmente per comporre altre applicazioni di business.

Il Service Assembly Modeler
Il Service Assembly Modeler (SAM) di BEA supporta la composizione e la visualizzazione di applicazioni composite. La composizione avviene in un ambiente di sviluppo basato su Eclipse. In questo ambiente il gruppo di sviluppo può assemblare rapidamente applicazioni composite riusando servizi che esistono già, o creando nuovi servizi. SAM consente agli sviluppatori di vedere il modello di assemblaggio delle applicazioni composite, così come la definizione in linguaggio XML della composizione.

AquaLogic Enterprise Repository (ALER) consente alle organizzazioni di gestire le applicazioni composite e i servizi riusabili. I gruppi di sviluppo possono sottomettere le loro applicazioni composite in ALER direttamente da SAM. ALER fornisce visibilità alle applicazioni e ai servizi esistenti, tracciabilità tra le applicazioni composite e le loro dipendenze, dati analitici che misurano il riuso e facilitano la analisi di impatto.

Il Service Assembly Modeler (SAM) è un plug-in per Eclipse che fornisce strumenti per lavorare con i modelli di assemblaggio SCA per i servizi compositi. SAM viene distribuito con AquaLogic Enterprise Repository (ALER) e altri prodotti della famiglia BEA AquaLogic.

Si può usare SAM per:

• Rendere compatibili con SCA le applicazioni AquaLogic esistenti e poi creare service assembly model basati su queste applicazioni.
• Visualizzare composizioni SCA e altri artefatti di tipo service assembly model.
• Sottomettere modelli in AquaLogic Enterprise Repository (ALER).

Links

Introduzione a SCA:
http://en.wikipedia.org/wiki/Service_component_architecture
http://weblogs.java.net/blog/meeraj/archive/2008/01/introducing_ser.html

Prodotti BEA:
http://e-docs.bea.com/aler/docs30/pdf/SAMhelp.pdf
http://www.bea.com/framework.jsp?CNT=pr01891.htm&FP=/content/news_events/press_releases/2007
http://ecommerce.bea.com/showproduct.jsp?family=WLS&major=10.3SCA&minor=-1

Specifiche:
L’attuale insieme delle specifiche SCA sul sito OSOA comprende:
SCA Assembly Model
SCA Policy Framework
SCA Java Client & Implementation
SCA BPEL Client & Implementation
SCA Spring Client & Implementation
SCA C++ Client & Implementation
SCA Web Services Binding
SCA JMS Binding

SOA Reference Architecture: a che cosa serve

L’obiettivo di SOA è allineare le capacità dell’IT agli obiettivi di business: secondo le statistiche, il principale motivo per cui molte aziende hanno adottato, o stanno adottando, questa strategia è l’agilità che essa consente al sistema informativo.

La metafora dei mattoncini del LEGO rende bene l’idea: diversi assemblaggi degli stessi componenti possono produrre rapidamente costruzioni diverse, soddisfacendo i requisiti di business in un tempo ridotto, ma con una qualità superiore, rispetto all’approccio IT tradizionale.

Oltre alle dichiarazioni di principio e alla corretta gestione delle informazioni all’interno dell’azienda, è necessario però che esista un quadro di riferimento architetturale in cui i servizi che vengono sviluppati trovino una adeguata collocazione. Oltre al modello da fornire ai progettisti, servono una infrastruttura tecnologica e un piano di investimenti per la sua realizzazione.

La figura seguente mostra uno schema sintetico di architettura di riferimento, in cui vengono evidenziati i Service Consumers e i Service Providers insieme a tutti i servizi condivisi che comprendono quelli applicativi e quelli infrastrutturali.

Come usare la SOA Reference Architecture

Il primo passo per l’adozione della SOA Reference Architecture di BEA è la sostituzione dei generici tipi di componente descritti dal modello con i componenti specifici del cliente: per esempio, “Portali” può essere specificato come “Portale Risorse Umane” e “Portale Customer Service”. “Packaged Applications” può diventare “SAP” e “Oracle Financials”. “Atomic Business Activities” può comprendere “Emissione dell’ordine” e “Pagamento”.
L’azienda può anche identificare come i nuovi progetti si adattano allo scenario complessivo, per esempio mettendo a disposizione un processo di business condiviso “Aggiunta Nuovo Prodotto” o fornendo un data service “Cliente”.
Il risultato è una istanza concreta della SOA Reference Architecture – un modello specifico per quell’azienda che diventa la definizione formale della architettura SOA. Fornisce lo schema per classificare l’infrastruttura e i servizi condivisi; definisce le relazioni tra la SOA desiderata e l’architettura esistente. Specifica la visione architetturale e determina il percorso da seguire per la sua costruzione. Infine, serve come cruciale strumento di comunicazione e di verifica della conformità.

Oltre a focalizzare le risorse dello sviluppo nella creazione delle soluzioni, le aziende devono gestire i progetti che ne risultano. La SOA Reference Architecture può servire da modello per un singolo progetto così come per l’intera SOA.
Un architetto e il responsabile del progetto possono usarla per scomporre le funzionalità di business in un insieme di servizi, assegnare la responsabilità per ciascun blocco al gruppo di sviluppo più adatto, monitorare l’implementazione.
In questo modo si possono ottenere il parallelismo nello sviluppo dei componenti, l’eliminazione delle duplicazioni, una efficace attribuzione dei costi a diverse voci di bilancio.

Il white paper

La SOA Reference Architecture di BEA fornisce benefici di lungo termine alle aziende fornendo un modello per costruire una SOA di livello enterprise in modo scalabile.
La potenza di SOA è la sua flessibilità. Ogni azienda può adattare i suoi particolari asset IT al suo business specifico.
Tuttavia questa potenza è inutile senza controllo: è necessario un modello che indirizzi il lavoro e permetta di verificarne i risultati.
Usando una SOA Reference Architecture, le aziende possono stabilire quali servizi dovrebbero costruire e quando farlo.
Possono aumentare il parallelismo e ridurre le duplicazioni nel portafoglio dei progetti di sviluppo. Possono imporre una governance efficace basata su policy che applicano correttamente i principi generali a circostanze specifiche.
La chiave per ottenere questi benefici è la conoscenza del posto che ciascun progetto e ciascun servizio occupano nello schema più ampio della SOA a livello enterprise. Usando la SOA Reference Architecture, sia le persone di business che quelle dell’IT possono indicare con precisione il ruolo di ogni servizio esistente o proposto.
Le dipendenze, le mancanze e le duplicazioni appaiono evidenti. La pianificazione, la cooperazione e l’approvvigionamento diventano più semplici. Le aziende possono finalmente trasformare l’agilità in un processo gestibile. BEA ha tracciato la strada con una SOA Reference Architecture basata su anni di esperienza nel mondo reale.

Un white paper che espone in dettaglio il valore della costruzione di una SOA Reference Architecture può essere scaricato dal sito BEA, nella sezione SOA.

La struttura di consulenza di BEA offre diversi servizi – che saranno discussi in altri post su questo blog – mirati alla definizione di un’architettura di riferimento specifica per il cliente e alla sua realizzazione.

Side by side deployment: non più sospensioni del servizio

Una caratteristica utile di Weblogic Server, dalla versione 9 in poi, è il cosiddetto production redeployment: una strategia di deployment delle applicazioni web che consente la coesistenza di due versioni dell’applicazione, garantendo il rilascio di una nuova release senza interrompere il servizio offerto agli utenti. E’ utile per la correzione di bug o per l’aggiunta di nuove funzionalità, senza dover chiudere l’applicazione nè aggiungere server ridondanti per redirigere il traffico durante la sostituzione.

Quando la nuova versione viene attivata, la vecchia viene mantenuta in funzione dal server finchè le sessioni utente già attive vengono completate oppure vanno in time out: nel frattempo la nuova versione comincia a servire tutte le nuove richieste. La figura seguente mostra come le richieste http vengono gestite da WLS:

Gli utenti che stavano navigando non subiscono alcun effetto dell’attivazione della nuova versione, quindi non è necessario pianificare finestre temporali di rilascio, magari di notte o nel week end come a volte si è costretti a fare. Versioni successive delle applicazioni possono essere storicizzate sui server, per cui è sempre possibile tornare indietro ad una versione precedente con la stessa modalità trasparente agli utenti. Inoltre, se una nuova versione viene attivata in Administration Mode, questa diviene visibile solo sul canale di amministrazione di WLS: ciò consente di eseguire test di corretto funzionamento prima dell’apertura al normale traffico utente.

Le operazioni di deployment e di attivazione delle versioni possono, come tutte le operazioni di amministrazione, essere eseguite attraverso la console web di WLS, attraverso script ANT o WLST, programmi java o strumenti esterni di configuration management. Alcuni tipi di applicazione non possono essere gestiti con questa modalità di rilascio, che è limitata a web applications e enterprise applications: vedere la documentazione online di WLS per i dettagli.

Allargare l’orizzonte

Sono appena tornato da un viaggio di lavoro in un paese arabo, dove ho tenuto un SOA Discovery Workshop. E’ stata un’esperienza che mi ha fatto riflettere sui vantaggi – che non sempre ho tenuto presenti – derivanti dal fatto di lavorare per una multinazionale dell’informatica.

Non mi riferisco ai vantaggi ovvii, come essere costantemente proiettati sulla frontiera della tecnologia e delle nuove tendenze nel campo dell’IT oppure essere a contatto con le diverse realtà costituite da clienti che sono sempre grandi aziende, contenenti a loro volta una varietà di culture, di tecnologie e di personaggi. Negli otto anni che ho passato finora in BEA mi sono trovato davanti a molte sfide professionali e umane. Molte volte sono andato oltre quello che ritenevo il limite delle mie conoscenze e delle mie capacità, spesso ottenendo risultati che mi hanno fatto crescere in esperienza e consapevolezza. Dopo i primi anni in cui ero molto focalizzato sulla tecnologia, ultimamente sono stato affascinato dai rapporti tra le persone: ho studiato con attenzione la capacità di comunicare, i rapporti di forza, l’abilità diplomatica, il rispetto per le posizioni differenti dalla propria, l’efficacia nel convincere gli altri. Ho incontrato tante persone da prendere come esempio e altri che erano la dimostrazione vivente degli errori nella comunicazione. Io stesso a volte ho sbagliato approccio di fronte a opinioni discordanti.

Certe volte le persone, pur di affermare il proprio punto di vista su quello degli altri, sprecano ottime occasioni per mettersi d’accordo su un punto che garantisce la soddisfazione propria e quella dell’interlocutore: quello che viene definito un “win-win“. Spesso chi non fa parte della propria squadra, della propria fazione o non condivide la nostra fede viene considerato “l’altro”, con cui il conflitto è inevitabile.

Lunedì scorso ho avuto una sensazione diversa anzi, citando John Belushi, “ho visto la luce”. Ero in volo su un panorama stupendo, e il cielo era colorato da un tramonto difficile da descrivere (sono un ingegnere con tendenze sociologiche, non ancora un poeta…). Sotto di me le montagne di un paese straniero dove, in mezzo alla neve che per molti chilometri copriva tutto, potevo vedere le luci di una piccola città e un serpente di luci che la raggiungeva: peccato non avere la macchina fotografica… Mentre stavo pensando “deve essere una località di sport invernali, come ce ne sono da noi: allora le hanno anche loro…” mi sono detto: “ma chi sono i loro e i noi?”. Di fronte alla bellezza della natura e alla considerazione che il genere umano è un ospite sulla Terra (forse influenzato anche dal fatto che stavo ascoltando Starway to heaven dei Led Zeppelin e avevo appena finito di leggere Prelude to foundation di Asimov) mi sono reso conto che noi e loro eravamo la stessa cosa. Popoli differenti, nonostante le lingue e le religioni, sono sempre ospiti dello stesso mondo e apprezzano la stessa bellezza (e contribuiscono ugualmente alla sua rovina). A parte piccoli o grandi egoismi, tutti hanno bisogno degli altri e si sentirebbero soli se non potessero confrontarsi con loro. Credo che abbiamo tutti da imparare dal confronto con qualcuno che può dare, su quello che pensiamo o che facciamo, una visione complementare alla nostra. Se ci troviamo d’accordo ne usciamo rafforzati e più sicuri, se no potremmo anche scoprire di aver trascurato qualche aspetto importante e trarne comunque un vantaggio; a volte invece, dovendo arrivare a un compromesso perchè nessuno dei due riesce a convincere pienamente l’altro, si può avere la soddisfazione di aver evitato un conflitto che avrebbe fatto maggiori danni.

Ovviamente questo discorso vale su piani differenti: partendo da considerazioni sull’umanità intera si può arrivare alla propria famiglia oppure ai rapporti di lavoro: tra colleghi, tra cliente e fornitore, tra concorrenti. A volte la volontà di collaborare per l’interesse comune e quella di accettare un diverso punto di vista consentono risultati che sarebbero irraggiungibili se fossimo concentrati solo nel dimostrare di essere più intelligenti o più bravi.Per un architetto, che deve garantire per definizione l’armonia dell’insieme, è una bella lezione (non che io abbia sempre cercato di imporre la mia visione, anzi è da un po’ di tempo che stavo lavorando sulle capacità di mediazione: però sicuramente quelli che mi conoscono sanno che non sono uno tenero…).Giusto per concludere: perchè ho voluto raccontarvi queste considerazioni? Perchè sicuramente, prima o poi, io e qualcuno di voi ci incontreremo per motivi di lavoro… magari ci troveremo in disaccordo, ma spero che aver condiviso queste considerazioni ci aiuterà a trovare una soluzione che vada bene a entrambi 🙂

6 errori da non fare in un progetto SOA

L’articolo di Paul Callahan Top 10 mistakes when implementing SOA projects su Zdnet è molto chiaro e personalmente condivido tutto il suo contenuto. Ripetere gli stessi concetti, per quanto possa sentirli anche miei, sarebbe inutile e potrebbe dare l’impressione di attribuirsi il lavoro degli altri…

Comunque voglio aggiungere qualche considerazione, raggruppandole in sei categorie – il che non implica necessariamente che io ne sappia meno di Paul che elenca 10 argomenti 🙂 – per dare il mio contributo basato sull’esperienza personale. Sono solo spunti di discussione, perchè non possiamo dilungarci su questo blog: sarei in ogni caso felice di approfondire l’argomento con chiunque sia interessato a condividere le proprie esperienze, quindi scrivete i vostri commenti o mandateci una email, ci farebbe piacere.

Tecnologia

Spesso l’adozione di SOA viene interpretata come un’iniziativa meramente tecnologica e si concentrano (a volte si sprecano) molto tempo e molte risorse nel definire puntigliosamente le caratteristiche dei prodotti che si dovranno usare per coprire ogni eventuale necessità futura.

In questo modo l’avvio di un progetto richiede lungo tempo, e si guardano da lontano quelli che sono partiti in modo più pragmatico. Pur essendo uno dei sostenitori di un’architettura di riferimento ben definita (basata su tutti prodotti BEA o meno, va bene lo stesso: e poi un’architettura non è fatta di soli prodotti) sostengo che si può anche procedere per iterazioni successive, cominciando a sperimentare e facendo tesoro dell’esperienza; definendo una visione di ampio respiro mentre si implementano le cose semplici che sono a portata di mano. Pensando in modo strategico e agendo contemporaneamente in modo tattico. Programmando una roadmap che sia oggettivamente realizzabile.

Tra l’altro, a volte la tecnologia di cui si dispone è già sufficiente per iniziare la realizzazione di quello che serve: ho visto fior di architetture realizzate utilizzando Tuxedo o il CICS, quindi non sempre la tecnologia più attuale è necessaria per ogni progetto.

Governance

Molte decisioni devono essere prese nella realizzazione di un programma SOA di livello enterprise:

• Chi definisce e modifica i servizi?
• A chi è consentito l’uso dei servizi?
• Quale livello di servizio dobbiamo fornire?
• Chi paga per la costruzione del servizio?
• Chi paga per l’infrastruttura per i servizi?
• Come devono essere gestite le interdipendenze tra i servizi?
• Come esporre i servizi all’esterno?

Si devono fare anche queste, ed altre, considerazioni:

• Struttura organizzativa
• Finanziamento
• Processi Operativi e strumenti di supporto
• Standard
• Competenze
• Principi Guida
• Change Management

Non ci si può illudere di non dover affrontare questi argomenti, sicuramente quando sono spinosi: quindi metteteli in conto dall’inizio. In ogni azienda esistono posizioni di potere che possono essere intaccate da una strategia basata sulla condivisione e sulla collaborazione: oltre a una rivoluzione culturale servono regole (rispettate) che consentano all’intero sistema di funzionare, possibilmente con il coinvolgimento attivo di tutti gli attori.

Esperienza

A volte ci si fa prendere dall’entusiasmo, avendo intuito (o anche studiato in modo approfondito) i benefici che si possono ottenere da un approccio SOA. Quindi si parte in quarta: si studia, si organizza, si acquista quello che serve e si inizia un bel progetto.

Se però non si ha esperienza di iniative di questa portata, sia dal punto di vista di una architettura enterprise che da quello della famosa governance, si rischia di ritrovarsi in mezzo a una palude.

I tempi di realizzazione, l’integrazione, il budget o il change management possono diventare dei problemi in corso d’opera. A volte si costruisce un bel prototipo, che però non ha le caratteristiche sufficienti per la messa in esercizio; oppure si realizza l’infrastruttura perfetta, ma nessuno ha un servizio utile da metterci sopra.

Vale quindi la pena di confrontarsi con qualcuno che abbia già intrapreso (e portato avanti con successo) lo spesso percorso, per fare tesoro della sua esperienza e impostare il proprio lavoro nel modo migliore.

Consiglio di parlare con project manager, program manager e architetti che abbiano già realizzato progetti SOA reali per farsi raccontare quali difficoltà hanno incontrato e come le hanno eventualmente risolte. Tra questi potete considerare colleghi che hanno il vostro stesso ruolo in altre aziende, consulenti che lavorano per i system integrator o i software vendor, tra cui ovviamente BEA. Mi raccomando però di verificare le credenziali dei sedicenti esperti, perchè SOA è sulla bocca di tutti e il mondo è pieno di “enterprice architett”.

Iniziativa IT senza partnership con il business

Se la divisione IT di un azienda intraprende un’iniziativa SOA in modo autonomo, di solito lo fa per uno di questi motivi:

• va di moda, quindi se gli altri lo fanno un motivo ci sarà
• è moderno, quindi se lo facciamo possiamo metterci in evidenza come innovatori
• possiamo chiedere una quota di budget per rinnovare le nostre infrastrutture.

E’ invece consigliabile che l’inizio del progetto derivi da un’iniziativa condivisa con i responsabili del business dell’azienda: a seconda del settore, con la produzione, la logistica, il marketing, il demand management.

Se l’iniziativa è fine a se stessa, non produrrà un valore per l’azienda. Non avrà un ROI dimostrabile e non darà lustro ai suoi responsabili. Se invece è condivisa con chi può beneficiare dei suoi risultati in termini di fatturato, dimostrerà di portare vantaggi al business. E’ essenziale un sistema di metriche per dimostrare in modo quantitativo il vantaggio generato. Ma soprattutto è necessario che ogni attività sia mirata alla soluzione di un reale problema che gli utenti di business percepiscono nella loro attività. Se per esempio un processo di vendita richiede troppo tempo, ridurne la durata ottimizzando il processo (eliminando attività manuali, per esempio) può avere effetto sul flusso di cassa. Rendere la produzione più efficiente può diminuire l’immobilizzo di capitale e le spese per la logistica. L’IT dovrebbe imparare a parlare lo stesso linguaggio del business e a interpretarne le necessità (condividendole in modo esplicito ed evitando assunzioni che potrebbero non essere condivise).

Mancanza di pragmatismo

Tra l’altro, la condivisione di una roadmap può evitare che si creino aspettative ingiustificate o, peggio, che non ci siano aspettative. Rendere visibili i risultati ottenuti nelle fasi intermedie della roadmap, secondo quanto pianificato, garantisce il supporto degli sponsor di business e non fa venire meno il sostegno negli eventuali momenti in cui il progetto incontra dei problemi. Per questo motivo bisogna assolutamente evitare approcci di tipo Big Bang, in cui risultati eclatanti vengono promessi alla fine di un arco di tempo troppo lungo: si potrebbe non arrivare mai a dimostrarli…

La figura seguente mostra che – a seconda della situazione che fa nascere l’iniziativa SOA – è opportuno organizzarsi in modo differente: la roadmap conterrà azioni adeguate alla situazione e nella sequenza più opportuna.

 

Comunicazione

• Marketing interno: come detto nell’introduzione, occorre definire un piano strategico e realizzarlo in modo tattico. E’ importante che l’azienda cominci presto ad apprezzare i risultati, per creare un circuito virtuoso intorno all’iniziativa SOA.
• Riuso degli asset nei progetti: se si realizzano dei servizi utili ma pochi ne conoscono l’esistenza, probabilmente il vantaggio del riuso sarà limitato. Conviene mettere a punto una strategia di comunicazione e gli strumenti a supporto (service repository e/o un portale intranet, newsletter, eventi periodici…).
• Demand management: dare a chi si interfaccia con il business la visibilità degli asset disponibili (possono nascere nuove idee dalla conoscenza dei servizi esistenti) o la possibilità di esprimere i requisiti in modo da iniziare il ciclo di vita dei servizi (o delle applicazioni composite): il repository è sempre utile.
• Diffusione della cultura della condivisione: le modalità dipendono dal contesto aziendale, ma questa attività è quanto mai necessaria.

SOA è solo tecnologia? Consigli utili su come approcciare un progetto SOA

Ormai tutti, nel mondo dell’IT, conoscono i principi di SOA e i benefici che si possono ottenere adottando una architettura orientata ai servizi. Molto spesso, però, il primo approccio di chi deve valutare se e come intraprendere un percorso verso SOA è puramente orientato alla tecnologia: si parte con la scelta dei prodotti che dovrebbero consentire la costruzione e la gestione di servizi riutilizzabili e si ragiona sugli standard per l’interoperabilità tra le diverse piattaforme presenti in azienda.

Molto spesso ho visto assimilare SOA all’uso dei web services, come se questi fossero la panacea di tutti i mali. Altre volte, aver realizzato applicazioni che esponevano qualche servizio è stato considerato un traguardo di successo nella creazione di un’architettura. In altri casi è stata costruita un’infrastruttura per i servizi, ma mancano i servizi…In realtà, per la visione che io mi sono creato partecipando a qualche progetto, bisognerebbe affrontare la materia con uno sguardo un po’ più allargato.

Uno degli aspetti fondamentali che possono garantire il successo (oppure minarlo alle fondamenta) è il fattore umano: in termini di motivazione ma anche di organizzazione e disciplina.

Il riuso dei servizi e tutto quello che ne consegue (agilità, time to market, etc.) non può prescindere dalla condivisione del lavoro e dei risultati. Non si combattono i silos tecnologici se non si eliminano quelli legati alla conoscenza e all’iniziativa delle persone: se ciascuno pensa di lavorare per se stesso, anzichè per l’azienda, sarà difficile ottenere risultati significativi indipendentemente dalla bontà delle infrastrutture.

Nella definizione di BEA Systems, SOA è una strategia IT che organizza le diverse funzioni contenute nelle applicazioni dell’azienda in servizi interoperabili, basati sugli standard, che possono essere combinati e riusati rapidamente per soddisfare i requisiti di business.Le parole chiave sono strategia e requisiti di business. Organizzazione, comunicazione e governance contano almeno quanto la tecnologia. I requisiti di business sono l’unica cosa che può dare senso ad ogni iniziativa IT, che non deve essere fine a se stessa: una bella architettura non si costruisce perchè è di moda, oppure per raccontarla in un evento pubblico, ma perchè è utile all’azienda. E l’utilità si misura in termini di fatturato: soldi guadagnati in più, perchè i processi di business beneficiano dei risultati ottenuti in modo quantificabile, oppure si spende di meno perchè si ottimizzano procedure e implementazioni.Non a caso la metodologia proposta da BEA si basa sul cosiddetto “Modello dei sei domini”, che prevede l’analisi e l’ottimizzazione – in parallelo – di tre aspetti legati alla tecnologia (Architecture, Building Blocks e Projects & Applications) e tre legati alla organizzazione e alla comunicazione (Business Strategy & Processes, Organization & Governance, Costs & Benefits). Tutti e sei i domini contribuiscono al risultato finale e, pur raggiungendo l’eccellenza in alcuni di essi (per esempio Building Blocks), si potrebbe perdere una buona parte dei vantaggi se qualcosa non funziona negli altri (per esempio Organization & Governance).

Adozione di una Organizzazione e di un processo di Governance SOA

Di solito i gruppi di lavoro che implementano i sistemi nelle varie aree funzionali hanno già realizzato un buon livello di condivisione interna. Programmi, componenti e transazioni vengono, molto spesso, riutilizzati per consentire un risparmio di tempo e per evitare sforzi duplicati di manutenzione.

Tuttavia lo scambio di informazioni è basato sulla iniziativa dei singoli individui, che vanno alla ricerca del collega in grado di ricordare se e come un certo programma può essere utilizzato. Non esiste un deposito centralizzato ed accessibile delle informazioni sugli asset aziendali, nè un processo standardizzato per la catalogazione dei servizi.Per gestire in modo coerente l’adozione di una nuova metodologia, indirizzando le attività all’interno dei vari progetti e verificando il raggiungimento degli obiettivi desiderati, è opportuno che venga costituito un team dedicato a questa attività.In particolare, essendo l’adozione di SOA una estensione dei processi già in uso per quanto riguarda la Governance IT e influenzando parti dell’azienda che non sono propriamente all’interno della struttura IT (si veda la figura seguente, che mostra le relazioni tra le attività e le strutture), è opportuno un coinvolgimento del management al più alto livello per indirizzare il processo e monitorarne l’avanzamento.

<clicca per ingrandire>

Il ciclo di vita dei servizi – parallelo a quello delle applicazioni composite, che li utilizzano per fornire agli utenti finali il valore aggiunto – deve avere delle solide basi di riferimento, quali:

• Organizzazione dei gruppi di lavoro: ruoli e responsabilità;
• Processo (e strumenti) per l’individuazione, la creazione e la gestione dei servizi;
• Linee guida per l’implementazione, coerenti con l’architettura di riferimento che è stata definita;
• Metriche per misurare i benefici e i costi sostenuti, consentendo la valutazione del ritorno sull’investimento (ROI) e la conferma (o la correzione) della roadmap definita per SOA.

Organizzazione

Si propone quindi la creazione delle seguenti strutture organizzative, che possono eventualmente essere mappate sulla organizzazione esistente riconoscendo ruoli o responsabilità aggiuntive ai gruppi di lavoro.Si evidenziano i ruoli che dovrebbero essere rappresentati in ciascuna struttura; a seconda della disponibilità di persone e competenze, più ruoli potrebbero anche essere assegnati alla stessa persona (all’interno di un gruppo o a cavallo di più gruppi).

In particolare, il gruppo definito al punto 2 potrebbe basarsi sulle figure attualmente inserite nel team di Architettura, assegnando ad esse nuove responsabilità (descritte nei paragrafi seguenti), compatibilmente con i carichi di lavoro esistenti.I gruppi definiti ai punti 3 e 4 sono in realtà quelli che già attualmente si occupano dello sviluppo dei progetti nelle varie aree funzionali. Eventualmente il punto 3 potrebbe essere assegnato su base temporanea (quando la sua attività si rendesse necessaria) a risorse che normalmente appartengono alle aree verticali del punto 4.1. Comitato guida SOA Composto dal Direttore dei Sistemi Informativi, da un Architetto che sia in grado di rappresentare l’evoluzione nell’adozione di SOA, e da rappresentanti delle linee di business.Tiene sotto controllo l’avanzamento delle iniziative legate a SOA e ne rende conto alla direzione dell’azienda.2. Gruppo per la gestione dell’Architetture SOA, composto dalle seguenti figure/ruoli:

• gestore del catalogo dei servizi,
• metodologo (per definire, guidare e raffinare il processo),
• architetto dei dati,
• architetto di integrazione (EAI),
• architetto dedicato alla Security.

Questo gruppo dovrebbe riunirsi periodicamente con i gruppi di sviluppo (una riunione ogni due settimane salvo necessità diverse) per allineare tutti gli attori sulle nuove realizzazioni, le best practices, le strategie di medio termine.Valida le richieste di realizzazione dei nuovi servizi utilizzando il processo definito, li censisce nel catalogo, opera a supporto dei gruppi di sviluppo fornendo competenze tecniche o metodologiche, valida l’architettura proposta per i nuovi progetti.Tra le responsabilità di questo gruppo di lavoro:

• Condivisione dell’informazione (best practices, processi gestionali, evangelizzazione SOA, descrizione dei processi di business dei clienti con modello standard, per esempio UML o BPEL).
• Realizzazione della SOA Dashboard (che deve mostrare al comitato guida lo stato di avanzamento della roadmap).

3. Sviluppo dei servizi di business condivisiUna volta che i servizi candidati sono stati individuati dal Gruppo per la gestione dell’Architetture SOA, se la visibilità dei servizio va oltre il singolo progetto e/o se la realizzazione richiede un parallelismo per rispettare la pianificazione del progetto, si incarica della implementazione e del rilascio dei nuovi servizi.Questo gruppo è anche responsabile della creazione dei servizi infrastrutturali per arricchire l’architettura con tutte le funzionalità di base riutilizzabili in ogni progetto: sicurezza, log, audit, monitoraggio, reporting.4. Sviluppo dei servizi verticaliI vari gruppi di progetto, strutturati secondo le aree funzionali esistenti, si incaricano di realizzare i servizi con visibilità locale in autonomia. Resta la collaborazione con il Gruppo per la gestione dell’Architetture SOA, con cui le scelte architetturali devono essere concordate.La figura seguente mostra l’intersezione delle responsabilità dei gruppi di lavoro definiti in precedenza:

<clicca per ingrandire>

La tabella seguente mostra in che modo i gruppi definiti in precedenza collaborano e si dividono la responsabilità relativamente al ciclo di vita dei servizi (SDLC = Service Development Life Cycle) e dell’architettura SOA.

<clicca per ingrandire>

Processo di gestione del ciclo di vita dei servizi

Per facilitare e rendere più rapida l’adozione della metodologia SOA, BEA propone ai propri clienti l’uso del proprio Enterprise Service Engineering Framework (ESEF). All’interno di ESEF sono definiti:Processo di proposta, approvazione, implementazione dei serviziLinee guida e template per:

• Identificazione dei servizi
• Analisi e progettazione
• Costruzione e rilascio
• Esposizione dei servizi e versionamento
• Monitoraggio

La figura seguente mostra l’overview del processo definito per gestire i servizi che vengono identificati analizzando i requisiti di un nuovo progetto oppure razionalizzando l’accesso a funzionalità già esistenti nei sistemi attuali.

<clicca per ingrandire>

La maturity matrix

L’utilizzo delle best practices può essere misurato secondo due direzioni ortogonali: la maturità (qualità di quello che è stato realizzato) e l’adozione (misura quantitativa dell’estensione). La tabella seguente mostra una prima rappresentazione di come si possa valutare lo stato attuale di una organizzazione per valutare se soddisfa le necessità di business. In base alla stessa tabella si può ipotizzare un percorso per raggiungere il livello ritenuto necessario in base a considerazioni pragmatiche, che tengano conto delle effettive necessità e delle risorse (tempo e costo) che si possono realisticamente mettere in campo.

<clicca per ingrandire>

La struttura di cui faccio parte mette a disposizione dei clienti una serie di strumenti per affrontare le varie fasi del percorso verso la realizzazione di una Service Oriented Architecture:

• esplorazione dei possibili ritorni e delle risorse necessarie
• pianificazione del percorso (roadmap relativa all’architettura e all’organizzazione)
• costruzione dell’infrastruttura e dei servizi

Nella prima fase vengono proposti, a seconda delle condizioni di partenza: un self assessment, un SOA Discovery Workshop, un SOA Assessment effettuato da consulenti della SOA practice di BEA in collaborazione con il cliente.Nelle fasi successive sono disponibili servizi di consulenza orientati maggiormente alla tecnologia o alla governance, oppure che abbracciano tutti i sei domini contemporaneamente. Tutti sono strutturati secondo una struttura modulare per adattarsi alle esigenze specifiche di ogni organizzazione, evitando l’imposizione di un modello fisso che potrebbe essere inapplicabile in certi contesti.Chi volesse approfondire le tematiche trattate in questo post, oppure il contenuto e lo scopo dei servizi di consulenza legati a SOA, può contattarmi per discuterne di persona.