Da un anno almeno su Blog e magazine spopolano le checklist che elencano le ragioni per cui una iniziativa SOA aziendale fallisce.
Finalmente si inizia a leggere qualche elenco sensato (non che quelle poche viste fino ad oggi non lo fossero, ma erano baricentrate sulle scelte tecnologiche, quindi vendor-oriented e parziali) su cosa puo’ facilitare una evoluzione aziendale SOA.
Una Architettura Service Oriented e’ praticamente sempre, innanzi tutto, una discontinuita’ filosofica con il passato: un passato fatto quasi sempre di gestioni application-oriented, solution-oriented, praticamente mai accompagnata da una attenzione degna di nota alla architettura sottostante tant’e’ che molto spesso non esiste nemmeno nelle aziende -italiane- una divisione che si occupa di architetture.
Se esiste non viene ascoltata piu’ di tanto, spesso viene confusa con il gruppo di architetti tecnologici, viene vista come il gruppo che rompe le scatole agli applicativi, scrive linee guida inutili, mette regole inutili, costose e che fanno perdere tempo a chi deve sfornare gli applicativi, che in realta’ sono quelli che fanno il vero lavoro.
Salvo poi, ovviamente, ritardare, stracostare, incartarsi nei problemi di integrazione e vivere preoccupati aspettando la prossima patch (di qualsiasi cosa ancorche’ ininfluente) che dovrebbere “risolvere quel maledetto problema che ci rende instabili, lenti, inspiegabili”.
Vi ci ritrovate?
David Linthicum scrive su Ittoolbox cinque ragioni perche’ le iniziative SOA hanno successo che condivido pienamente.

5 – L’azienda ha investito in formazione, fornendo alle persone che stanno costruendo l’architettura gli approcci e le tecnologie necessarie a risolvere i problemi

4 – L’azienda ha assunto le persone giuste, che tradotto nella realta’ italiana significa che ha messo sul progetto le persone giuste. La considerazione giustissima e’ che l’architettura e’ una attitudine e se una persone non la possiede possiamo anche tenerlo in aula sei mesi senza portare a casa alcun risultato. Dice che investire nello staff ha tanta importanza quanta investire nelle tecnologie ma i migliori ovviamente costano di piu’, anche se pagano alti dividendi. Ovviamente questa considerazione cozza pesantemente con la situazione italiana dove questo concetto, se mai c’e’ stato. si e’ perso per strada.

3 – L’azienda ha capito requisiti e business case. Nel senso di capire obiettivi e aspettative di ROI dell’iniziativa. Aspettative vaghe e ritorni miracolistici sono la maggior fonte di calo di tensione durante il progetto, situazione che porta direttamente al fallimento.

2 – L’evoluzione SOA (non il “progetto SOA” che non esiste) deve essere guidato dal commitment della direzione. Dice che non c’e’ nulla di peggiore di fare una innovazione pesante a livello ambientale – ed e’ proprio cio’ che SOA e’- senza la spinta del top della organizzazione, che deve avere la volonta’ politica di abbracciare il cambiamento. Da questo punto deriva un impegno che tutto lo staff tecnico deve avere: far capire alla direzione l’importanza di questa evoluzione e creare la volonta’ forte di andare in questa direzione.

1 – Una prova del concetto serve a validare la tecnologia. Un’auto non si racconta, si prova. Per SOA e’ la stessa cosa.

Da questo post sono partite una serie di domande e considerazioni che sintetizzo.

Se la natura di SOA e’ top-down come puo’ un individuo o un dipartimento creare un “momentum” per SOA e sfatare i miti negativi come “SOA e’ lenta perche’ una i web services” o “SOA e’ costosa” perche’ il ROI e’ a livello enterprise mentre i costi sono aggiuntivi sui progetti?
La risposta non e’ semplice ma alcune considerazioni si possono fare.
Alcuni ROI sono facilmente intuibili: vantaggi tecnici quali scalabilita’, predicibilita’, sicurezza granulare, monitorabilita’, interoperabilita’, per fermarsi ai piu’ immediati.
Ma il piu’ grosso e percepibile vantaggio immediato e’ che se alcuni elementi di una soluzione sono gia’ testati (servizi gia’ in produzione), non devono essere ritestati quando viene fatta una variazione, con vantaggi sia di costi, che di time to market, che di solidita’.
Questo, che viene portato come uno dei vantaggi principali, e’ chiaramente una ragione molto forte per l’adozione di un approccio SOA: purtroppo in Italia non e’ un argomento cosi’ forte in quanto si scontra con la consuetudine di non considerare i test come elemento cardine e imprescindibile dello sviluppo.
Bisognerebbe pero’ aprire un discorso molto ampio sulla qualita’ di quello che viene prodotto in Italia, cosa che presto faremo. Resta il fatto che se il test non compare come fase formale nel processo di sviluppo, questo argomento e’ debole perche’ il costo del test non e’ esplicito ma e’ affogato in quegli allungamenti e quei problemi di progetto che usualmente rendono insoddisfatti senza sapere precisamente il perche’.
Questa difficolta’ di “vendere all’interno SOA” si puo’ attenuare con un approccio bottom-up, cioe’ evolvendo a SOA la parte di applicativo che deve essere manutenuta per un processo business che va in modifica. Questo approccio aiuta certamente a non scontrarsi col Moloch del “commitment aziendale a SOA”, molto difficile da costruire, ma non elimina la necessita’ di avere i business-leaders “on board”.