Cos’è un Maturity Model?
Il concetto di maturity model è stato introdotto nel 1991 dal Software Engineering Institute con il CMM (Capability Maturity Model). Questo famoso modello (oggi evoluto nel CMMI, vedere sotto) è stato disegnato per identificare il grado di maturità delle organizzazioni nel processo di sviluppo del software (su 5 livelli), ed è stato ispirazione per una serie di metodologie di valutazione (assessment), di varia complessità.
La valutazione rispetto ad un maturity model di questo tipo serve a identificare il grado di maturità di un’organizzazione indirizzando anche le attività che devono essere migliorate per raggiungere il gradino successivo. In pratica il concetto è “misurare” il grado di maturità del processo per poterlo migliorare e monitorare i cambiamenti nel tempo.
In questo caso, però, il tipo di maturità che intendiamo analizzare non è quella del processo (o, meglio, non solo), ma quella di aderenza ai principi SOA e quindi ad un paradigma architetturale. Questo tipo di valutazione deve quindi giudicare sia il livello di quello che è stato fatto che il livello di quello che si può fare. Oggi questo concetto è molto importante, dato che è frequente che le organizzazioni richiedano ai consulenti una valutazione di quanto è “riutilizzabile” in servizi di quello che già posseggono, in modo da valutare anche i costi e definire correttamente la roadmap per raggiungere l’obiettivo. Molti attori del mercato (principalmente grossi vendor e consulenti) stanno ad oggi proponendo una serie di standard che possono essere utilizzati a questo scopo: in questo articolo ne guarderemo alcuni promettenti.

Capability Maturity Model Integration
Iniziamo con questo modello perchè è ampliamente utilizzato ed è di ispirazione per gli altri processi di valutazione, anche se non è direttamente in relazione con SOA.
Il Capability Maturitity Model Integration (CMMI) è uno standard definito dal Software Engineering Institute (SEI) indirizzato a definire un livello di maturità del processo di sviluppo software (vedere [MOKA_CCMI]).
Per valutare la qualità di un processo, il CMMI ha definito tre attributi qualitativi fondamentali:

1. Capability: è l'insieme dei risultati che un processo consente di conseguire. Esprime le potenzialità del processo e permette di effettuare stime attendibili sulla possibilità di raggiungere i risultati di un progetto, sia per il committente che per il produttore.
   
2. Performance: è una misura dei risultati effettivi ottenuti nell'applicazione del processo. Una valutazione a consuntivo, un indice, dei risultati che sono stati raggiunti.
   
3. Maturity: è una misura dell'efficacia del processo e della estensione e precisione con cui le fasi e le attività dello stesso sono esplicitamente definite, gestite, misurate e controllate. Rappresenta una valutazione del livello di padronanza e controllo del processo da parte dell'organizzazione, ivi inclusa la capacità dell'organizzazione di migliorarlo, ottimizzarlo… o comunque modificarlo in risposta a necessità che si presentano.

Il CMMI prevede oltre alla definizione del modello e dei suoi attributi anche i relativi livelli per gli opportuni livelli per misurare l'efficacia del processo.
Il Capability Level - indica il livello di istitituzionalizzazione del processo: la capacità dell'azienda di eseguire, controllare, e migliorare le performance di un processo. Sono definiti sei livelli di capability. Il Maturity Level è una misura dell'estensione e dell'efficacia dell'intero processo aziendale. Sono definiti cinque livelli di maturità, ognuno con livelli di difficoltà e richieste diverse.

Figura 1: CMMI

SOA Maturity Model
Come già sottolineato, molti sistemi di valutazione si ispirano al CMMI del SEI: il modello che diverse grandi imprese hanno adottato per controllare la "qualità" dei processi del proprio dipartimento IT.
Ad esempio, l’iniziativa congiunta di Sonic Software, Systinet, AmberPoint e BearingPoint ha portato alla creazione di un insieme di specifiche, fattori critici di successo, standard e metodologie, che ha per fine quello di valutare il grado di adozione in un'azienda delle tecnologie SOA (vedere [SOA_MM]).
Come in CMMI, anche in SOA-MM sono definiti diversi livelli di maturità crescente, stavolta legati a come e quanto profondamente un'impresa ha adottato l'approccio SOA al suo interno.
La piramide riportata in SOA-MM paragona i cinque livelli del CMMI ai cinque analoghi livelli del SOA Maturity Model:

1. Functionality, in cui si ha l'adozione iniziale delle tecnologie SOA
   
2. Cost Effectiveness, in cui i servizi sono architected, ovvero ancora una volta sono definiti degli standard per la gestione (governance) delle tecnologie SOA
   
3. Responsiveness, in cui il focus è sulla soddisfazione tramite il SOA dei processi di business, macro-obiettivo che può essere realizzato mediante la realizzazione di servizi "di business" (livello 3.a) o di servizi "collaborativi" (modello 3.b);
   
4. Transformation, o livello dei servizi di business "misurati"
   
5. Optimization, o livello dei servizi di business ottimizzati.

Figura 2: I livelli del SOA-Maturity Model (Sonic Software, Systinet, AmberPoint e BearingPoint)

Oltre alla figura piramidale viene fornita anche una tabella, che mette in relazione i livelli di maturità del modello con i più evidenti benefici in termini di business (prime-business-benefits), la diffusione in azienda (scope), i fattori critici tecnologici e organizzativi, e gli standard di riferimento fino agli obiettivi (key-goals) e alle principali pratiche (key-practices).

Figura 3a: Descrizione dei vari livelli SOA-Maturity Model (Sonic Software, Systinet, AmberPoint e BearingPoint)

Figura 3b: Descrizione dei vari livelli SOA-Maturity Model (Sonic Software, Systinet, AmberPoint e BearingPoint)

La “piramide” e la tabella non sono di facile comprensioni ma richiedono uno studio e soprattutto una “matabolizzazione”. Il modello proposto da Sonic Software e dai suoi partner cerca di fissare una base di auto-valutazione comprensibile sia all'IT che ai business manager.
Uno degli suoi scopi principali infatti è quello di colmare il gap tra figure IT e business per quanto riguarda il livello aziendale attuale del soddisfacimento dei requisiti SOA.

• Primo livello – Initial Services
  Il primo livello è quello più semplice ed è limitato ad esportare come servizi alcune funzionalità IT. Si tratta principalmente di progetti pilota e sono “confinati” per lo più nell’ambito di sperimentazione del gruppo R&D all’interno dell’IT. Si inizia a prendere confidenza con gli standard di prima generazione come XML, XSLT, SOAP e WSDL.
• Secondo livello – Architected Services
  Al secondo livello il coinvolgimento ai principi SOA si allarga a tutto lo staff IT e si inizia a definire gli obiettivi, acquisire competenza e a strutturare il G.d.L di conseguenza. Si analizzando gli standard di seconda generazione (UDDI, BPEL4WS, WS-Security, …) e si individuano le tecnologie e prodotti da utilizzare e le linee guida da seguire. A tale livello si ha quantomeno uno “sponsorizzazione” da parte del CIO.
• Terzo livello – Business Services / Collaborative Services
  Al terzo livello l'implementazione delle SOA esce dall'ambito IT per coinvolgere anche i responsabili delle linee di business, è il primo passo verso l’“allineamento” tra IT e business.
• Quattro livello – Measured Business Services
  A tale livello si ha ormai una architettura SOA ben delineata con strumenti di Business Activity Monitoring e di Event Stream Processing che permettono di collezionare i dati di business, valutare il ROI del progetto e identificare eventuali punti da migliorare.
• Quinto livello – Measured Business Services
  Nel quinto livello l’architettura SOA è ormai consolidata e rodata, il CEO e l’IT sono “sintonizzati” e condividono la mission aziendale.
  L’obiettivo finale è quindi l’ottimizzazione dei processi e servizi di business.

Ad esemplificazione dei vari livelli di maturità, viene mostrato come un progetto classico iniziale costituito da un portale per le vendite che si interfaccia verso un'applicazione di CRM legacy ed un servizio di previsione e tracciamento degli ordini, utilizzando opportune interfacce, può evolvere verso un’architettura SOA oriented in modo incrementale.

Figura 4: Esempio [SOA_MM]

Al livello 1 si introduce un ESB come backbone, al livello 2 si centralizzano servizi come Single Sign-ON, trasformazione sintattica/semantica dei dati, Services Repository, …
Al Livello 3, per l'approccio Business Services viene introdotto un servizio di "orchestrazione” dei servizi (Orchestration) mentre nel Livello 4 fanno la comparsa i tool come il Real-time Event Stream Processing ed il BAM (Business Activity Monitoring),
Il Livello 5 adotta le stesse tecnologie del 4 con l’obiettivo di ottimizzare il business sfruttando tutti i dati real-time resi disponibili dall’architettura SOA realizzata.
Ovviamente tutti i prodotti di riferimento indicati nel documento sono quelli commercializzati dalle case promotrici come Enterprise Service Bus, Sonic

Il Service Integration Maturity Model (SIMM)
Il Service Integration Maturity Model (SIMM) è un altro modello proposto da IBM che si focalizza principalmente sulla maturità dal punto di vista dell’applicazione dei principi Service Oriented alle problematiche d’integrazione.
In questo modello i livelli previsti sono 7:

• Silo (data integration): Vengono utilizzate soluzioni di integrazione ad-hoc. A questo livello l’architettura non è aperta al cambiamento.
• Integrato (application integration): L’organizzazione si muove verso una forma di EAI (Enterprise Architecture Integration), cioè si cerca una forma di integrazione architetturale. A questo livello l’integrazione si ottiene con connessioni proprietarie e punti di integrazione. Le modalità di integrazione sono adattate a sistemi legacy e si fa ancora data integration.
• Componentizzato (functional integration): Le parti critiche delle applicazioni vengono fattorizzate o wrappate in componenti. L’integrazione tra i componenti avviene tramite le interfacce definite, cercando di esporre le funzionalità in maniera modulare.
• Servizi semplici (process integration): Si comincia ad utilizzare SOA definendo alcuni servizi ad uso interno o anche esterno ma in scala ridotta.
• Servizi composti (supply-chain integration): Si definisce un eco-sistema di servizi, che possono essere esposti a tutta la supply-chain .
• Servizi virutalizzati (virtual infrastructure): Si crea un’infrastruttura virtualizzata per le applicazioni, che a questo livello sono composte di servizi, componenti e flussi.
• Servizi dinamicamente riconfigurabili (eco-system integration): A questo livello l’architettura è riconfigurabile e i servizi possono essere composti dinamicamente.

E’ chiaro che in questo caso la misura del livello di maturità è la capacità di integrazione e gli obiettivi sono il massimo dinamismo e la massima adattabilità a fronte del cambiamento e della necessità. E’ implicito in questo modello il fatto che SOA è considerato il paradigma architetturale più promettente per raggiungere questi obiettivi.

Assessment
Una volta che si è scelto un maturity model, come si effettua l’assessment? Il modello stesso in genere indica cosa occorre verificare e questa attività può essere condotta con gli strumenti abituali di valutazione (questionari, checklist, ispezione della documentazione di processo e del codice, ecc). Tutto questo può essere effettuata da una task-force interna, da consulenti esterni esperti della materia oppure da … tool.
Un esempio di tool è disponibile on-line: IBM espone infatti la possibilità di effettuare un SOA-self-assessment traminte uno strumento gratuito di autovalutazione sullo stato SOA nella propria azienda che affronta i temi chiave relativi a processi, architettura, applicazione e infrastruttura.
Collegandosi all'URL del [SOA_SELF_ASSESSMENT] viene proposto un questionario per aiuta a capire lo stato dell'arte e del modello aziendale e quali sono i primi passi da perseguire per traghettare verso un’architettura SOA.

Figura 5: IBM SOA-self-assessment on-line

Per tale analisi del livello di maturità bisogna indicare il settore in cui opera la propria azienda e quali sono le iniziative/motivazioni per cui si sta valutando la possibilità di utilizzare SOA (es: iniziativa strategica, soluzione per affontare punti deboli specifici per processo e/o cpmponente di business, progetto pilota di implementazione sperimentale es: utilizzo di un ESB), valutazione di un prodotto relativo a SOA per una possibile acquisizione o l'introduzione di tecnologia di base quale servizi Web o BPEL, ...
Rispondendo ad una serie di 16 domande riguardante quattro categorie (processi, architettura, applicazione e infrastruttura) il tool indica il livello attuale di maturità dell’architettura e delinea un set di raccomandazioni utili per iniziare a delineare una roadmap verso SOA.

Figura 6: Esempio di report dell’IBM SOA-self-assessment tool

Anche BEA fornisce un tool analogo (vedere [BEA_SOA_SELF_ASSESSMENT]). Il tool ma si concentra su sei aree diverse (architecture, building blocks, business strategy & process, costs & benefits, organizations & governance, and projects & applications).

Figura 7: Esempio di report dell’IBM SOA-self-assessment tool

Una volta risposto alle domande, viene inviato direttamente via email il report dell’assessment.

Conclusioni
Una volta capito/stabilito quanto un’azienda è “matura” nella sua implementazione di un’architettura SOA-oriented tramite un maturity model, è possibile definire i passi da intraprendere.
Questi passi devono essere definiti poi formalmente in una roadmap che ci permetta di “traghettare” l’organizzazione verso il nostro obiettivo: la completa adozione dei principi di SOA a livello architetturale e organizzativo. Il maturity model scelto deve essere utilizzato per verificare e misurare gli avanzamenti di maturità che si sono programmati.

Bibliografia
[MOKA_SOA_I] M. Piraccini, S. Rossini: SOA: Introduzione - MokaByte 100 - Ottobre 2005
[MOKA_SOA_II] M. Piraccini,S. Rossini: SOA: Metodologia - MokaByte 101 - Novembre 2005
[MOKA_CMMI] M. Minzoni: CMMI Ottimizzare il processo per migliorare il prodotto -
MokaByte 90- 9mbre 2004
[SOA-MM] Sonic Software Corporation, AmberPoint Inc.,BearingPoint, Inc., Systinet Corporation: A
[SIM] A.Arsanjani, K. Holley: Increase flexibility with the Service Integration Maturity Model
(SIMM) Maturity, adoption, and transformation to SOA
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/
[IBM_SOA_SELF_ASSESSMENT] IBM SOA Self AssesmentTool: ibm.com/websphere/soa_assessment
(http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/soaassessment)
[BEA_SOA_SELF_ASSESSMENT] http://www.bea.com
[MOKA_WS_1] S. Rossini, R. Spazzoli: Web Services: il punto sulla standardizzazione (I) - MokaByte 96, Maggio 2005
[MOKA_WS_2] S. Rossini, R. Spazzoli: Web Services: il punto sulla standardizzazione (II) - MokaByte 97, Giugno 2005