Quelle est la valeur des outils de workflow? [fermé]

Je suis nouveau dans le développement de Workflow, et je ne pense pas vraiment avoir une "vue d'ensemble". Ou peut-être pour le dire différemment, ces outils ne "cliquent" pas actuellement dans ma tête.

Il semble donc que les entreprises aiment créer des dessins commerciaux pour décrire les processus, et à un moment donné, quelqu'un a décidé de pouvoir utiliser un programme de type machine d'état pour contrôler les processus à partir d'une ligne et de boîtes comme un diagramme. Dix ans plus tard, ces outils sont énormes, extrêmement compliqués (mon entreprise joue actuellement avec WebSphere, et j'ai suivi une partie de la formation, c'est un monstre, même les versions dites "minimalistes" de ces outils de workflow comme Activiti sont énorme et compliqué, mais pas aussi compliqué que la bête qui est WebSphere afaict).

Quel est le grand avantage de le faire de cette façon? Je peux en quelque sorte comprendre que les diagrammes simples de lignes et de boîtes sont utiles, mais pour autant que je sache, ces choses sont des langages de programmation visuels à ce stade, avec des conditions et des boucles. Les programmeurs semblent faire un travail considérable dans la couche des lignes et des boîtes, ce qui pour moi ressemble à un langage de programmation visuelle vraiment merdique et vraiment basique.

Si vous allez aussi loin, pourquoi ne pas simplement utiliser une sorte de langage de script? Les gens ont-ils jeté le bébé avec l'eau du bain à ce sujet? La ligne et les boîtes ont-elles été prises à un niveau absurde, ou est-ce que je ne comprends tout simplement pas la valeur de tout cela?

J'aimerais vraiment voir des arguments pour défendre cela par des gens qui ont travaillé avec cette technologie et comprendre pourquoi elle est utile. Je n'y vois pas de valeur, mais je reconnais que je suis également nouveau dans ce domaine et que je ne l'ai peut-être pas encore tout à fait.

Du point de vue d'un développeur, vous avez raison de dire que ces environnements "visuels" sont vraiment difficiles à travailler. Les flux de travail SharePoint 2010, que j'utilise, mettent au rebut toutes les meilleures pratiques en matière de création de bons logiciels d'entreprise - pas de tests automatisés, pas de réutilisation de code, de logiciels illisibles ... Tout ce qui est plus complexe qu'un modèle prêt à l'emploi peut être pénible à maintenir , comme vous le ressentez.

Mais du point de vue de l'entreprise, les flux de travail présentent d'énormes avantages - du moins, en théorie. Pour citer ce livre blanc , l'efficacité, la responsabilité, le contrôle et la facilité d'utilisation d'un flux de travail automatisé offrent d'énormes gains de productivité. Imaginez à quel point un processus d'approbation ou d'intégration simple serait beaucoup plus inefficace sans cette automatisation. En outre, le fait même de définir un flux de travail est précieux pour une organisation qui essaie de contrôler ses processus métier.

L'état actuel du logiciel de workflow n'est pas la faute de l'entreprise. Ils veulent simplement leur faciliter la vie, et les flux de travail sont parfaits pour cela. Je voudrais surtout nous blâmer, le service informatique:

1. Pour ne pas être plus transparent avec l'entreprise sur la complexité et la fragilité du système. On cache toute la complexité.
2. Pour ne pas pouvoir "gratter nos démangeaisons" avec des solutions de workflow intuitives et simples. Il s'agit probablement plus d'un coup de gueule contre les packages de grandes entreprises comme SharePoint et SAP, mais ils sont meilleurs que les solutions personnalisées disponibles

Il n'y a qu'un seul avantage réel, mais énorme: la séparation des préoccupations .

Ainsi, au lieu que la logique d'orchestration des processus soit intégrée dans notre système, elle devient une configuration externe. Une carte, en gros. Vous pouvez le changer (beaucoup plus) indépendamment, vous pouvez avoir plusieurs processus, plusieurs versions de processus, plusieurs versions de plusieurs processus s'exécutant en même temps, et c'est tout prêt à l'emploi dans n'importe quelle solution décente.

Historiquement, le concept de SoC a gagné à plusieurs reprises - à partir du principe Unix «faites une chose, mais faites-le bien», et être appliqué encore et encore - comme avoir des composants serveur dédiés comme ESB, différents systèmes de persistance, la mise en cache, l'équilibrage de charge , la surveillance, comme la séparation du CSS du HTML, etc.

Votre processus métier et ses règles de flux sont souvent orthogonaux à vos données, aux "écrans" de l'interface utilisateur ou à la "hiérarchie" des utilisateurs. Il est donc parfaitement logique de le développer et de le modifier séparément des autres aspects du système. C'était la prémisse sur laquelle BPM est apparu au début des années 1990.

Depuis lors, de nombreux outils et langages ont été créés pour prendre en charge ce concept, le plus connu étant le BPMN - un langage graphique pour créer des "organigrammes" qui mappent directement aux processus. Alors que les gens se plaignent de sa grande taille et de sa lourdeur (ayant plus de 100 symboles dans le vocabulaire) et préconisent des approches modernes comme le S-BPM (n'a que 5 symboles de base), la pratique actuelle de l'industrie consiste à s'en tenir au BPMN ou à ses dérivés, sous-ensembles ou frères et sœurs.

Vous n'avez pas l'air satisfait de BPMN:

Les programmeurs semblent faire un travail considérable dans la couche des lignes et des boîtes, ce qui pour moi ressemble à un langage de programmation visuelle vraiment merdique et vraiment basique.

Mais ce n'est pas si mal) Il y a une théorie derrière. Et la version 2.0 a pris un bon aperçu des lacunes de 1.0.

Si vous allez aussi loin, pourquoi ne pas simplement utiliser une sorte de langage de script?

Le paradigme impératif et les langages de script ne sont pas toujours la meilleure réponse. Comme vous l'avez probablement vu dans les langages déclaratifs (comme HTML, CSS, SQL, Drools ou ceux internes de Nginx, Graddle et Maven, Puppet, etc.), le code résultant peut être beaucoup plus petit et plus propre qu'une version écrite en " langage décent, comme Java ou C ++ ".

Quant à votre autre point:

pour autant que je sache, ce sont des langages de programmation visuels à ce stade, avec des conditions et des boucles.

avez-vous regardé les événements et déclencheurs ? BPMN est une langue et vous devez l'apprendre avant de l'utiliser, ou au moins vous familiariser avec elle.

Sous le capot, BPMN est XML, vous pouvez donc le modifier à la main ou le générer. Et vous pouvez les contrôler par version, car XML est basé sur du texte. Cependant, le simple fait d'avoir un XML qui peut être traduit en organigrammes ne semble pas que son goona vous aide, et c'est correct - écrire votre propre analyseur ou éditeur pour cela est une tâche difficile et coûteuse avec des avantages discutables.

Heureusement, il existe déjà des outils sur le marché qui font exactement cela.

Activiti est gratuit et très populaire auprès des développeurs et des propriétaires d'entreprises, en raison de son prix initial ( zéro ), de la disponibilité des informations et de l'humilité. Le dernier point est vraiment unique, car Activi se concentre uniquement sur la gestion de vos processus commerciaux, sans essayer de vous associer à des solutions globales. De plus, il est ouvert - il vous suffit donc de connaître Java et REST pour le mettre en service. L'inconvénient est que le côté client, la logique d'intégration et d'application / métier et l'ensemble de l'architecture sont laissés au développeur, donc si votre équipe de développement est faible - préparez-vous à l'échec. Le coût total de possession peut être étonnamment élevé pour un outil gratuit ;)

De l'autre côté du spectre se trouve Pega (Pega PRPC), le roi régnant des systèmes BPM (selon Gartner et Forester), qui semble étonnamment bon pour son âge. Ce monstre évier de cuisine est même capable de CRM, d'OCR et (si je ne me trompe pas) de capacités de reconnaissance vocale, d'analyse prédictive, de gestion des règles métier et de l'éditeur d'interface utilisateur WYSIWYG. Cependant, cela vient avec un prix sérieux. Non seulement cela coûte une fortune, mais tout le développement se fait au sein d'une application Web, ce qui signifie que vous devez utiliser un navigateur, qui est IE8 (plus certains plugins, ainsi que des hacks laids, comme utiliser Excel pour éditer des tableaux de données). De plus, l'édition Java, Javascript ou HTML / CSS se fait également avec un navigateur Web - alors dites au revoir aux tests unitaires, à la mise en évidence du code IDE, à la refactorisation et à tous vos jouets de programmation que vous avez adoré.

Bon côté? vous pouvez implémenter un système complexe DANS LES SEMAINES [ PDF , voir page 22]. Et oui, le résultat n'est pas garanti.

IBM a récemment quelque peu (accoring au rythme du temps de l' entreprise) ont acheté Lombardi, et offre maintenant une solution très compétitive (mais alors vous devrez acheter tout ibm , you'know). Appian est un jeune vendeur qui a des idées intéressantes et des commentaires positifs, mais la façon dont ils sont écrits (deux langues DSL supplémentaires en plus d'une langue visuelle) ne me plaît tout simplement pas.

Il y a d'autres acteurs et leurs solutions. La plupart d'entre eux sont tout simplement horribles. Comme - vos yeux, votre cerveau et votre cœur saignaient littéralement, quand vous les regardez simplement. Alors, faites confiance à vos tripes et ne faites pas que vos développeurs et vos utilisateurs vous détestent.

Note de clôture:

Le système BPM est le même pour les processus, ce que Photoshop est pour les images. N'ayez pas peur que son visuel. Ne lui faites pas faire le travail qui ne lui convient pas (rappelez-vous les sites Web créés entièrement dans Photoshop, qui étaient presque impossibles à modifier?). Restez simple et ne faites pas de bugs;)

Il y a des années, avant la naissance de la plupart d'entre nous, les développeurs de logiciels devaient écrire leur propre code pour stocker les données. Si vous aviez besoin de sauvegarder l'état du programme, eh bien, cela était considéré comme faisant partie de la fonction du code, de nombreux développeurs de logiciels ont fini par écrire du code pour organiser les données et les enregistrer et les lire, etc.

Et puis quelqu'un a réalisé que c'était quelque chose qui arrivait souvent - que, la logique pour sauvegarder, organiser, lire et rechercher des données était en fait un composant qui était si couramment utilisé qu'il devrait s'agir de son propre composant. Et nous avons des bases de données.

Au cours des 10 à 15 dernières années, les services informatiques ont réalisé que la logique de chorégraphier et / ou d'orchestrer les processus métier est si courante qu'elle devrait également être son propre composant, ce qui a conduit à toutes sortes d'outils de workflow différents.

Il existe 3 principaux avantages d'un outil de workflow:

1. Temps nécessaire pour effectuer et déployer des modifications : vous pouvez développer et modifier la logique d'un flux de travail sans les mêmes risques techniques que vous avez avec la modification d'un morceau de code.
2. Transparence : la logique métier dans un système basé sur le BPM est immédiatement disponible et lisible par l'analyste métier, alors que seuls les développeurs pourront lire la logique métier dans les systèmes "basés sur le code".
3. Réutilisation des composants techniques : les outils BPM sont souvent utilisés conjointement avec des systèmes dotés d'une architecture orientée services. En séparant la logique métier des composants techniques - en particulier pour les systèmes d'entreprise qui doivent implémenter des centaines ou des milliers de processus métier différents - vous êtes en mesure de réutiliser les composants techniques tout en consacrant relativement peu de temps au développement de la logique métier (avec un workflow outil).

Cependant, l'un des problèmes les plus courants que je rencontre avec le flux de travail et l'utilisation des outils BPM est que les développeurs essaient toujours d '"enfouir" la logique métier dans du code non transparent.

Ce que je vois, tout le temps , c'est que les développeurs essaient toujours d'ajouter la logique métier de la manière la plus technique possible, au lieu de la manière la plus transparente possible. C'est naturel, car les développeurs sont, de par leur nature même, beaucoup plus à l'aise avec le code qu'avec un outil de workflow. De plus, plus vous gardez de logique sur le plan technique, plus vous aurez besoin de développeur. Malheureusement, c'est la pire chose qu'un développeur puisse faire à un système BPM car il ou elle minimise les principaux avantages de l'utilisation de BPM.

Enfin, la plupart des outils BPM ne sont pas assez loin pour que les analystes commerciaux puissent développer eux-mêmes les workflows: c'est pourtant l'objectif recherché. Idéalement, les analystes commerciaux développeraient les diagrammes de workflows / processus métier et les développeurs ne travailleraient que sur les composants techniques appelés par le moteur de workflow.

Les déclarations ci-dessous sont mon expérience personnelle en utilisant des outils de workflow, en particulier Oracle BPM Suite (10.3G & 11G). Tout d'abord pour préciser, votre question se concentre sur les outils de workflow qui permettent de modéliser des modèles de processus exécutables, ces outils font partie de Business Process Management Systems (BPMS). Cette modélisation de processus spécifique se développe définitivement et vous pouvez vous y référer en tant que langage de programmation visuel.

Le principal avantage est l' agilité de comprendre et de changer la logique du processus

Avec les modèles de processus métier, vous couvrez une explication visuelle de la logique du processus et en même temps un composant intégratif exécutable. Cela permet une intégration et une intégration plus rapides des programmeurs, car moins de documentation sur les transitions, les conditions (passerelles ou règles métier) et le flux de processus en général doit être documentée, depuis sa partie du développement.

De plus, vous avez attaché des capacités de reporting / surveillance, ce que vous devriez développer individuellement pour chaque application, ce qui est couvert par la plupart des BPMS.

De plus, dans la plupart des environnements de développement BPM, les adaptateurs de service sont préconfigurés (par exemple JMS, services Web, JDBC, etc.), ce qui permet de développer plus rapidement des solutions de middleware dans une intégration interactive étape par étape, réduisant ainsi les erreurs humaines de codage.

La plate-forme de workflow suivante offre de nombreux avantages mentionnés ci-dessus - Approche basée sur la plateforme pour l'automatisation des workflows

La valeur

La proposition de valeur est que les flux de travail peuvent être créés ou modifiés rapidement et facilement pour s'adapter à la nature changeante d'une entreprise. Une partie importante de la réalisation de cette proposition de valeur est que les processus métier eux-mêmes sont des unités de ressources dans le système.

Les workflows en tant qu'unités de ressource signifient qu'un processus métier est défini comme une seule «unité». Pour comprendre ce que je veux dire par là, considérez tout programme informatique écrit pour une entreprise. Il met en œuvre un processus métier à coup sûr, mais la logique de ce processus est susceptible de se répandre dans une certaine mesure autour du code source. Un outil de flux de travail devrait permettre de définir le processus dans un endroit bien contenu. Il pourrait être dans un seul fichier de configuration, ou extrait d'un diagramme visuel, ou cela pourrait signifier que le flux de travail est dans un seul module de code qui peut être branché, peut-être même échangé ou configuré à la volée.

Pourquoi la valeur peut ne pas être réalisée

Cette proposition de valeur peut être sapée par les difficultés à couvrir les cas non-vanilla, à s'intégrer à la technologie d'interface utilisateur qui change très rapidement, à de mauvaises pratiques telles que l'utilisation de l'outil de workflow comme un wrapper uniquement et la mise de toute façon la vraie logique dans le code.

Une mauvaise conception des outils eux-mêmes peut être un facteur limitant. Un exemple serait un outil qui requiert que tous les paramètres passés entre les processus soient dans une carte Java, avec des restrictions sur les valeurs que vous pouvez réellement mettre sur la carte, au lieu de simplement de vieux paramètres de méthode (je pense à l'un des plus outils populaires en particulier qui fait cela).

Je pense qu'il est probablement juste de dire qu'IBM, en tant que grand acteur avec un grand écosystème technologique, se débrouille mieux que les autres. S'ils contrôlent également la technologie d'interface utilisateur et la technologie de base de données et SOA utilisée conjointement avec l'outil de flux de travail, ils ont de meilleures chances de créer un écosystème qui s'intègre bien et crée une opportunité de vraiment utiliser cette idée.

Il est certainement vrai que l'effort d'écriture de l'interface entre un outil de workflow et les autres parties d'un système peut complètement annuler la proposition de valeur. Il vaut toujours la peine d'examiner s'il existe une meilleure façon de faire les choses.

La programmation est un workflow

La vérité est que la programmation (dans les langues impératives au moins) EST déjà un workflow. Vous pouvez avoir du code qui implémente le flux de travail qui concerne la gestion de la technologie du système; accéder aux fichiers et exécuter des requêtes SQL, etc. Vous pouvez avoir un code qui implémente le flux de travail d'entreprise; définir l'état d'un document et le transmettre à un réviseur par exemple.

Reconnaître cela et concevoir votre code pour diviser proprement ces préoccupations distinctes est difficile à réaliser complètement, mais vous pouvez certainement obtenir un long chemin pour y parvenir.

Je suis d'accord avec vous, parfois nous finissons par utiliser ces outils parce que quelqu'un d'autre a décidé que c'était une bonne idée, et ils sont tout simplement trop complexes et rendent notre travail plus difficile. Je ne pense pas que ce soit toujours le cas, il faut un examen attentif pour décider si cela en vaut la peine ou non.

L'outil que vous utilisez n'est pas très clair. Je suppose que vous faites peut-être référence à l'ensemble général d'outils appelés outils de modélisation des processus métier. Il y a une bonne raison d'utiliser de tels outils. Toute entreprise de qualité définit ses fonctions en termes de processus et l'analyste ainsi que les experts métier peuvent dessiner ces processus confortablement (jusqu'à ce que vous les liez aux normes ...). Vous pouvez créer de tels processus au niveau conceptuel sans aucune connaissance de la programmation Web et si vous avez le bon outil, vous pourrez peut-être également convertir le processus en une application fonctionnelle (des personnes expérimentées doivent embarquer pour que cette magie entre en production). bien sûr). L'idée est donc bonne.

L'objectif des outils visuels n'est pas seulement la documentation des processus. L'utilisation des outils est destinée à aider les professionnels à réorganiser les processus et, parfois, à exécuter des simulations pour découvrir les points où les processus sont moins efficaces que souhaité afin que des plans puissent être mis en place pour éliminer les goulots d'étranglement.

Il existe un moyen standard que de nombreuses entreprises utilisent aujourd'hui appelé BPMN 2.0 (Business Process Modeling Notation). Je vous recommande de bien comprendre cette notation si votre outil l'utilise.

Le corpus de connaissances sur la gestion des processus métier est une ressource célèbre que vous voudrez peut-être également prendre en considération.

Ce qui précède couvre le côté commercial. Le côté technique nécessite SOA et BPEL, je ne suis pas sûr de pouvoir fournir des conseils ici et maintenant.

En exemple simple par l'histoire.

Âge de pierre

Au début, vous aviez de petites entreprises de menhir où les gens disaient quoi faire et ils le faisaient. Parfois, les choses tournent mal et la personne X ou Y est blâmée (on ne sait jamais vraiment qui l'a fait).

Internet et le courrier électronique ont été inventés.

Les gens écrivaient maintenant aux autres quoi faire, et ces gens avaient souvent des problèmes avec leur e-mail, le lisaient mal ou simplement supprimaient un e-mail sans jamais le lire; si souvent des choses où il ne faut pas le blâmer sur un mauvais e-mail

Le flux de travail a évolué hors de l'administration En standardisant les actions, les gens ont finalement pu voir à quelle phase qui avait interrompu un processus, et en même temps, obtenir une vue d'ensemble numérique de ce qui avait réellement été fait. Cela a bien fonctionné jusqu'à ce que les gens veuillent changer les processus standard, ou jusqu'à ce qu'une personne XY inconnue provoque une demande de base de données incorrecte entraînant une corruption de la base de données, renvoyant la production à l'âge de pierre.