本章讨论了控制复杂度的设计思想,包括对结构复杂度的控制和对过程复杂度的控制。在控制结构复杂度的时候,对粒度的控制在控制结构复杂度时起到了很大的作用。从单体系统到SOA系统就是粒度不断变小的趋势的最好证明。可以说更细粒度封装的组件使得变更更加容易和可行,因为封装的特性使得该组件与其他组件在内容上互不影响,这看似与我们在第1章所讨论的柔性的定义一致。但是是否粒度越细,柔性就越高呢?我们当然希望获得充分的柔性以应对各种变化,但与此同时我们也需要知道实现柔性或者说采用更细的粒度所带来的成本甚至代价。这是业务流程管理者在进行设计的时候需要考虑清楚的重要决策之一。

回忆我们在3.2.3中讨论的3个流程设计方案中的方案二和方案三。这可以作为粒度的选择对柔性的影响的例子来讨论。其中方案二全部使用细粒度的Web服务,而方案三则全部使用粗粒度的Web服务。现在我们要判断的是这两种方案中,谁的柔性更高。既然柔性的定义涉及应对变化的能力,那么我们就来看看这两个方案在面对同样的变更需求时是如何实现变更的。为了完成这样的实验,我们还需要设定几个变更的情景(scenarios):

·S1:移民法规对各项收入要求进行调整和变更。这其实是最容易发生的变更情况。实际上,该法规对收入的要求是每6个月(每年的1月1日和7月1日)进行一次调整,调整的依据是财务部根据当前荷兰国内的通货膨胀率提出的调整数据。虽然每次调整并不大,但是作为一项法律法规,行政单位是必须严格遵守并按指定的时效开始执行。

·S2:调整对年龄的要求。这项变更在实际中至目前为止还未发生过。可以说以30岁作为界限的设定是相当稳定的一个条件。但是如果要调整的话,还是能有好几种可能,包括改变30岁的这个分水岭,变成比如35岁(S2a);或者增加一项年龄的档次,另设一个对50岁以上申请人的要求(S2b);也或者是减少申请条件,取消对不同年龄的区别对待(S2c)。

·S3:增加新的额外条款。这种情况可以有许多种可能。在实际的法规变更中,出现了两次这种变更。一次是在原有逻辑的基础上,添加了一条规定:对在荷兰正规高等院校毕业一年之内的外国学生的收入要求降至25000欧元每年。此举是为了留住受过高等教育的国际化人才在荷工作。后来又在此基础上扩大了受众群体,让所有在荷兰正规高校毕业的博士,以及来自全球排名前150名高校毕业的硕士和博士都可以享受以上的条款。

有了以上的变更情景之后,要比较方案二和方案三在柔性上的高低,实际上就是比较它们在以上情景当中是如何实现变更的。我们不将方案一纳入这个比较当中是因为作为一个单体系统,以上任何一个情景的变更都是对整体的影响。

首先我们来看S1情景。S1属于非结构性的调整,即无论哪个方案都不需要调整它们的流程结构。在单个修改任务上细粒度的服务会有微弱的优势,因为Web服务内部的结构更加简单。然而,方案二要修改两个细粒度的Web服务,而方案三只需要修改一个粗粒度的Web服务。所以在此情景中,这两个方案在变更上的工作量相当,任何一方都没有较对方明显的优势。

接下来我们继续比较在S2情景下的情况。其中S2a对于方案二和方案三而言也是非结构性的调整。在方案二中,我们只需要把流程判断条件中的30改为35即可。在方案三中,也是对MakeDecision服务中的条件做一次修改。两个方案中的修改任务都只有一次,工作量相差无几。但是在S2b和S2c的情况下,对于方案二而言就不再是非结构性的调整了。在S2b中,方案二需要在30岁以上的路径下再分列两条路径,以处理大于等于30岁且小于50岁的情况和大于50岁的情况。与此同时还需要单独为这两种情况开发专门的Web服务。最后流程的总路径会上升至3条,分别是:小于30岁、大于等于30岁且小于50岁、大于50岁。在S2c的情况下,整个方案二需要推倒重建,因为原先基于年龄的判断已经不在了。对于方案三而言,在S2b和S2c的情况下处理起来都要容易不少。在S2b的情况下,只需要在MakeDecision服务中添加一段判断语句。在S2c的情况下,整个MakeDecision服务需要改写,但是流程本身只需要修改调用的环节InvokeMakeDecision。至于GetProfile服务,如果不做修改其实问题不大,只是会产生一个无用的变量age。

最后我们再来看看S3的情况。该情景要实现起来会复杂很多。在方案二中,如果想尽量保持原有的流程不做变动,那么就需要在流程的最开始处(即receiveInput之后)判断申请人是否为应届毕业生;如果不是则继续进行现有的流程,否则就要进入新建的流程进行处理。这里涉及如何判断一个申请人是否为应届毕业生,这很可能需要新建一个Web服务来完成这项功能,然后还要根据相应的业务逻辑开发另外一个包含根据收入情况进行判断的Web服务。更改之后整个流程会与之前有很大的不同。在开发新流程的过程中,GetIncome服务可以得到重用,这个是细粒度服务在重用性上的优势所在。但是在进行流程开发和部署上,方案二还需要做许多工作,包括开发新的Web服务,重新部署新建的流程等。对于方案三而言,这样的更改同样不轻松。但较之方案二,方案三有一个优势在于,即使在这样巨大的改动下,方案三的流程部分依然可以保持不变。其更改的结果可能会产生一个较为臃肿的MakeDecision服务。在这种情况下,MakeDecision服务内部的结构会变得比较复杂,这已经不是能够靠单纯地增加几行“IF…THEN…”的判断语句可以实现的。在这个Web服务的内部,不得不包含新的流程。由于Web服务只是一种封装的技术手段,服务的内容无特别的限制,它既可以是基于软件的服务(SBS),也可以是人工提供的服务(HPS),或者两者混合在一起。一个业务流程自然也可以封装在一个服务当中,而这个业务流程本身也可以调用其他Web服务。整个方案三改造的过程实际上就是在一个简单的流程之外构建了一个复杂的服务以完成相应的功能,为了实现这个复杂的服务又往里面添加的新的流程。

综合以上三种情景下方案二和方案三的更改情况来看,方案二只能在细微的更改下保持全局的姿态不变,而方案三不管在何种变更发生的情况下,其基本形态均不受影响。从柔性的定义,即在处理的过程中只改变或调整系统中受这些变更所影响的活动,同时保持不受影响的活动的本质形态^[55]来看,方案三的柔性会更高。

与此同时,通过对方案二和方案三的比较我们还可以发现,复杂度可以在结构复杂度和过程复杂度之间出现转移的现象。如果我们想保持Web服务内部的结构简单功能单一,在应对复杂的变更情景时就需要构建相对复杂的流程,以便使用这些简单的Web服务,这是方案二的特点。如果我们想要保持流程的简单纯粹和不受变更的影响,那么我们就不得不增加Web服务内部结构的复杂度,这是方案三的特点。以上的讨论也可以再次反映本章在第一节所阐述的观点:一个系统的复杂度是其与生俱来的特性,不管如何进行简化,复杂度不会凭空消失,只会从一种形式转移成另外一种形式。

明白结构复杂度和过程复杂度之间的相互转化关系,对于业务流程的设计而言,具有重要的指导意义。因为系统的分解和划分是一件人为的事情,而我们在处理各种复杂系统的时候习惯性地采用各种分解手段来控制结构复杂度。在许多IT工作中,工程师们也无可厚非地希望各个组件具有更高的可重用性。但是从业务流程柔性的角度考虑,他们必须知道各种方案的利弊,以选择合适的粒度去平衡结构复杂度和过程复杂度。而且从系统柔性的角度出发,良好的柔性表现往往预示着一个恰到好处的平衡点:过粗的粒度无法带来足够的柔性(例如方案一),过细的粒度造成过高的过程复杂度又会降低系统的柔性(例如方案二)。

【注释】

[1]Sommerville I.Software Engineering[M].9th ed.Boston,MA:Addison-Wesley,2011.

[2]Norman D A.Living with Complexity[M].Cambridge,Massachusetts:MIT Press,2010.

[3]Érdi P.Complexity Explained[M].Heidelberg:Springer,2007.

[4]Del Re G.From Complexity Levels to the Separate Soul[M]//Agazzi E,Montecucco L.Complexity and Emergence:Proceedings of the Annual Meeting of the International Academy of the Philosophy of Science Bergamo,Italy 9-13 May 2001.Singapore:World Scientific Publishing Company,2002:181-203.

[5]Simon H A.The Sciences of the Artificial[M].3rd ed.Cambridge,Massachusetts:MIT Press,1996.

[6]Berryman S Democritus.Stanford Encyclopedia of Philosophy[EB/OL].http://plato.stanford.edu/.

[7]Polkinghorne J C.Reductionism:Interdisciplinary Encyclopedia of Religion and Science[M].Rome:Centro di Documentazione Interdisciplinare di Scienza e Fede,2005.

[8]Simon H A.The Sciences of the Artificial[M].3rd ed.Cambridge,Massachusetts:MIT Press,1996.

[9]Merali Y:Complexity and the Services Science Agenda[M]//Hefley B,Murphy W.Service Science,Management and Engineering Education for the 21st Century.Heidelberg:Springer,2008:285-293.

[10]何明昕.关注点分离在计算思维和软件工程中的方法论意义[J].计算机科学,2009,36(4):60-63.

[11]Dijkstra E W.On the Role of Scientific Thought,Selected Writings on Computing:A personal Perspective[M].New York:Springer,1982:60-66.

[12]Hürsch L W,Lopes V C.Separation of Concerns[R].Technical Report,Boston:Northeastern University,1995.

[13]所谓硬编码是指在程序当中要改变参数时必须修改原始代码并重新编译的情况。

[14]Nutt G J.The Evolution towards Flexible Workflow Systems[J].Distributed Systems Engineering,1996,3(4):276-294.

[15]Medina-Mora R,Winograd T,Flores R,et al.The Action Workflow Approach to Workflow Management Technology[C].ACM Conference on Computer-Supported Cooperative Work,1992:281-288.

[16]Georgakopoulos D,Hornick M,Sheth A.An Overview of Workflow Management:From Process Modeling to Workflow Automation Infrastructure[J].Distributed and Parallel Databases,1995,3(2):119-153.

[17]Sommerville I.Software Engineering[M].9th ed.Boston,MA:Addison-Wesley,2011.

[18]Sommerville I.Software Engineering[M].9th ed.Boston,MA:Addison-Wesley,2011.

[19]Faget J,Marin M,Patrick M,et al.Business Processes and Business Rules:Business Agility Becomes Real[M]//Workflow Handbook 2003.Lighthouse Point:Future Strategies Inc.,2003:77-92.

[20]Lienhard H,Künzi U-M.Workflow and Business Rules:A Common Approach[M]//Fischer L.Workflow Handbook 2005.Lighthouse Point:Future Strategies Inc.,2005:129-140.

[21]Müller R,Greiner U,Rahm E.Agent Work:A Workflow System Supporting Rule-Based Workflow Adaptation[J].Data＆Knowledge Engineering,2004,51(2):223-256.

[22]Faget J,Marin M,Patrick M,et al.Business Processes and Business Rules:Business Agility Becomes Real[M]//Workflow Handbook 2003.Lighthouse Point:Future Strategies Inc.,2003:77-92.(www.daowen.com)

[23]Studer R,Benjamins V R,Fensel D.Knowledge Engineering:Principles and Methods[J].Data＆Knowledge Engineering,1998,25(1-2):161-197.

[24]Kendal S,Creen M.An Introduction to Knowledge Engineering[M].London:Springer,2006.

[25]Gaines B R,Shaw M L G.Eliciting Knowledge and Transferring It Effectively to a Knowledge-Based System[J].IEEE Transactions on Knowledge and Data Engineering,1992,5(1):4-14.

[26]Gasˇevic′D,Djuric′D,Devedzˇic′V.Model Driven Engineering and Ontology Development[M].2nd ed.Heidelberg:Springer,2009.

[27]Gaines B R,Shaw M L G.Eliciting Knowledge and Transferring It Effectively to a Knowledge-Based System[J].IEEE Transactions on Knowledge and Data Engineering,1992,5(1):4-14.

[28]Russell S J,Norvig P.Artificial Intelligence:A Modern Approach[M]//3rd ed.Upper Saddle River.New Jersey:Prentice Hall,2010.

[29]Lee J,Siau K,Hong S.Enterprise Integration with ERP and EAI[J].Communications of the ACM,2003,46(2):54-60.

[30]Samtani G,Sadhwani D.Enterprise Application Integration(EAI)and Web Services[M]//Web Services Business Strategies and Architectures.New York:Apress,2002:38-55.

[31]Howe J.The Rise of Crowdsourcing[J].Wired Magazine:CondéNast,2006,14(6):176-183.

[32]Erl T.Service-Oriented Architecture:Concepts,Technology,and Design[M]//Upper Saddle River.New Jersey:Prentice Hall,2005.

[33]Parnas D L.On the Criteria to be Used in Decomposing Systems into Modules[J].Communications of the ACM,1972,15(12):1053-1058.

[34]Parnas D L.On the Criteria to be Used in Decomposing Systems into Modules[J].Communications of the ACM,1972,15(12):1053-1058.

[35]Schilling M A.Toward a General Modular Systems Theory and Its Application to Interfirm Product Modularity[J].Academy of Management Review,2000,25(2):312-334.

[36]Tiwana A,Konsynski B.Complementarities Between Organizational IT Architecture and Governance Structure[J].Information Systems Research,2010,21(2):288-304.

[37]与之相对的是一些难以通过计算机完成而必须由人工来执行的部分,比如判断所提交的证明材料的真伪和完整性(是否签字盖章等)。

[38]Van Engers T.Legal Engineering:A Structural Approach to Improving Legal Quality[M]//Macintosh A,Ellis R,Allen T.Applications and Innovations in Intelligent Systems XIII,London:Springer,2006:3-10.

[39]Gino F,Staats B R.The Microwork Solution:A New Approach to Outsourcing Can Support Economic Development-and Add to Your Bottom Line[J].Harvard Business Review,2012,90(12):92-96.

[40]Malone T W.Modeling Coordination in Organizations and Markets[J].Management Science,1987,33(10):1317-1332.

[41]Crowston K.Towards a Coordination Cookbook:Recipes far Multi-Agent Action[D].MA:MIT Sloan School of Management,Cambridge,1991.

[42]Malone T W,Crowston K,Lee J,et al.Tools for Inventing Organizations:Toward a Handbook of Organizational Processes[J].Management Science,1999,45(3):425-443.

[43]Malone T W,Crowston K,Lee J,et al.Tools for Inventing Organizations:Toward a Handbook of Organizational Processes[J].Management Science,1999,45(3):425-443.

[44]Schonenberg H,Mans R,Russell N,et al.Process Flexibility:A Survey of Contemporary Approaches[M]//Dietz J L G,Albani A,Barjis J.Advances in Enterprise Engineering I.Heidelberg:Springer,2008:16-30.

[45][92]Malone T W,Crowston K.The Interdisciplinary Study of Coordination[J].ACM Computing Surveys,1994,26(1):87-119.

[46]Crowston K,Rubleske J,Howison J.Coordination Theory:A Ten-Year Retrospective[M]//Zhang P,Galletta D.Human-Computer Interaction and Management Information Systems:Foundations.New York:M.E.Sharpe,2006:120-140.

[47]Soffer P.On the Notion of Flexibility in Business Processes[C].CAiSE'05 Workshop,2005:35-42.

[48]Alexander C,Ishikawa S,Silverstein M,et al.A Pattern Language:Towns,Buildings,Construction[M].New York:Oxford University Press,1977.

[49]Alexander C.The Timeless Way of Building[M].New York:Oxford University Press,1979.

[50]Gamma E,Helm R,Johnson R,et al.Design Patterns:Elements of Reusable Object-Oriented Software[M].Boston,MA:Addison Wesley Professional,1994.

[51]Fowler M.Patterns of Enterprise Application Architecture[M].Boston,MA:Addison-Wesley Professional,2002.

[52]Van der Aalst等人在对这些模式进行命名的时候使用的是“工作流模式”(workflow pattern)。这除了跟他们的信息技术和计算机科学的研究背景和长期使用的命名习惯有关之外,也说明了这些模式通常使用在(软件)技术环境下,即工作流以及其他与流程相关的信息技术的设计和实现当中。关于工作流与业务流程之间的联系与区别我们在第1章讨论过,业务流程管理可以采取技术视角,也可以从组织和管理等非技术视角来改进业务流程,而工作流侧重技术视角。Van der Aalst等人在介绍他们总结的模式时并未强调这一区别,也同时使用“业务流程”和“工作流”这两个词汇。本书遵循这种处理方式,并将这些模式统称为“流程模式”。

[53]http://www.workflowpatterns.com/。

[54]Suriadi S,Andrews R,Ter Hofstede A H M,et al.Event Log Imperfection Patterns for Process Mining:Towards a Systematic Approach to Cleaning Event Logs[J].Information Systems,2017,64(1):132-150.

[55]Schonenberg H,Mans R,Russell N,et al.Process Flexibility:A Survey of Contemporary Approaches[M]//Dietz J L G,Albani A,Barjis J.Advances in Enterprise Engineering I.Heidelberg:Springer,2008:16-30.