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