Les propositions de workflows agiles peuvent être classées selon les approches ou technologies suivies. En fait, deux grandes approches sont utilisées pour obtenir de l’agilité dans les workflows (Schonenberg et al. 2008), ce sont : l’approche impérative (dite classique) et l’approche déclarative.
- L’approche impérative : met l'accent sur la définition précise de la façon dont un
ensemble de tâches doit être effectué (c'est-à-dire, l'ordre des tâches est explicitement défini). En langages impératifs, les contraintes sur l'ordre d'exécution sont décrites, soit par l'intermédiaire de liens (ou connecteurs) entre les tâches soit par des conditions sur les données qui leurs sont associées.
- L’approche déclarative : se concentre sur ce qui devrait être fait et non sur comment le
faire. Elle utilise les contraintes pour restreindre l’exécution de certaines tâches. Par défaut, tous les chemins d'exécution sont autorisés.
Dans la catégorie des solutions impératives, plusieurs solutions ont été proposées. Dans (Adams, 2007), l’auteur présente des solutions qui permettent pour la plupart de traiter des
56
exceptions durant l’exécution ; d’ajouter, de supprimer des tâches, voir même de modifier le séquencement des tâches. C'est possible en se basant sur des E-C-A (Events-Condition- Action) (Greiner et al. 2005). Le souci avec ces propositions est qu’elles se basent toutes sur une intervention manuelle pour apporter de la flexibilité.
Une autre approche très intéressante se base sur les " worklets " (Adams et al. 2006). Cette solution utilise l’Architecture Orientée Service (SOA), se base sur un répertoire de tâches (worklets) liées ou pas, et sur une base de règles RDR (Ripple Down Rules). L’enchaînement des tâches et le traitement des exceptions se basent sur les règles définies dans la base RDR, ce qui permet de la flexibilité ou de l’adaptabilité au contexte d’exécution. Un avantage est que pour adapter un workflow aux changements survenus dans le processus métier, il suffit d’ajouter les nouvelles tâches dans le répertoire des tâches, et les règles qu’il faut dans la base de connaissance RDR. Le système de gestion de workflow open source YAWL (Yet Another Workflow Language) implémente cette méthode.
Il existe également une approche qui est appelée "Case Handling" (Van der Aalst, 2005) qui consiste à piloter le travail en se basant sur les données et non plus sur le processus. En d’autres termes, elle se base sur les informations disponibles pour décider des activités à lancer et non plus sur les activités déjà exécutées. Ainsi, chaque participant au processus aurait accès aux informations complètes concernant le cas traité, et il lui serait possible d’exécuter n’importe quelle tâche du moment où les données sont disponibles. L’un des problèmes majeurs de cette approche est la redondance d’informations ainsi que les incohérences qui lui sont corrélées. Parmi les systèmes de gestion de workflow qui se reposent sur cette méthode, nous citons FLOWer un système de gestion de workflow commercial (Van der Aalst, 2005).
L’évolution du contexte de l’entreprise, le B2B, le e-commerce ou encore la coopération et collaboration entre les organisations ont fait naître le besoin d’avoir des workflows inter- organisationnels (WIO) lâches. Plusieurs solutions ont été proposées. La plupart des auteurs préconisent une approche multi-agents et l’utilisation des services web (Zeng, 2001) (Buhler et Vidal, 2005) (Aberg et al. 2005) (Blake et Gomaa, 2004) et (Bouzguenda et al. 2008). Parmi ces travaux, nous citons les travaux de (Bouzguenda et al. 2008) où les auteurs s’intéressent à un environnement collaboratif, où il faut trouver des partenaires participants au processus et
57
où les partenaires peuvent changer en pleine exécution du WIO. Les auteurs proposent une solution basée sur l’approche multi-agents pour le traitement de la flexibilité, les services web pour faciliter la recherche de partenaire et deux ontologies pour la recherche et la sélection de partenaires.
Dans la catégorie des solutions déclaratives, l’outil le plus connu qui se base sur cette approche est Declare (Pesic et al. 2006). Il s’agit d’un prototype de système de gestion de workflow. Il utilise la logique temporelle pour modéliser et exécuter des processus métiers. Actuellement, Linear Temporal Logic (LTL) est le langage utilisé pour développer des modèles de processus dans Declare. Declare précise l’ensemble des contraintes qui guident l’exécution du processus. Dans Declare, il est supposé que les utilisateurs savent déjà ce qu'il faut faire. En principe, les utilisateurs peuvent exécuter les tâches dans un ordre quelconque aussi souvent qu'ils le veulent ; sauf s'il y a des contraintes qui interdisent de faire cette action. Ces contraintes représentent les politiques qui ne doivent pas être violées (exemple : dans un processus de gestion d’un patient, qui se compose de plusieurs tâches avec la contrainte qui dit qu’aucune tâche ne peut s’exécuter tant que la tâche « enregistrement patient» n’est pas achevée.). Autrement dit, les contraintes précisent ce qu'il ne faut pas faire au lieu de spécifier la façon de travailler. Ce qui laisse beaucoup de place pour l’initiative des utilisateurs, qui peuvent prendre des décisions et travailler de différentes manières avec le même modèle.
La Figure 18 présente cette classification en précisant les technologies utilisées pour atteindre les objectifs d’agilité et en donnant des exemples d’outils ou de travaux appartenant à chaque classe.
58 Approches workflow flexible Approches déclaratives Approches impératives Approches E-C-A (Events-Condition- Action) Approches Worklets Approches Case Handling Approches Ontologies (Aberget al, 2005) (Bouzguen da et al, 2008) FlOWer(Van der Aalst, 2005) Adaptflow(G reiner et al, 2005) YAWL (Adams et al, 2006) Approches Pour une organisation Approches Pour environnement interoganisationnel Approches Services web Approches Systèmes multi- agent (Buhler et Vidal, 2005) Declare (Pesic et al, 2006) Langage Linear Temporal Logic (LTL)
Figure 18. Classification des approches de workflow agile