Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide. Ma quale strategie adottare? Il punto di partenza deve essere sempre l‘assessment rispetto ad un maturity model.
Introduzione
Nei precedenti 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] e [4] abbiamo visto come sia indispensabile capire il livello di maturità dell‘organizzazione e definire in base a questa una roadmap che definisca i passi aziendali (organizzativi, tecnologici, metodologici e culturali) per definire un processo evolutivo ed incrementale con l‘obiettivo di una architettura SOA matura.
In [5] abbiamo parlato di Service Oriented Integration (SOI): i principi Service Oriented applicati alle problematiche d‘integrazione.
Nel precedente [6] si sono introdotte le caratteristiche saliente di un Enterprise service BUS (ESB) ed in [7] si sono presentati alcuni tra i principali ESB open-source.
In questo articolo analizzeremo alcune possibili strategie di adozione di SOA all‘interno dello scenario IT.
SOA: Come iniziare
Sappiamo già che l‘adozione di SOA all‘interno di un‘organizzazione con un sistema informativo affermato non può prescindere dalla valutazione del sistema presente rispetto ad un Maturity Model. Una volta effettuata questa valutazione, abbiamo proposto un esempio di Roadmap che può essere seguita per aumentare la maturità dell‘organizzazione rispetto al modello.
Nonostante la Roadmap sia indicativa di una serie di passi che possono essere raggiunti, è opportuno specificare meglio alcune strategie che possono essere seguite nell‘introduzione di SOA in un‘azienda.
Questo tipo di strategie si sovrappongono alla Roadmap presentata suggerendo di fatto come agire rispetto all‘estensione dei servizi introdotti e all‘importanza per il business degli stessi nelle fasi iniziali di adozione di SOA.
- Trials/Pilot: si sviluppa un progetto pilota che implementa l‘architettura nel modo corretto per dimostrare al management dell‘azienda la possibilità dell‘adozione di SOA e mostrarne in maniera tangibile i vantaggi, minimizzando il rischio.
- Low Road: vengono sviluppati servizi SOA non critici come ad esempio l‘iscrizione dei corsi interni, logistica aziendale, ecc. In questo stadio l‘architettura è completa ma non si sviluppano servizi core di business.
- LOB (Line Of Business): si sviluppano con SOA alcune applicazioni relative al business dell‘azienda prendendo come riferimento una singola linea di business.
- Enterprise Wide: SOA è utilizzato per il sistema informativo dell‘azienda a tutti i livelli: dallo sviluppo di infrastrutture ai servizi mission-critical.
Strategie di Adozione e Maturity Model
Ma quale di queste strategie adottare?
Il punto di partenza deve essere sempre l‘assessment rispetto ad un maturity model.
Come abbiamo già spiegato (vedere [3]), a seguito dell‘assessment e della definizione della maturità , è possibile individuare una roadmap per evolvere in maniera incrementale verso una architettura full-SOA. Noi abbiamo presentato un esempio di roadmap (vedere [4]): è bene precisare che che la roadmap è correlata al maturity model utilizzato, infatti la definizione della maturità ci permette di posizionarci sulla roadmap. Questo posizionamento ci aiuta a definire le azioni che dobbiamo intraprendere per evolvere il sistema informativo.
Le strategie presentate ci possono ulteriormente indirizzare sull‘estensione delle azioni che vanno intraprese, rispetto alla dimensione dei progetti e rispetto all‘impatto sul business aziendale.
Ad esempio se la valutazione evidenzia una bassa maturità , è opportuno iniziare con un Pilot, cioè su un progetto piccolo con funzionalità che non hanno effetto significativo sul business aziendale. Se invece SOA è già stato utilizzato all‘interno dell‘azienda con successo per servizi infrastrutturali o applicazioni interne, può essere sensato estenderne l‘adozione direttamente ad una linea di business.
Stage 1 – Exploring (copre Level 1 e Level 2): un Proof of Concept e/o Pilot dove si prende un segmento di business e lo si reingegnerizza
Stage 2 – Expanding (copre Level 3 e 4): inizio di condivisione dei dati (es: anagrafe di un cliente) mediante il riuso del medesimo servizio
Stage 3 – Exploring (copre level 5 e 6): possibilità di aggiungere “isole informatiche” all‘architettura senza problemi
- un Maturity Model aiuta nella valutazione di un sistema informativo rispetto ad una architettura full-SOA
- una Roadmap indirizza in maniera corretta i passi da effettuare per evolvere l‘architettura e suggerisce anche l‘estensione (nei termini specificati) degli interventi
- la strategia di adozione è diretta conseguenza del livello del Maturity Model e della Roadmap che si vuole intraprendere.
SOA Pilot
Il caso realisticamente più frequente è quello della realizzazione di un progetto pilota, con obiettivi più o meno ampi a seconda degli esiti di valutazione del SOA Assessment.
L‘implementazione di un progetto pilota è una buona scelta in una organizzazione “poco matura”; in questo caso infatti il Pilot può essere utile per validare SOA come architettura di riferimento per il sistema informativo aziendale.
Un Pilot non coinvolge funzionalità mission-critical, ma è necessario che raggiunga risultati credibili e che i servizi implementati riguardino problematiche reali; inoltre il progetto deve avere la dimensione giusta per essere considerato un test realistico e realizzare in maniera compiuta tutti i principi architetturali e metodologici.
Un‘altra caratteristica importante è che occorre definire per il Pilot dei precisi obiettivi e prevedere dei chiari criteri di raggiungimento e valutazione (clear acceptance criteria).
Questo agevola la “sponsorizzazione” del CIO. E‘ molto piu‘ facile infatti sponsorizzare come primo passo verso SOA un Pilot ben dimensionato e dai chiari risultati che non progetti di dimensione eccessiva e quindi troppo rischiosi in termini di tempo, costi e business.
Inoltre il Pilot, nel caso raggiunga gli obiettivi posti, può essere esteso, e quindi può fungere da punto di partenza per una adozione iterativa di SOA all‘interno dell‘organizzazione.
In sintesi, i vantaggi di partire utilizzando un pilot sono:
- Richiede un budget limitato
- Permette di prendere confidenza con la tecnologia
- Permette di fare “palestra” da un punto di vista metodologio, architetturale e tecnologico
- Permette di provare i prodotti tecnologici di diversi vendor
- Verifica le possibilità di integrare i sistemi legacy esistenti
- L‘eventuale fallimento è poco rischioso
Conclusioni
Nel prossimo articolo implementeremo un semplice “pilot”. L‘esempio pratico ci consentirà di “ripassare” quanto spiegato in questa serie di articoli dedicati a SOA.
Bibliografia
[1] M. Piraccini, S. Rossini: SOA: Introduzione – MokaByte 100 – Ottobre 2005
https://www.mokabyte.it/2005/10/soa-1.htm
[2] M. Piraccini, S. Rossini: SOA: Metodologia – MokaByte 101 – Novembre 2005
https://www.mokabyte.it/2005/11/soa-2.htm
[3] M. Piraccini, S. Rossini: SOA (III): Il Maturity Model – MokaByte 102 – Dicembre 2005
https://www.mokabyte.it/2005/12/soa-3.htm
[4] M. Piraccini, S. Rossini: SOA (IV) Roadmap – MokaByte N.103 – Gennaio 2006
https://www.mokabyte.it/2006/01/soa-4.htm
[5] M. Piraccini, S. Rossini: SOA (V) SOI – MokaByte N.104 – Febbraio 2006
https://www.mokabyte.it/2006/02/soa-5.htm
[6] M. Piraccini, S. Rossini: SOA (VI) ESB (I) – MokaByte N.105 – Marzo 2006
https://www.mokabyte.it/2006/03/soa-6.htm
[7] M. Piraccini, S. Rossini: SOA (VII) ESB (II) – MokaByte N.106 – Aprile 2006
https://www.mokabyte.it/2006/04/soa-7.htm
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/
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