Ecco la “Service-Averse Architecture”

Ieri c’e’ stata l’apertura del SOA Executive Forum di InfoWorld, riferisce Elizabeth Book su EQbiz.
Nel Keynote Speech Anne Thomas Manes, VP and Research Director al Burton Group ha usato il nuovo termine coniato dalla Book il giorno precedente “Service-Averse Architecture”, dicendo che e’ quello che molte organizzazioni hanno oggi.
L’analisi di una IT malata, fatta davanti agli Executive della Corporate America che mediamente resistono a SOA, e’ spietata:

    -Il grande budget che le aziende impiegano nell'IT porta a progetti che non raggiungono gli obiettivi di tempi di rilascio, di costo e di servizio che ci si aspettava facessero.
    -Piu' dell'80 percento del budget viene speso in manutenzione ed "operations" ed i nuovi progetti pesano solo il 20 percento.
    -Nelle medio-grandi aziende ci sono piu' di 500 applicazioni, fanno 35 diverse attivita' ma forniscono solo 20 prestazioni importanti.
    -Ci sono centinaia di database che contengono pressoche' le stesse informazioni ma in modo incompatibile.
    -Si stanno spendendo troppi soldi nelle ancore delle barche. I sistemi legacy vi stanno tirando giu', e vi rimane troppo poco denaro per l'innovazione.

Il “SOA fitness program” richiede una nuova e differente prospettiva, dice:

1. State attenti alle vecchie abitudini. Non costruite nuove applicazioni se non avete bisogno di nuove “capability”.
2. Guardate alle applicazioni che gia’ avete. Identificate le ridondanze.
3. Ristrutturate la vostra applicazione in un servizio.
4. SOA e’ ristrutturare le funzionalita’ duplicate in un servizio. Le applicazioni quindi trasformano questa funzionalita’ in un servizio.

SOA non e’ integrazione, ha poi detto Anne:

1. SOA riguarda la progettazione, non la tecnologia. “La tecnologia da’ i tool. Sta a voi usarli in modo efficace.
2. SOA riguarda la riduzione delle ridondanze, o la distruzione dei silos applicativi.
3. L’integrazione aumenta la ridondanza, e rafforza i silos applicativi.
4. Progettare servizi condivisi e’ difficile e implica una mentalita’ diversa.
5. Ci vuole tempo per costruire servizi che siano ben utilizzabili.

E’ ironico che questi discorsi vengano fatti negli Stati Uniti, terra di informatici predisposti alla novita’, ricca di early adopter per qualsiasi prodotto sensato, Mecca della sperimentazione pragmatica e anche rischiosa.

Cosa avrebbe detto in Italia?

Cosa ne pensate?