Alec Sharp探讨建模与BPMN

个人简介 Alec Sharp，从业30多年，其中的25年从事咨询顾问工作。他在一个比较偏门的多个合领域里有着深厚的积累，这些领域包括：业务流程识别、建模、分析与二次设计；应用需求规约；数据建模和信息管理等。他是Clariteq Systems咨询有限公司的资深咨询顾问兼创始人。

   

1. 这次您因何来到新西兰？

这次我是作为软件教育（Software Education）组织成立20周年活动的嘉宾来的。20年并不意味着伟业，在一个领域里坚持这么久意味着他们在做正确的事情。而且我也愿意这么想，因为他们在多次客户交流中邀请我去做了演讲。

   

2. 一直以来困扰一些InfoQ读者的一件事情是：人们对建模的抵触，或者说建模的价值所在。我们为什么要建模，尤其在今天这样一个到处推崇敏捷的世界里。

实际上刚刚你问道了三到四个问题。我们还是先回到第一问题上把。你谈到对敏捷的抵触。我认为导致这一情绪的原因是，我们看到的建模往往在这样一个层次上，我称之为规约层。譬如，在数据建模领域，当人们看到一个数据模型，他们实际看到的是某个物理的数据库设计的图形化表示。在业务流程建模领域，尤其随着BPMN的出现，当我们看到一个完整的流程模型，它并不怎么以业务人员容易理解或阅读的方式呈现的，而更多地是为具体的自动化工作流而设计的——某个SAP工作流或MQ消息流程或某些类似工具上的工作流。

我认为这种情况发生的原因是，为了建模而开发的工具的主要目的是支持（应用）构建，而不是分析或规划。因此，这导致了人们的抵触。我还可以对这个问题做进一步开讨论，但我记得你还问到了别的问题，比如：我们为什么要建模？——如果我们要解决的问题不是直观可见的，那我们就应该建模。所以，最好为它建立图形化或符号化的模型，这样，人们容易对要讨论的问题能达成一致的理解。这样，我们也许能够像操纵一个流程模型一样操纵模型，而不需要在参与流程的人员之间走过来走过去。

任何时候，只要你发现你不能直观地看到你正在做的事情，建模都是合理的。你的身体姿态在向我表明你想问下一个问题了，但是还是让我对这个问题多谈一点点。业务流程，是我做了大量建模的领域，它就是一种不一定能被直观看到的事物。不能一次就看明白，尤其当流程牵扯到处于不同地理位置的人员时。在这种情况下，一个简单但完整的模型是无价的。而对于一群，比方说，工位紧密聚集在一起的人们而言，其价值就会打很大折扣。

   

3. 这套构建复杂模型的概念与敏捷思想“能简单就简单”不冲突吗？

不，会冲突。构建复杂的模型与敏捷思想一定是冲突的，但是简单的模型不会。我给你举一个例子。如果我在作战室（War Room，译注：项目管理用语，指项目成员聚在一起办公）的墙上将积压工作（backlog）中用户故事（User Story）列举出来，这就是一种模型。它是一种文字形式的模型，或者，我还可以将我的用户故事（User Story）写在一些好看的贴纸上，但这仍然是模型。这样的模型我称为范围层模型。我们可以稍后对此做进一步展开，但是只要是我参与的建模，不论它是流程建模、用例建模、业务服务规约建模或者是数据建模，都可归类到三个层次：范围层、概念层和规约层。

那些详细的模型，只要包含足够的内容，足够严格，实际上都能从它们构建出代码的，它们是规约层，这些模型可能不大适合敏捷环境。但是范围层模型，如“这是我们要实现的一组流程或用户故事（User Story）”或“这是我们的流程的高层次的整体图景”——这些模型就完全适合。而且，随着项目范围的增长，它们就变得非常有用了。

   

4. 能不能进一步解释您刚刚提到的建模的不同层次？

一些读者可能熟悉Zachman框架。John Zachman是该领域的开拓者之一，他指出，尤其在他早期探讨信息系统的文章中指出，当我们讨论问题或为之建模时都有在这么三个层次。其实层次不止三个，但是我关心的是最主要的三个。第一层被他称为“规划者视图”，也就是非常高层的模型，供我们探讨范围，比如输入是什么，输出是什么。这对应于我所说的范围层建模。接下来他谈到的是“所有者视图”，这一层次的模型是问题的所有者比较喜欢的模型。

它则类似于我的词汇中的概念模型。简单的符号、方框和线条，没有太多的语义规则，但在多个参与者之间建立沟通却是非常棒的。然后，进一步细化下去就到了John所谓的“设计者试图”，这类模型的详细程度足以用它们来构建代码。John早期的文章是通过与建筑物进行类比来进行描述的，然而，我和这个世界上的成千上万的人都用他这套方法来讨论业务和系统结构。我还可以进一步讲一下。假设我们谈流程——还是那句话，这是我做得工作最多的领域——一个范围级流程可能是一个简单的方块，它描述的可能是一个家族，即一组相关联的业务流程，譬如客户关系管理。

也许，其中还描述了这个范围中的单个流程，如增加新客户、完成一次客户访谈、解决客户服务问题，诸如此类。甚至还可能会细化到流程里面的步骤，但这仍然是一个简单的块图，人们可以指着这些方格说“这些属于范围内，而其他的就不在范围内了”，同样，人们不需要参加任何培训、不需要使用任何特殊工具就能理解并创建这样的模型。然后，在流程上下文中，如果我们要看一下它的概念及流程模型，则可能借助于泳道图，可能借助于分解图。

但我们将依赖于泳道图，它描述了流程中不同的参与者，方框和线条显示了不同角色执行的活动以及它们之间的整体流向关系。在做这些事情时，需要的仅仅是方框和线条，甚至不需要我们的老朋友——棱形的决策块。没有过多的符号，业务人员在看这样的模型时一点儿也不会感觉到不舒服。这一层次的模型非常有益于人们分享对流程的整体理解。顺便说一句，这些模型在敏捷环境中是非常有用的，其中每个步骤则可能对应了一个用户故事（User Story）。

在每个框中还有很多细节和规则，但是我们并不需要看到这些。我们仅需要看到整体流程，以便于形成流程概念。最后，我们可以细化到规约层或细节层，此时我们所在的层次有太多的细节，它们展示了不同的流程路径，这一层非常具体，以致于便于在某个工作流引擎上实现。换句话说，你可能有一个非常细化的BPMN模型，根据它就能生成运行在某个商业工作流工具上的BPEL。

   

5. 这就是一些东西，如BPMN，用得太重的地方吗?

绝对！人们常常指着我是BPMN的批判者，坦白地说，有一阵子是这样的。但是我反对的更多的是工具的误用。如果谈论的是非常细节的逻辑的数据模型或类图，这当然是可以的，而且还有必要细化到这个层次，但是如果在概念层，我们只需要达成对事物的共识，细化到这一层次就不需要了。

   

6. 我听过您用一个词语来描述BPMN这样的工具，称其为“可视化编程语言”。

是的。我这句话很容易得罪某些人。有一次我看到一张BPMN图，然后我发现如果把这张图拿给负责该流程的业务人员去看，他肯定完全看不懂。与此同时，我脑海 中浮现了30年前的一副画面，那时我在用APL编程，我不清楚InfoQ的读者是否了解APL，但是如果你去Google一下，你就会发现APL其实是“一个编程语言” （A Programming Language）的缩写。这种语言由这样一些希腊字母构成的：Rho（大写P，小写ρ），Tau（大写Τ，小写τ ）和Omega（大写Ω，小写ω）及其他类似符号。它们每一个都代表一个矩阵操作，非常强大，你要做的是将他们排在一起形成有名的“一条线”，我们喜欢写这样的APL程序，它包含很多这些符号，但他们都在一行。

它们可以把事情做得很好，而且现在还有人在使用，比如说保险，在某些核保环节中。不论怎样，核保人员看到任意一个符号时绝对看不懂，但是它却代表着其某些重要的业务上的东西。我们还可以拿COBOL做个比较。你大概不会把COBOL程序中表达的逻辑呈给业务人员看吧，但是它的确很重要。怎么说呢，BPMN是一个类似的事物。它类似于APL，类似于COBOL，它是一种编程语言。我所反对的是人们把它称为业务流程建模语言。我认为把它称作自动化工作流规约语言要贴切很多。我猜无论哪个BPMN的粉丝看到这里时，都会被我气坏的。

   

7. 为我们做个总结，这些流程建模技术、方框和线条，它们如何在软件开发的世界里应用呢？如何在敏捷软件开发的世界里应用呢？

它们可能并不适用。如果我们要解决的问题是严格限制的，没有任何工作流，那么它们就可能不适用。实际上，在我的书中，在采访之前你非常大方地介绍过了，我们问过一个问题“什么时候应该对工作流进行建模？”答案是“当工作流动时，你就需要为工作流建模”——一点儿也不奇怪。如果你有一个复杂的订单处理流程，此项工作要从客户转到销售前台、转到订单管理人员、再到物流等等，那么一个简单的工作流就能帮到你。

正如人们理解“如果我做了这个用户故事（User Story），在此之前是什么，在其之后呢？”因为在一个复杂流程中，事情很容易变得不一致，或者错失改进或简化流程的重要时机。我认为，由于我们一直强调它的作用，当然是在合适的细节层次上强调——所以，我们就不需要花很多时间去建模，不需要花很多时间去争论什么场合应该使用什么符号。

然后，我认为它在敏捷环境中也极其有用，事实上，在过去几年我做了很多工作，也给一些敏捷团队做过许多培训，他们经常惊奇地发现范围和概念级建模非常有用，因为它可以帮你避免走一些弯路，而若不这样做则不能避免。而且，一些简单的概念模型，不管是流程模型，还是用例模型，或是过去最喜欢的数据模型，都能改善沟通，节约开发流程中的一些迭代周期。

   

8. 非常感谢您的时间，祝您好运，并祝此行愉快！

现在我身在世界上一个最好的地方，就在新西兰惠灵顿旁边，所以我是个开心的家伙。谢谢你们邀请我。