Red Hat的一个更加结构化的BPM设计方案有望搭设应用开发界与业务流程管理的桥梁，让企业架构师、开发者和业务侧的人更快速更容易地实时新的业务流程。这一框架可以带来业务自动化和现代交付技术，这是企业为未来项目做好准备的关键要素，Red Hat咨询的业务自动化实践负责人Justin Holmes在旧金山举行的Red Hat峰会上如是说。

Holmes说，微服务开发者经常提出，与业务流程管理（BPM）相比，他们可以用微服务和DevOps更加快速地使业务敏捷。这一派的人说BPM老了，不需要了。Holmes则反驳说抛弃BPM模型相当于“倒洗澡水时连孩子也一起倒了。”

“想出如何利用业务自动化和持续集成来汲取这两个世界之长并将其合并到一起很重要，”特殊。在Red Hat Summit的一次演讲上，Holmes描述了一个结构化设计方法是如何实现业务自动化和DevOps以及BPM的联姻的。

据Holmes说，第一部是要做出一张能够说明通常是替BPM定义的目标映射图。这种模型的优势之一是可以更容易地切换到不同的基础设施组件。它还可以让现代BPM模型中的各种技术角色规划更加容易。还可以让业务线的经营人员在不需要IT的情况下也能创建和修改业务逻辑。开发者则更专注于确保应用在规则改变时能够提供一致的功能。

映射的目标是提高业务端的人对IT系统运作方式的可视性。下一步就是映射规则和某人做的决策以建立存储库。

模型组件

Red Hat的愿景基于一个围绕着企业架构进行绘画结构化的设计模型。这些组件包括对业务和逻辑进行建模、对工件定义版本，开发和存储程序包、部署包并执行业务逻辑等。

建模就是捕捉执行业务逻辑这个任务。这个逻辑可以用应用代码来建模，加上业务自动化元素或者两种方法的结合。这包括了想到编辑工具、集成开发环境（IDE）、基于文档的生成和电子表格等。

版本控制系统是也包括有源代码和业务逻辑在内的业务逻辑工件的主存储库。版本化可以让记录工件变更日后更加容易并且可以实现过去版本的恢复。

生成系统包括准备过程以及编译工件为程序包用于发布。这些程序包存放在程序包存储库，后者包括了一个逮捕书软件包的主要来源。这样在每次需要部署时可以更加有效和一致地重建程序包。

部署系统执行预定义且之前经过验证的决定以减少错误的几率。这包括了一个管理控制台、对应用资源的包括，以及推送运行时以及轮训运行时工具。

执行环境包括服务器、存储、操作系统、无论以及其他执行业务逻辑所需的系统。

混合搭配组件

这一基本框架看起来有点像一份固定价格菜单。它先从6个问题开始，每一个组件都要求一个答案。就像菜单一样，从6个类目当中选出一个选项非常重要。

“每一类目选出1个以上选项是可能的，就像饭店一样，”Holmes说：“只是这么做的代价是需要更多的开发和维护。”

另一件重要的事情，他补充说，是开胃菜并不影响前菜。在这个框架中，业务建模工具的选择对执行环境的选择并没有影响。各种组件都可以切换自如。这些都是垂直的决定，是可以随时改变的。

“这对我们来说不是独一无二的，”他说：“同样地模式你可以用在竞争对手或者你自己的内部工具上。”

Holmes用几个案例研究来说明他的观点。例子之一是一家希望检查信用卡欺骗性收费行为的公司。据称其决策模型可以更容易地把治理引入到这一过程当中。另一个例子是医院，这家医院试图在现有的IBM BPM系统之上增加功能。Holmes说设计模式方法使得他们可以看到哪些地方的技术是有重合的，然后再进行合理化。

利用版本控制

Red Hat做出了一个有趣的架构性决定，把它的JBoss BPM从数据库驱动的版本控制和生成系统转为基于Git的版本控制和Maven生成系统。

“对于一个相对较小的技术变化来说这代表了一种大规模转变，”Holmes说：“原因是这个行业一直以来都是用数据库和专利版本控制的。但是在CI/CD（持续集成/持续开发）的世界里面没有这个传统。”

Holmes说这一决定部分是基于这个事实，即这些工具已经是可以检查组件完整性以及寻找安全漏洞的软件供应链概念的一部分。他还指出这些问题已经在现代CI/CD中得到解决。

“如果所有解决方案都要你自己做的话用数据库很难实现这个，”Holmes解释说：“我们决定不要自己开发生成或版本控制系统。这是一个大规模的转变，因为每一条规则变更都要经过跟Java代码相同的持续交付管道。”

让开发者和业务端用一样的IDE

Holmes还说这一新模型可以让业务用户和开发者使用相同的开发工具进行代码编写和业务流程设计，传统业务自动化服务有个web门户是很正常的，因为这可以让不太懂技术的用户使用，而开发者则使用IDE。据Holmes说，这种办法可以把责任分得很清楚，而且IDE专门做几件事、Web界面专门做另几件事实有可能的。

Holmes还说把这两个都集成进同一个IDE里面可以让支持跨职能团队协作成为可能，这样看起来也像一支现代的敏捷团队。

“这种办法鼓励我们建立跨职能的团队，这样学科专家和开发者就能处在同一个团队，使用相同的工具，”Holmes说。