Qualche parere che consente di andare oltre i sensazionalismi e di fare il punto sull’utilizzo di queste tecnologie.
Un ficcante dibattito a distanza fra analisti consente di scrivere qualche parola su cosa siano oggi Ajax e le Soa (Service Oriented Architecture), per le aziende e per l’industria tecnologica.
Cominciamo da Ajax. Secondo l’analista Interarbor Solutions ci sono due stili ricompresi dalla definizione. Il primo è quello meramente acronimico, che individua il comparto tecnologico della materia, ossia Asynchronous JavaScript and Xml. Un secondo, più esteso, individua un’ampia gamma di Rich Internet Application. La distinzione non è solo retorica fra termine e uso che se ne fa.
Secondo l’analista Ajax sta prosperando, e ancora di più lo sta facendo l’uso generico della parola, al punto tale che la si associa a più declinazioni tecnologiche, che rischiano anche di portare fuori strada.
La sintesi fatta dal direttore delle tecnologie Soa di webMethods, Miko Matsumura, è illuminante. Lui parla spesso di “Soa dal volto umano”, per dire che nel concetto c’è molta cibernetica, cioè una via di mezzo fra l’uomo e la macchina. Ajax, allora, è una via per gettare un ponte fra la parte umana e quella tecnologica dell’architettura.
L’esempio di una soluzione Ajax sotto gli occhi di tutti, quello di Google Maps, è calzante in merito.
Allora è vero, come nota Interarbor Solutions, che non importa tanto il beneficio che promette una tecnologia, ma il modo con cui lo si ottiene.
E qui entrano in gioco gli sviluppatori, che secondo un altro analista, onStrategies, sono l’anello determinante della catena che deve umanizzare la tecnologia. Il fatto, sostiene, che con Ajax gli sviluppatori abbiano molte possibilità per realizzare qualcosa di vicino alle esigenze dell’utenza è indiscusso. Ma, sempre con Ajax, hanno in mano qualcosa che si va via via allontandando dal concetto di standardizzazione.
L’analista fa riferimento alle centinaia di strumenti e alle decine di framework per Ajax, sottolineando che questa condizione se da un lato offre agilità, dall’altro toglie dal campo il concetto del riutilizzo degli oggetti (e ciò fa anche capire il perché i vendor storici del campo Java si siano buttati nel business della standardizzazione di Ajax, tramite OpenAjax).
Sintetizzando: sul termine c’è tanto (giustificato) sensazionalismo, non è importante come lo si pronuncia, ma quello che si fa a livello di utente, e c’è il rischio che si crei una confusione creativa.
E il tema del riutilizzo degli oggetti evoca il tema delle Soa, che stando a Gartner hanno già oltrepassato il momento della sensazione, della moda, e si stanno confrontando con l’aspetto pratico della faccenda.
Il fatto è che le aziende ora stanno usando le Soa in produzione (o almeno dovrebbe essere il momento per farlo). Le applicazioni Soa sono realizzate da molte componenti “semovibili” e questo le rende più complesse di quelle, monolitiche, tradizionali.
Le società che utilizzano le Soa hanno a che fare con aspetti di governance, test, configurazione, gestione metadati, controllo dei livelli di servizio, sicurezza, interoperabilità. Problemi non nuovi per le applicazioni largamente distribuite.
Il vantaggio apportato dalle Soa è la riduzione dei tempi per spalmare un cambiamento su tutta l’infrastruttura, contrariamente a quanto avviene nella fase di introduzione di un’applicazione Soa, generalmente più lunga di una tradizionale applicazione distribuita.
Ma dopo le cose vanno meglio e i tempi di deployment si accorciano.
Verso la metà dell’anno Gartner ha chiesto a oltre un centinaio d’aziende di valutare gli aspetti positivi e negativi dei loro progetti, per poter arrivare a concludere che le il prossimo anno un progetto su due di applicazioni business critical sarà fatto in Soa e che nel 2010 la percentuale sarà dell’80%.
I dati raccolti hanno pure riportato che le Soa non stanno producendo risparmi consistenti, anche se stanno avendo un impatto positivo sull’agilità di movimento dell’azienda. Inoltre gli investimenti in Soa, Web service e Web 2.0, rispetto ai 12 mesi precedenti sono cresciuti di quasi il 60%.
La valutazione dei benefici indotti spinge un altro analista, Redmonk, a sottolineare che le Soa devono essere uno stimolo di business, ma devono anche essere pilotate e non subite. Il problema è che troppo spesso ci si sofferma sull’aspetto “service oriented” e si trascura quello dell’architettura. Invece, Redmonk sostiene che è proprio il tema architetturale e disciplinare a rivelare se gli effetti apportati sono da iscriversi alla voce “valore”.
Per chiudere definitivamente il capitolo “sensazionalismo” riguardo le Soa, l’analista ZapThink fa notare che esistono degli indicatori che rendono la cosa indiscutibile: il fatto che sul versante dell’offerta le proposte sono ormai consolidate, l’aumento del numero e della portata dei contratti in materia di progetti Soa negli ultimi 12-18 mesi, il buon livello di specializzazione raggiunto dalle implementazioni degli utenti, il graduale spostamento degli effetti delle Soa dall’area della produzione a quella del rapporto con i clienti (consumo), e, non ultimo, l’aumento della richiesta di figure professionali adeguate (enterprise e software architect).
