Un Enterprise Service Bus è solo l’inizio. È il repository lo strumento che consente di tenere sotto controllo “l’anarchia” delle Soa, e quindi di fare governance.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
C’è stato un tempo, nemmeno troppo lontano, in cui era diffusa l’opinione che l’implementazione di una Service Oriented Architecture (Soa) si risolvesse con l’acquisizione di un Enterprise Service Bus (Esb). Si riteneva che bastasse prendere un Esb, abilitare come servizi un paio di applicazioni esistenti, realizzare alcuni nuovi servizi, mettere bene insieme il tutto bastasse per creare una Soa.
A dire il vero, durante il primo periodo della crescita Soa, questo genere di scenario non era tanto lontano dalla realtà. Le aziende avevano a disposizione un numero relativamente limitato di servizi e li utilizzavano in maniera altrettanto limitata. I dipartimenti It erano nella fase di “sperimentazione Soa” e si stavano prendendo tutto il tempo necessario per capire che cosa effettivamente funzionasse e quali potessero essere i reali benefici derivanti da questo approccio. Inoltre, con alcune piccole eccezioni, le Soa venivano adottate a livello di divisione e per applicazioni che non si potevano realmente considerare mission-critical.
Comunque, come tutte le evoluzioni informatiche che le hanno precedute, anche le Soa continuano a maturare e a migliorare. Dai loro primi esperimenti le aziende hanno compreso che le Soa possono effettivamente portare nuova linfa ai sistemi e alle applicazioni esistenti, generando nel contempo nuovo valore. Le Soa rendono più facile il riutilizzo dei servizi, contribuendo a ridurre i costi e ad incrementare produttività, efficienza e agilità.
Ma per avvalersi realmente dei benefici derivanti dall’adozione di architetture Service Oriented, le aziende dovrebbero abbandonare l’approccio del progetto ad hoc che ha caratterizzato la maggior parte delle implementazioni iniziali in ottica Soa e far proprio un nuovo atteggiamento che renda possibile l’introduzione di nuove dinamiche, tali da indurre un mutamento positivo nell’organizzazione e nei processi.
Senza un cambiamento verso questo approccio mentale, in grado di incrementare le strutture coinvolte nell’implementazione di una Soa, le aziende corrono il rischio reale di ritrovarsi in una situazione di “Soa Anarchy”. Purtroppo questo scenario non è così inverosimile: le prime sperimentazioni Soa hanno creato un ambiente ideale per la proliferazione di architetture Service-Oriented isolate all’interno delle diverse aree operative e Business Unit.
Con la propagazione incontrollata di tali architetture all’interno dell’intera azienda, ci si trova di fronte alla concreta possibilità che i servizi siano stati duplicati in varie divisioni, perdendo di fatto uno dei principali vantaggi che le Soa consentono: il riutilizzo dei servizi. Inoltre, questo approccio dispersivo nell’implementazione delle Soa crea le premesse per una gestione inefficace dei servizi esistenti e delle risorse It che li supportano, oltre che per l’instaurazione di una situazione di sovrapposizione delle responsabilità (o peggio ancora, di mancanza di responsabilità) dei servizi all’interno dei sistemi informativi.
Per consentire il passaggio della Soa alla fase successiva è necessario uno strumento che non si limiti soltanto a migliorarne il livello di maturità, ma che contribuisca anche ad incrementarne l’efficacia e che sia in grado di governare lo sviluppo delle Soa tramite la definizione di aspetti organizzativi, processi e ruoli necessari per indirizzare e gestire le nuove dinamiche legate alle Soa.
“Governance” è una parola che suona bene, soprattutto se per un attimo si riflette sulla possibile alternativa, ma il percorso per arrivare a governare le Soa non è sempre chiaro. Qualcuno potrebbe affermare che “basta semplicemente mettere tutto in un Registry e si è pronti per partire”. Purtroppo “semplicemente” è la parola chiave e chiunque abbia una qualche esperienza con l’implementazione di architetture Service Oriented, vi dirà che “semplicemente” è un termine che può essere utilizzato molto raramente per descrivere questo processo.
Questo non significa che le funzionalità di un Registry non siano importanti: sapere quali sono i servizi disponibili in un’azienda e come accedervi è il primo passo necessario per tenere sotto controllo la “Soa Anarchy”. Ma resta ancora molto da fare per mettere in pratica concretamente una buona “Soa Governance” e lo strumento che deve essere considerato come il seme di tale realizzazione è il Repository.
Mentre il Registry è sostanzialmente comparabile ad un indice dove sono registrati e localizzati i servizi, il Repository è un catalogo completo dei servizi disponibili all’interno dell’organizzazione che non consente soltanto di capire cosa fanno e dove sono, ma aiuta le aziende ad assicurare che questi possano essere utilizzati in maniera appropriata. Attraverso la raccolta e l’archiviazione di tutte le informazioni associate ai sevizi (non solo relative all’interfaccia, ma anche alle policy, alle specifiche di implementazione, alle interdipendenze, etc.) e mediante la disponibilità di diverse “viste” dei servizi basate sui ruoli e sulle responsabilità interne all’organizzazione, una strategia efficace basata sul Repository promuove un riutilizzo ottimale dei servizi e migliora il controllo sul deployment e sull’impiego degli stessi, quale parte di una piú ampia strategia Soa.
Ciò che rende unico un Repository Soa è il fatto di coinvolgere tutti gli aspetti del ciclo di vita di un’architettura Service Oriented, dalla progettazione e lo sviluppo fino al deployment e alla gestione, mettendo a disposizione dell’utente, in maniera efficiente, quanto necessario per realizzare una rete di servizi distribuita nell’ottica di una Soa matura.
Ad esempio, un Repository è in grado di raccogliere i contratti di servizio, i dettagli implementativi, le policy legate all’impiego del servizio ed altre informazioni più generali, come l’elenco degli utenti autorizzati ad utilizzare ogni servizio. In sostanza, il Repository consente di contenere tutte le informazioni necessarie per un nuovo deployment dell’intera rete di servizi. Con questo tipo di potenzialità diventa molto più facile controllare quali servizi devono essere rilasciati e verificare costantemente mediante il Repository se la propria architettura Service-Oriented è in linea con quanto pianificato.
Il mondo delle Soa sta maturando e si sta evolvendo, conseguentemente anche le aziende devono progredire se vogliono implementare con successo un’architettura Service Oriented: mentre prima era sufficiente un Esb per iniziare, adesso il buon esito della realizzazione di una Soa richiede molto di più. Le aziende devono iniziare a pensare alle strategie di “Soa Governance” e alle tecnologie che possono davvero aiutarle a raggiungere i propri obiettivi: in quest’ottica la scelta di un Repository adeguato rende possibile l’individuazione, il governo e la gestione del ciclo di vita dei servizi attraverso tutta l’organizzazione.
Con queste potenzialità a disposizione, le aziende sono in grado di riutilizzare i servizi esistenti, di comprendere meglio le relazioni tra i diversi servizi e di ridistribuirli nuovamente man mano che la Soa evolve, ottenendo in questo modo agilità e flessibilità per il proprio business, a ragione ritenuti i principali benefici derivanti dall’implementazione di un’architettura Service Oriented.
(*)Sales Solution Architect, Iona Technologies
