工作流工具的价值是什么？[关闭]

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

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

用这种方法最大的好处是什么？我可以理解简单的折线图和箱形图很有用，但是据我所知，这些东西目前是可视化的编程语言，带有条件和循环。在这里，程序员似乎在行和框层中进行了大量工作，在我看来，这就像是一种非常糟糕的，非常基础的可视化编程语言。

如果要走的那么远，为什么不只使用某种脚本语言呢？人们有没有为此把婴儿和洗澡水一起扔出去？线条和盒子的事物是否被带到了荒谬的水平，或者我只是不理解所有这些的价值？

我真的很想看到使用此技术的人们对此进行辩护并理解其用途的理由。我看不到其中的价值，但我认识到我对此也很陌生，可能还不太了解。

从开发人员的角度来看，您正确地说这些“可视”环境确实很难使用。我使用的SharePoint 2010工作流提供了围绕创建优秀企业软件的所有最佳实践-没有自动化测试，没有代码重用，无法读取的软件...比开箱即用的模板复杂的任何事情都难以维护。 ，如您所愿。

但是从业务的角度来看，工作流具有巨大的好处-至少在理论上是这样。引用本白皮书，自动化工作流程的效率，责任心，控制和易用性可带来巨大的生产率收益。想象一下，如果没有这种自动化，简单的批准或入职流程会效率低下。同样，定义工作流的行为对于试图控制其业务流程的组织也很有价值。

工作流软件的当前状态不是企业的错。他们只是想让生活更轻松，而工作流程对此非常有用。我最会怪我们IT部门：

1. 对于系统的复杂程度和脆弱性，未与企业保持透明。我们掩盖了所有复杂性。
2. 不能通过直观，简单的工作流解决方案“抓痒”。对于SharePoint和SAP之类的大型企业包，这可能更像是麻烦，但它们比那里的自定义解决方案要好

真正的好处只有一个，但却是巨大的： 关注点分离。

因此，与其将流程协调逻辑嵌入到我们的系统中，不如将其变成外部配置。基本上是一张地图。您可以独立地更改它（更多），可以有多个进程，多个版本的进程，多个版本的多个进程同时运行，而这在任何体面的解决方案中都是开箱即用的。

从历史上看，SoC的概念赢得了很多次-从Unix原理“做一件事情，却做得很好”开始，一次又一次地被应用-就像拥有专用服务器组件（如ESB，不同的持久性系统，缓存，负载平衡）一样，监控，例如从HTML拆分CSS等。

您的业​​务流程及其流程规则通常与数据，UI“屏幕”或用户“层次结构”正交。因此，与系统的其他方面分开开发和更改它是非常有意义的。这就是BPM在1990年代初出现的前提。

从那时起，创建了许多工具和语言来支持这一概念，其中最著名的就是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，听起来并不像它的傻瓜那样，这是正确的-为此编写自己的解析器或编辑器是一项艰巨而昂贵的任务，并且带来可疑的好处。

幸运的是，市场上已经有一些工具可以证明这一点。

Activiti是免费的，并且由于其初始价格（零），信息的可用性和谦虚性而在开发人员和业务所有者中都非常受欢迎。最后一点确实很独特，因为Activi仅专注于管理您的业务流程，而没有尝试将您与整包解决方案捆绑在一起。而且，它是开放的-因此您只需要了解Java和REST即可启动和运行它。缺点是客户端，集成和应用程序/业务逻辑以及整个体系结构留给开发人员，因此，如果您的开发团队很弱，请为失败做好准备。免费工具的总拥有成本可能高得惊人；）

频谱的另一面是Bega系统的统治者Pega（Pega PRPC）（根据Gartner和Forester的说法），其年龄似乎令人吃惊。这个和厨房一样的庞然大物甚至还具有CRM，OCR和（如果我没记错的话）语音识别功能，预测分析，业务规则管理和所见即所得UI编辑器的功能。不过，它的价格很高。这不仅要花很多钱，而且所有的开发工作都是在一个Web应用程序内完成的，这意味着您必须使用IE8浏览器（加上一些插件，再加上一些丑陋的技巧，例如使用Excel编辑数据表）。此外，还可以使用Web浏览器来进行Java，Javascript或HTML / CSS编辑-告别单元测试，IDE代码突出显示，重构以及您喜欢的所有编程玩具。

好的一面吗？您可以在一周内实现复杂的系统[ PDF，请参阅第22页]。是的，结果无法保证。

IBM有所最近（accoring给企业时间节奏）已经买了隆巴迪，并且现在提供非常有竞争力的解决方案（但那么你将不得不购买一切IBM，you'know）。Appian是年轻的供应商，具有有趣的见解和积极的反馈，但是它们的编写方式（除了可视化语言外，还增加了两种DSL语言）对我来说并不有吸引力。

还有其他参与者及其解决方案。他们大多数人简直太恐怖了。就像-当您简单地看着它们时，您的眼睛，大脑和心脏就会流血。因此，请相信自己的勇气，不要让开发人员和用户讨厌您。

结束语：

对于流程，BPM系统是相同的，对于图像，BPM系统是相同的。不要害怕它的视觉效果。不要让它做不适合它的工作（还记得完全在Photoshop中创建的网站，这些网站几乎无法编辑吗？）。保持简单，不要犯错误;）

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

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

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

工作流工具有3个主要优点：

1. 进行和部署更改所需的时间：您可以开发和更改工作流程的逻辑，而不会像更改代码段那样面临相同的技术风险。
2. 透明度：业务分析师可以立即使用基于BPM的系统中的业务逻辑，并且可以将其读取，而只有开发人员才能读取“基于代码”的系统中的业务逻辑。
3. 技术组件的重用：BPM工具通常与具有面向服务的体系结构的系统一起使用。通过将业务逻辑与技术组件分离（尤其是对于必须实施成百上千个不同业务流程的企业系统），您可以重用技术组件，同时花费相对较少的时间来开发业务逻辑（通过工作流工具）。

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

我看到了什么，所有的时间，是开发商仍试图增加业务逻辑中最技术的方式可能，而不是尽可能最透明的方式。这是自然的，因为从本质上来说，开发人员对代码的理解远比对工作流程工具的适应性高。此外，以技术方式保留的逻辑越多，作为开发人员的需求就越多。不幸的是，这是开发人员对BPM系统最糟糕的事情，因为他或她削弱了使用BPM的主要好处。

最后，大多数BPM工具还远远不够业务分析师可以自己开发工作流；但是，这就是目标。理想情况下，业务分析师将开发工作流/业务流程图，而开发人员将仅处理工作流引擎调用的技术组件。

以下陈述是我在使用工作流工具方面的个人经验，特别是Oracle BPM Suite（10.3G和11G）。首先要说明的是，您的问题集中在能够对可执行流程模型进行建模的工作流工具上，这些工具是业务流程管理系统（BPMS）的一部分。这种特定的过程建模肯定正在开发中，您可以将其称为可视化编程语言。

主要好处是敏捷的理解和更改过程逻辑

使用业务流程模型，您可以直观地说明流程逻辑，同时还可以执行可执行的集成组件。由于开发的一部分，通常只需要记录有关过渡，条件（网关或业务规则）和流程的较少文档，因此可以使程序员更快地上岗和下岗。

此外，您还附加了报告/监视功能，这是每个BPMS都必须针对每个应用程序分别开发的功能。

此外，在大多数BPM开发环境中，服务适配器是预先构建的（例如JMS，Web服务，JDBC等），从而允许逐步逐步集成来更快地开发中间件解决方案，从而减少了编码中的人为错误。

遵循工作流程平台确实实现了上述许多好处- 基于平台的工作流程自动化方法

价值

价值主张是可以快速轻松地创建或更改工作流，以适应不断变化的业务性质。实现此价值主张的重要部分是，业务流程本身是系统中的资源单元。

工作流作为资源单位，意味着将业务流程定义为单个“单位”。要理解我的意思，请考虑为企业编写的任何计算机程序。它肯定实现了一个业务流程，但是该流程的逻辑可能会在一定程度上围绕源代码散布。工作流工具应允许在一个封闭的地方定义流程。它可以在一个配置文件中，或者从一个可视化图表中提取，或者可能意味着工作流在一个可以插入，甚至可以即时交换或配置的代码模块中。

为什么价值可能无法实现

覆盖非典型案例，与快速变化的UI技术集成，不良做法（例如仅将工作流工具用作包装程序以及将真实逻辑放入代码中）的困难可能会破坏此价值主张。

工具本身的不良设计可能是一个限制因素。一个示例就是一个工具，该工具要求在流程之间传递的所有参数都在Java Map中，并且限制了您可以实际在地图上放置的值，而不仅仅是普通的旧方法参数（我想到了其中一个尤其是执行此操作的常用工具）。

我认为，可以说IBM作为拥有大型技术生态系统的大型公司，比其他公司更公平。如果他们还控制UI技术以及与工作流工具结合使用的数据库和SOA技术，则他们更有可能提出一个可以很好地集成在一起的生态系统，并创造机会真正利用这个想法。

的确，编写工作流工具与系统其他部分之间的接口的工作可以完全否定整个价值主张。始终值得考虑是否有更好的做事方法。

编程就是工作流程

事实是，编程（至少是命令式语言）已经是工作流程。您可能具有实现与处理系统技术有关的工作流的代码。访问文件并运行SQL查询等。您可能具有实现业务工作流程的代码；设置文档的状态并将其传递给审阅者。

认识到这一点并设计代码以清晰地分割这些单独的问题很难完全实现，但是这样做肯定可以走很长的路。

我同意你的观点，有时我们最终使用这些工具是因为其他人认为这是一个好主意，而且它们太复杂了，使我们的工作更加困难。我认为情况并非总是如此，需要仔细考虑一下是否值得。

不清楚使用的是哪个工具。我猜您可能是指称为业务流程建模工具的一般工具集。有充分的理由使用此类工具。任何高质量的企业都根据流程定义其功能，分析师以及业务专家可以轻松地绘制此类流程（直到您将它们与标准捆绑在一起...）。您可以在概念水平上创建此类流程，而无需任何Web编程知识，并且如果您使用正确的工具，也可以将流程转换为正常工作的应用程序（有经验的人员必须参与其中才能使这种魔力投入生产当然）。所以这个主意很好。

视觉工具的目的不仅仅是过程的文档。该工具的使用旨在帮助专业人士重新设计流程，并且有时会运行仿真以发现流程效率不如预期的要点，以便可以制定计划来消除瓶颈。

如今，许多公司都使用一种称为BPMN 2.0（业务流程建模表示法）的标准方法。我确实建议您先了解一下这种表示法（如果您的工具正在使用它）。

在知识的业务流程管理机构是著名的资源，你可能要考虑为好。

以上介绍了业务方面。技术方面需要SOA和BPEL，但是我不确定现在是否可以针对这些方面提供建议。

以历史为例。

石器时代

最初，您有一些小型的出租公司，那里的人告诉他们该怎么做，然后他们做到了。有时事情错了，而X或Y人也受到责备（永远不确定是谁真正做到了）。

下一代互联网和电子邮件发明了。

人们现在写了别人该怎么做，而这些人经常遇到自己的电子邮件问题，错误地阅读它，或者只是删除了一封电子邮件而从未阅读过；很多时候，不要将错误归咎于不良电子邮件

工作流从管理中演变而来 通过标准化操作，最终人们可以看到在什么阶段停止了流程，同时获得了实际执行情况的数字化概述。直到人们想要更改标准流程，或者直到某个未知的XY人员引起了不正确的数据库请求，导致数据库损坏，这使生产回到了石器时代，这才奏效。