La strada che un Cio deve seguire è quella di partire da una precisa analisi dei requisiti di business per poi arrivare a una solida architettura, secondo le specifiche orientate ai servizi
Da un po’ di tempo si sta parlando sempre più di Service oriented architecture (SOA), grazie anche alla maggiore diffusione dei Web service, che proprio in ambito SOA giocano un ruolo da protagonisti. Pur avendo caratteristiche di base molto interessanti, «la SOA non è però la panacea contro tutti i mali – ci ha spiegato Paolo Malinverno, vice presidente di Gartner Research – e non tutte le applicazione possono essere sviluppate secondo il paradigma della Service oriented architecture. Una SOA può, per esempio, essere adatta quando esiste un’interazione tra applicazioni che richiede una certa risposta, ma non è indicata in presenza di un evento o di una serie di transazioni che avvengono dopo un evento. In questo caso, consiglio di mischiare servizi ed eventi perché sono questi due elementi la base per descrivere l’attività di un’azienda».
La SOA rende però più facile l’integrazione del dipartimento It e può essere particolarmente adatta in ambienti eterogenei. Gli sviluppatori non devono spendere un tempo eccessivo per scrivere le nuove linee del codice necessarie a collegare le applicazioni. Invece, possono usare i protocolli standard, quali i Web service. E gran parte dei pezzi del codice di una SOA è riutilizzabile, riducendo così i costi di sviluppo.
«Occorre però sapere che i Web service non sono la SOA – ha aggiunto Malinverno – ma una serie di standard più maturi. La SOA è un’architettura, un modo per realizzare applicazioni avvalendosi dei Web service e questi ultimi sono una maniera per implementare una SOA». In questo senso, non è certo la via migliore quella che intende implementare in modo affidabile ed efficace una SOA, focalizzandosi solo sullo sviluppo di Web service. La strada da seguire si deve, invece, basare su un tracciato metodologico completo e strutturato: una precisa analisi dei requisiti di business deve portare a una solida architettura, che possa essere messa in opera secondo le specifiche SOA. Fattori essenziali sono una facile manutenzione e un elevato grado di flessibilità, che consenta un veloce adeguamento a eventuali evoluzioni. Il beneficio che può comportare una SOA è la nascita di un dialogo migliore fra il Cio e il dipartimento It, riuscendo a far andare d’accordo chi ha una visione spiccatamente tecnica con chi ha una visione più orientata al business.
Organizzare il dipartimento It
«Il metodo più diffuso per realizzare una SOA efficiente e soprattutto affidabile – ha precisato Malinverno – è quello di prendere un pezzo di infrastruttura e di applicarla, oppure di crearla partendo dai servizi di più basso livello, sviluppandola gradualmente. È però frequente anche un approccio top down: il Cio ha sentito parlare bene di questo strumento e chiede al responsabile It di realizzare una SOA, pur non sapendo bene di cosa si tratti».
Per implementare una SOA bisogna anzitutto organizzare il dipartimento It in modo particolare perché tutte le Service oriented architecure integrano componenti preesistenti. La SOA prevede un approccio graduale: se si vuole farla crescere bisogna governarla in modo molto preciso altrimenti degenera. Le decisioni devono essere disciplinate da processi precisi: è bene stabilire quali servizi realizzare e con quali priorità, stabilendo sin da subito chi si occuperà della manutenzione.
È poi opportuno partire con un progetto pilota, che miri al consolidamento del supporto It al business e verificare che tale progetto abbia un’efficacia misurabile. «Si deve evitare una proliferazione incontrollata dei servizi It da sviluppare – ha sottolineato Malinverno -. Bisogna mettere a punto un meccanismo di governo che massimizzi il riutilizzo di servizi esposti, aspetto questo che rappresenta uno dei maggiori vantaggi della SOA nella semplificazione dell’It».
Il vice presidente di Gartner ha poi ricordato che è bene perseguire una strategia di lungo termine, che abbia per obiettivi l’agilità, la semplificazione degli asset informativi dell’impresa e la corrispondente diminuzione dei costi di manutenzione.
Secondo Malinverno, inoltre, occorre ricordarsi che la SOA non è una meta, ma un percorso e quindi va pianificata per passi successivi e realizzazioni incrementali, ma senza perdere di vista i ritorni previsti nel breve e medio termine. È però bene sapere che «se si inizia una SOA non la si finisce mai. I pionieri di questa architettura hanno iniziato sette od otto anni fa e oggi hanno una copertura dell’infrastruttura It del 70-80%, il rimanente non è detto convenga metterlo in SOA. Nostante ciò, le aziende che hanno investito nella SOA sostengono che funzioni e che i costi di manutenzione stiano scendendo».
