Category Archive

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

La gestione degli aspetti di Authentication, Authorization ed Accounting (AAA) riveste un’importanza fondamentale per la sicurezza sia delle applicazioni usate all’interno dell’azienda stessa che di quelle utilizzate per proporre servizi alla propria clientela.

Questo a maggiore ragione in questi ultimi anni in cui la legge sulla privacy ha introdotto ulteriori requisiti e spostato la sicurezza da un solo concetto di difesa per chi eroga un servizio ad un meccanismo di difesa di chi usa quel servizio e come tale è costretto a fornire dati sensibili.

Le attuali soluzioni di Identity Management che implementano le funzioni di AAA hanno risolto egregiamente gli aspetti di Autenticazione che, tramite il Single Sign-On, permettono inoltre di unificare e centralizzare il controllo e la profilazione degli utenti.

Questo non è vero per quanto riguarda l’Autorizzazione soprattutto se questa è intesa come gestione dell’entitlement (cosa un utente è abilitato a fare) di tipo totalmente centralizzata, fortemente granulare e con alto gradi di dinamicità.

Ad oggi molto spesso la gestione dell’entitlement è implementata all’interno della singola applicazione rendendo difficile, se non impossibile la gestione dell’Autorizzazione in una architettura orientata ai servizi, dove l’applicazione non conosce a priori il contesto nel quale il servizio che offre viene “consumato”.

Ma cosa si intende esattamente per Entitlement?

La parola entitlement, specialmente se tradotta dal dizionario, può significare cose diverse a persone diverse. In questo contesto, per entitlement si intende un insieme di privilegi che governano quello che l’utente di una applicazione è abilitato a fare.

Un entitlement è la relazione tra una risorse dell’applicazione (o in forma più astratta un oggetto di business) e l’insieme di utente/gruppo/ruolo, rappresentata secondo una struttura gerarchica.

Gli entitlement:

• sono soggetti ad una massima proliferazione;
• necessitano di considerare diverse informazioni di contesto prima di effettuare una decisione;
• devono essere consistenti all’interno dell’infrasttuttura e all’insieme delle applicazioni;
• devono essere allineati con i sistemi di Identity Management;
• devono evolvere indipendentemente dalle applicazioni e dai servizi;

Tuttavia….

ad oggi la maniera più comune di implementare gli entitlements è cablarli nel codice dell’applicazione!!!

Per rispondere a questa esigenza BEA ha sviluppato la soluzione BEA AquaLogic Enterprise Security che permette di esternalizzare, unificare e semplificare la gestione delle politiche di autorizzazione ovvero degli entitlement.

La figura seguente mostra un esempio di applicazione di trading. Questa applicazione può essere usata da differenti tipologie di utenti, ma solo gli utenti che sono traders possono fare operazioni di acquisto/vendita. Inoltre, i traders posso operare solo per gli specifici conti per i quali sono autorizzati e solo fino ad uno specifico importo per ogni definito per ogni conto.

Come si può vedere nel secondo caso, la decisione è rimossa dall’applicazione e valuta a runtime dal motore di BEA AquaLogic Enteprise Security.

Utilizzando BEA AquaLogic Enterprise Security all’interno della propria infrastruttura si possono quindi definire le linee guida con cui devono essere sviluppate le applicazioni per quanto riguarda la funzionalità di gestione dell’Autorizzazione, ovvero:

• nessuna policy cablata nel codice
• nessuna policy dipendente da un file di configurazione
• scrittura del codice uniforme verso un unico layer per la gestione della sicurezza

Come funziona AquaLogic Enteprise Security in dettaglio?
Al prossimo post…

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.

Firmato Booz Allen Hamilton è il recente survey “Quanto è efficace la tua organizzazione IT”, indirizzato a CIO, manager dell’IT e non. Il survey è ancora aperto (se volete compilarlo lo trovate qui, sono 24 domande) ma l’articolo odierno su CWI fa emergere già interessanti dati. Certo il tema del connubio tra Business e IT, più volte ripreso da BEA, è sempre più scottante: da un lato un IT troppo spesso ingessato da architetture e soluzioni ‘rigide’ e silos verticali, e dall’altro modelli di Business sempre più reattivi, veloci ed aggressivi. E con la figura del CIO o dell’IT manager a gestire il difficile compito di allineare il proprio IT alle incalzanti richieste del Business. BEA risponde con numerose soluzioni volte a ridurre il gap IT-Business, e le raccoglie sotto un unico messaggio dal chiaro ed evocativo nome “Liquid Enterprise”: provate a fare un giro sul sito per scoprire qualcosa in più sulla Business Agility.

Virtualizzazione (delle architetture IT) è una delle buzzword del momento: e BEA, come spesso accade, la fa da leader ancora una volta. Viene rilasciato oggi un utilissimo calcolatore online del TCO (Total Cost of Ownership), che mette a raffronto i costi associati a tre diversi scenari per applicazioni Java enterprise:

1. piattaforme non virtualizzate, dove le applicazioni girano su sistemi dedicati
2. il modello a sistemi operativi virtualizzati, dove più di una macchina virtuale gira sullo stesso sistema operativo
3. e la architettura BEA LiquidVM, che permette alle applicazioni Java di girare su macchine virtuali, senza sistema operativo (e quindi al massimo delle performance ed efficienza)

I dati richiesti dal calcolatore sono pochi, ma le informazioni che si ottengono sono di estremo valore. Da provare.

In un post precedente si parlava dello scorso convegno Forum ValueIT su SOA e IT Governance. Grazie agli organizzatori sono ora disponibili tutti i video delle presentazioni. Vi invito a dare un occhiata al sito del Forum dove, previa registrazione, troverete tutti i video, ed anche la presentazione di BEA Systems “La soluzione BEA per il governo di una architettura a servizi (SOA)”. Buon ascolto.

Anche quest’anno BEA partecipa all’ IDC Virtualisation & Enterprise Conference 2.0. I temi trattati sono di estrema attualità ed interesse, e la comunità ICT, sia lato utenti finali che vendor e operatori, sta raccogliendo rilevanti risultati con queste soluzioni.

BEA porta la sua voce da leader sui temi della SOA, delle Dynamic business application e della Virtualizzazione, con un intervento nella mattinata del 18 di Paolo Salvalaglio. Nel pomeriggio del 18, invece Massimo Tripodi presenterà un caso estremamente interessante di Fastweb, che ha implementato con successo con noi uno straordinario progetto SOA.

Vi aspettiamo lunedi!

Sviluppato come guida per il governo del Regno Unito, l’Information Technology Infrastructure Library (ITIL) è uno standard nato alla fine degli anni ’80 con lo scopo di offrire una serie di “best practice” per la gestione dei servizi IT, promuovendo un approccio di qualità al fine di ottenere maggiore efficacia nel lavoro e sempre più efficienza nell’utilizzo dei sistemi informativi.

Il crescente affermarsi sul campo di questo standard dipende dal riconoscimento e dall’adesione da parte di quelle organizzazioni che, in modo sempre maggiore, sono dipendenti dall’Information Technology, e che sono decise a soddisfare i loro scopi e le loro necessità di affari.
Questa dipendenza conduce alle necessità di servizi di qualità dell’IT sempre maggiori, qualità per la quale lo standard ITIL fornisce una serie di indicazioni da seguire.
Esso, infatti, descrive i processi, le attività, i ruoli e le responsabilità per poter gestire in modo flessibile l’organizzazione e i problemi che possono sorgere, al fine di migliorare la qualità dei servizi forniti e di rispondere alle esigenze del mercato, dei clienti e degli acquirenti. ITIL è supportato da uno schema di qualifica completo, da organizzazioni accreditate di training, e da strumenti di implementazione e di valutazione.
Questo insieme di “best practice”, in sostanza, non si presenta come una serie di rigide regole, ma più semplicemente come una traccia da adattare caso per caso a seconda delle necessità, dei bisogni, delle particolarità e delle caratteristiche dell’azienda. Lo standard può essere utilizzato:

• nel settore pubblico - Governo centrale e locale, Autorità sanitarie e politiche
• nel settore privato - Banche, Assicurazioni, Telecomunicazioni, Servizi Pubblici, Trasporti
• dalle società IT - Fornitori di prodotti, Società di System Integration, Società di Outsourcing

La documentazione ITIL è suddivisa in più libri, che trattano ognuno un aspetto diverso della gestione dei servizi IT; sono tutti leggibili in modo indipendente, ma ovviamente presentano sempre concetti strettamente correlati tra di loro. I libri di cui la documentazione è composta sono i seguenti:

SERVICE SUPPORT :
assicura che il Customer abbia accesso ad appropriati servizi per il supporto di funzioni di business. I processi descritti sono: il Service Desk, l’Incident Management, il Problem Management, il Configuration Management, il Change Management e il Release Management.
SERVICE DELIVERY :
questa sezione riguarda il rilascio del servizio richiesto per permettere un supporto adeguato ai clienti. Vengono trattati i processi del Capacity Management, del Financial Management per i Servizi dell’IT, dell’Availability Management, del Service Level Management e dell’IT Service Continuity  Management.
PIANIFICAZIONE PER IMPLEMENTARE IL SERVICE MANAGEMENT :
questa parte introduce all’utilizzo dell’ITIL in quanto fornisce una guida sull’allineamento dei bisogni di business all’IT e sulla valutazione dei livelli correnti di maturità del Service Management. Aiuta l’organizzazione ad identificare i punti di forza e di debolezza, permettendo di sviluppare i primi e di superare gli ultimi.
ICT INFRASTRUCTURE MANAGEMENT :
si occupa dei processi, dell’organizzazione e degli strumenti necessari per fornire un’infrastruttura stabile di IT e comunicazioni ed è la base per i processi di ITIL Service Management. Questa parte si occupa di Design & Planning, Operations e Technical Support.
APPLICATION MANAGEMENT :
fornisce un aiuto agli utenti, agli sviluppatori e ai manager del servizio per identificare quali applicazioni possono esser gestite da una prospettiva di service management.
SECURITY MANAGEMENT :
questa sezione si occupa della sicurezza dal punto di vista del fornitore del servizio, identificando come il Security Management si relaziona con l’IT Security Officer e come fornisce il livello di sicurezza necessario.
THE BUSINESS PERSPECTIVE :
si occupa di far comprendere ai manager il carico di business. Le questioni trattate includono il Business Relationship Management, il Partnership and Outsourcing, dei continui miglioramenti e sfruttamenti dell’informazione, Communication and Technology (ICT) per trarre vantaggio dal business.

La figura seguente mostra i processi che fanno parte dell’area “Service Support”

Ogni processo ITIL è a se stante nella sua definizione, ma per svolgere pienamente il suo scopo deve essere preso in considerazione con tutti gli altri.BEA Systems ha adeguato la propria struttura di supporto per essere in linea con le Best Practices ITIL, con particolare riferimento al Service Support, e inoltre richiede che i Support Account Manager che hanno la responsabilità dei Clienti di tipo Mission Critical siano certificati ai maggiori livelli ITIL. Come a dire: “al vostro servizio” con le nostre “migliori risorse”.
Per informarsi o saperne di più www.itsmf.it

Chiara Scarafiotti, ITIL Practitioner Support & Restore

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.

In anteprima un nuovo whitepaper scritto a 4 mani con gli amici di VMWare: vengono analizzati i trend di adozione di SOA e Virtualizzazione, e vengono analizzate situazioni in cui una tecnologia sfrutta l’altra o ne abilita migliori risultati. Un bel documento di valore per CIO, IT manager ed architetti enterprise. Scarica il whitepaper

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.

Segnalo questo bell’articolo tratto da ZDNet, dove l’autore evidenzia 12 fattori che contribuiranno allo sviluppo di SOA, Web 2.0 e SaaS (Software as a Service) nel breve-medio termine. L’autore sostiene che queste tre tecnologie hanno caratterizzato le discussioni nell’IT nell’ultimo periodo, ma che il 2008, per una serie di trend che si stanno concretizzando, sarà l’anno in cui vedremo queste tecnologie applicate nelle “next generation enterprises”. Buona lettura.

http://blogs.zdnet.com/Hinchcliffe/?p=157

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.

All’inizio era la telefonia tradizionale con i suoi servizi voce in grado di mantenere in crescita le revenue dei vari operatori telefonici. Poi sono arrivati i servizi a valore aggiunto (VAS) e la continua ricerca della killer application, l’ “Applicazione” che avrebbe dovuto colmare la diminuizione dei profitti dei servizi voce e degli sms. Sono stati fatti diversi tentativi, gli operatori hanno iniziato a collaborare con alcuni partner selezionati, per fornire servizi alternativi. Tutto questo non ha funzionato, o solo in parte. La dimostrazione sono le continue pubblicità che si vedono in giro dove gli operatori insistono ancora su offerte di voce e SMS/MMS senza mai promuovere nulla di nuovo.Nel frattempo sono arrivati i vari Google, Skype, Youtube, SecondLife che stanno catalizzando l’attenzione degli utenti relegando i carrier a semplici fornitori di connettività. L’utente acquista un abbonamento flat (a breve anche su terminale mobile), ottiene il suo accesso internet e diventa un nodo della rete, libero di decidere cosa fare e con chi.Ed ancora, l’introduzione di applicazioni quali wikies e blogs hanno spostato il ruolo dell’utente che da singolo consumatore dei contenuti presenti su internet a produttore. Gli americani hanno coniato il termine “prosumer”.E’ nato così il social networking con i sui strumenti di condivisione delle informazioni , di tagging, bookmarking, blogging e tutte quelle forme di aggregazione che fanno parte ora di un fenomeno chiamato Web2.0.Ora lo scenario sta cambiando, gli operatori hanno smesso da tempo di cercare la killer application e stanno cercando di inseguire questa nuova onda di entusiasmo e soprattutto hanno realizzato che o si alleano o perdono la guerra.

Si cominciano a concretizzare i primi progetti di Service Exposure che consistono nel rendere disponibili le funzionalità della rete come servizi accessibile dall’esterno a disposizione di chiunque voglia realizzare applicazione composite (mashup networks).

Questo perchè, sul piano tecnologico, gli operatori hanno ancora diverse carte da giocare perchè una delle grosse limitazioni nei servizi offerti dalle varie “Google companies” è data dal fatto che l’utente è anonimo in quanto si presenta con un indirizzo internet o al più è l’utente virtuale che ha deciso di essere. L’applicazione Google puo’ al massimo lavorare sugli header HTTP o sui cookies per cercare di gestire in qualche modo l’utente.

Gli operatori invece sono in possesso di un insieme di informazioni pregiate sull’utente per la realizzazione di servizi innovativi in quanto sono “fisicamente connessi” con loro:

• Location – hanno l’informazione su dove l’utente si trova a diverse granularità
• Network – hanno l’informazione su quale rete sono attestati
• Bandwidth – hanno l’informazione sulla banda disponibile per una specifica sessione
• Presence – hanno l’informazione sul terminale che l’utente sta utizzando tra quelli a disposizione con la stessa identita

Questi sono solo alcuni esempi di informazioni che fino ad oggi hanno tenuto gelosamente all’interno delle proprie reti sia per questioni puramente tecnologiche sia soprattutto perchè considerate un loro valore da non condividere

Ma oggi più che mai gli operatori possono raccogliere la sfida del Web 2.0 mettendole a disposizione sotto forma di Web Services , API, Widget, Pagelet.

BEA Systems ha creato da tempo una famiglia i prodotti WebLogic Communication Platform proprio per rispondere a questa nuova esigenza offrendo agli operatori una serie di soluzioni che permettono in modo rapido, seguendo un approccio SOA, di “esporre la rete come servizio”.

Per ulteriori approfondimenti vedi il sito http://www.bea.com/wlcp/

“Non è un blog, è una brochure!” Questo è stato il commento di un amico che ha letto Caffè con BEA e sigh, io sarei tra i colpevoli. In effetti nel mio post precedente ho parlato e dato un giudizio positivo di un prodotto BEA, WebLogic Integration. Chiedo venia, purtroppo posso parlare di ciò che conosco. Per tentare di farmi perdonare, vi propongo un’altra riflessione, certo basata su WLI (vedi sopra) ma applicabile a tutti i prodotti dello stesso tipo.Spesso mi sono imbattuto in clienti che mi chiedevano: perchè dovrei usare un motore di processi ? Ecco, secondo me, le ragioni per utilizzarlo e quelle per farne a meno:I motivi del SI

1. si sviluppa più in fretta (perchè i wizard mi nascondono le complessità delle interfacce da usare)
2. si fà l’integration test più in fretta (perchè il debug di front-end e back-end è integrato)
3. la gestione dello stato dei processi è già pronta e non richiede ulteriore sviluppo
4. il monitor dei processi in produzione è già pronto e non richiede ulteriore sviluppo
5. è più semplice modificare l’applicazione quando è già in produzione

I motivi del NO

1. non ho controllo del codice perchè uso molti wizard e componenti già pronti
2. non posso realizzare certi trucchi, perchè lo strumento me lo impedisce
3. vorrei poter controllare alcuni dettagli dei processi in esecuzione, mentre lo strumento me ne visualizza altri

Le due liste non sono esaustive, anzi vi esorto a completarle o a modificarle secondo la vostra esperienza. Per quanto mi riguarda, e qui rischio l’ennesima stroncatura, i sostenitori della seconda lista finiscono spesso per riscriversi un process engine quasi per intero e dunque, io che sono di natura un pigro, mi chiedo: non era meglio prenderlo già pronto?

Tempo fa partecipai ad un avvincente progetto di integrazione: inserimmo un “bus” per lo scambio di messaggi fra le diverse applicazioni di una SIM (Società di Intermediazione Immobiliare) e grazie a questo “strano oggetto” i traders ed i loro capi potevano vedere informazioni tra loro correlate ma che risiedevano in sistemi differenti ed isolati. Le modifiche avvenivano in tempo reale ed i dati erano dunque sempre aggiornati.

Ma non fu questa la parte che più piacque al cliente. L’iniziativa ebbe successo grazie alla rapidità con la quale l’IT riusciva a realizzare le richieste dell’utente finale. Oltre naturalmente, all’affidabilità del sistema, che non perdeva un messaggio.

Se, dopo quasi dieci anni, cito ancora quell’esperienza è perchè il confronto con la realtà di oggi appare ancora istruttivo: le interfaccie di comunicazione fra il bus e le applicazioni da integrare venivano sviluppate a mano di volta in volta, partendo da un set di librerie proprietarie. Non esisteva il concetto di processo o di orchestrazione. Il mapping dei dati era realizzato con uno strumento visuale che alimentava un motore esterno al bus. Forse ciò che è cambiato meno da allora ad oggi è la trasformazione dei messaggi. Eravamo già ad uno stadio evoluto, anche se non utilizzammo standards come XML.

In un progetto più recente che ho potuto osservare da vicino, il system integrator ha semplificato la componente di integrazione ed introdotto l’uso di un motore di processi utilizzando WebLogic Server e WebLogic Integration. Il bus comunica con le applicazioni via SOAP, RMI o JDBC, ed ha integrato la componente di processo consentendo la creazione di nuove funzionalità basate su quelle offerte dei sistemi esterni.

WebLogic Integration ha fatto la parte del leone. Ha consentito l’integrazione delle applicazioni e lo sviluppo dei processi in pochissimo tempo. L’infrastruttura di test inclusa nel prodotto ha ridotto i tempi di collaudo e le funzionalità del motore hanno sollevato il system integrator dall’onere di dover sviluppare da sé la logica di stato e persistenza di messaggi e di processi.

Naturalmente non solo BEA Systems offre strumenti di questo tipo. Ma ciò che voglio evidenziare, al di là dei prodotti utilizzati, è il progresso avvenuto in questo campo. Si programmano sempre meno le interfaccie di comunicazione (che son sempre state una materia ostica, nello sviluppo e nel collaudo) e si riduce sempre di più il tempo di realizzazione di nuove funzionalità, grazie all’uso dei process engine come WebLogic Integration.

Oggi affronto un progetto d’integrazione con grande serenità, convinto che l’adozione di WebLogic Integration sollevi il team da molto lavoro inutile, elimini le cause di tanti errori e consenta di raggiungere l’obiettivo con tempi certi e, cosa più importante, con la soddisfazione del cliente.

La collaborazione tra BEA ed Italtel continua con una intervista a Marco Casucci, Head of Services and Services Enabler Unit. Italtel, basandosi sulla WebLogic Communication Platform, è riuscita in breve tempo, e prima in Europa, ad implementare e lanciare sul mercato una soluzione innovativa e dirompente per il mercato delle Telecomunicazioni: la parola d’ordine è Convergenza, di reti, risorse, servizi, …
Per una lettura più approfondita clicca qui.