La Soa è l’opportunità che il mondo It ha per facilitare il cambiamento e diventare strumento di soluzioni innovative. Ma come sempre accade, le novità trovano fanatici e detrattori in egual misura. Ecco un vademecum utile sia per consigliare i primi sia per chetare i secondi.
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.
Lo sappiamo: in un mondo in continuo cambiamento è inevitabile cercare strade nuove. Il mondo dell’informatica si distingue in questa ricerca, non fosse altro che per l’immagine d’innovazione e tecnologia avanzata che si è conquistato. Sappiamo anche che gli “utenti” lamentano spesso che le loro richieste sono soddisfatte in ritardo e che le soluzioni costano troppo. Quante volte abbiamo sentito dire che l’lt è un costo ed un freno al business?
Ecco che per superare queste difficoltà si è fatto strada il paradigma della Service Oriented Architecture. Oggi la Soa rappresenta l’opportunità per il mondo It di facilitare il cambiamento e diventare strumento per soluzioni innovative.
Come sempre accade, le novità trovano entusiasti sostenitori ed irriducibili detrattori. La Soa non si sottrae a questa regola ma, dal momento che chi l’ha già ampiamente adottata e coloro i quali la stanno provando riportano grandi vantaggi, pensiamo che sia necessario fare qualche riflessione annotando le cinque “trappole” che più spesso abbiamo visto lungo il percorso e che possono creare ostacoli se non addirittura condurre all’insuccesso.
Prima trappola: Soa è semplicemente una scelta tecnologica
Il principale vantaggio dell’adozione della Soa è rappresentato da una maggiore flessibilità e capacità di adattamento della “macchina It” a nuove esigenze di business. È perciò necessario che le funzioni aziendali utenti dell’It partecipino al cambiamento. La Soa metterà nelle loro mani, attraverso gli strumenti di process modeling, la capacità di ridisegnare i processi aziendali e le modalità di esecuzione degli stessi. La Soa coinvolge tutta l’azienda a partire dal top management perché rappresenta un modo nuovo di lavorare e di collegare gli utenti agli strumenti che utilizzano quotidianamente. Occorre ottenere il consenso e il reale sostegno per un cambiamento anche nella cultura aziendale verso un modello di maggiore condivisione delle risorse ed un riallineamento delle responsabilità.
Seconda trappola: Soa è un modo per ridurre i costi
Un effetto sui costi It, soprattutto di sviluppo e manutenzione del software, si potrà vedere quando il parco dei servizi Soa avrà una consistenza numerica e sarà costituito da elementi realmente efficaci per i processi aziendali. Questo richiederà tempo ed investimenti per la creazione di competenze e per predisporre le infrastrutture; da qui la necessità del supporto di tutta l’azienda.
Per una corretta valutazione non si devono però considerare solamente i costi dell’It ma più in generale i costi del cambiamento a fronte di nuove esigenze. È nella riduzione dei costi aziendali complessivi che si otterranno i maggiori benefici. La possibilità per gli utenti di agire direttamente sulle leve dei supporti It permetterà di avvicinarsi agli obiettivi più rapidamente, con minori ricicli e con meno errori utilizzando componenti già collaudati. Saranno quindi le aziende più dinamiche che operano in mercati altrettanto dinamici ad ottenere i maggiori vantaggi.
Terza trappola: tutte le applicazioni devono essere Soa
Certamente le applicazioni possono essere progettate per utilizzare al meglio le tecnologie che accompagnano la Soa, ma questo non significa che si debba riscrivere o modificare tutto il parco applicativo. Non significa neanche che tutte le applicazioni devono rispondere alle regole della Soa o che sono adatte ad essere trasformate in ottica Soa. Il percorso corretto passa per l’analisi di nuovi requisiti di business e delle funzionalità fornite dal parco applicativo esistente, la valutazione della qualità del codice, del suo valore, con lo scopo di identificare gli elementi candidati ad essere servizi utilizzabili a supporto di più processi. Solo al termine di queste attività si potranno avere elementi sufficienti per una decisione ragionata.
Quarta trappola: Soa non richiede di riconsiderare l’Infrastruttura
In termini applicativi la Soa permette di esporre e comporre i servizi in modo flessibile e dinamico, nello stesso modo l’infrastruttura It deve essere in grado di mettere in comunicazione tali servizi secondo schemi non predefiniti e fornire un ambiente in grado di rispettare i livelli di servizio richiesti a fronte di ambienti altamente flessibili e dinamici. Inoltre l’infrastruttura deve anche essere in grado di garantire la sicurezza negli accessi ai servizi in funzione dei diversi profili degli utenti in conformità a regole e processi definiti a livello aziendale e quindi trasparenti alle applicazioni e servizi. Pertanto, per ottenere un utilizzo ottimale di tutte le risorse, il modello Service Oriented si deve applicare anche all’insieme di hardware, software, organizzazione e processi che costituiscono l’Infrastruttura dell’It aziendale.
Pensiamo alla governance in generale, che deve essere rivista ed ancor più rigorosamente adottata per governare un mondo di servizi che devono essere condivisi, pur rimanendo sotto il controllo di unità diverse.
Quinta trappola: Soa è una moda e non cambierà l’It
L’It è già cambiato: la Soa ha portato notevoli cambiamenti nelle scelte d’investimento dei produttori ed i prodotti a supporto della Soa sono già sul mercato. Esiste quindi uno stimolo generale di tutta l’industria It verso la Soa. Chi sostiene che tutto questo può essere solo una moda deve però essere cauto nell’attendere. Il percorso verso la Soa non può essere avviato in tempi brevi ed i risultati si vedono con una certa gradualità. Si tratta di trasformazioni dell’azienda nei suoi modelli di business e organizzativi, nell’acquisizione di nuove competenze e nella definizione di un percorso di adozione graduale che permetta di assimilarne le differenze rispetto ai paradigmi passati per sfruttarne al massimo i benefici. Tanto l’accelerazione nell’adozione senza aver definito un cammino solido, quanto un atteggiamento di astensione, sostenendo che si tratti di una moda, non permettono all’azienda di ottenere i vantaggi legati ad un modello di business flessibile e aperto, in termini It.
In sintesi: il passaggio al modello Service Oriented comporta cambi di tecnologia ma troviamo la vera novità nella sempre più stretta vicinanza del business e delle sue esigenze con il mondo It e le sue complessità. Un cambiamento che toccherà le regole ed i modelli comportamentali perché si dovrà tener conto sempre di più del fatto che un servizio sviluppato per un determinato contesto potrà essere utilizzato da altre funzioni in contesti anche molto diversi e spesso non prevedibili.
(*) Ibm Executive It Architect
