写点什么

BPM 不是软件工程

  • 2009-01-30
  • 本文字数:1853 字

    阅读完需:约 6 分钟

Keith Swenson 在其发布于 BPM.com 的新文章的开头这样写道:

BPM 社区中的大多混淆和困难都是由于某些人认为BPM 是软件工程的一种而造成的。的确,从外表看它非常象软件工程:由需求开始,然后确定需要在变量中保存和检索的信息,接着可能要画出它们之间的关系,最后就是把成品在联网的计算机上安装和执行。但是,它们之间存在区别,而这个区别就是 BPM 之所以存在的原因。

根据 Keith 的说法,软件工程在其 50 多年的历史中已经取得了极大的进步,包括结构化和面向对象编程、复杂的建模语言(UML)和大量在开发过程每个阶段发挥作用的工具。结果,软件工程师会将“业务流程管理”视为另一项将图转换为可执行程序的简单活动:

当我们手握锤子的时候,我们会开始把所有围绕在我们周围的问题都看作是钉子……业务流程步骤被解释成和程序步骤完全类似。软件工程师几乎靠条件反射就能将高级别功能翻译成低级别的函数序列,然后借助控制流等将其翻译成某种最终可转换成机器语言、执行就绪的东西。我猜想很多人都有这样的感觉:BPM 纯粹是大量的市场炒作,其核心不过是软件工程世界中很平常的东西。这到底有什么了不起?

Keith 试图通过区分业务流程和典型的程序来定义软件工程和 BPM 的区别:

“业务流程”不是程序。支撑它的虽然可能是程序,但是业务流程是组织想要完成的事情。你可以说业务流程是程序的目标,而不是程序本身。业务流程由业务人员管理:这个人他理解“业务”,决定完成业务的策略,评估业务的健康状况,决定如何变更业务以满足不断变化的条件。软件工程师管理软件,而业务人员则管理业务流程。

他接着概述了 BPM 解决方案和一般程序的主要区别:

  • 业务人员所画的图就是被执行的那张图。它不会为了软件工程师的方便而转换成其他形式。它不会为了执行而转换成其他形式……这种转换是出于优化执行的目的,尤其是在处理能力有限的机器上。某些业务流程仍将需要这种转换,但是绝大多数的业务流程将不会受限于 CPU 的性能。
  • 历史和分析报表需要匹配原始图表,以支持业务用户能评估组织的执行状况,它不是为了让程序员能分辨程序的运行状况。
  • 在软件系统中,用户很少需要知道程序的内部结构,但是从这个角度来说,业务流程不是程序。流程本身必须是可见的,即便有程序支撑它执行也是如此。参与流程的人必须能了解当前步骤、后续步骤和最终步骤。这是 BPM 和软件工程的最大区别。

根据 Keith 的说法,混淆和误解的一个最大来源是由于 BPM 设计和开发大都是由软件工程师完成的:

遗憾的是,很多研究 BPM 系统的人大都具有软件工程的背景,并下意识地认为 BPM 应该具有某种标准软件的特性。软件工程师将系统视为一种发送、接收和转变信息的手段,他们受训将业务问题归纳为可以按这些方法来执行的某种事物。业务人员不会把焦点放在字节的发送和接收上,相反他们更看重职责和承诺。这是看待业务流程的不同方法。这种区别的效果是巨大的。试图把所有软件工程的特性都装入到 BPM(业务人员)的特性中,其结果必然是两面不讨好。时至今日,你仍会碰到一些人认为 BPEL 是实现业务流程的终极方式。BPEL 仅仅提供了一种发送、接收和转换的手段……这些是软件工程的需求,而不是业务流程的需求。软件工程师会告诉你,利用这些原语(primitive)你可以实现任何东西,可能包括电子表格,但是这忽视了一个要点,一个我们一开始为什么需要电子表格和 BPM 的要点:因为它们不是软件工程。

Keith 在其文章的结尾对目前 OMG BPMN 2.0 活动进行了评估:

在 OMG 邮件列表中,关于“BPMN 怎么会只是统一建模语言(UML,软件工程师钟爱的作图标准)的另一个方言”激起了广泛的讨论。软件工程师的确可能会从 BPMN 中看到对软件工程有用的东西。记住,OMG 组织主要是由软件工程师构成并为软件工程师服务的,大多数 OMG 成员会得出以上结论完全不足以为奇。他们大多数甚至可能认为 UML 对所有学科都有用。把 BPMN 看成是 UML 的一个方言对于将把一张图归纳成一个可执行程序的软件工程实践非常有用。

BPMN 的存在是为了让业务人员可以表达业务单元内部人员之间的交互。在 OMG 内部也有不少的人明白这一点,我希望这些人不要被那些认为所有问题都是软件工程问题的人所压倒,这样对我们大家都有好处。BPMN 的存在不是为了软件工程师的方便,因为 BPM 不是软件工程

在业内,对于软件工程和 BPM 之间的关系的确存在大量混淆。它们是完全不同,但又相互关联的学科。一方面,完全有可能设计和实现没有任何自动化的业务流程;另一方面,业务流程自动化确实需要涉及大量的软件工程。

查看英文原文: BPM Is Not Software Engineering

2009-01-30 02:341771
用户头像

发布了 255 篇内容, 共 56.6 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

Python基础详解(一)

五分钟学大数据

Python 7月月更

百度APP iOS端内存优化实践-大块内存监控方案

百度Geek说

ios

Rancher2.6 Monitoring Grafana 对接 LDAP

Rancher

Kubernetes k8s rancher

数据库每日一题---第22天:最后一次登录

知心宝贝

数据库 算法 前端 后端 7月月更

JAVA编程规范之OOP规约

源字节1号

后端开发

30岁被裁,我想明白的几件事

老张

职业第二曲线 职场发展

浅谈:NFT元宇宙链游系统开发原理

开发微hkkf5566

2022阿里最新流出MySQL性能优化实践笔记,GitHub上已获千万赞

了不起的程序猿

Java 数据库 java程序员 MySQL 数据库

Python丨实用技巧Tips

AXYZdong

Python 7月月更

来了,MyBatisPlus的join联表查询

冉然学Java

Java mybatis 编程、 Fork/Join框架

推荐一个鸿蒙即时通讯软件《果聊》,有点屌呢!!

坚果

OpenHarmony 7月月更 harmony

户外全彩LED显示屏显示功能

Dylan

全彩LED显示屏 户外LED显示屏

java培训JVM中方法调用的深入理解

@零度

JVM JAVA开发

AI简报-how to use Loss Surfaces 一种模型集成

AIWeker

AI简报 7月月更

亚马逊云科技如何通过智能营销帮助苏泊尔实现年产破亿?

Lily

浅析eTS的起源和演进

HarmonyOS开发者

HarmonyOS

渗透测试(PenTest)基础指南

SEAL安全

网络安全 DevSecOps 渗透测试 开源软件供应链 软件供应链安全

React Native 跨端框架与小程序混编实战

Speedoooo

flutter 小程序 React Native APP开发

架构“浴火重生”宝典名不虚传!GitHub开源半日标星竟已超300k!

冉然学Java

Java 架构 笔记分享 #Github #开源

用友网络:把握穿越周期的关键,高研发投入下的发展韧性

Lily

AWS Trusted Advisor

冯亮

云计算 DevOps AWS

OneFlow源码一览:GDB编译调试

OneFlow

源码 编译调试 框架解析

来TDengine 开发者大会,探索数据架构的迭代升级

TDengine

数据库 物联网 ​TDengine

双引擎 GPU 容器虚拟化,用户态和内核态的技术解析和实践分享

Baidu AICLOUD

异构计算 AI加速 GPU容器虚拟化

web前端培训从 Vue CLI 怎样迁移到 Vite

@零度

前端开发 vite

墨天轮沙龙 | 北京大学李文杰:面向知识图谱应用的图数据库系统gStore

墨天轮

数据库 图数据库 知识图谱 开源数据库 国产数据库

Android-聊聊自动化测试真经

芝麻粒儿

android 7月月更

秒懂 Git 与 Gitee

攻城狮杰森

git gitee 7月月更 入门教程

Neuron 2.1.0发布:支持Sparkplug B规范,更完善的工业协议支持

EMQ映云科技

物联网 IoT 工业 7月月更 版本发布

Pro 多店版系统,功能全才非它莫属!

CRMEB

得物数据库中间件平台“彩虹桥”演进之路

得物技术

数据库 云原生 中间件 得物 彩虹桥

BPM不是软件工程_SOA_Boris Lublinsky_InfoQ精选文章