工作流工具的价值是什么？

Question

我是工作流开发的新手，我认为我并没有真正理解“大局”。或者换句话来说，这些工具目前并不是在我的脑海中“点击”。

因此，公司似乎喜欢创建业务图纸来描述流程，而且在某一时刻，有人决定他们可以使用像程序这样的状态机来实际控制线上的进程和图表这样的框。十年后，这些工具非常庞大，非常复杂(我的公司目前正在玩WebSphere，我参加了一些培训，这是个怪物，甚至像Activiti这样的所谓的“极简主义”工作流工具也是庞大而复杂的，尽管并不像WebSphere afaict那样复杂)。

这样做有什么好处呢？我可以理解简单的行和框图是有用的，但据我所知，这些都是可视化的编程语言，包括条件和循环。这里的程序员似乎在行和框层做了大量的工作，在我看来，这是一种非常糟糕的、非常基本的可视化编程语言。

如果你要走那么远，为什么不直接使用某种脚本语言呢？有人用洗澡水把孩子扔出去了吗？线和盒子的事情是被带到了一个荒谬的水平，还是我只是不理解这一切的价值？

我真的很希望看到那些使用过这项技术的人为这一观点辩护，并理解它为什么有用。我不认为它的价值，但我认识到，我也是新的，可能还没有完全得到它。

Answer 1

从开发人员的角度来看，您正确地说，这些“可视化”环境确实很难使用。我使用的SharePoint 2010工作流，抛出了关于创建好的企业软件的所有最佳实践--没有自动化测试，没有代码重用，没有可读的软件.任何比开箱即用的模板更复杂的东西都是痛苦的，就像你正在经历的那样。

但从企业的角度来看，工作流有着巨大的好处--至少在理论上是如此。引用这份白皮书的话来说，自动化工作流的效率、问责制、控制和易用性提供了巨大的生产率提升。想象一下，如果没有这种自动化，简单的审批或上机程序会有多低效率。此外，定义工作流的行为对于试图控制其业务流程的组织来说也是很有价值的。

工作流软件的现状并不是企业的过错。他们只是想让自己的生活变得更简单，而工作流程对此很有帮助。我主要是责怪我们，IT部门：

1. 因为没有更透明地了解这个系统的复杂和脆弱程度。我们隐藏了所有的复杂性。
2. 因为不能用直观、简单的工作流解决方案来“挠我们的痒”。这可能更像是对大型企业包(如SharePoint和SAP )的猛烈抨击，但它们比现有的自定义解决方案要好得多。

Answer 2

只有一个真正的好处，但它的巨大好处:分离关注。

因此，不是将流程编排逻辑嵌入到我们的系统中，而是成为外部配置。一张地图，基本的。您可以独立地更改它(更多)，您可以拥有多个进程、多个进程的版本、多个进程同时运行的版本，这在任何合适的解决方案中都是现成的。

历史上，SoC的概念赢得了很多次--从Unix原则开始--“做一件事，但做得好”，并被一次又一次地应用--比如拥有专门的服务器组件，比如ESB、不同的持久系统、缓存、负载平衡、监视，比如将CSS从HTML中分离等等。

您的业务流程及其流程规则通常与您的数据、UI“屏幕”或用户“层次结构”正交。因此，从制度的其他方面来发展和改变这一制度是非常有意义的。这是上世纪90年代初BPM出现的前提。

从那时起，创建了许多工具和语言来支持这个概念，其中最著名的是BPMN --一种用于创建直接映射到进程的“流程图”的图形语言。虽然人们抱怨它庞大而笨重(词汇中有超过100个符号)，并且提倡现代方法，比如S-BPM (只有5个基本符号)，但目前的行业惯例是坚持使用BPMN或它的衍生产品、子集或兄弟姐妹。

您对BPMN不满意：

这里的程序员似乎在行和框层做了大量的工作，在我看来，这是一种非常糟糕的、非常基本的可视化编程语言。

但它并没有那么糟糕)背后有理论支持。2.0版从1.0缺陷中获得了一些很好的洞察力。

如果你要走那么远，为什么不直接使用某种脚本语言呢？

命令式范例和脚本语言并不总是最好的答案。正如您可能在声明性语言(如HTML、CSS、SQL、Drools或Nginx、Graddle和Maven、Puppet等的内部语言)中看到的那样，生成的代码可能比用“体面的语言(如Java或C++)”编写的版本更小、更简洁。

至于你的另一点：

据我所知，在这一点上，可视化编程语言是用条件和循环完成的。

你查过事件和触发器了吗？BPMN是一种语言，你必须在使用之前学会它，或者至少熟悉它。

在幕后，BPMN是XML，所以您可以手工编辑它或生成它。而且您可以对它们进行版本控制，因为XML是基于文本的。然而，仅仅拥有一个可以转换成流程图的XML听起来并不像它的goona帮助您，而且这是正确的--编写您自己的解析器或编辑器，因为它是一项艰巨而昂贵的任务，其好处值得怀疑。

幸运的是，市场上已经有一些工具能够做到这一点。

Activiti是免费的，并且非常受开发者和企业所有者的欢迎，因为它的初始价格(零)，信息的可用性和谦逊。最后一点是非常独特的，因为Activi只关注于管理您的业务流程，而不是试图将您与整个包解决方案联系在一起。而且，它是开放的-所以您只需要了解Java和REST就可以启动和运行它。缺点是客户端、集成和应用程序/业务逻辑以及整个体系结构留给开发人员，所以如果您的开发团队很薄弱--为失败做好准备。对于一个免费的工具来说，拥有的总成本可能是惊人的高;)

光谱的另一边是佩加(Pega )，BPM系统的王者(根据Gartner和Forester的说法)，它看起来非常适合它的年龄。这个-一个厨房-水槽庞然大物甚至能够实现CRM，OCR和(如果我没有错的话)语音识别能力，预测分析，业务规则管理和WYSIWYG UI编辑器。不过，它也有一个严肃的价格标签。这不仅花费了一大笔钱，而且所有的开发都是在一个web应用程序中完成的，这意味着你必须使用浏览器，即IE8 (加上一些插件，加上丑陋的黑客，比如使用Excel编辑数据表)。此外，Java、Javascript或HTML/CSS编辑也在使用web浏览器--因此，告别单元测试、IDE代码高亮化、重构以及所有你喜欢的编程玩具。

好的一面？您可以在几周内实现复杂的系统[PDF格式，见第22页]。是的，结果不能保证。

ibm最近(根据企业的时间节奏)收购了Lombardi，现在正在提供非常有竞争力的解决方案(但您知道，接下来您将不得不购买所有IBM产品)。Appian是一个年轻的供应商，有有趣的洞察力和积极的反馈，但是他们的写作方式(除了可视的DSL语言之外，还有两种额外的DSL语言)对我没有吸引力。

还有其他玩家，以及他们的解决方案。他们中的大多数都很可怕。就像-你的眼睛、大脑和心脏都会流血，只要你简单地看着它们。所以，相信你的勇气，不要让你的开发者和用户讨厌你。

结束语：

BPM系统同样适用于进程，而Photoshop则适用于图像。别怕它是视觉的。不要让它做不适合它的工作(还记得完全用Photoshop创建的网站吗？)保持简单，不要制造bug ;)

Answer 3

几年前，在我们大多数人出生之前，软件开发人员必须编写自己的代码来存储数据。如果您需要保存程序状态，那么，这被看作是代码功能的一部分，所以许多软件开发人员最终编写了代码来组织数据，保存和读取数据等等。

然后有人意识到这是经常发生的事情--保存、组织、读取和搜索数据的逻辑实际上是一个非常常用的组件，应该是它自己的组件。我们有数据库。

在过去的10到15年中，IT部门已经意识到，编排和/或编排业务流程的逻辑是如此的普遍，因此它也应该是它自己的组件，从而导致了各种不同的工作流工具。

工作流工具有三个主要好处：

1. 进行和部署更改所需的时间:您可以开发和更改工作流的逻辑，而不需要更改代码段所具有的相同技术风险。
2. 透明度:基于BPM的系统中的业务逻辑可立即为业务分析师所用并可读，而只有开发人员才能在“基于代码”的系统中读取业务逻辑。
3. 技术组件的重用: BPM工具通常与具有面向服务体系结构的系统一起使用。通过将业务逻辑与技术组件分离--特别是对于必须实现数百个或数千个不同业务流程的企业系统--您可以重用技术组件，同时在开发业务逻辑上花费相对较少的时间(使用工作流工具)。

然而，我在工作流和BPM工具的使用中遇到的最常见的问题之一是，开发人员仍然试图将业务逻辑“隐藏”在不透明的代码中。

我一直看到的是，开发人员仍然试图以最技术性的方式添加业务逻辑，而不是以最透明的方式添加业务逻辑。这是很自然的，因为从本质上说，开发人员比使用工作流工具更适合使用代码。此外，您在技术上保持的逻辑越多，作为一个开发人员就越需要您。不幸的是，这是开发人员对BPM系统所能做的最糟糕的事情，因为他或她正在削弱使用BPM的主要好处。

最后，大多数BPM工具还不足以让业务分析人员自己开发工作流:然而，这就是目标所在。理想情况下，业务分析人员将开发工作流/业务流程图，而开发人员将只处理工作流引擎调用的技术组件。