• Commenti

Dieci cause di fallimento per i progetti Soa

• Data 10-12-2008
• di Roberto Bonino

Dal confronto di alcuni esperti emergono le ragioni dei molti stop a progetti Soa già avviati, ma anche i consigli perché si possa raggiungere l’obiettivo prefissato.

Per quali ragioni diverse iniziative Soa conducono a progetti incompleti o bloccati prima di compiersi? La cattiva comprensione dei soggetti coinvolti sembra essere alla radice di questi fallimenti. In sintesi, è quello che emerge dall’analisi compiuta da alcuni esperti di Burton Group, Zapthink e Cio.com, che hanno elaborato interviste condotte in proprio e contributi apparsi su diversi blog, per mettere a punto un decalogo delle cause che portano al blocco di progetti legati alle archietture orientate ai servizi. Vediamoli uno per uno.

1) Non si riesce a far comprendere il valore delle Soa alle varie figure professionali
I progetti consacrano grandi quantità di tempo, risorse umane e denaro per mettere a punto la miglior architettura possibile. Buona cosa, ma questo si fa spesso a danno di un corretto confronto con le figure professionali presenti in azienda. Così, quando l’architettura è pronta, nessuno se ne serve, perché nessuno ne comprende l’interesse. Occorre, dunque, avviare un progetto mettendo in cima a tutto il bisogno di rispondere a problematiche che vengono dai soggetti che appartengono all’azienda. Meglio se si usa il grimaldello della “killer app”, cioè dell’applicazione in grado di risolvere ogni problema. Il Bpm (Business process management) è certamente la “killer app” per le Soa.

2) Viene sottostimato l’impatto dei cambiamenti organizzativi
Le Soa implicano spesso vasti cambiamenti nell’organizzazione delle imprese, soprattutto laddove non esistono architetture d’impresa consolidate. Questo genera incertezza, paura dell’ignoto e, dunque, una resistenza al cambiamento. A ogni livello aziendale, ciascuno ha le proprie inquietudini e questo deve essere messo in conto, arrivando ad assoldare un esperto di ch’ange management.

3) Non si ottiene il corretto sostegno dal management
È molto improbabile che un’iniziativa Soa riesca se non è sponsorizzata da qualche “pezzo grosso” della gerarchia aziendale. Di fatto, anche le Soa si possono tradurre in una molteplicità di progetti. Non esistono “piccole” Soa. Un’iniziativa in tal senso coinvolge molti (o tutti) dipartimenti aziendali, visto che si tratta di rompere i silos. Occorre, dunque, poter contare sul sostegno di qualcuno capace di far superare gli ostacoli.

4) Si prova a implementare una Soa con pochi investimenti
I progetti Soa costano cari e occorre esserne coscienti. Oltre agli investimenti tecnologici nel middleware, occorre prevedere gli strumenti di governance, la formazione, la consulenza e altro. Alcune imprese provano a fare in proprio per limitare i costi, ma, a meno che non s abbiano in casa veri esperti in Soa, queste scelte conducono al disastro.

5) Si manca delle competenze necessarie
Questo punto è un corollario del precedente. Spesso, per problemi di risorse economiche, le aziende vogliono avviare progetti Soa con persone che non hanno l’esperienza necessaria. Invece, occorrono esperti, che si tratti di architetti, professionisti dei tool o della modellizzazione dei processi. Occorre chiedere all’azienda di poter stanziare fondi per la formazione sia degli informatici che di coloro ai quali i tool di Bpm sono destinati.

6) Si gestiscono male i progetti
Il miglior progetto Soa non arriverà in fondo se la gestione è carente. Come per tutti i progetti, occorre saper gestire i rischi, far sì che tutti seguano i piani e così via. A meno che tutto non sia su scala molto grande. Il miglior project manager presente in azienda dovrà seguire lo sviluppo Soa e dovrà avere qualche competenza tecnica, per capire le Soa a livello concettuale.

7) Si vede la Soa come un progetto e non come un’architettura
Molte aziende, ingenuamente, credono che la Soa sia un progetto come un altro e coinvolgono vari soggetti, fra esperti di Esb, interfacce utente, modellazione dei processi, reti, architetture dei dati e così via. Invece di perdere tempo in tante riunioni, meglio riunire i soggetti coinvolti in un open space e favorire il lavoro collaborativi.

8) Si sottovaluta la complessità della Soa
Dal punto di vista dell’utente, Soa e Bpm sono di grande semplicità: devono apparire come applicazioni integrate di centinaia di software e servizi applicativi. Visto dall’interno, questo rappresenta un esercizio pericoloso, anche per gli sviluppatori agguerriti. Occorre prevedere che numerosi ostacoli si frappongano sul cammino, che si tratti di prodotti non maturi o dell’integrazione con l’esistente. In tutti i casi, occorre fissare obiettivi realistici, non dimenticare mai l’infrastruttura di sicurezza per ciascun sottoprogetto e procedere per iterazioni, allo scopo di evidenziare il valore per le singole aree aziendali.

9) Non si applica una governance Soa
Che si chiami gestione o governance, si tratta di implementare una politica dei gestione globale in azienda. Tanto nella fase di progettazione (per far sì che gli sviluppi rispettino i principi architetturali, soprattutto) che poi nell’implementazione, per contabilizzare i servizi consumati, controllare le performance e così via. Meglio costruire un’equipe dedicata, con tool specifici, per rafforzarsi nel tempo rispetto ad altre strutture.

10) Si consente che i vendor guidino l’architettura
Occorre stare in guardia dalla cosiddetta Vda (Vendor driven architecture). L’obiettivo di ogni fornitore è di vendere quante più cose possibili. Ma l’obiettivo dell’aziende è arrivare a un’implementazione di successo e procurare all’impresa il massimo di benefici con il minimo di spese. Dunque, c’è un conflitto di interessi. I vendor tendono ad argomentare che l’acquisto della loro piattaforma completa può ridurre i costi di integrazione, ma il vantaggio delle Soa è di poter combinare elementi diversi e aggregarli. È dunque consigliabile dotarsi dall’inizio dei giusti esperti, prima di contattare i fornitori, chiedendo sempre a questi ultimi pilot o test preventivi a ogni ordine. Certamente, è una decisione difficile da prendere, visto che i progetti Soa sono comunque costosi e richiedono anni di investimento.