Office Business Applications: perche' Microsoft ci crede!! (1 parte)

Questo è il primo di una serie di post architetturali per raccontare un po' il punto di vista Microsoft nel variegato mondo delle architetture applicative. Qui trovate la mia idea per questa serie ... tenetela d'occhio perchè molti titoli sono ancora da definire :-)

Da più di un anno Microsoft sta ponendo molta enfasi sul concetto di OBA , ovvero : Office Business Applications . In questi 3 post cerchiamo di capire quali motivazioni architetturali hanno spinto Microsoft a definire un nuovo acronimo e, soprattutto, quali vantaggi possono ottenere le aziende adottando questo modello di sviluppo delle applicazioni.
Per capire OBA dobbiamo partire dal concetto di composite application, ma, procediamo a piccoli passi...

Da SOA alle Composite-Applications

Cominciamo con una semplice domanda: “perchè il mercato e le aziende guardano da tempo SOA (Service Oriented Architecture) con tanto interesse ”?
Risposta (non proprio semplice): ”Perchè SOA è un insieme di principi architetturali che permettono di ottenere l' Enterprise Agility e la Business Innovation scomponendo e rendendo fruibili gli asset IT tramite servizi”! ... tradotto significa: facilità di modifica del software a fronte dell'evoluzione del business (agile systems).

Questa scomposizione e ri-composizione dei servizi è alla base degli agile systems che si concretizzano tramite le composite applications. Ma cosa sono queste “fantomatiche” composite applications? Una composite application non è altro che una applicazione costruita tramite il riuso di componenti software (asset) che, una volta composti, rappresentano una specifica funzionalità di business.

La composition si riferisce quindi alla possibilità di realizzare soluzioni assemblando componenti invece di riscrivere le funzionalità tutte le volte da zero.
Capisco che la prima reazione potrà essere :

“WoW...il riuso dei componenenti! Questa si che è una novità !!!” :-)

E’ vero che fin dagli albori del OOP (Object Oriented Programming) fino a SOA l’obiettivo è sempre stato lo stesso : flessibilità, modularizzazione e riuso (all’interno del codice, tra oggetti fino ad arrivare ai servizi). Però, in questo caso la vera novità risiede nello spostare questi concetti da un piano tecnologico a quello di business! Inoltre tale capacità di adattamento viene estesa a tutti i quattro tier applicativi (Quattro?? Non è un errore … tra poco vediamo) permettendo la composizione delle applicazioni ottimizzando i processi di business tramite workflow e metadati anche quando i componenti sono già in produzione.

In figura 1 è rappresentata l’evoluzione della specie. Questa immagine la ritroverete in varie presentazioni e articoli sparsi su internet. E’ la più completa che ho trovato ma ad essere sinceri a me non piace molto perché dà quasi l’impressione che le composite application siano l’evoluzione di SOA mentre in realtà sono il candidato ideale per estendere, usufruire ed aggregare i servizi di back-end (ovvero SOA).

Figura 1

Prima di addentrarci nei meandri delle composite applications analizziamo i problemi e i limiti delle soluzioni attuali. Cosa hanno oggi le applicazioni di business aziendali LOB (Line-of-Business) che “non va bene" ? Il limite più evidente è dato dalla rigidità: spesso sono monolitiche e difficili da scomporre. Queste applicazioni non permettono la collaborazione tra diversi domini funzionali perché riflettono il modello transazionale dei processi di business. Dietro questa risposta un po’ criptica (Architect oriented) esiste una ragione di fondo molto più semplice :

le applicazioni LOB non pongono al centro del disegno le persone ma i processi!!!

...e questo è esattamente l'opposto del trend iniziato con il fenomeno del Web 2.0 !!!  

Perché questo è un problema? Facciamo un esempio!
Prendiamo un processo di business complesso a piacere e analizziamo come questo possa essere definito in un sistema IT tradizionale. Nella figura 2 è rappresentata una versione semplificata di un processo che porta un contatto (Lead) verso la creazione di un ordine.

Figura 2

Il flusso è chiaro e ben definito. Ma questo processo rappresenta veramente quello che avviene nella realtà? Se consideriamo solamente le attività “server side” la risposta è si, ma se consideriamo il processo nella sua interezza, ovvero comprensivo delle attività degli utenti (marketing, vendite, tecniche … e relativa collaborazione), la risposta è ovviamente no! Quello che avviene nella realtà invece è schematizzato nella figura 3

Figura 3

Ad esempio, per arrivare alla creazione di un ordine deve essere valutata e creata l’opportunità tramite l’analisi della documentazione del cliente, spesso in forma di documenti word o pdf, il calcolo dei costi della soluzione tramite fogli excel – che spesso comporta l’interazione tra personale tecnico e di vendita– il calcolo degli sconti e così via…

Esiste quindi un processo destrutturato (people-driven) che ha come attori principali le persone (information workers) e obiettivo quello di trovare le informazioni giuste al momento giusto per veicolare le decisioni corrette.
In questo mondo destrutturato (non sto facendo politica:-) vengono utilizzati tool di produttività individuale potenti e flessibili - come ad esempio quelli presenti in Office – che aiutano gli information workers nel processo decisionale (spesso costringendo gli utenti ad operazioni altamente specializzate come ad esempio il copia/incolla)! Il vero limite è rappresentato essenzialmente in 2 aree:

1. Parte delle informazioni utilizzate da questi tool sono per lo più locali e non sincronizzate con i processi di back-end, affidandosi completamente all’esperienza e alla capacità delle singole persone (nel bene e nel male).
   1. A tutti gli effetti queste attività sono parte integrante del processo reale di business ma non vengono gestite dai sistema ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) o SCM (Supply Chain Management), solo per citarne alcuni.
2. L’altra parte delle informazioni invece risiedono all’interno di n applicazioni verticali (LOB) che però hanno il grosso limite di non permettere lo scambio dei propri dati in modo “controllato” … affidandosi completamente all’esperienza e alla capacità delle singole persone (nel bene e nel male) nel merge dei dati.

La mancanza di una visione olistica del processo di business viene chiamata Result Gap causato dalla diversità di operare tra i sistemi e le persone frenando direttamente la produttività individuale e quindi quella aziendale! Questo Result Gap rappresenta quindi il divario tra la domanda di incremento di produttività che i dirigenti richiedono e il ROI (Return of Investment) reale e percepito.

Produttività, produttività e ancora … produttività. Questo è il motivo per cui il result gap viene chiamato anche l’ultimo miglio della produttività o Last Mile of Productivity. Ma non è finita qui! Ritroveremo questo importante sostantivo più avanti lungo il cammino...
La presenza di questo ultimo miglio è stato evidenziato per la prima volta da una ricerca di Gartner nel 2002 “The Knowledge Worker Investment Paradox”.

Diamo un ordine di grandezza a questo divario!

• Gli utenti ottengono dal 50% al 75% delle informazioni rilevanti di business da altre persone (Gartner).
• Più dell’ 80% delle informazioni digitali risiedono su HD locali o documenti “personali” (Gartner).
• Le persone al centro della conoscenza aziendale! Molto del valore viene perso quando gli utenti lasciano l’azienda (Gartner).
• 42% delle licenze CRM non vengono deployate (Gartner).
• 70% delle implementazioni di CRM falliscono (Butler Group).
• Più del 40% delle implementazioni di ERP riportano problemi di “user adoption” e mancanza di valori significativi del ROI (AMR).

Questo gap non può essere colmato solamente intervenendo sulle singole applicazioni as-is. Oggi per una azienda non è pensabile - e vantaggioso in termini di investimento - scrivere “tonnellate” di codice per avere un framework capace a run-time di assemblare servizi e componenti software!D’altro canto il semplice disporre di componenti non implica avere delle composite application!
E’ necessario quindi puntare su una piattaforma applicativa che out-of-the-box abiliti alla composizione e che permetta alle applicazioni di adattarsi facilmente ai cambiamenti grazie alle funzionalità della piattaforma stessa! Infine questa piattaforma applicativa deve essere in grado di fornire agli utenti e agli sviluppatori un ambiente altamente configurabile, sincronizzato tra tutti i layer aziendali e che garantisca la sicurezza nello storage e nei flussi applicativi.

“Che relazione corre tra le composite application e la piattaforma applicativa” ?: Le applicazioni forniscono gli asset per la composizione che la piattaforma è in grado di gestire e configurare tramite i propri containers.

“In che modo la piattaforma abilita alla composizione” ?: Fornendo i container e i component types che possono essere installati all’interno degli stessi container; infine gli asset applicativi diventano delle collezioni di componenti gestibili dalla piattaforma.

Last but not least la piattaforma deve mettere a disposizione dei tool per progettare, sviluppare e gestire in modo semplice gli asset applicativi!
Andare verso una composition architecture richiede quindi un fondamentale cambio nel modo di progettare le applicazioni all'interno dell'azienda (che analizzeremo in un secondo post) perché l’obiettivo è ambizioso volendo passare dalle attuali applicazioni:

• Monolitiche.
• Single path UI.
• Orientate ai processi e alle regole di business.
• Difficili da estendere e modificare.

a:

• Componibili e scomponibili.
• Con capacità di servire più domini funzionali.
• Adattabili al modo di lavorare degli utenti.
• Abilitanti alla collaborazione tra persone e servizi.

Dalla teoria alla pratica: vediamo come questi concetti si calano nella realtà Microsoft.

Nella seconda parte vedremo come dalle composite applications si arrivi alle office business applications.

--Mario

Comments

• Anonymous
  September 07, 2007
  OBA è una sigla che sta per Office Business Applications . Non è mai facile spiegare in poco tempo cosa

• Anonymous
  September 07, 2007
  Ieri con Pietro Brambati abbiamo pubblicato su soapbox un breve filmato introduttivo su OBA (Office Business

• Anonymous
  September 16, 2007
  Piccolo excursus su Office System 2007 A supporto dei post che sto scrivendo su OBA (Office Business

• Anonymous
  September 16, 2007
  Nel post precedente abbiamo visto come il " fenomeno Web 2.0 " registrato nel mondo consumer stia portando

• Anonymous
  October 02, 2007
  Il MS Dynamics CRM: oltre il concetto di CRM verso una piattaforma applicativa

• Anonymous
  October 14, 2007
  Venerdì scorso ho tenuto il WebCast del percorso formativo per architetti sulle Office Business Applications

• Anonymous
  October 21, 2007
  Parlando di applicazioni di produttività individuale impera spesso la filosofia del "good enough". Quante volte abbiamo sentito dire frasi come "tutte le versioni di office sono uguali" oppure "per l'uso che ne faccio, è sufficiente avere qualunque versione

• Anonymous
  December 12, 2007
  In questi miei precedenti post 1 e 2 avevo accennato alle OBA come una declinazione delle composite applications

• Anonymous
  February 07, 2008
  In questa pagina terrò aggiornata la lista di risorse per la progettazione, lo sviluppo e la maintenance

• Anonymous
  February 15, 2008
  Stavo per pubblicare questo post quando mi sono accorto che Pietro e Giuseppe hanno scritto un post su

• Anonymous
  February 15, 2008
  Stavo per pubblicare questo post quando mi sono accorto che Pietro e Giuseppe hanno scritto un post su

• Anonymous
  June 12, 2008
  Volevo segnalare la nuova applicazione inserita nella sezione Best Italian Applications del nostro sito