Le SOA stanno entrando in quel periodo travagliato in cui si cerca una nuova identità, si impara ad abbandonare la fanciullezza e si imbocca la strada (ben più lunga) della maturità. Anche per le SOA il ciclo di vita sancisce tappe evolutive che marcano non solo l’evoluzione delle tecnologie ma al contempo la trasformazione culturale delle aziende, due direttrici di sviluppo che crescono e si arricchiscono beneficiando tra l’altro di quel fenomeno ben noto ad antropologi e psicologi conosciuto come serendipità, cioè quel meccanismo di scoperta casuale che permette di ri-orientare interessi e opportunità in modo del tutto inatteso.
La diversità, sorgente di serendipità
La serendipità è spesso il terreno fertile su cui cresce l’agilità. Qualche tempo fa leggevo “La complessità culturale” di Ulf Hannerz; nella presentazione (di Arnaldo Bagnasco) mi ha colpito proprio il richiamo a questo meccanismo di crescita, solo in apparenza casuale. Un concetto gravido di conseguenze, che Hannerz ha utilizzato per definire la città, un luogo in cui si può trovare una cosa mentre se ne cerca un’altra. Ci ho pensato su un po’ e ho provato ad applicare questa suggestiva metafora alle SOA. A ben pensarci rappresenta anche il principio del Cloud Computing, quella nuvola di servizi e di applicazioni che con i suoi nuclei di condensazione diventa foriera di soluzioni, chissà quanto casuali. Semplici suggestioni, frutto di una lettura affascinante? Forse no, forse l’itinerario suggerito, pur con qualche forzatura, può ben rappresentare lo scenario evolutivo delle nuove tecnologie. A quindici anni dalla comparsa dei primi progetti SOA, Gartner osserva come le architetture Service Oriented rappresentino solo un aspetto del complesso mondo del computing, particolarmente agili, capaci di plasmare l’organizzazione d’impresa. Costruire sul concetto di servizio significa assegnare valore strutturale alla specificità; i servizi sono “sorgenti di diversità” e le architetture SOA diventano strumenti di “organizzazione delle diversità”, in grado di intercettare quell’insieme di significati che costruisce la cultura aziendale. Le SOA di nuova generazione sono sempre più la concretizzazione di questo approccio alla specificità, tipico di un assetto federale e federato; sono capaci di rileggere il tradizionale paradigma dell’unità, che concepisce l’omogeneizzazione come il frutto della progressiva armonizzazione delle prassi e delle applicazioni, tra loro profondamente diverse. Con le nuove architetture Service Oriented l’unità è piuttosto il frutto di un atto di volontà che, come tale, “tiene insieme” processi e applicazioni diverse che l’equipe di sviluppo sceglie di mantenere insieme pur rispettando le specificità che le rendono diverse. Si tratta di un vero e proprio federalismo tecnologico e gestionale, che permette alle specificità di manifestarsi e di esprimersi in libertà.
Una federazione di applicazioni
Le applicazioni SOA rendono possibile una certa “promiscuità” di soluzioni, in cui logiche proprietarie del servizio e logiche imposte dai fornitori di servizio convivono e collaborano operativamente. La progressiva diffusione dei modelli SaaS, l’ingresso degli ADAM (gli Alternative Delivery Model) e la comparsa del Cloud Computing rappresentano sostanziali catalizzatori per la migrazione verso le SOA, oltre che essere agenti di cambiamento delle medesime logiche progettuali Service Oriented. Sta soprattutto agli sviluppatori software e agli architetti scegliere il giusto mix tra applicazioni SOA e non SOA, tra servizi o parti di essi concepiti con logica provider o con logica consumer. Come ha osservato Gartner al Symposium 2009 di Cannes, le applicazioni monolitiche, non distribuite, sono più semplici da sviluppare, implementare e manutenere rispetto alla applicazioni SOA; ciò non significa che le SOA portino necessariamente a rendere il contesto operativo più complesso di quanto non si immagini. La complessità è più spesso il frutto di una lettura non univoca, non chiara dei requisiti del business, un difetto di analisi, dunque, da cui dipendono percorsi progettuali e di crescita più confusi. Non c’è applicazione diffusa che non sia per sua natura eterogenea e complicata, ma è altrettanto vero che la maggior parte dei processi di business oggi è sempre meno riconducibile ad applicazioni lineari e monolitiche. Grazie alle SOA, questi processi possono essere implementati, monitorati, potenziati; non diventano più semplici ma sono certo più gestibili. Le SOA non semplificano, non sono agenti di semplificazione, sono piuttosto strumenti di razionalizzazione della diversità, proprio come gli approcci federali a cui si è fatto riferimento. Le SOA, piuttosto, permettono di gestire con maggior efficacia i processi articolati; consapevolezza a cui si è giunti, peraltro, solo negli ultimi anni, al crescere delle esperienze e dei progetti andati a buon fine. Non è più l’epoca delle facili illusioni, quelle dei primi anni Novanta; ora è il tempo della ragionevolezza e del realismo, che permette di valutare razionalmente limiti e benefici, costi e vantaggi economici.
La nuova generazione di SOA
La maggior parte delle prime implementazioni SOA, quelle di inizio anni Novanta, richiedeva interazioni di tipo RPC (Remote Procedure Call), uno stile peraltro ampiamente diffuso anche dal Web Services Description Language (WSDL). La recente evoluzione SOA, invece, ha fatto sì che questo modo di interagire fosse progressivamente abbandonato, sostituito da stile alternativi ritenuti più efficaci e versatili come i REST (Representational State Transfer) e le EDA (Event-Driven Architecture), soluzioni quest’ultime particolarmente flessibili. La scelta delle modalità di interazione ha una ricaduta diretta sul software dell’infrastruttura, a partire dai Web Services. Gli standard Web Services (WSDL in particolare) hanno dato un contributo sostanziale alla diffusione delle SOA; nel tempo però ne sono emersi i limiti, soprattutto là dove si è reso necessario implementare specifiche applicazioni. È bene tener presente che si tratta semplicemente di limiti, non di veri e propri ostacoli destinati a limitare la diffusione delle SOA come si paventò tempo fa. Le architetture Service Oriented, infatti, non dipendono direttamente dai Web Services tanto che le implementazioni più recenti neppure ne fanno ricorso diretto; a esse si aggiungono le SOA Event-Driven che richiedono espressamente tecnologia di tipo non-Web. Sempre più diffuse, invece, le SOA che ricorrono a un mix di middleware e protocolli di comunicazione, in grado di rispondere con agilità ai molteplici stili di interazione, in particolare in un contesto sempre più “real time”. Se questi aspetti prettamente tecnici coinvolgono direttamente architetti e sviluppatori, diverso è il coinvolgimento dell’utente finale, soprattutto quando l’utente è un uomo del business che non può sapere se l’applicazione che usa è stata sviluppata in un contesto Service Oriented o segue altri stili architetturali. È proprio la prossimità al tempo reale, la sostanziale riduzione dei tempi di interazione, a costituire uno dei parametri cardine per la valutazione business di una SOA. Le architetture SOA realizzano sistemi di continuous intelligence, che hanno un effetto diretto e tangibile sulla vita e sulle modalità di lavoro degli utenti finali, realizzando la cosiddetta situation awareness che permette di mappare l’evoluzione degli scenari di lavoro, associando meccanismi di allerta (attraverso SMS o e-mail) a fronte di situazioni valutate come critiche. A questo approccio si associano i meccanismi di revisione costante, da cui scaturisce il dinamismo intrinseco delle SOA che a sua volta permette di realizzare condizioni ottimali di gestione dei processi, in modo da promuovere la libertà creativa frutto delle interazioni generate.
