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

Nel post precedente abbiamo visto come il "fenomeno Web 2.0" registrato nel mondo consumer stia portando anche all'interno dell' Enterprise una richiesta sempre maggiore di innovazione e di cambiamento nell'uso delle tecnologie. Le classiche architetture applicative incentrate solamente sui processi di business si integrano con difficoltà con le nuove esigenze di collaborazione e sharing dei dati necessarie però al raggiungimento "dei soliti vecchi" obiettivi : maggiore efficienza nel seguire le esigenze del business!

Sempre nel post precedente abbiamo introdotto il concetto di Composite-Applications. In questa seconda parte vediamo come dalle composite-applications arriviamo (finalmente) alle Office Business Applications !!

Dalle Composite-Applications alle Office-Business-Applications

Da quanto abbiamo visto fin ora possiamo riassumere quanto segue :

il fine è l' Enterprise Agility e la Business Innovation mentre il mezzo è rappresentato dalle composite application che possono vivere grazie ad una piattaforma applicativa che li ospita!

Il passaggio dalle composite application alle office business application è VERAMENTE molto ma molto semplice perché … le office business application SONO delle composite application (fosse sempre così facile :-) che in casa Microsoft servono ad abilitare il famoso ultimo miglio della produttività individuale e quindi aziendale! A questo punto risulta semplice anche l’associazione tra la piattaforma applicativa per la collaborazione tra utenti e processi e Microsoft Office System 2007.

Per capire veramente cosa è la piattaforma applicativa Office System 2007 vediamo come è avvenuta la trasformazione di Office da strumento di produttività individuale a piattaforma di collaborazione. Anche in questo caso iniziamo con una domanda che tutti noi, almeno una volta nella vita, ci siamo posti o abbiamo sentito dire :

”Una nuova versione di Office? ma ormai che ci sarà di nuovo in Office?? Ci sono già tutte le funzionalità che mi servono per scrivere e fare i calcoli !!! ”

Credo questa frase sia seconda, in popolarità, solo a:

“non ci sono più le stagioni di una volta” :-)

In realtà sono circa 11 anni che Microsoft ha in atto una evoluzione verso la collaboration anche se i primi tempi si parlava più di cooperazione che di collaborazione. Questa cooperazione avveniva solo tra le applicazioni client con la possibilità di integrazione dei dati via OLE (Object Linking & Embedding) e prima ancora via DDE (Dynamic Data Exchange – preistoria… ). Successivamente sono arrivati prodotti e servizi Office server-side cha hanno permesso di spostare il concetto di integrazione tra dati a collaborazione tra persone! Nel 1996 c’erano solo 5 applicazioni desktop mentre oggi con Office System 2007 la suite completa ne comprende circa 30 (da Project Server, OneNote, Groove a Excel Services, Sharepoint…).
I primi anni la velocità di adattamento degli utenti è stata molto alta. Ci siamo subito abituati all’integrazione, ad inserire immagini nei nostri documenti, incrociare dati tra prodotti Office (es fogli di Excel da Word) ecc… Più lento invece è l’adattamento (ancora oggi in atto, vedi il result gap) degli utenti alla collaborazione.
Nulla di strano! Nel primo caso era solo un adeguamento alla tecnologia il secondo richiede un adeguamento ai processi!

Per chi non conosce nulla, ma proprio nulla, di Office System 2007 consiglio il mio piccolo riassuntino :-)

Office Business Applications

Torniamo all’esempio del processo di business presentato nel primo post e vediamo dove può essere collocato Office System 2007  per colmare l'ultimo miglio della produttivà: (figura 1).

 
Figura 1

La parte "Classic" Enterprise Applications è l'area delle architetture applicative come SOA, EDA, ESB, EAI ... dove i principali protagonisti sono i servizi di business e l'integrazione tra applicazioni LOB (Line-of-Business).
La seconda componente invece rappresenta la nuona piattaforma applicativa che abilita alla collaboration tra le persone e lo sharing delle informazioni sfruttando gli strumenti di produttività individuale ben conosicuti dagli utenti lato client.
Questa componente permette di coniugare il mondo verticale dei servizi e delle applicazioni LOB con la natura orizzontale della collaborazione tra utenti.
Vediamo come... In Figura 2 ho rappresentato il tipico flusso operativo: ogni applicazione di business (quadri neri in basso) ha il proprio front-end (quadrati verdi). Spesso l'utente si trova a lavorare con più applicazioni contemporaneamente per avere una visione completa dell'intero processo di business. Inoltre è a carico dell'utente prelevare e condividere con altri utenti le informazioni dalle singole interfacce (sempre riquadri verdi) per assemblarle all'interno di documenti Office come Word, Excel e Outlook... (il famoso Result Gap o Ultimo miglio della produttività). Un ottimo esempio è raccontato in questo video fatto da Giuseppe Guerrasio e Pietro Brambati.

 
Figura 2 

Le Office Business Applications  vogliono cambiare questa visione perchè la vera innovazione avviene al di fuori dei processi strutturati grazie alle interazioni tra persone sfruttando però la precisione e il rigore dei dati di back-end. A questo proposito la produttività dell'utente viene posta al centro integrando gli strumenti di Office lato client con le applicazioni LOB del back-end passando dall'infrastruttura applicativa (MOSS). Questa soluzione offre quindi un'ottima opportunità agli utenti di avere una visione documento-centrica dei servizi di business e la libertà di comporre le informazioni delle LOB applications con un buon livello di "controllo referenziale"... il tutto gestito da una logica a Human Workflows!

Nell'esempio in Figura 3 vediamo uno strumento di collaborazione (ad esempio Outlook 2007) all'interno del quale vengono visualizzate in modo strutturato informazioni da più applicazioni LOB aggregate secondo la logica di business espressa nell'infrastruttura applicativa. Inoltre queste informazioni possono essere condivise facilmente tra utenti ed integrate automaticamente all'interno di altri prodotti come Word ed Excel.
E' importante notare la direzione delle frecce! L'applicazione client scrive e legge informazioni da MOSS il quale va a leggere e scrivere informazioni nelle LOB application tramite il componente BDC (Business Data Catalog). Questo significa che (spesso) non è necessario intervenire direttamente nella customizzazione delle applicazioni LOB.

Sempre nell'esempio in Figura 3 è rappresentato un Tab custom che da il nome all'applicazione OBA (1) che raggruppa delle informazioni provenienti dal CRM (2) integrandole con quelle su mainframe (3) relative allo stesso cliente.

Figura 3

Alcune precisazioni:

• Outlook è un buon candidato per aggregare le informazioni di business ma non è l'unico! Nel post successivo vedremo in dettaglio come l'integrazione può avvenire... finoa a spingersi a soluzioni basate su Smart-Client.
• Le applicazioni OBA espongono la logica di composizione delle informazioni a tutti gli strumenti Office.
• Già molti sviluppatori hanno iniziato ad integrare alcune funzionalità all'interno dei strumenti Office ma con il solo scopo di migliorare l'interfaccia o aggiungere qualche funzionalità. In questo caso però stiamo solo usando una piccolissima percentuale delle potenzialità di OBA in quanto manca la vera integrazione con i processi di business.
• L'obiettivo di OBA è di sostenere il mondo destrutturato NON renderlo strutturato o limitandone le possibilità d'azione.

Alcuni esempi concreti

Per "toccare con mano" vediamo alcuni esempi di applicazioni OBA. In figura 4 è rappresentato Microsoft Dynamics che utilizza Outlook come interfaccia utente customizzabile.

 
Figura 4

In figura 5 e figura 6 sono due esempi di una applicazione di collaboration e sharing dei dati sviluppata da Dassault Aviation in collaborazione con Microsoft. Nello specifico in figura 5 vediamo l'integrazione di alcuni processi server direttamente in Word per supportare gli ingegneri nella scrittura di un documento tecnico. Le informazioni provengono direttamente dall'infrastruttura applicativa!!!

Figura 5 

In figura 6 vediamo invece un'altra parte della stessa soluzione con una interfaccia Web SharePoint.In questo caso è integrata una web part custom in grado di visualizzare in 3D i componenti inseriti man mano dalll'operatore. Tali informazioni provengono, manco a dirlo :-), da applicazioni LOB di back-end.

 
Figura 6

Per capire la reale portata di questo tipo di soluzioni vi invito a guardare questo breve video che spiega l'intera soluzione di Dassault.

L' evoluzione dei Layer applicativi

Come si inserisce questa piattaforma applicativa di composizione all’interno della tradizionale architettura a tre livelli (Presentation Tier, Application o Business Tier e Data Tier)?
Partiamo dal problema delle applicazioni LOB discusse precedentemente: l’Application Tier è il responsabile principale delle problematiche discusse fin qui perché è il livello dal forte focus ai processi strutturati e alle “business transactions”. Inoltre si integra in modo rigido direttamente con il Presentation Layer (quello visibile dagli utenti) che invece dovrebbe gestire il mondo destrutturato. Quindi, per rispondere alla domanda è necessario introdurre un quarto layer dal nome Productivity Tier (figura 4) con l’oneroso compito di disaccoppiare i due layer (Presentation e Application) e quindi di colmare l’ultimo miglio della produttività con la garanzia di collaboration e consistenza a livello di business!

 
Figura 4

Lo scopo del Productivity Layer è quindi quello di creare un ambiente controllato per la collaborazione e la condivisione delle informazioni capace di integrarsi con la rigidità dei processi dell’Application Tier. Inoltre il productivity layer è lo strato che rende possibile la collaborazione tra applicazioni verticali appoggiandosi ai servizi di back-ed (leggasi SOA) e/o al BDC (Business Data Catalog) persente in MOSS.
A questo punto il presentation layer è libero di esprimersi come meglio crede :-) lasciando piena libertà agli utenti di lavorare al meglio!!!
E’ importante notare che le composite application o office business application non si basano solamente sul productivity layer ma sulla combinazione di componenti software o asset distribuiti su tutti i quattro layer. In figura 5 si può vedere come le funzionalità di Office System 2007 si rimappano e si integrano con i vari layer mentre nel post successivo parleremo di come avviene la composizione all’interno di ogni singolo layer.

Figura 5

Prima di terminare questo post rimane un ultimo importante concetto da capire: gli asset. Abbiamo detto che le office business application sono delle composite application formate da una collezione di asset assemblate all’interno di Office System 2007. Ma cosa sono questi asset o componenti software? Ecco la lista degli asset principali gestiti della piattaforma:

• Documenti di ogni tipo
• Struttura OpenXML
• Workflows
• Business Activities
• Business Rules
• Schema
• Interfacce a Web Services di back-end o esterni
• Metriche
• Web Parts
• Dashboards
• Sites
• Data connections
• Autorizzazione
• Reports

Le varie applicazioni OBA possono integrare ed estendere questa lista.

Concludo questa seconda parte rispondo ad una delle domande più frequenti che ricevo quando parlo di OBA: “Perché SOA non ci può aiutare anche in questo contesto”?

Risposta scherzosa: perché non è un caso elencato qui :-)

Risposta seria: SOA descrive i principi per erogare i servizi di business di back-office analizzando principalmente l’Application Tier ( e il Data Tier), ovvero la patria dei (Web) services, della SCA (Service Component Architecture), degli ESB (Enterprise Service BUS) e della EAI (Enterprise Application Integration) anche se alcune volte camuffata da ESB ;-)
SOA è quindi una componente molto importante nell'architettura IT aziendale ma non si occupa (direttamente) della produttività personale.

Nel prossimo post concluderemo questa breve panoramica su OBA analizzando le tecniche di composition nei vari layer e i passi per un architetto che si appresta ad adottare questa nuova tipologia di applicazioni valutando gli aspetti di design, di deployment e di maintenance.

A presto...

--Mario

Comments

• 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 23, 2008
  No, non solo non è uno scherzo ma con OBA intendo proprio Office Business Applications e non il