邱嘉文 张恂

v1.3 draft，2005-07
（请勿转载）

一、从人类的进化说起

人类区别于其他动物的特征之一是：人类会制造工具，而其他动物不会。虽然根据目前科学观察的结果，这一命题受到了挑战（有报道说，某些种类的猴子也会在一定程度上制造和使用某些工具），但这更加证实了如下命题的正确性：所有动物进化的趋势之一就是学会制造更加高级和有用的工具，工具的升级换代是动物进化的重要标志。

在人类从石器时代进化到计算机（信息）时代的漫长历程中，计算机的发明是人类进化史上的一次飞跃，自此人类已经能够将自己大脑中的某些智能移交到自己发明的工具之中，让工具更加容易被操作和使用（注：因此，本文所用的“计算机”与“电脑”是同义词，可以随意替换）。如果回顾一下计算机作为人类的工具，从计算控制的工具发展到通信工具和管理工具，其应用范围从独立解决局部计算、控制问题到联网解决群体信息沟通和协作问题的发展历程，我们无疑就会发现：计算机应用系统（软件）已经是一个非常复杂和庞大的工具系统，其发挥的总体效用几乎已经超出了人类历史上制造的任何其他工具系统。

尽管计算机系统这一工具非同寻常，但在人们的传统观念之中，计算机系统的定位始终还是工具——它仅仅只是工具，人类的身外之物，不过是被人类操控的一种客体对象而已。如今尽管人类的生产和生活已经离不开计算机和软件，人类的某些个体和群体的生命甚至也已经命悬于计算机系统，但大多数人还是不敢相信：计算机系统已经开始或者正在成为人类自身的一部分。而另一些人却始终认为：计算机信息系统不但早已融入了人类的社会、生产和生活活动，未来人造智能器官的发明说不定还能使计算机融入人类的躯体活动，智能化软件也必定能使计算机融入人类的思维活动，人类已经而且必将彻底地离不开计算机了。持有这些观点的人，大概也能接受这种新思维：即，计算机系统已经不再是在人类的身体和思想以外独立存在的工具，而是有可能成为人类自身的一部分！

武侠小说经常用“人剑合一”来形容剑法高超之人，大约是说一个人运用剑术非常娴熟，几乎达到了天衣无缝、无懈可击的程度，以至于那把工具（剑）就好似化作了舞剑人自己肉身的一部分，人似剑，剑似人。推而广之，当人类的一种工具发展升级到极致，操作这样的工具是不是也可以像操作身体的某个部件一样呢？对于人类的社会化组织——企业机构而言，计算机信息系统似乎也正在成为一种“人剑合一”的系统。那么，我们看待传统计算机应用软件的视角是否应该发生改变，软件还是原来的那个软件——单纯的、孤立的业务工具吗？

二、不同观念对应用软件开发的影响

一个人，一家企业，一台计算机，一个计算机网络，这些都是“系统”。然而，制造 系统要使用的工具 和制造 系统本身的部件 是两个具有不同意义的概念：

系统要使用的工具 是指一个系统边界之外独立存在的其他实体。一般这类工具只提供具体的操作指引，使用工具的系统只要根据操作指引来操纵它，工具就会发挥在制造之前已经设计定义好的操作功能和功用。

系统本身的部件 则是指一个系统边界之内的实体。它必须融合在这个系统内部的周边部件和子系统（subsystem）的环境中，这意味着部件需要满足这些周边部件和子系统的接口（interface）规范，只有这样它才能和系统内部的其他部件和子系统一起紧密协作，最终完成系统自身的功能。

当以上这两种概念作用到同一个产品上的时候，会导致对产品的不同视角、不同观念，不同的观念则会导致产品制造策略的不同，进而导致制造出来的产品的架构和特性也有所不同，这一区别在计算机软件的开发过程中表现的尤为明显。计算机应用软件是一种人工主导制造（build）的信息产品/工具，使用它的用户系统是人或者企业。于是，存在两种不同的观念来看待要开发的软件。一种观念把软件看成是 企业要使用的工具 ，而第二种观念则把软件看成是 企业本身的一部分 。目前持前一种观念的人士似乎占绝大多数，许多人甚至不认为这两种观念有什么区别。

在一般的制造工具的层面上，当我们把一件事物当作工具来设计和制作的时候，往往已经在长期的活动中体察到了某种明显的操作功用的需求，比如木工把钉子钉进木料，就需要锤子的敲打功用。此时，制作工具的注意力几乎全部集中到了实现工具的本身之上，比如制作工具的基本材料选什么，这些材料有什么特性，如何组合、粘接这些材料才能制作出满足功用需求的工具？等等 …… 这些都是非常合理和自然的想法。

但是当我们把一个事物当作另一个系统的部件来设计和制作的时候，情况将有所不同，人们制作部件的注意力会较多地转移到使用这个部件的系统身上来。比如，使用该部件的系统要完成什么功能活动，要做的部件在这些活动中起到什么作用，如何协调周边部件与新部件的关系，如何避免其他部件对新部件的排斥，要做的部件必须满足哪些外部特性？等等 …… 对这些问题的思考显然与如何实现这个部件本身的思考同等重要，而这些也是非常合理和自然的想法。

回到软件开发过程中，当我们把待开发的软件看作是一个外部工具的时候，软件要满足的功用通常事先就比较明显，于是软件开发者很容易把考虑的重点放到关于软件设计和实现的问题上来，比如：

- 用什么样的机器、网络、设备？
- 基于什么操作系统？
- 用什么数据库管理系统？
- 采用什么编程语言开发？
- 采用 C/S 还是 B/S 架构？
- 基于 J2EE 还是 .Net 平台？
- 软件的数据持久层、应用逻辑层、通讯控制层、界面交互层如何处理，等等一系列的问题

以上这些考虑全部是以计算机软、硬件资源为核心，逐层整合计算机系统的各项技术资源来构建信息系统的。越底层的资源重用性越高，而对于具体业务的功用，通常实现在这一架构的最顶层或最外层。最终，这样的计算机应用系统就可以实现为一个相对独立于业务之外的通用或专用工具。如今，这种应用软件开发的观念似乎占据了国内大部分软件技术人员的头脑。

然而，如果把待开发的应用软件当作是一个部件（使用它的企业或个人在业务系统中的一个部件）来考虑的话，情况则会发生一些微妙的变化。我们将必须分配较多的精力来分析这个企业或个人的业务过程，必须对这个企业或个人的业务过程建立模型，这就是国内外所谓的“ 业务建模 ”（business modeling）的工作。当建立业务模型之后，可以在其上模拟业务流程的运作，发现业务流程运作中存在的问题和机会，发现为了维持高效的业务流程而必须构造的业务部件，以及这些部件必须满足的外部接口特性，以及其中的哪些业务部件必须纯粹由人力来实现，哪些部件必须由计算机来实现，哪些必须由其他设施来实现，哪些又必须综合人力、计算机、其他设施的能力来共同实现等等。

显然，经过业务建模之后，我们开发软件的目的和意义，不再仅仅是提供一个在业务过程中使用的单纯的工具，而更应该是提供一个契合业务设计需要的，用来完成高效业务过程的业务部件。也只有根据这样的理念开发出来的软件，才是真正的 人剑合一 的应用软件系统 。

三、应用软件开发观念变更的内在驱动力

由于买方市场的兴起，产业界观念的变化早已发生，产品制造商的观念早已从关注“我要做什么事”转变到关注“客户要做什么事”，而“帮助客户成功”、“让客户更满意”、“以客户为中心”、“为客户创造价值”等等理念也早已经成为众多企业奉行的宗旨，有的甚至还写进了国际标准。在计算机软件开发领域，除了同样的外部因素促使软件产品、系统开发观念发生改变之外，可能还有一些其独特的内部原因。

在计算机发明的初期，软件的作用和其他工具一样，是帮助人们完成计算和控制作用的工具，当时开发软件的观念仅限于“制造工具”的范畴是自然的。但随着计算机硬件水平的迅速提高，全球互联网络的出现，计算机开始向社会的各行各业渗透，它的作用已经从满足基本操作的功能需求转变为满足业务运作和管理的需求，计算机与软件应用范围的广度、深度，应用规模的大小、复杂度，影响的人数、地域均在高速扩张。如今，计算机不但可以满足人类各种广泛的需求，事实上计算机系统也早已经成为人类社会这个大系统不可分割的一部分。

考察计算机软件的发展过程，针对不同类型软件需求的发展顺序大致如下：
•  操作系统软件
•  软件开发工具软件
•  应用支撑平台软件
•  业务工具软件
•  业务部件软件

在以往的分类当中，人们并没有把 业务工具软件 与 业务部件软件 进行严格的区分，它们往往被统一归属在 应用软件 一类中。在具体的软件产品中，这种区分也并不十分明显。形成这一现象的原因是多方面的。只有在更加宏观、更加抽象的层次上才能体会到存在这两类应用软件的大趋势，这种特点也导致了部件软件需求增长的隐蔽性。加上在思维惯性的作用下，人们对开发软件的观念也不可能一下子从 制造身外的工具 转变为 制造身内的部件 。

软件开发者未能及时转变这一观念造成了一些软件项目在规划和立项阶段就出现了失误，而且造成这些失误的这一根本原因往往在现实中遭到了忽视。经常用来形容这些失误的词语包括：“闭门造车”、“市场定位不明确”、“不符合业务需求”、“不适应企业环境”等等。这些描述都把导致软件项目失败的原因归结到软件、系统、产品的研发过程之外了，因而在具体软件项目中它们往往得不到重视，即使开始重视了也因找不到较好的解决办法而最终不了了之。

然而，业务部件软件需求增长的这一 大趋势 不会等待软件开发人员观念的变化，也不会等待他们准备好解决问题的办法。这导致了一方面存在大量这方面的需求增长，另一方面不少软件开发机构生存困难，而接到订单的软件企业又面临项目失败率高居不下的尴尬局面。这是明显的宏观层面的“供不对求”现象。一旦处理不好，有可能造成社会资源的大量损失，在一定程度上出现新的、针对业务部件软件需求的“软件危机”。

软件工程科学和技术发展到现今，已经为解决业务工具软件时代的“软件危机”做出了不朽贡献，在面对业务部件软件时代的“软件危机”方面，人们也已经有所觉醒，这意味着在传统的软件工程方法论方面将面临新一轮的突破。从软件工程研究的重心逐渐从编码测试转移到分析设计，从分析设计逐渐转移到需求工程，从软件需求工程转移到企业业务工程这一大趋势看，我们就能明显地感觉到：软件项目成功的大部分关键因素，已经从软件之内转移到软件之外。作为企业业务工程的主要内容：业务分析和业务设计，也就是业务建模的工作，不仅将成为软件工程方法论新一轮的突破口，而且将对软件本身的架构技术产生深远的影响。

四、系统架构与业务架构的概念关系

在一般的意义上，架构 指的是为了将各种 资源 整合成为一个系统而采用的阵式和结构，这种 阵式 和 结构 决定了系统在整体上的外部特性（功能与非功能的）。其中，资源 包括物理的 硬资源 和逻辑的 软资源 ； 阵式 指的是如何在物理空间和概念空间部署那些聚合成团的资源，以便在整体外观上满足系统规模和样式的需求； 结构 是指系统内部的资源以及资源团之间如何运用扭结和排斥、粘合和分立、导通和隔绝、作用和反应、发送和接收、特化和泛化等构造手段，建立起来的既相互独立又相互依存的静态和动态关系集合。

系统内在的动静态结构支撑着整体外观上 相对稳定 的系统阵式。这里的“相对稳定”意味着：在与系统内部结构变化相同的时空尺度上，系统架构的变化并不明显，而在一个更大的时空尺度上，当原来的系统架构成为更宏大的外部系统的内部结构时，其变化才被显著化。这同时意味着：一个“活着”的系统的架构不是一成不变的，成长中的系统会发生架构的积极演变和进化，衰老中的系统则会发生架构的僵化和蜕化。

在 IT 领域所说的系统架构指 计算机信息系统的架构 ，是包括软件系统和硬件系统资源在内的架构，本文讨论的系统架构专指 软件系统的架构 ，是指包含如何整合计算机软件的资源架构；在业务工程领域说到的 业务架构指的是业务组织运作体系的系统架构 ，简称 为业务架构 ，业务架构不仅整合业务组织中的人力资源、财金资源、物资资源和信息资源，而且还包括整合组织外的客户需求资源等等。

明确了上述的概念，理解业务架构和系统架构的关系就要从被整合的资源的关系的角度出发，存在两种不同的合理理解。

第一种理解是 狭义 的业务资源观点：计算机软件资源是一种特殊的必须由计算机来处理的信息资源，而一般狭义的业务资源主要是由人来处理的，包括人力资源、财金资源、物资资源和信息资源等资源。这说明，业务架构和系统架构是 相互独立 的，是两种不同层面不同性质的架构，讨论的领域完全不同。这样区分的意义是：可以将适合不同处理者处理的资源分开讨论，一方面避免讨论用计算机来处理本应该由人来处理的资源，另一方面也有利于从人直接处理的资源中发现有利于适合计算机处理的资源，这是软件需求工程的需要。

另一种理解是 广义 的业务资源的观点：计算机软件的资源可以被看成是广义的业务资源的一部分，它们只是取代了原来由人来处理的部分信息资源。这说明，系统架构可以被看成是业务架构的一部分，是业务架构在计算机系统中的信息化延伸。这样将软件资源等同为业务资源的意义是：可以在业务层次将适合不同处理者处理的资源结合讨论，一方面能建立明确的适合不同处理者处理的资源边界，有利于定义软件系统的边界，另一方面又有利于将软件资源在业务层面与其他业务资源一起整合在同一个业务架构之中，这即是软件需求工程的需要，也是企业业务工程的需要。

在以计算机为中心的软件开发观念中，很容易把业务架构的概念搞错，从而把业务架构与系统架构的关系搞混。

如图 1 所示，以计算机为中心的软件开发观点从计算机的软硬件资源出发，向外层透视，也会看到软件所需要处理的部分业务信息资源，这部分业务信息资源也可能存在局部整合的需求。 往往信息系统的开发者会认为对这些局部的业务资源的整合，就是业务架构 。随着业务信息化的普及，业务组织中其他形式的资源越来越多地被抽取出业务信息资源，业务信息资源也越来越多地被转变为可由计算机来处理的形式，看上去适合计算机处理的信息资源逐渐已经在信息层面覆盖了业务组织的全部业务资源， 这种局面将进一步加深对业务架构的上述误解，甚至蒙蔽了许多业内专家的眼睛 。这种误解带来的后果就是：彻底忽视真实业务架构的存在，认为业务架构只是软件架构中的较高层——即应用层所实现的业务信息资源的整合架构。这更加容易陷入“部件软件危机”的陷阱，因为，毕竟真正的业务架构要整合的资源，还包括大量的计算机以外的实物资源。即便是业务信息资源覆盖了其他所有的业务资源，实际的业务运作，仍然还是以人为中心的包括各种实物资源在内的运作过程。

如果我们把计算机系统比作地球系统，把业务组织系统比作太阳系系统，那么如图所示，当今广泛流传和应用的软件系统架构就好比是“地心说”的产物，而作为“日心说”的业务架构又该是怎样的呢？如图 2 ，业务架构是以满足人的需求为核心来整合业务资源的。从业务资源整合的角度来看理想的业务的层次型架构，应该是以人力资源为核心，逐层向外分别为知识资源层、财金资源层、物资资源层和工作资源层来构成整个业务实体。业务的运作的过程，就是外层的资源 请求和使用 内层资源，内层资源 支撑和驱动 外层资源，各层资源相互融合，共同流转的过程，可以用如图 3 所示理想的业务整体实体的、分层的动态流模型来表示。

各层的业务资源可以分别抽取出或抽象为信息资源，这就是业务信息资源。业务信息资源按业务资源的层次可对应划分为：人力信息资源，知识信息资源，财金信息资源，物资信息资源和工作信息资源；按是否可以被计算机信息系统来处理，可以分为可计算机化的业务信息资源和不可计算机化的业务信息资源。计算机硬件在业务架构中属于物资资源的一部分，可计算机化的业务信息资源注入到计算机系统中后，经过系统架构的整合，将成为计算机信息系统。由此可见，系统架构是可计算机化的业务信息资源的整合者，而业务架构则是所有业务资源的整合者，系统架构是业务架构的特殊部分。

五、观念变更对软件架构的深远影响

完成从 业务工具软件 到 业务部件软件 的观念转变，是以软件的架构技术成熟到一定阶段为前提的。在现有成熟的软件架构和未来开发框架下，特别是在 OMG 倡导的模型驱动架构（MDA）理念之下，许多软件开发人员今后将从编码、测试等与计算机底层机制密切相关的工作中逐渐解放出来，软件开发中留给人类大脑的工作，已经逐渐后退到系统的分析设计了，也就是说，软件架构技术的发展，已经在系统实现方面迈出了实质性的步伐，实现一个需求明确、结构复杂、一定规模的软件系统，已经不再件是十分困难的事情了。这一方面使得信息化建设中业务工程的问题显得更加突出，另一方面也为解决业务工程的问题准备了基础条件。

然而，随着组织的业务架构和 IT 系统架构同时不断演进，业务架构与软件架构不匹配的矛盾也日见突出。在业务上我们应该以业务架构为骨干，整合优化组织的各项业务资源，而偏向 IT 技术变革的视点则往往以系统架构为骨干来整合计算机的软、硬件资源，这种视点、观念上的差异会妨碍组织业务架构与 IT 架构的优化整合，加上两者变更速率、强度的不同，常常导致 IT 系统难于适应，及时满足组织业务发展的需要因而变得尤其困难。

不同的业务架构往往服务于不同的组织功能、经营模式和理念。在一个业务架构基础上不断增加和增强业务部件，如库存管理、财务管理、导购管理、收银管理、保安管理、人力资源管理、物流管理、供应链管理等等，就能逐步实现不同模式企业的业务架构的演进。不同类型的企业，其相应的 IT 系统是大不相同的，这些 IT 系统简单的可以是单机库存管理，财务管理，复杂的可以是进销存、物流、供应链管理系统。随着企业业务模型的升级，其原有的软件系统大多需要抛弃重建以适应新的业务体系，其中关键的原因之一就是 IT 系统架构不能适应业务架构的进化。

解决业务工程问题逐渐将成为 IT 系统开发当中的焦点问题，开发软件的观念会逐渐从 开发业务工具 转变到 开发业务部件 ，构造信息系统的核心工作层面将从系统层上升到业务层。原先的以 IT 系统架构来整合系统资源的模式，将被以业务架构来整合整个业务组织的所有业务资源的模式取代。要整合的业务资源包括软硬件系统资源，也包括其他非 IT 资源，软件系统的资源将更多地按照业务架构的要求而非仅仅软件架构本身的要求，与其他非软件的业务资源一起进行重新组织和部署。 开发软件的目标将是帮助企业直接实现一个优良的业务模型，而不是仅仅实现一个优良的软件系统模型 。

如图 6 所示，在这个理想的业务架构工作流视图中，一般的业务工作包括从捕捉业务机会到评估过程效益的循环过程。此过程将消耗部分资源的储备并积累相关的信息和知识储备，组织在此过程之后取得业务效益，以补充相关资源的储备。为使业务的实体、组织资产得到增长，必须保证过程中取得的效益大于所消耗的资源的价值，才能保证有高于消耗的资源价值的新资源不断补充到资源储备中。

如果按照顺利实施以上业务架构的要求来考虑开发和部署 IT 系统，无疑我们首先应该考虑如何整合相关的人力资源、信息/知识资源、资金资源和物资资源，使其成为业务部件，并通过这些部件的运行保证整个业务过程实现增值。计算机软件、数据库等等只是整个业务架构的信息/知识资源中的一部分，并且它们应根据优先保证业务部件高效运作的目标进行开发和部署，这可能与单纯整合所有计算机软、硬件资源使其成为一个所谓的信息系统的传统目标相左，从而消除了建立庞大而统一、铁板一块的 IT 系统架构的必要性 。

可以预计，宏观上明显的业务层和 IT 系统层的界限将被打破，业务层和 IT 系统层的耦合将按照业务架构优先的原则重新组织。IT 系统架构将被微分到业务部件的层次，以适应业务架构的需要，可能我们不再需要一个与业务架构同层次的、庞大而统一的 IT 系统架构。以业务架构为核心，以开发业务部件为目标的新的软件开发时代即将到来。

（完）