工作流的7宗罪
在过去的15年里，在完成数百个工作流程项目时，我发现以下7个问题是工作流相关项目中的典型问题，
让我们逐一审视这些问题。旁注：当我说工作流时，我指的是由工作流引擎控制的（可能长期运行的）业务流程。这通常涉及用例人工任务管理以及服务编排/调用。
1.没有引擎
仍有许多项目根本没有使用工作流引擎 - 我看到两个原因：
- 项目没有考虑，因为对工作流引擎无感。
- 项目拒绝引擎是出于可疑的原因，例如“我们只有简单的要求，工作流引擎有点过分”或“没有适合我们特殊要求的产品。”我已经在2009年写过关于这种现象的博客（对不起：仅限德语）那个时候） - 不幸的是它仍在那里。
问题是：引擎轻巧灵活。你可以轻松地获得功能强大的Open Source工作流引擎，并在任何环境中将其作为库运行。学习曲线也很容易征服。运行工作流引擎的投资不是很大。只需确保选择正确的引擎。
在整个DevOps生命周期中，这些收益绝对值得，在我的第一个客户任务：由CTO组成的订单管理团队的所有直线经理在我们办公室会面，因为周末销售数据下降到零。这是由于我们从订单流程调用服务的错误引起的。但我们没有意识到这一点，因为我们没有任何技术来监控SLA或KPI。使用工作流技术免费获得的东西！
2.零码套件
我想引用分析师Sandy Kemsley 2014 报告 - 因为它很好地总结了这个罪：
“今天许多BPM专家都会告诉你，业务敏捷性的关键是业务主导的零代码、模型驱动的开发。换句话说，非技术分析师创建了一个图形化流程模型，可以在不编写代码的情况下生成可执行流程应用程序。实际上，在过去的15年中，厂商一直试图通过使用模型驱动的设计和开发，使业务流程管理系统（BPMS）更加用户友好，并且更易于分析。这些零代码范例允许非技术参与者创建自己的可执行流程模型，通常使用业务流程模型和符号（BPMN）标准。
然而，除了简单的非集成流程之外，现实情况是大多数BPMS项目涉及技术开发人员以及非技术分析师，遗憾的是，为分析人员提供简单界面的专有模型驱动环境可能会对开发人员效率和代码透明度造成障碍。这张纸探讨复杂项目中零代码BPM的神话，以及专有设计和开发工具如何造成阻碍 - 而不是帮助 - 熟练的企业开发人员。它考虑了如何将标准开发工具和编码语言与BPMS结合使用，可以在业务和IT之间建立桥梁，而无需使用不适合其需求的工具：业务主导的功能设计与企业标准应用程序中的高效开发相结合开发环境“
用我的话说：如果你想自动化你的核心流程，除非你有个性化的要求 - 否则，请购买标准软件！
零代码平台迫使你使用其专有的编码方式。它可能是基于图形和向导的，但它也是编码，对于非技术人员来说，这通常太复杂了。当然，零代码套件只允许你按照他们希望的方式编写代码。通常这是他们自己奇怪的脚本语言会导致反模式死亡属性面板，你必须进行反向翻译才能编写“普通代码”，比如用Java编写。
3.土生土长的引擎
在我的整个职业生涯中，我看到了数以百计，甚至数千种本土发动机，当你从无引擎起步时，后面就是自己发明引擎，过了一段时间，项目经理开始意识到他们错过了什么。它们在订单表中引入了第一个小状态标志，但是，如果没有及时收到客户付款，你还需要暂停，一段时间后，项目引入了一个小的XML或JSON方言，使流程更加灵活。恭喜你，你已经建立了自己的引擎！
我认识的所有公司都希望摆脱这种引擎，维持它是一场噩梦。让1-4人全职工作并不罕见，在功能和成熟度方面，它总是缺乏专业引擎，特别是面对快速变化的IT世界中。
因为我经常讨论它，所以我只是在实现引擎时添加了一个典型的后续要求列表：
- 监控和操作：如何保持所有正在运行的实例或故障的概述并提供干预选项？
- 可见性和领域语言：如何让所有利益相关者（包括领域专家）都能看到状态和模型？如何轻松更改这些模型？你是否开发了自己的语言，可能包括图形表示？
- 版本控制：工作流实例通常很长时间运行，因此在更改工作流模型时始终有运行实例。怎么处理这个？
- 性能和可扩展性：如果引擎不仅每天运行数百个实例，而且每天运行数百万个实例，会发生什么？
- 时间和超时：每当你需要跟踪时间时，你需要引入调度程序。这是一个活跃的组件，它不仅自身复杂的地形，而且还影响可扩展性，可测试性和资源管理。
4. BPM单体
每当我提到BPM monolith时，人们通常会提出三种关联：
- 巨大的BPM套件本身就是一块巨石单体，
- 瀑布项目大爆炸生活，
- 中央BPM系统声称集中执行所有业务流程，这违反了系统部分的责任（例如有界上下文）。
全部正确！
巨大的BPM套件本身确实感觉像一块巨石，它们由各种组件组装而成，通常由BPM供应商获得。由于零代码特性，这些工具必须提供无数功能才能满足某些要求 - 因为你无法简单地按照自己的方式编写所需的解决方案。这些工具试图将完整的开发栈推送到客户的环境中，包括自己的版本控制，部署或测试工具。我会告诉你什么：软件工程已经对这些问题有了非常好的答案，你可能会感觉到供应商试图最大化锁定你 - 而不是真正为了客户成功。
Big Bang go-lives大家伙似乎在BPM世界中非常受欢迎。这是关于业务分析师记录每个业务流程“不要错过任何东西”，关于绘制漂亮的“流程环境”以及IT部门将大量精力投入到“流程地图”中，这些服务将所有服务分类，为稍后在SOA某些服务中重用。在开始第一个自动化项目之前，许多公司仍然这样做。这是一个大错误。选择一个流程然后开始吧！在我们的最佳实践中，我们建议如下：
“使用相关流程，你可以显示BPM的好处，包括投资回报率（ROI）计算。但要避免太大或过于政治化的过程，以尽量减少由于可避免的原因而导致的失败风险。“
相反，小型项目是端到端的：设置架构，设置技术堆栈，建模流程，自动化流程，添加用户表单，添加任务列表，调用服务; 这样做你将学到很多东西，在下一个项目时你已经可以应用了。跳过第一步中不需要的任何东西 - 你可以经常牺牲一些有趣的功能来提高速度。请记住，现在基本上每个行业都有颠覆性的竞争对手，他们遵循精益创业的方法来构建“ 最小可行产品 ”并快速转向。
中心化BPM服务往往是有明确定位，在“旧时代”做BPM + SOA。中央BPM服务执行编排整个业务流程的各种服务，然而，这种观点已经过时，因为微服务和“领域驱动设计”学科被采用。这些方法简单地遵循有界上下文：在负责它的组件中实现业务逻辑 - 并使每个组件尽可能独立。不同的服务可能实现整个过程的一小部分，而端到端流程则来自这些服务的协作。这是一个非常强大的方法，虽然有自己的挑战，我将在未来几周内专门撰写各篇文章。
编辑：我最近专注于自己的博客文章，主题是在使用有界上下文时避免使用BPM monolith。
5.粒度泛滥
在粒度方面你可以做错。为了划清界面，我从现实生活中的一些例子开始（对不起，如果你想重新认识到自己的工作）。
模型以图形方式显示了太多细节。有些开始于init变量或负载配置等活动。这些不是商业动机方面！现在你再也无法识别真正的业务流程了。纯图形编程发生了什么 - 我看不到什么价值。最佳选择是在图形模型中使用业务驱动的过程 - 以及代码中编写其他所有内容。根据经验，图形模型中的所有元素都应该是领域专家可以理解的！毋庸置疑，你当然也应该使用领域专家的语言。
顺便说一句：这种情况经常发生的原因是，一些建模语言和大多数零代码工具迫使工程师对每一个和所有内容进行建模，因为编程不是“时尚”（记住第二次犯罪）。
6.违反利益相关者的栖息地
有两个误解，我称之为IT遵循业务，IT忽略业务。
业务利益相关者（客户）通常仍然认为他们完全掌握了一些要求，并且可以为IT实施提出一些要求。这在过去十年中没有奏效 - 将来肯定不会奏效。数字化告诉我们：几乎商业模式的所有领域都受到技术的影响。如果你想成功，你就无法锁定IT！科技创业公司不会这样做。他们将与IT密切合作，以了解技术的机会和局限性，并使其与领域和业务理解保持一致工作起来，这是关键！
然而，我也观察到另一个极端，特别是在科技创业公司内部：忽视业务利益相关者。在查看时尚科技公司的工作流引擎时，你将看到低级JSON文件，并且没有业务友好的流程可视化。像BPMN这样的既定标准被抛弃！
那你该怎么办？使用BPMN模型与业务利益相关者交谈，准确地使这些模型可执行并获得正确的粒度。
7.过度工程
每个人都知道工程技术，所以让我把它放在工作流程的背景下。
首先，似乎有一种反应，即在从供应商处购买的工作流引擎之上再次构建内部BPM平台，目标是对引擎再次抽象，以能抛开供应商获得自己的独立性，包括中央规则的执行以及重复使用常用功能。实际上，这些举措都没有真正奏效。BPM和工作流程通常是如此多样化，中央平台不能轻易地帮助不同的项目，导致人们拒绝在公司内使用它，需要花费精力说服他们，这减慢了工作流产品的新软件版本的采用，总的来说，抛开供应商追求独立性是一种错觉（你曾尝试过一次SQL数据库吗？）。
其次，内部平台通常变得非常复杂，由多个组件组成（例如工作流引擎，报告引擎，决策或业务规则引擎，搜索引擎，文档管理系统，门户，服务总线甚至甚至可能一些ERP）。“嘿 - 你只需要编写一些粘合代码！”在项目级别定义最佳架构的方法可能不会产生集成产品！
所以你最好从小做起，在迭代中工作，敏捷，当然尽可能少地构建你所需要的。请记住：你的颠覆性竞争对手会这样做。
结论
在我为共同创立的公司Camunda工作的过程中，我收集了数百个支持这7个工作流程的故事。正是这些故事促使我们首先创建了自己的BPM平台。作为创始人，如果你想使用我们的技术，我当然很高兴，但作为BPM爱好者和开发者，我的主要目标是分享这些故事，以帮助你避免这些罪恶。如果应用得当，工作流程可以非常酷并为你的用户带来巨大价值！