Un approccio federativo alle iniziative Soa

I consigli di Gartner sull’adozione delle Service oriented architecture, viste come un modo pratico per dare flessibilità ai processi aziendali

Gartner sta osservando il fenomeno delle Soa (Architetture orientate ai servizi) da oltre 10 anni, in quanto ha pubblicato un primo articolo sul tema nell’aprile 1996, per cui ne ha seguito fin dall’inizio l’evoluzione.

«In effetti, negli ultimi anni, abbiamo avuto modo di parlare con molti clienti delle loro esperienze nell’ambito delle Soa, per cui abbiamo affiancato molte imprese nei vari stadi di adozione – osserva Massimo Pezzini, vice president e distinguished analyst di Gartner, durante un incontro sul tema -. Abbiamo, così, collezionato una serie di best practice, cioè cose che bisogna fare e cose da evitare per avere successo con un’iniziativa Soa. Inizierò con una riflessione: quello che stiamo vedendo, soprattutto in grandi organizzazioni, magari di natura multinazionale, distribuite in varie parti del mondo, è che nascono molte iniziative Soa, che operano in parallelo senza collaborare, e questo non è consigliabile dal punto di vista architetturale e organizzativo, ma è un fatto che sta succedendo. Un altro aspetto è che in realtà va riconosciuto che portare avanti un’iniziativa Soa a livello dell’intera organizzazione risulta troppo complesso e difficile: questo non tanto per motivi tecnologici quanto organizzativi, per cui il modello a cui stiamo giungendo, sulla base di queste analisi, è che l’approccio giusto per affrontare un’inizia Soa a livello aziendale è quello federativo. Ovvero, è consigliabile spezzare l’organizzazione in tanti piccoli domini Soa, tra di loro indipendenti, che poi vengono federati, cioè reintegrati sia dal punto di vista tecnologico che da quello organizzativo».

Pezzini, dunque, ha strutturato il suo intervento in tre blocchi: nella prima parte ha affrontato il tema del business e dei technical driver, cioè le motivazioni per l’adozione di Soa o per la non adozione Soa, in quanto «si può vivere anche senza, visto che Soa non è nient’altro che una serie di strumenti e di tecnologie che si applicano in certi casi e non in altri – chiarisce l’analista -. È consigliabile non adottare l’approccio “visto che lo fanno tutti, devo farlo anch’io” ed è sempre bene, prima di adottare un progetto Soa, chiedersi se si sta facendo la scelta giusta».

La seconda parte riguarda l’adozione di un modello che dovrebbe aiutare ad affrontare l’introduzione della Soa attraverso degli step incrementali, in quanto «la cosa bella della Soa è che non è come l’implementazione di un Erp, che costringe l’azienda a fermarsi e a lavorare di notte, in quanto può essere introdotta in azienda in modo incrementale: si parte da un primo progetto, si fa esperienza e poi si procede con un altro».

Nella parte finale, infine, vengono affrontati alcuni problemi tipici che si incontrano in un progetto Soa e quindi quali sono le cose da fare.

Partendo dai driver delle Soa, Pezzini afferma che sono, innanzitutto rappresentati dalle tematiche che ruotano attorno al Business process improvement o integration (cioè la necessità delle aziende di integrare meglio i processi per diventare più efficienti e risparmiare soldi), e all’aspetto della business agility o flexibility (che è la necessità di dotarsi di infrastrutture e di architetture applicative in grado di reagire più velocemente alla richiesta di cambiamento). «In quanto uomini dell’It, ci siamo sentiti dire tante volte dagli uomini del business che siamo un freno al cambiamento e all’innovazione, perché ci mettiamo troppo a realizzare le applicazioni. La Soa è un modo, forse non l’unico, ma sicuramente efficace, per introdurre maggior flessibilità e agilità all’interno dei processi aziendali. Va inoltre sottolineato che oggi ci sono tecnologie che si possono utilizzare a costo zero, come quelle open source».

Ma ci sono anche degli inibitori, «perché non è tutto rose e fiori nell’affrontare una Soa». Infatti, implica l’introduzione di un’infrastruttura tecnica molto più complessa e questo, naturalmente, comporta avere in azienda gli skill necessari. Ci sono, poi, problemi di governance e problemi con i vendor che, naturalmente, vedono nella Soa un modo per fare business.

Ma l’inibitore più importante è il fatto che l’It deve cambiare culturalmente, in quanto Soa implica di introdurre la cultura del riuso, della collaborazione e della condivisione anche dei costi, tutte cose che normalmente è difficile introdurre in un dipartimento It, specialmente di grandi dimensioni. Ma esiste anche un driver fondamentale che spingerà molti a imbarcarsi in progetti Soa, ed è la strategia dei fornitori di soluzioni applicative. «Se si guarda a player come Sap, Oracle, compresi i piccoli, tutti stanno portando su Soa le loro soluzioni – sottolinea l’analista -. Per cui se si è clienti di queste soluzioni, ci si troverà prima o poi trascinati verso questa direzione. Succederà esattamente quanto è successo circa 15 anni fa quando si passò al client server». Per lungo tempo, quindi, le aziende utenti si troveranno in una situazione ibrida: da una parte crescerà un patrimonio applicativo che nasce con un’ottica modulare di riutilizzo, e dall’altra continuerà a esistere una grossa parte di architettura attuale, per cui si dovrà affrontare il problema di far coesistere i due mondi.

Nei prossimi 5 anni il patrimonio applicativo di molte aziende sarà composto fondamentalmente da tre macro blocchi: alcune applicazioni che sono sviluppate in casa, tipicamente quelle che danno un vantaggio competitivo. Poi ci sarà una forte componente di software pacchettizzato, affiancato da una componente sempre più crescente di Software as a service, tipicamente i processi più commoditizzati, come ad esempio il payroll.

In questa situazione, la Soa è di aiuto, perché tramite i suoi paradigmi è possibile integrare tra di loro questi tre mondi e le aziende hanno interesse a integrarli per due motivi: prima perché devono automatizzare dei processi di business che andranno a pescare dati e informazioni dalle tre isole prima descritte, e poi perché potrebbero essere dei transitori. Certi processi di business, che oggi differenziano la società, un domani potrebbero diventare pacchettizzati o commoditizzati. Quindi la situazione è fluida, per cui la Soa aiuta a mantenere stabilità nei processi dallo stadio iniziale a quello finale.

Un’adozione graduale

Tipicamente, un programma Soa si sviluppa per stadi, che Gartner ha provato a modellizzare in quattro fasi: introduction, spreading, exploitation e plateau.

«Molto spesso l’ambizione iniziale è quella di avere un’architettura Soa che abbraccia l’intera azienda – spiega Pezzini – ma questo per ora è un’aspirazione. Oggi molte aziende si trovano nella prima fase: solitamente nel progetto si identifica un problema di business, come per esempio potrebbe essere lo sviluppo di un portale self service per i clienti. In molti casi non conviene nemmeno dire al business che si tratta di Soa. In questo progetto vengono messe in opera le tecnologie, gli aspetti organizzativi e, se ha successo, si costruiscono altri progetti adiacenti, per cui pian piano la Soa inizia a espandersi. Tipicamente, tutto questo avviene nell’ambito di una unità organizzativa, che ha un solo referente che è anche quello che paga il progetto. Il problema è quando si passa a situazioni con più unità di business coinvolte, divisioni e centri di costi. Qui la problematica diventa difficile, non tanto per ragioni tecnologiche quanto organizzative. Rispondere alla domanda “chi paga?” non sempre è facile. Se poi si riesce a superare con successo questa transizione, la strada è aperta. È provato che si può usare come piattaforma di lancio l’esperienza che si fa nel primo progetto e, se viene bene, si procede incrementalmente a introdurre meccanismi sempre più organizzativi di governance e sempre più infrastruttura tecnologica in modo da poter transitare da step a step».

Quindi è essenziale partire bene, costruire know how e skill anche di tipo organizzativo, per passare poi ai prossimi progetti e dopo un po’, quando si hanno già 4/5 progetti di successo, si può andare dall’amministratore delegato e dire che tutti hanno in comune l’approccio Soa, per cui visti i benefici ottenuti, anche in termini di risparmio, si può proporre di propagare i benefici ottenuti a livello dell’intera azienda. «Ma – allerta Pezzini – cercare di giustificare a livello di business un massiccio investimento senza avere la confidenza e soprattutto la possibilità che si è in grado di farlo, è per la maggior parte delle aziende proibitivo. A meno che l’imput avvenga dall’alto».

Gli errori da evitare

Come detto, il primo progetto è critico, perché se fallisce abbiamo chiuso con la Soa. Ci sono, quindi, alcune cose che bisogna tenere in conto. «Spesso, parlando con i clienti, la loro prima preoccupazione è chiedermi quali prodotti usare – afferma l’analista -. Noi rispondiamo “dipende” in quanto la Soa, che è un insieme di concetti, di rappresentazioni architetturali, deve essere calata nella realtà dell’azienda, che conosce bene chi guida il progetto. Quindi la scelta delle tecnologie, dei prodotti e via dicendo, deve basarsi su un insieme ragionevole di requisiti. Per esempio, bisogna chiedersi: “La mia Soa dovrà gestire 100.000 transazioni al giorno o 100 milioni? Quali sono gli aspetti di availability, dovrà essere 24×7 o avere requisiti più rilassati? Le applicazioni che gireranno sulla Soa sono critiche dal punto di vista dei tempi di risposta, o meno?” Per cui c’è tutta una serie di requisiti non funzionali da valutare che consentono di fare delle scelte ragionate. Un altro aspetto è quello della separazione delle responsabilità. Un errore che abbiamo visto fare spesso è di mischiare i due aspetti delle Soa, quello infrastrutturale e quello puramente applicativo. Questo è sbagliato, perché l’infrastruttura che costruiamo nel primo progetto non deve essere ottimizzata solo ed esclusivamente per quel progetto, ma deve rappresentare una piattaforma di lancio anche per quelli che seguiranno. Quindi, è bene organizzare un team che sia incaricato di definire l’infrastruttura, che naturalmente dovrà supportare i requisiti di quel primo progetto, ma dovrà essere pensata per più progetti, e un altro team che sarà responsabile dello sviluppo. Naturalmente i due team devono collaborare e il primo mattone concreto da sviluppare deve essere l’infrastruttura».

Una volta che l’azienda si è convinta che la Soa serve, il problema è capire come integrare le vecchie applicazioni custom in un contesto di architettura orientata ai servizi. Si possono seguire tre strade: buttare tutto quello che si è fatto in precedenza e rifarlo in chiave Soa, ma è costoso e rischioso. Un’altra strada è non fare niente, ma utilizzando tecnologie di application integration si ricavano delle interfacce all’interno delle applicazioni non Soa che in qualche modo le facciano somigliare alle Soa. Ci sono dei vantaggi nel perseguire questo tipo di approccio, in quanto si tratta di un intervento non invasivo e la vecchia applicazione continua a fare quello che faceva prima; anche il costo è abbastanza basso.

«Naturalmente ci sono anche dei problemi, – sottolinea Pezzini – perché questi software di application integration sono abbastanza difficili da manutenere e da gestire e si corre il rischio di fare disastri, in quanto utilizziamo dei meccanismi non propriamente disegnati per queste motivazioni. La via intermedia è quella di non cambiare l’applicazione ma di “sistemarla” in modo tale da reanderla almeno un pochino simile alla Soa. Non si cambia funzionalmente l’applicazione, ma la si reingegnerizza un po’, per esempio separando la parte di logica di presentazione da quella di business. In questo modo, rispetto alla precedente scelta, l’applicazione è più facile da manutenere, mentre gli aspetti negativi sono dati dal fatto che l’approccio è invasivo, e quindi pericoloso, e naturalmente i costi sono superiori. Molte aziende partono con un primo progetto, non vogliono rischiare, si accontentano di usare queste tecnologie in certi ambiti, ma poi, vedendo che funziona, prendono confidenza e procedono verso una graduale sostituzione. Quindi, una volta che si è componentizzata l’applicazione, si può pensare di rimuovere gradualmente alcune componenti, buttarle via e sostituirle con nuove che o vengono sviluppate ad hoc o magari vengono acquistate. Questo tragitto logico offre anche una chiave di lettura su come la Soa possa essere utilizzata in un contesto che oggi si chiama application modernization».

Gli aspetti tecnologici rilevanti

Man mano che l’azienda procede verso la realizzazione della Soa, si rende conto che ci sono numerosi problemi di natura tecnologica, perché nel creare un’infrastruttura tecnica sempre più complessa, deve integrare molti componenti: application server, middleware, integrazione di tool di Business process management, portali e chi più ne ha più ne metta. In questo processo, l’aspetto più critico è la “Soa backplane”, che rappresenta l’infrastruttura software e hardware che si deve mettere in piedi per consentire l’integrazione e l’interoperabilità dei vari livelli applicativi (Erp, Crm, portali, contact center e via dicendo). Questo è un fattore critico ed è l’aspetto tecnologico più importante.

Un altro aspetto rilevante di un’architettura Soa è il concetto di riutilizzo. Ovvero nella misura in cui si ha componentizzato le applicazioni, sarebbe l’ideale riuscire a riutilizzare questi componenti attraverso molte applicazioni: l’obiettivo è di accelerare il processo di delivery di nuove soluzioni e ridurre i costi di sviluppo tramite il concetto del riutilizzo dei servizi. In effetti, si riesce a realizzare dei mattoni applicativi che poi si riutilizzano all’interno di più progetti con benefici notevoli.

«Però per fare tutto questo – osserva Pezzini – bisogna mettersi d’accordo sui dati. Per esempio “Che cosa è un cliente?” Per l’Erp di Sap è una cosa e per Siebel un’altra, per cui i due dati sono incompatibili tra loro. Quindi è difficile pensare di poter riutilizzare servizi estratti da queste due applicazioni, se non ci si mette d’accordo su che cosa è un cliente. Per cui fondamentale per il successo di un’iniziativa Soa è che si definiscano quelli che noi chiamiamo gli oggetti di “business standardizzato”, che non sono nient’altro che la rappresentazione standardizzata di alcune entità critiche, all’interno delle aziende clienti, partner, fornitori e via dicendo, in modo da consentire una condivisione dei dati, indipendentemente dal modo con cui sono effettivamente rappresentati all’interno dell’applicazione. Quindi, una delle mosse da fare, è creare questi standard, cosa peraltro non facile, che però va fatta se vogliamo concretamente ottenere i benefici del riuso in un ambito Soa».

Le regole da darsi

Uno degli obiettivi della Soa è il riutilizzo dei componenti, ma come facciamo concretamente a raggiungerlo? «Ci sono alcune mosse fondamentali che dobbiamo mettere in pista – suggerisce l’analista – e che sono legate alla governance, al processo e non alla tecnologia. La prima: non si può lasciare agli sviluppatori la libertà di fare le cose come vogliono loro, di decidere quali servizi implementare e come. Ci deve essere un meccanismo che fa sì che ogni servizio che deve essere sviluppato venga validato, seguendo certe regole che vengono definite per favorire il riutilizzo. Quindi, sia il team di sviluppo che ha bisogno di quel servizio per una certa applicazione che deve essere realizzata per un certo progetto, sia potenziali futuri utenti/clienti di questo servizio, devono poter dire la loro. Questa è una fatica in più, perché significa fare riunioni, scambiarsi documenti, dedicarci tempo, per cui il tutto va fatto con cognizione di causa, però alla fine si rivela importante. Un altro punto è quello di tenere traccia di quanto si è già sviluppato in casa, si deve sapere quali sono i servizi fatti, quali quelli che sono in sviluppo, in test, si deve avere piena visibilità di quello che sta succedendo, per cui serve il catalogo dei servizi. E ancora, dal momento che le cose non succedono per magia, consiglio di guidare con l’approccio del “bastone e della carota”. Quindi si devono adottare dei meccanismi premianti, che incoraggino gli sviluppatori da un lato a costruire dei servizi riusabili e dall’altro a riutilizzare quello che effettivamente è stato sviluppato. Questo approccio, però, non è nella natura dei programmatori, che pensano di poter fare sempre meglio degli altri. E questo è l’aspetto culturale di cui parlavo all’inizio, che è uno dei più difficili da superare».

Conclusioni

«Anche nelle Soa chi comincia bene è a metà dell’opera – conclude il vice president -. Quindi il primo progetto deve essere utilizzato per creare le fondamenta della Soa e incominciare a mettere in pista dei meccanismi leggeri di governance. Secondo aspetto, misurare ciò che si fa, per capire se si sta andando nella giusta direzione, per poter avere degli argomenti a difesa di quanto si sta facendo e per poter identificare dei problemi prima che diventino cruciali. Per questo è importante definire delle metriche per misurare se quello che si sta facendo ha un senso. Per vincere la resistenza culturale bisogna imparare a usare un’astuta combinazione di “bastone e carota”. Infine, attenzione all’estremismo. La Soa non è una religione, in quanto è una serie di principi di buon senso e come tale vanno applicati con il proverbiale granello di sale. D’altra parte si sono visti dei progetti fallire semplicemente perché certi principi furono applicati con il paraocchi, si adottarono tecnologie di cui non c’era bisogno e architetture eccessivamente complesse».

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome