Una volta capito/stabilito quanto un?azienda è matura nella sua implementazione di un?architettura SOA-oriented, è possibile definire i passi da intraprendere: l‘insieme di questi passi definisce la Roadmap per l‘evoluzione dell‘organizzazione verso un‘adozione di SOA più matura.
Negli scorsi articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [1]) che delle metodologie di analisi e di design (vedere [2]) .
Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide.
In [3] abbiamo visto come sia indispensabile capire quanto l‘organizzazione che vuole utilizzare architetture a servizi sia matura per l‘effettiva adozione di queste. Implicitamente ciò significa confrontare il grado di maturità tecnologica di un‘azienda con un “maturity model”, quindi in pratica effettuare un‘operazione di assessment.
Una volta capito/stabilito quanto un‘azienda è matura nella sua implementazione di un‘architettura SOA-oriented, è possibile definire i passi da intraprendere: l‘insieme di questi passi definisce la Roadmap per l‘evoluzione dell‘organizzazione verso un‘adozione di SOA più matura.
Roadmap
Una volta capito/stabilito quanto un‘azienda è matura nella sua implementazione di un‘architettura SOA-oriented, è possibile definire i passi da intraprendere.
SOA è una strategia da adottare non a big-ben sull‘ambiente IT esistente ma bensì deve essere integrata con l‘esistente in modo incrementale e razionale: la roadmap è la descrizione dei passi aziendali (organizzativi, tecnici, metodologici e culturali) che devono definire un processo evolutivo ed incrementale. L‘esempio di roadmap che esporremo è stato elaborato cercando di individuare i macro-step più importanti (in effetti è possibile dettagliarlo ulteriormente) e con l‘obiettivo ambizioso di un‘organizzazione che abbia completamente assorbito tutti gli aspetti di SOA e che di conseguenza ne ricavi il maggior valore possibile. Questa Roadmap deve essere quindi considerata un “condensato” e non ha pretesa di essere esaustiva: può essere piuttosto il punto da cui partire per elaborare una strategia nel momento in cui ci si trovi di fronte ad un caso concreto.
Initial Services
Iniziamo ponendoci nelle condizioni di attuare la fase 1 della roadmap: l‘integrazione punto-punto (P2P).
Per focalizzare meglio le idee ed i passi della roadmap, si prevede l‘uso tecnologico dei Web Services.
Un Web Service è un servizio riutilizzabile che può essere richiamato attraverso tecnologie internet e che dialoga in XML. La rappresentazione dei dati nei Web Services avviene mediante XML e per questo sono definiti “language-neutral”.
I WS utilizzano per la comunicazione protocolli standard internet (es: HTTP) e per questo sono definiti “platform-netural”.
I WS sono quindi standard-based, language e platform neutral: sono i candidati ideali per semplificare le problematiche d‘integrazione e per l‘implementazione dei servizi (vedere [MOKA_WA_1], [5]).
Di fatto a questo livello della roadmap si ha la stessa torta, ma ricoperta con una nuova crema.
Ci muoviamo verso una prima versione prototipale di SOA (SOA Pilots) che deve essere utilizzata per verificare l‘architettura e dimostrare al management che i principi enunciati sono effettivamente utilizzabili.
In questa realizzazione prototipale è importante seguire in maniera ferrea tutti i dettami architetturali di cui abbiamo già parlato. A questo livello, comunque, i prototipi hanno principalmente lo scopo di sperimentazione tecnologica.
Architected Services
L‘obiettivo è iniziare a assorbire SOA culturalmente all‘interno dell‘organizzazione. Si comincia ad introdurre il Service Model, che permette di definire sia i requisiti che l‘interfaccia delle implementazioni tecniche (Service Contract).
Si inizia a comprendere l‘importanza di disegnare servizi “coarse-grained” e debolmente accoppiati con il service consumer, e nuovi sviluppi vengono iniziati con questi obiettivi.
Il Service Model ha una semantica ben definita (quella dei servizi) e può essere oggetto di modellazione MDA (in questo caso si parla di SOA Metamodel). L‘acquisizione di questi concetti è poi di supporto a tutta l‘attività dei livelli successivi della roadmap.
Di fatto nel livello precedente abbiamo introdotto i servizi dal punto di vista tecnologico: ora introduciamo il linguaggio comune con cui l‘organizzazione può descrivere il suo sistema informativo.
Si inizia quindi a “istituzionalizzare” i concetti di SOA a livello organizzativo.
In parallelo, cominciano a emergere problematiche di infrastruttura e di gestione.
Si iniziano ad individuare delle categorie di servizi infrastrutturali che vengono progettati e implementati a supporto dei servizi di business. Esempi tipici sono la sicurezza/autorizzazione, logging, alerting…
Inoltre l‘acquisizione da parte dell‘organizzazione dei concetti di SOA comincia a porre problemi di gestione (SOA Management) che possono comprendere problematiche come:
- Ciclo di vita dei servizi (versionamento, analisi delle dipendenze, deprecabilità )
- Qualità dei servizi
- Definizione della capacità dei servizi (livelli di servizio, scalabilità , …)
- Monitoring
- Management (configurazione, attivazione, etc)
- Business Activity Monitoring (BAM)
Alla fine di questa parte del percorso avremo definito dei servizi mission-critical supportati da servizi di infrastruttura che l‘organizzazione è in grado di gestire. Inoltre sarà presente una notazione comune che sia gli esperti funzionali che gli architetti possono utilizzare per la definizione del sistema informativo.
Business Services
Come possiamo ora evolverci? Il passo successivo è l‘introduzione di strumenti per la gestione dei processi. Da questo momento le applicazioni vengono disegnate (o ristrutturate) come orchestrazione di servizi, che a loro volta possono essere costruiti componendo altri servizi. E‘ qui che si comincia ad avere un forte ritorno sull‘adozione di questo tipo di architettura, e si mette in pratica la capacità di riutilizzo che fino a questo punto era in gran parte “potenziale”. Analisti e Architetti lavorano in sinergia utilizzando il concetto di servizio e i concetti SOA sono diffusi a tutti i livelli IT.
Verificando il riutilizzo e la capacità di composizione, l‘organizzazione è anche spinta a condividere i servizi tra processi e applicazioni differenti e a condividere i servizi con altre organizzazioni che cooperano con essa.
A questo punto si può abbandonare il concetto di servizio “statico” muovendosi da un‘integrazione punto a punto a una integrazione dinamica (cioè: ricerca di un service provider da parte di un service consumer).
Questo permette di disaccoppiare Service Consumer e Service Provider. Il consumer “cerca” il servizio pubblicato nel Service Registry per poi utilizzarlo.
SOA Nirvana
Uno dei problemi che un‘organizzazione incontrerà a questo livello è che, avendo risolto il problema dell‘integrazione dal punto di vista tecnologico e architetturale, si troverà a dovere risolvere il problema dell‘integrazione a livello dei dati.
Questo problema risiede nel fatto che, se da una parte è vero che SOA porta a esporre il data model ad un livello di astrazione più alto (non so se i dati che arrivano sono ricavati da un DBMS, un sistema legacy, ecc…) è vero anche che la struttura dell‘informazione non è definita e la devo conoscere a priori se voglio integrarmi con un servizio che la espone: devo cioè conoscere a priori la semantica dell‘informazione che il mio sistema deve elaborare.
Questa questione in realtà è sempre presente, ma di solito viene “mascherata” da problemi di integrazione più contingenti, che in questo caso non si presentano perchè vengono risolti dall‘infrastruttura SOA.
Il concetto di Semantic Integration riguarda questo problema, partendo dalla considerazione che il problema dell‘integrazione dei dati è dovuto al fatto che non conosco la loro semantica. Posso risolvere il problema introducendo un sistema di definire la semantica dei dati che sia “elaborabile”, ad esempio attraverso il concetto di ontologia.
In pratica un‘ontologia (che può essere definita in Web Ontology Language, uno standard W3C (vedere [10]) permette di definire un modello con relazioni e regole con cui è possibile “catturare” le relazioni semantiche tra i dati. La descrizione del data model tramite ontologie può permettere l‘automatizzazione dell‘integrazione tra servizi.
A questo punto abbiamo gli strumenti per definire l‘integrazione tra i dati: possiamo “maneggiare” i dati prodotti da servizi esterni (se ne conosciamo le ontologie).
In conclusione abbiamo tutti i prerequisiti di astrazione (tecnologica, architetturale e a livello dei dati) perché l‘integrazione sia meno “dolorosa” possibile.
L‘organizzazione che è a questo livello è in grado di adattarsi velocemente al cambiamento con costo minimo e integra il proprio sistema informativo senza problemi all‘esterno con altre aziende con livello di maturità analogo. Il riuso della logica già scritta è incoraggiato e il management è in grado di comprendere l‘architettura fino ad un dettaglio che in precedenza non possedeva.
Conclusioni
In questo articolo abbiamo parlato dell‘importanza di avere una roadmap che definisca i passi aziendali (organizzativi, tecnici, metodologici e culturali) per definire un processo evolutivo ed incrementale con l‘obiettivo di una architettura SOA matura.
Abbiamo inoltre proposto una implementazione di Roadmap che prevede una serie di passi essenziali da seguire, cercando di mantenere un giusto equilibrio tra completezza e pragmatismo; esistono in rete anche altre proposte di roadmap molto interessanti, come ad esempio quella di Zapthink (vedere [6]).
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti gruppi bancari, pubblica sanità, pubblica amministrazione e software house.
Attualmente ricopre il ruolo di Sofware Factory Manager, Lean Change Agent ed Enterprise Architect presso Capgemini.
Esperto in ambito di sanità pubblica come Project/Program Manager per la governance dei progetti IT strategici di Cartella Clinica Elettronica (CCE) e Fascicolo Sanitario Elettronico (FSE).
Esperto in ambito bancario dove ha ricoperto per una decina d'anni il ruolo di Project Manager e Leader Software Architect (BPM, IWBank e BPS) occupandosi della pianificazione e gestione del progetto, del coordinamento del gruppo di sviluppo software sia InHouse che Nearshore/Offshore. Esperto nella conduzione di progetti secondo metodologia di Project Management PMBok e metodologia agile Scrum.
Si occupa di Java dal 1999 arrivando da precedenti esperienze in C e C++ in ambito Telco (Alcatel & Siemens). Ha pubblicato più di un centinaio di articoli su argomenti di IT Governance, Project Management, architetture enterprise e problematiche di Integrazione e SOA. È coautore dei libri "Manuale pratico di Java" (2001) e "La programmazione della piattaforma J2EE" (2005) editi da Hops/Tecniche Nuove. Certificazioni IT Governance: COBIT V.4.1 Foundation Certificate; certificazioni IT Service Management: ITIL V.3 Foundation Examination; certificazioni Project Management: CSM - Scrum Master, CSPO - Scrum Product Owner, PMI: 35 contact hours.
Profilo linkedin: http://www.linkedin.com/pub/stefano-rossini/30/977/242
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/