关注点分离是人们在计算科学和软件工程领域的长期实践中确立的一项方法论原则^[10]。所谓关注点分离即“分而治之”(divideand-conquer)的观点:将整体视为部分的组合体并对各部分分别加以处理^[11]。在编程中使用该原则,可以使程序中的不同信息保持局部性,以便于程序的编写、理解、重用和修改^[12]。而系统架构的不断发展,其实也是遵循着关注点分离的原则不断演化的过程,并且促使系统的柔性不断增加。

为了观察这个变化过程,我们选取业务流程管理系统的总体结构作为参照物来进行讨论。最初引入业务流程管理系统是在20世纪80年代。业务流程管理系统早期的实现方式是以文档为驱动的,系统中包含了许多硬编码(hard code)^[13],并倾向于实现办公自动化^[14]和仿照原有的高度结构化的文档处理过程进行系统设计^[15]。这样的系统通常包含一些常见的信息对象,比如数据表格或者电子文档,系统中运行的业务流程基本上是围绕着这些信息对象的处理工作。其主要的组织结构是围绕着处理这些信息对象的用户之间所形成的日常事务的形态,其中一部分工作可以通过计算机自动完成。这就好比是工厂里面的流水线,每个“零件”(信息对象)都按照同样的次序经过一个又一个“工位”(系统用户),而其中某些步骤可能由自动化的机器代替完成。

这样的系统被称为单体系统(monolithic system),即系统本身没有明显的层次结构(或者说所有的组件都在一个层次上),系统支持静态的业务流程管理,在设计的时候并未充分考虑业务流程可能产生的变化。Monolithic这个词通常表示“铁板一块”的意思,这个词义用在这里其实也相当合适。一些20世纪90年代中期的文献^[16]向我们介绍了当时的单体系统的架构是如何实现的。在一个组织当中,虽然多个单体系统之间有时候可能会共享一个中央数据库,但是它们各自运行的业务流程之间是彼此孤立的,受平台的限制,要想实现跨部门的流程非常困难。单体系统的内部结构是紧耦合的。在那个时代,越来越多的软件系统被各自的部门采用不同的技术进行单独的开发。有时候迫不得已非要在两个系统之间建立联系的时候,通常会在数据库后台进行一些表与表之间的数据交换,而在流程层面上的交互则基本没有,通常在技术上也不太可行。由多个相互独立的单体系统组成的企业应用环境如图3-1所示。

单体系统架构所能提供的业务流程柔性非常低,因为每一次变更所带来的配置管理工作都会非常复杂,并且影响整个系统。单体系统中实施配置管理的基本活动包括^[17]:

图3-1　包含多个单体系统的企业应用环境示意图

·变更管理:记录来自客户和开发者对于系统变更的请求,权衡这些变更的成本以及对系统的影响,并决定哪些变更请求应该被执行。

·系统编译:即组装程序的组件、数据和运行库的过程,并通过编译产生可以运行的系统。

·版本管理:包括追踪系统各组件的不同版本,并确保不同的开发者对组件所做的更改不会影响到其他组件。

·发布管理:包括准备向用户发布系统的工作,并追踪所有已向用户发布的系统版本。

由于在单体系统当中,每一个细微的变化都需要对系统进行重新编译和发布,这样就加大了配置管理的工作量。与此同时,当许多变更交织在一起的时候,版本控制变得非常繁琐。这些繁琐的工作使得系统应对变化的速度变得迟缓,维护成本也随之提高(见图3-2)。许多组织逐渐意识到这个问题:没有一个集成的环境,这些单体系统能够提供的效率也非常有限,柔性的缺乏使这些系统在使用和维护上越发成为阻碍组织快速应对环境变化的绊脚石。

图3-2　配置管理的基本活动^[18](www.daowen.com)

虽然在第一代业务流程管理系统的设计当中,基本没有在架构层面上体现出关注点分离的应用,但是第二代的系统已经开始考虑企业对柔性的需求,特别是如何应对需要经常更改业务流程的情况,出现了“流程与规则分离”的设计^[19][20]。Muller、Greiner和Rahm甚至将这种设计看做2000年前后那一代BPM系统的典型架构特征^[21]。流程定义了内部实体(如部门、员工、应用程序等)和外部实体(如客户和合作伙伴等)之间进行交互的方式,它关注的是业务行为是如何执行的。而规则代表的是决策过程中的知识和逻辑,它关注的是“做什么”(what),即具体的内容;而不是“怎么做”(how),即执行的过程^[22]。流程与规则分离的原因在于,流程通常是相对固定的,而进行决策的规则却经常发生变化。举个简单的例子,多数情况下,一个审批的流程大致上包含这样的几个步骤:①申请人提交申请,②审批单位接收申请并检查提交的材料,③根据审批的规则和已有的信息做出审批,④返回审批的结果。这个描述虽然比较概要,但是在许多行业当中,审批的流程大致如此,所不同的地方主要是提交审批的事项和材料,以及各行各业根据审批的内容所执行的规则。但是这些规则往往经常发生变化。这一现象在知识密集型的组织当中尤为明显,比如金融行业、政府部门和高科技行业。这些行业的业务流程当中,通常应用大量的业务规则。如果这些组织采用之前介绍的单体系统来实现这些规则的自动化执行,那么大量的变更请求会导致这些系统无法消化进而难以维护。因此业务规则需要从流程当中剥离出来,并由通晓这些规则的业务人员进行管理,而不是依赖于将这些规则写入到程序中的开发人员。

在流程与规则分离的设计思想影响下,许多知识库系统(knowledge-based system,KBS)被引入企业应用当中,这些系统很多时候又被称为专家系统(expert system)。知识库系统借助人工智能(artificial intelligence)的方法和技术,使用基于计算机的知识推理为解决问题提供决策。在KBS的实现当中,有一项专门的工作称为知识工程(knowledge engineering)。正如软件工程关注开发大型软件系统的方法与技术,知识工程关注的是知识库系统的开发与构建^[23]。尽管KBS有许多种类型,但知识工程的主要内容有两个:知识获取和知识表达^[24][25]。知识获取(knowledge acquisition)是收集、组织和构造关于某个主题、域或问题区间的知识的过程,并为最终将其整理进入KBS做准备;而知识表达(knowledge representation)是将知识用计算机可以理解的形式进行表达^[26]。在人工智能领域,目前有相当多的技术可以用于知识表达,常见的有产生式规则(production rules)、语义网络(semantic networks)、框架(frames)和语义网(semantic web)等。当知识表达准备妥当之后,KBS Shell就可以使用这些知识表达模型进行推理,并将结果提供给用户作为参考,如图3-3所示。

图3-3　KBS实现与应用过程中的基本活动^[27]

与之前提到的单体系统相比,KBS可以清晰地追踪从知识源到知识表达之间的关系。一旦知识源发生变化,可以轻易地定位到需要更改的知识表达模型,并做出相应的更改。更重要的是,单体系统中遇到的系统配置问题在KBS上处理起来要容易得多。受益于这种可追溯性,知识表达的版本控制只需要时刻保持与知识源一致,并且由于知识表达与流程是分离的,因此不需要重新编译整个系统,也没有了发布管理上的维护成本。每个知识表达模型之间可以保持相对独立,这便于它们在版本控制上不易发生相互影响。

这里需要特别指出的一点是,KBS并没有在整体上减少知识应用的复杂度。在单体系统当中,为了实现同样的功能,依然需要知识获取与知识表达的工作和过程,只不过这些工作都需要由系统的开发和维护人员负责完成,所有的复杂度都堆积在IT部门和IT人员身上。而在KBS当中,这样的复杂度被分解并分开管理和控制了。在KBS当中,IT人员只需要专注于软件系统的开发和维护,知识和规则的建模和维护则由知识工程师来完成。知识工程师的角色可以由通晓业务规则的业务人员经过相应的知识表达技能培训之后来承担,也可以由通晓人工智能知识的技术人员经过业务培训之后来充当。这里的关键在于选择何种知识表达技术来构建KBS。通常而言,知识表达技术的表达能力(expressiveness)和学习该技术的困难程度以及进行推理的困难程度成正比关系。也就是说,表达能力越强的技术,例如语义网技术,学习起来就越困难,想要设计并实现利用该技术进行运算的推理引擎(inference engine)就越困难^[28]。这再一次印证了我们之前的观点,复杂度不会减少,只能对其进行管理和控制。在KBS当中,维护和应对变更的复杂度被分摊到拥有不同技能的人员身上。通过不同人员分工的方式管理各自擅长的领域,提高了工作的效率,因而加速了系统应对变化的能力,所以具有更高的柔性。而这样做的代价是,产生另外一个需要平衡的方面:表达能力和技术的复杂程度(即其拥有成本)。如果选用易于业务人员学习的知识表达技术,能够保证本单位的业务人员可以较快掌握该技术,并有更多业务人员可以达到建模技能的水平要求。然而使用简单建模技术所得到的模型由于表达能力较弱,模型的体量会更大。举个例子,一个在语义网中非常简单的模型,用产生式来表达的话可能需要很大的篇幅。在这种情况下,推理引擎的结构会比较简单,即其售价或者开发成本较低,而模型维护起来却会比较麻烦,可读性也较差。如果采用高级的知识表达技术,可以获得更高的表达能力,即使用简单的模型便可以表达出复杂的业务逻辑;但是人员的培训成本较高,与此同时,推理引擎也很复杂,即其售价或开发成本更高。由此可见,复杂度的控制和分解其实也体现在对KBS的维护成本与拥有成本之间的权衡上。

KBS的发展和应用同样也引起了应用架构的变化。KBS体现的是流程与规则分离的设计思想,但是要发挥KBS的真正作用必须将决策的功能引入到具体的流程当中,这就对系统之间的集成有了更高的要求。这种需求催生了多种中间件技术和企业应用集成(enterprise application integration,EAI)技术的发展。为了集成企业现有的各种应用,EAI技术在20世纪90年代开始逐渐被广泛应用^[29]。正因为有了可以实现多系统集成的环境,才真正使得流程与规则分离的设计上升到架构的层面成为一种可能。

EAI的实现需要创建和管理许多中间件(middleware)以满足流程与规则分离的要求。由于流程中有多个步骤,其中若干个步骤可能需要将业务规则或业务逻辑从流程中剥离出来并在单独的系统中进行管理。在流程的运行过程当中,这些系统需要与流程系统进行通信以实现决策支持的功能。在这个过程当中,可能还需要跟一些遗留系统(legacy system)进行数据交换,例如多年前开发的某个单体系统。这些系统之间的交互都需要依靠相应的中间件来完成。图3-4给出了一个在EAI架构下实现业务流程的例子。

用现在的眼光来看,早期的EAI技术是有些落伍的。其中最重要的一个原因是中间件的开发和维护的复杂度问题。在早期的EAI应用中,为了实现两个应用系统之间的连接,需要为这两个系统开发一个中间件。如果一个组织仅仅有两三个系统需要集成,这样做问题不大。但如果需要集成的系统数目众多的话,中间件的开发和管理就是一件非常麻烦的事情。假设某企业有n个系统需要以这种EAI的方式进行相互连通,其中n≥2,那么需要开发和维护的中间件数量为n(n－1)/2。如果这个企业有10个系统需要进行相互连接,那么中间件的数目将会是45个。然而,根据Samtani和Sadwani^[30]的估计,在当时,世界500强的企业平均至少有50个在不同技术平台上的系统需要进行集成,这意味着完成这项集成工作需要维护上千个中间件。由于这些中间件都是针对指定系统特别定制的,一旦系统的输入输出发生变化,与之相连的所有中间件都需要进行修改。随着系统数量的增加而带来的中间件数量的爆炸式增长,以及与之伴随的繁重的维护工作成了早期EAI技术的短板。

图3-4　基于EAI技术的业务流程管理系统中流程与规则分离的实现^[31]

要想解决早期EAI的致命短板,这就要求不同技术平台上的应用都能通过一个统一的接口标准进行通信。在2000年,简单对象访问协议(simple object access protocol,SOAP)的提出为解决这个问题指明了一条出路。很快,许多公司和软件供应商开始意识到构建非专有互联网通信框架在推进电子业务技术上的巨大潜力。这最终催生了创建一种完全基于Web分布式技术的标准化通信框架的想法,并以此实现横跨组织内部和组织之间各种差异化应用的概念^[32]。这一概念被称为Web服务。伴随着Web服务的提出,模块化的架构设计思想开始流行,并促使SOA成为当前业界广泛采用的架构。