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.

Alcune roadmap già  indirizzano la stetegia di adozione a secondo del livello. Ad esempio BEA mappa le strategie di adozione in tre fasi, ciascuna delle qulai copre due livelli del proprio modello di maturità .

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

Riassumendo:

• 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