Limiti

Dopo aver analizzato i fattori di successo dei sistemi di workflow, le loro caratteristiche comuni e la loro architettura di base, è doveroso soffermarci sui limiti della maggior parte di essi, e sulle problematiche ancora aperte su cui numerosi gruppi di ricerca in tutto il mondo stanno lavorando. Molti sistemi sono stati infatti realizzati senza una chiara comprensione dei requisiti degli utenti e quindi erano spesso inadatti a rispondere alle esigenze delle aziende. Per capirne il motivo, è necessario comprendere come sono nati i primi prodotti di workflow. I diretti antenati dei sistemi di workflow erano le applicazioni di office automation o di gestione del lavoro cooperativo. In questi ambienti, i problemi principali da risolvere erano la condivisione delle informazioni e la collaborazione tra utenti (anche se nei primi prodotti nemmeno questi aspetti erano completamente risolti). Concetti come performance, scalabilità o affidabilità raramente erano considerati importanti in queste aree, e sfortunatamente questa caratteristica è stata ereditata anche dai prodotti di workflow più recenti. Per esempio, praticamente nessuno di loro si basa su tecnologie OLTP (On- Line Transaction Processing), né affronta le problematiche ormai ampiamente risolte dalla maggior parte dei sistemi di gestione dei database, sebbene molti di loro usino una base di dati per mantenervi le informazioni necessarie, ed alcuni di loro includano funzionalità che possono essere messe in relazione con quelle presenti nei sistemi di gestione delle transazioni. Di conseguenza, come vedremo, la robustezza e la maturità tecnologica raggiunta da questi ultimi sono ancora obiettivi molto lontani per i sistemi di workflow.

Un primo ambito di problemi aperti nel mondo dei sistemi di workflow esistenti, e forse il principale, è rappresentato dalla loro generale scarsa flessibilità. Più in dettaglio, la maggior parte dei sistemi disponibili:

sono dedicati ad una sola piattaforma, prevalentemente Windows;

sono limitati nella definizione dei partecipanti ed il loro assegnamento ai ruoli, spesso portando ad estreme semplificazioni che non consentono di ottimizzare la distribuzione del lavoro;

sono spesso legati ad un ambiente di sviluppo predefinito, che potrebbe non essere quello usato dall’utente;

non prevedono politiche di distribuzione del lavoro diverse dalla push, in cui è il sistema ad assegnare il lavoro ai partecipanti;

le interfacce con la maggior parte delle applicazioni esterne devono essere realizzate appositamente, essendo comprese nei sistemi solo quelle con i più diffusi software commerciali, e spesso non esiste alcuna forma di controllo sugli effetti collaterali di tali applicazioni;

in generale non riescono ad adattarsi ad alcune situazioni d’impiego, costringendo in tali casi l’utente ad adattarsi alle specificità, spesso molto vincolanti, dello strumento di workflow. Un secondo problema è legato al costo dei sistemi di gestione del workflow. I costi di licenza sono molto elevati ed inoltre costringono spesso le aziende a comprare delle licenze supplementari per applicazioni utilizzate dai sistemi stessi. In questo modo un’azienda che voglia utilizzare uno strumento di workflow per la gestione dei propri processi lo può fare solo se è disposta ad affrontarne i costi elevati e quindi solo se ne ha grande necessità. Di fatto le aziende di piccola o media dimensione, così come le pubbliche amministrazioni, sono quasi completamente escluse dall’acquisire sistemi di workflow per motivi principalmente finanziari, perdendo quindi la possibilità di incrementare notevolmente la loro efficienza.

Un ulteriore problema è quello del carico di lavoro inadeguato alle esigenze delle grandi aziende: la maggior parte dei sistemi di workflow, infatti, è stata progettata per l’uso all’interno di piccoli gruppi di lavoro11 e quindi non riesce a gestire più di poche centinaia di istanze al giorno, mentre per esempio un’azienda di telecomunicazioni ha a che fare in media con circa diecimila richieste al giorno, con punte di poche migliaia di istanze all’ora. È quindi necessario riuscire ad aumentare le performance di questi sistemi, e, anche grazie ai progressi tecnologici e di hardware, sembra che questo obiettivo sia raggiungibile in tempi brevi.

Un altro importante limite di questi sistemi è lo scarso supporto fornito per la gestione della concorrenza. Infatti, è molto frequente che due istanze di workflow, appartenenti o meno allo stesso processo, accedano alle stesse risorse, spesso in maniera concorrente: se, come succede nella maggior parte dei sistemi, si assicura la correttezza dell’esecuzione di ogni singola attività soltanto quando è eseguita da sola, si possono verificare errori che possono rivelarsi anche gravi, come letture di dati non aggiornati o scritture sovrapposte degli stessi. I più moderni sistemi di workflow implementano però alcuni semplici controlli: alcuni sfruttano un meccanismo di locking dei dati per precluderne temporaneamente l’accesso ad altre istanze, altri passano le informazioni condivise per riferimento, altri ancora creano per ogni modifica una nuova versione dell’oggetto condiviso ed affidano il controllo della consistenza all’intervento di sistemisti che decidono la versione da mantenere (tale metodo è però fortemente sconsigliato per i processi dove la modifica delle informazioni è un evento molto frequente, pena la necessità di analisi di un numero elevatissimo di versioni).

Infine, un ultimo importante problema dei sistemi di workflow è costituito dalla gestione dei fallimenti: ben pochi strumenti di workflow gestiscono il recupero della consistenza dei dati nel caso in cui un’istanza termini forzatamente, a causa di un crash del sistema, di problemi nella rete o nell’hardware, della mancanza di risorse disponibili o dell’impossibilità di raggiungere gli obiettivi del workflow. In questi casi devono essere annullate le attività già eseguite, oppure il workflow deve ripartire dal punto esatto in cui è avvenuto il fallimento: la maggior parte dei sistemi presenti sul mercato, però, permettono solamente agli sviluppatori dei processi di workflow di specificare delle attività che compiano azioni di recupero dello stato o di annullamento delle attività precedenti, senza fornire un supporto nativo per risolvere tale tipo di problemi. Inoltre, quasi tutti i sistemi sono carenti dal punto di vista della ridondanza e della flessibilità necessarie per assicurare la continua disponibilità dell’applicazione di workflow: essendoci spesso una sola base di dati comune a tutti i processi, infatti, un guasto o la sostituzione di un componente spesso determinano l’inutilizzabilità dell’intero sistema.

11 _{Ciò è riscontrabile in alcuni dettagli architetturali quali l’uso di una sola base di dati comune a tutti i workflow, il}

limitato supporto alla comunicazione tra utenti e la scarsa compatibilità con processi disegnati con strumenti di definizione diversi da quello fornito dal sistema.