Dal WorkFlow al BPM passando per SharePoint

Come da consiglio di Igor, mi sono andato a leggere l’articolo di Bob Mixon riguardante la confusione che spesso si ha in testa quando si parla di BPM e di WorkFlow. La confusione è ancor più accentuata quando nel mezzo si inserisce la parolina SharePoint.

Non voglio soffermarmi sul significato *accademico* dell’uno o dell’altro, tra l’altro Bob riporta delle citazioni puntuali pienamente condivisibili, vorrei invece soffermarmi su ciò che significa BPM e WorkFlow quando si parla di SharePoint, in modo un pochino più pratico.

SharePoint di per se non offre nulla di *ready to use*, ovvero non ha un proprio motore di workflow, funge da host processor al più vasto WinWF che da *poco* è stato incluso nel .Net Framework 3.X.

Microsoft da parte sua ha creato come *collante* tra un farmework (WinWF) ed un prodotto (WSS) un tool integrato a SharePoint Designer che è in grado di disegnare graficamente dei workflow documentali/autorizzativi e pubblicarli in Microsoft Office SharePoint Server, quindi essere consumati al suo interno. Questi ultimi, una volta pubblicati, utilizzeranno l’application server di MOSS per essere eseguiti e per compiere  tutti i tasks esposti dal modello di workflow stesso.

Ovviamente quando si parla di WinWF è facile pensare a SharePoint, in quanto quest’ultimo è uno dei primi prodotti che ne accentua notevolmente le potenzialità e che strizzi l’occhiolino a moltissimi ISV!

Il concetto di WorkFlow presente in MOSS non è altro quindi che una implementazione di un host di esecuzione che viene utilizzato dal motore di WinWF, e non fa *purtroppo* altro che accentuarne ancor più i  limiti:

• tecnico – architetturali
  • esecuzione interna ad un host processor
• teorico – modellazione
  • modellazione orizzontale/sequenziale
  • mancanza del concetto di fork

E’ tuttavia una implementazione molto importante, sia dal punto di vista strategico e di mercato se pensiamo alla sua introduzione nella famiglia di applicazioni office, sia dal punto di vista di modellazione: è uno dei pochi motori di WorkFlow che può essere utilizzato agevolmente dall’IT.

Tuttavia ancora le mancanze in termini di modellazione e di esecuzione non lo rendono appetibile a quel livello di applicazioni enterprise che hanno un proprio linguaggio di definizione e di modellazione e posseggono un robusto WorkFlow Management System per l’esecuzione di task lato server.

Detto questo è facile pensare che al concetto di BPM è ancor più difficile avvicinarsi, in quanto non solo una soluzione per il Business Process Management ha bisogno di avere a disposizione un robusto sottosistema lato server che permetta l’esecuzione di processi basati su specifiche descritte in linguaggio il più possibile naturale ma necessità di agire sull’organizzazione aziendale  esclusivamente attraverso ruoli, competenze, non certo su componenti software o documenti. Un BPM solitamente offre strumenti di modellazione, esecuzione, monitoraggio e verifica di veri e propri processi funzionali che necessitano di una architettura che permetta ogni livello dell’organizzazione di agire su di una singola istanza di processo e gestirla, senza scendere in specifiche di linguaggio o interfacce.

Spesso è questa la confusione che si crea, quando si vede l’interfaccia grafica di WinWF in visual studio o in qualche altro tool di modellazione grafico si pensa che si abbia il l’universomondo sotto di se e che si possa facilmente spostare oggetti agendo sulle competenze di una organizzazione: non è cosi e non c’è poi nulla di male!

WinWF si ferma prima e SharePoint è molto lontano da fare tutto questo! Ma se si inziano a mettere assieme strumenti e  tecnologie allora si si può iniziare anche a parlare di BPM, utilizzando però questa volta l’universo Microsoft e non esclusivamente SharePoint.

E’ un po come dire che una definizione ontologica può essere espressa sintatticamente attraverso le regole di definizione di un file XML, come ancora afferma qualcuno!

Quando tra qualche anno, BizTalk sarà costruito su WinWF e WCF sarà abbastanza maturo allora si potrà, forse, costruire un BPM con queste tecnologie, magari orchestrando la comunicazione tra processi attraverso l’utilizzo di WCF  rappresentandone le singole istanze in MOSS atrraverso WinWF, estendere Active Directory ed agire sui ruoli anziechè sulle persone, il tutto fruibile magari attraverso Office… ma per fare questo secondo voi, quanto ci faranno aspettare?