BPMS ou tout simplement la programmation simple?

Question

Que préférez-vous (du point de vue de votre développeur) quand il s'agit de mettre en œuvre un processus d'affaires?

Un système de gestion des processus métier (BPMS) ou tout simplement votre IDE favori avec les outils et les cadres nécessaires (un outil de reporting par exemple)?

Qu'est-ce que de votre point de vue le plus grand bénéfice d'un BPMS par rapport à un IDE avec vos outils personnels et des cadres?

OK. Peut-être que je devrais être plus précis ... Je suis arrivé à savoir un BPMS spécifique qui devrait le rendre facile à mettre en œuvre un processus d'affaires en configurant des règles. Mais pour moi en tant que développeur, il est difficile de travailler avec le système. Je voudrais travailler avec des fichiers texte que je peux refactoriser et je voudrais être en mesure de choisir la bonne technologie ou d'un cadre pour le travail que je dois faire. Au lieu de cela le système me oblige à configurer.

Il existe des règles où je peux utiliser java, mais même alors je dois coller à l'éditeur de systèmes sans IntelliSense etc.

Alors cela me conduit à la réponse à ma propre question - je voudrais utiliser les outils que je suis habitué au lieu d'avoir à apprendre à travailler avec un BPMS (au moins celui que je connais) parce qu'il me limite plus que ça aide. Le BPMS que je connais est un cadre à partir duquel il est difficile d'échapper! A cette époque, je préférerais un cadre comme Graal sur toutes les BPMS que je connais.

Alors peut-être la question plus précise est: vous sentez-vous la même ou êtes là BPMSes que vous soutenir dans beeing un développeur et penser comme un développeur ou faites la plupart d'entre eux vous forcer à faire votre travail d'une manière différente?

Answer 1

Je ne sais pas exactement ce que vous demandez, mais le choix BPM par rapport à la programmation simple dépendra des besoins. Un « processus métier » est un terme relativement vague en génie logiciel.

Voici quelques critères pour évaluer vos besoins:

• complexité des règles - Est-ce que les décisions / règles contenues dans votre processus simple, complexe, configurable, codé en dur
?
• la volatilité du processus - Quelle est la fréquence de votre changement de processus? Qui devrait être en mesure de faire le changement?
• intégration besoin - Votre processus réalisé en utilisant plusieurs services hétérogènes, ou est tout mis en œuvre dans la même langue
• synchrone / asynchrone à - Votre processus "de longue durée" avec la nécessité de gérer les actions asynchrones
• tâches - Votre processus implique l'interaction humaine, avec la tâche étant assignée / acheminés aux personnes en fonction de leur rôle / responsabilités
?
• suivi du processus - Quel est le niveau de contrôle que vous voulez sur les instances de processus existants en cours d'exécution? Avez-vous besoin de vérifier les actions, etc.?
• erreur de manipulation - En fonction des points précédents, comment comptez-vous traiter les erreurs ou une nouvelle tentative de défaut d'exécution de processus

En fonction de la réponse à ces questions, vous pouvez comprendre que votre processus est plus proche d'un tableau avec quelques actions et les décisions qui peuvent être exécutées dans une séquence, ou vous pouvez réaliser que vous avez besoin quelque chose de plus élaboré, et que vous ne voulez pas re-mettre en œuvre tout ce que vous-même.

Entre Programmation simple et un (par exemple solution complète de BPM fledge Oracle BPM Suite qui contient BPEL , , etc.), il y a solutions intermédiaires comme < a href = "http://www.jboss.com/products/jbpm/" rel = "noreferrer"> jBPM ou Windows workflow Foundation et probablement beaucoup d'autres. Ces solutions intermédiaires sont souvent bon compromis.

Answer 2

Dans mon expérience, les environnements de développement fournis par les systèmes BPMS sont troisième taux, improductif, et pratiquement vous forcer à écrire difficile à maintenir, le code mal conçu (en raison de leurs limites). La quasi-totalité des « caractéristiques » (UI, intégrations, etc.) fournies par le système BPMS Je connais (celui vendu par cette société du nom de sa base de données) ne valent pas l'argent que nous avons payé.

Si vous êtes obligé d'utiliser BPMS, en tant que développeur, mon conseil serait de construire autant de votre application dans un environnement de développement classique, tels que Java ou .Net, construire aussi peu que possible dans l'environnement lui-même BPMS et intégrer les deux. Les seules choses qui devraient aller dans le BPMS est le minimum pour faire fonctionner le processus d'affaires.

Answer 3

J'ai travaillé avec Biztalk dans le passé et plus récemment avec JBPM. Mon opinion est biaisée contre BPMs pour les raisons suivantes:

1. courbe d'apprentissage: Pour faire un travail de processus, je dois comprendre comment le système et le fonctionnement de l'éditeur. Il est assez difficile pour un développeur pour comprendre le système, et encore moins un utilisateur d'affaires. La représentation de glisser-déposer et visuelle est un excellent outil de démonstration. Il impressionne certainement les gestionnaires (qui paient en fin de compte pour elle), mais la productivité d'un développeur tombe juste.

2. Les développeurs non changeant le flux de travail: je ne l'ai pas vu une solution de BPM faire parfaitement. Bien qu'il ne ressemble pas à un code, faites un clic droit sur la boîte et vous ne devez mettre un peu de code, sinon il ne va pas fonctionner. Donc, vous avez certainement besoin d'un développeur pour le faire. La meilleure partie est qu'il est ni développeur, ni amical user friendly, juste utilisateur démonstration amicale.

3. Testablity et refactoring: Il est pratiquement impossible de tester un BPMS. Vous avez annoncé « cadres de tests unitaires », mais la plupart d'entre eux sont hacks et difficiles à utiliser. Récemment, je l'ai essayé JBPM un; Je fini par écrire beaucoup de code de colle et de faux gestionnaires de flux de travail pour le faire fonctionner. Le facteur de rupture pour moi si est refactoring. Si l'entreprise change radicalement son esprit sur la façon dont un processus d'affaires devrait chercher, alors bonne chance réorganisant les boîtes, parce que les réarrangeant ne fonctionneront pas, toutes les variables liées aux boîtes doivent également être réorganisées. Je préférerais la puissance de l'IDE et des tests pour factoriser mon processus d'affaires.

Si votre application a workflow, vous pourriez essayer une bibliothèque de flux de travail (avec ou sans état persistant). Il gère toujours vos flux de travail sans tout le ballonnement qui vient avec un BPM. Si un utilisateur d'entreprise doit comprendre le code, puis laisser l'entreprise préparer ordinogrammes bonne processus et les traduire en un bon code Domain Driven. Utiliser des tests d'acceptation de style de concombre pour faire apporter les développeurs et affaires ensemble. Un BPM est juste quelque chose qui essaie de faire trop de choses et finit par faire toutes ces choses mal.

Answer 4

BPMS-- beaucoup de cas d'affaires commun, cas d'utilisation sont déjà mis en œuvre. Donc, il vous suffit de savoir comment l'utiliser. Pour flux de travail commun, vous ne même pas besoin d'écrire une seule ligne de code, bien que la plupart du temps vous devez écrire des scripts pour couvrir des choses qui ne sont pas encore mises en œuvre.

Plaine programming-- il suffit d'utiliser l'IDE pour pirater le code. Le côté positif: plus de contrôle. Le négatif? Beaucoup de temps sont consacrés à la réécriture du code passe-partout. Et vous devez les maintenir.

Donc, en résumé, je préférerais un système de gestion des processus métier. Un que je recommande est ProcessMaker . Il dispose d'un concepteur de processus intuitif qui vous permet de concevoir flux de travail avec le glisser-déposer. Et vous pouvez toujours écrire déclencheur pour étendre les fonctionnalités de processus. Il est open source aussi bien.