业务架构的主题和规则

业务架构已经成了个时髦的词儿。就像安全一样，所有人都听说过，也都有自己的看法，但只有极少一部分人知道它的真正含义是什么。

本文在同时考虑主题和规则的情况下对业务架构的现象进行了探讨。不知道业务架构的主题，则很难判断业务架构角色的内涵和外延，比如规则。很多管理者和架构师会说：“这有什么问题？通过确定利益相关者，并收集他们的观点，基本上可以定义出业务架构。”很不幸，这种做法是极大的错误，它会引发很多自相矛盾的观点。

通过利益相关者的观点定义业务架构的支持者潜意识里会将重点从“它是什么”变成“它能为我做什么”，并且会参照 ISO/IEC/IEEE 42010 标准 1 处理观点和看法。然而，这个标准警告说观点不能定义而只能用来描述主题。我们在这里要把“描述”和“定义”区分开。可能收集了上千条描述也得不到主题的定义，因为所有描述或看法都是主观的，换句话说，每个人看到的都是他或她想看的。

我注意到，在各种会议和网上对业务架构数不清的讨论中，大部分争论都是围绕着业务架构是做什么的，或者说应该做什么的，实际上这是另一码事。在我们定义对驾车的看法时，能给出车的定义吗？不能，因为驾车只与在车里的几个操作控制，以及它们对车怎么移动的影响相关。此外，还有从车上发现不了的驾驶规则和法规；只看车的外观和内饰看不出它的内部结构。如果在车上这样简单的例子都解决不了，那么对于业务架构而言，我们凭什么觉得利益相关者通过观察能比业务架构师知道得多？

我在本文中介绍了一种方法，让我可以定义出和企业的业务领域无关的企业业务架构。结果我发现，业务架构比很多人想得都简单，同时跟企业中的其它业务有更复杂的关系。我将阐明这一结论的推理过程，同时列出一些成果。

业务架构定义

企业的架构业务元素

业务架构可以从业务和形式化两个角度定义。第一种方式基于业务价值。货币价值是一种众所周知的业务价值。很多人都认为这个价值，包括货币商品的等价物，是业务唯一看重的价值。货币价值的抽象非常简单，并且建模、测量和管理都很方便；然而，在消费型社会中，钱不能吃，也不能穿，更不能带走。

在成立一个新公司时，要写出企业的商业模式，就是公司的“业务面”。它通常是由企业的核心业务职能组成的，是企业在市场上区分于其它企业的关键。业务职能是企业跟消费型社会中的“供需”因素之间唯一的连接。

仅用货币价值衡量这个连接有点儿鼠目寸光。货币价值会混淆需求满足机制，经过长期的运营，在需求发生变化时，公司可能会错过调整这种机制以跟进需求的关键点。如果客户满意度下降了，公司的营收可能暂时还不会受到影响，但等到营收开始下降时可能就太迟了，公司在客户那里的名声可能已经坏掉了。也就是说货币价值可以用来衡量业务成效，但不应该作为唯一的标准。

与此同时，在消费型社会中，业务职能可以确定所有公司的业务价值。如果这个职能能够满足消费者的需求，它们就能帮公司赚钱。也就是说第二种方式用货币和职能来衡量业务架构。如果业务架构是基于业务职能的，那公司业务的精华和战略目标很可能能够适应市场的变化。

在讨论业务架构时，我首先假定它是个架构。我选了 ISO/IEC/IEEE 42010 1 中对架构的定义，并对它进行了扩展：一个系统 / 结构的组织体现在它基本能够自给的内聚元素中，它们彼此之间以及跟环境的关系中，以及能够指导其设计和进化的共享原则中。如你所见，这个定义并不局限于业务或技术。

有了这个定义，我对企业中几个显著的业务元素进行了考察，其中包括会被其他作者归结到业务架构中的那些。我所分析的元素是企业战略、业务能力、财务（营收 / 利润）目标、业务职能、客户和供应商、人员和业务流程、治理结构、业务信息、组织结构，以及对经济活动负责的结构。

在上面列举的这些元素中，只有业务职能和业务信息具备如下特质：

• 根本性—— 一个企业没有它们就无法存在，并且它们是不可取代的

• 自给性—— 它们不是从其它东西中推导出来的，可以独立存在

• 内聚性——它们是一致并互相关联的

• 导向相似性——它们有相同的指导原则。

也就是说这两个元素有架构化的属性。至于其它企业元素的特性，我可以简单地介绍一下：

• 企业战略——不能自给，其指导原则也可能跟其他企业元素的原则不同。企业战略跟企业的商业模式共同构成了业务架构的输入和目标。企业战略是由首席级管理人员制定并督导的。业务架构只是会促进战略的制定，并通过实践验证它的最终版本。

• 业务能力——是特定业务职能或某几个业务职能组合的具体实现。业务能力是实现业务架构的主要成果之一，而架构本身只是确定了业务能力的职能部分。

• 财务目标——构成了一个结构，而不是架构，因为它们不能自给，可能也不是内聚的。在本质上，企业的财务结构是由几个因素决定的，包括业务职能、运营及组织结构、实践方法及技术，以及市场的状态。

• 客户和供应商——业务架构确定的是企业内部的元素，而客户和供应商是外部元素；跟特定客户及供应商的关系是业务架构模型的输入和输出。架构模型中只包含客户和供应商的类型。

• 人员——不能自给，可能也不是内聚的，可以被取代及外部化（外包）。业务架构（模型）没有人员也可以存在，而业务架构的实现不行；所有架构的实现都是由人完成的。

• 业务流程——是业务职能的实现形式，更准确地说，是业务服务的实现形式。也就是说业务流程不是架构化的元素，而职能 / 服务可以是。

• 治理结构、组织结构，以及对经济活动负责的结构——是业务架构实现的主要输出；其中有一些也是业务架构的输入。如果它们偏离了业务架构的决策和方向，那企业必须调整 / 修改这些实现元素，以免在日常活动中遇到麻烦。

因此，尽管上面列出的这些元素对企业都很重要，但它们不属于架构。它们形成了业务架构存在和运转的环境。并不是所有一切对企业重要的东西都是业务架构（就像车里的东西不全是发动机）；业务架构是能够影响企业中一切东西的精华。

业务架构的主题

企业在开展业务时，会提出为什么、是什么、何人、何地 以及何时几个问题，业务架构的主题就是由这些问题的答案定义的。也就是说业务架构会详尽阐述企业的商业模式和企业战略规划，将它们转换到业务职能上去，而公司的其余部分则要解决这一职能如何或应该如何实现。

企业业务架构是由业务职能和业务信息组成的架构，它跨越业务管理和企业的组织结构，转化企业商业模式和企业战略规划中确定的目标和宗旨，定义出企业业务职能和业务信息。业务架构的这个定义是建立在前面那个架构定义基础之上的。

职能架构并不是新思想；尽管不是十分明确，建模语言 ArchiMate 称之为“业务职能架构”。(BFA)。它的定义是“_BFA_ 描述了执行流程的情境，并且可以辅助完成企业最重要目标的建模和可视化” 2。还有， “企业的业务模型…描述了业务流程、数据和信息、企业宗旨、成功的关键因素、信息区域，以及这些部分彼此之间的关系 2。”按这个逻辑，几乎企业中的一切都是“业务架构”。

相反，我觉得业务架构只是定义（不是描述）了职能的情境，不涉及具体实现，而“企业最重要的目标”是出现在企业战略规划里的。此外，就像我们之前讨论过的，业务架构不描述 “业务流程、数据和信息、企业宗旨、成功的关键因素、组织结构”。所有这些都是架构实现的因素。企业宗旨和成功的关键因素不能出现在架构中，因为它们是架构应该遵守的外部标准。

业务架构和它们的实现之间是 M:M 的关系。某个业务架构可能有几种可选的实现；反之亦然。实现不能用来定义架构。架构应该提供职能、信息和运营质量（比如可用性、扩展性、健壮性及安全性等等）的模型。因此，要在业务和技术两个领域中寻找解决方案的后者，会把业务架构当做需求源。

业务架构会处理当前的和规划好的职能架构模型。已有的职能通常被解读为业务竞争力，而规划好的职能是通过业务能力描述的（即在特定业务环境下实现某种业务职能 / 特性的潜力）。业务竞争力可能包括激励价值和当前行为，而业务能力定义了在特定条件出现时企业能做什么。

能力是业务职能和它可能（保留）的实现两者的组合，如图 1 所示。业务架构为每种能力定义了业务职能 / 特性的组合，而企业管理定义 / 预留了实现细节。无论如何，业务能力只是业务架构做什么以及业务架构规则定义的一部分。没有定义好 / 预留好实现的业务职能 / 特性列举是毫无价值的。比如你定义 / 规划了一次塞舌尔群岛的度假之旅，但如果所有的票都已经卖光了，这个计划就没用了。

图 1. 业务能力的组成部分

业务架构协会 (BAG)5 提出了一个完全基于能力、价值流和组织的概念，前面描述的业务架构跟他们提出的概念不同。这个架构指出愿景和战略是架构的输入，而战术是实现方法；由管理和组织共享的业务能力是主要实现机制，它不一定能跟架构相匹配（很不幸）；价值流是实现的结果，也可能跟架构的方向不同；架构设计项目跟实现项目是分开的，并且政策 - 规则 - 法规 - 指标 - 措施是架构对其他和其自身治理的贡献，比如在架构之外的。业务架构师可能是作为规则的一部分参与所有这些活动，而不是作为架构的主题。那就是说 BAG 并不是新方式，只是对将架构模型 - 规划和实现混合到一起的已有实践的支持，比如意图和现实混合。众所周知，根据业务环境，价值流和能力有可能落实，也有可能不能落实，比如构建假体的架构可能不是使用资源的最佳方式。

此外，我还发现 BAG 有几个原则是自相矛盾的。比如说，如果“业务架构的范围就是业务的范围”，那怎么能规定“业务架构是可重用的”呢，它根本不可能重用啊。或者，如果“业务架构不是规定性的”，企业中的所有人都可以做自己想做的，业务架构就成了多余的了。本文中呈现的业务架构范式是规定性的，它定义的业务职能和信息模型要求企业中的其他元素应该尽力实现。

即便没有正式记录，甚至都没被察觉，但每个企业都有自己的业务架构。只有业务职能和业务信息模型共同构成了特定的业务架构。企业的其它业务元素只是促成了架构方案的出现。这些元素或者影响业务架构，或者被业务架构影响，但都不构成业务架构。

职能业务架构的影响

基于职能和信息的业务架构本质上是一个实现了业务职能并提供业务能力的服务架构。换句话说，这种业务架构会引导企业向面向服务的方向发展 3，包括业务服务的结构。这样的架构能将战略业务目标 / 宗旨、回报、消费者需求和企业文化连接到一起 4。它还需要特定的公司组织和运营结构。这种架构将企业变成最适合在高度动态的外部环境中生存的形态。

通过对业务服务的重新组合，面向服务可以迅速适应变化。如果企业不想变得灵活，不在管理和组织结构上进行调整，那就不可能实现业务方案的灵活性 6 。业务架构面向服务的特性在企业中表现为主要的巩固因素，能够跟社会结构、企业文化、内部业务单元跟市场上的外部活动协同工作相兼容。

面向服务的业务架构适用于各种类型、各种规模的公司。面向服务基于业务创新、业务方案集成、业务灵活性和可扩充性，并融合了技术的可扩展性、安全性和可管理性，能够形成市场竞争优势。

形成业务架构的企业服务是组织和运营的实体，通过手动或自动的方式实现了特定的业务职能。这些实体通常跨越公司的业务领域和 IT 领域 4。信息技术作为业务职能的执行形式，在企业服务的优化中占有重要地位。粒度合适的服务组成了一个强大的工具，可以解决大部分的新业务任务和已有问题。

企业服务所提供的抽象级别让最完备的战术和战略管理成为可能。还允许出现多个有能力和竞争力的业务架构实现。因此，通过重新安排相互协作的企业服务的结构可能能够提升投入 / 产出的效率和客户价值。

对业务架构规则的几点说明

业务架构的规则是业务需求和业务能力之间的桥梁，提供了一种将是什么转化成怎么做的方法。既然业务架构是定义业务组织、管理和运营结构的需求资源，那业务架构的规则就要求业务架构能用在两个基本的维度中。首先，它们为企业的当前状态定义了业务职能模型，并规划出达到战略状态的职能能力。其次，它们通过改变产品、服务、组织和运营结构辅助企业管理业务转型的发展。这两个都会对企业财务目标的达成做出贡献。业务架构中的主题和规则的关系如图 2 所示。

图 2. 业务架构的主题和 规则

业务架构处理的并不仅仅是业务架构。通过业务架构的规则，它的影响能渗透到企业的很多元素中，但这些元素并不是架构所有或管控的。业务架构师将首席级高管的指令跟企业战略规划的方向及市场分析整合到一起，将指令变成业务职能组件——职能、特性、服务和产品。

业务架构师对经营业绩的贡献很大，但他们不定义业绩或营收，或者其它财务指标，这是公司各管理层的工作。业务架构师针对某些业绩或营收设计解决方案，但我不会管这叫业绩或营收建模。经营业绩和营收可以当做对扩展性、灵活性和健壮性这些业务架构品质的引导驱动因素。

业务架构师定义了业务单位应该承担的业务方案和 / 或任务，以便能跟上企业战略规划和公司的目标和宗旨。这些决策会影响或应该会影响业务运营结构、业务和技术管理结构、业务不熟、参评策略以及相关的技术交付，尽管哪个单位做什么是由相关的管理层定义的。

业务架构规则需要做出某些决策，但目前这是管理层的特权，应该跟业务架构师分享或授权给他们。这就是为什么业务架构师应该有比较高的业务级别，比如经理级或更高级别，因为他们要对业务管理的高层和中层施加影响。

业务架构师的工作主要着眼于中长期收益。短期方案，可以定性为“今天的收入不管明天的开支”或者“明天将是新的业务”，明显成本更高，风险更大，因为这样的业务很可能没有“明天”。尽管架构上出现错误的可能性不可否认，但在实现过程中更常见的是短期思维对架构方案的破坏。

总之，业务架构的规则 是对业务架构师这一角色的主要和次要职责的描述。把业务架构的主题和规则分开，可以分清架构模型层面和它在整个企业内的实现 4。这还有助于理清业务架构师和公司管理层两者各自的职责。

结论

本文讨论了业务架构主题和 规则 的定义，它的推理和选择。所用的关键方法是把架构的主题和 规则 分开，把架构和实现分开。业务架构师是那些开发架构主题模型，并在模型的实现中为公司其他部分提供辅助的人。

跟其它定义业务架构的方式相反，本文指出只有业务职能和业务信息才能被当作架构实体，共同形成业务架构的主题。业务架构的规则描述了业务架构师这一角色的主要和次要任务。

业务架构的这种定义把业务职能和实现它的业务服务– 获取业务能力的手段– 放到了第一线。基于业务服务的业务架构是实现企业商业模式和战略业务目标的最佳模型。它还能把战略业务目标 / 宗旨、营收、客户需求和企业文化整合起来。这个架构适合所有业务领域中任何规模的企业；它能够把一家公司变成面向服务的企业，最适合在高度动态的外部环境中经营业务。

资源

1 《软件密集型系统架构描述的推荐规程》. ISO/IEC/IEEE 42010:2011, 系统和软件工程 — 架构描述

2 《口袋书: 企业架构管理》. BiZZdesign 学院, ISBN: 979-90-809722-4-7. 2011

3 Michael Poulin. 《成为服务型企业的阶梯》. Trobador 出版社, ISBN 978-1848761-629, 2009.

4 Michael Poulin.《架构师知道经理人不知道的那些事儿》. BuTechCon, ISBN 978-0-9575199-0-9, 2013.

5 业务架构协会的网站在 这里 ，但它的大部分内容只对会员开放。

6 评估方案灵活性的方法在 4 中有描述

关于作者

Michael Poulin 是 BuTechCon 的业务和技术架构主管，这是一家总部位于英国的公司。他在英国和美国积累了丰富的架构经验。主要工作是弥合业务架构和现代技术之间的差距。

Michael 提供专业的培训和知识交流，他还是 BCS 和 IASA 的成员。Michael 在企业架构领域非常积极，对 OASIS SOA 标准做出了积极的贡献。Michael 已经撰写了多种出版物，包括“成为服务型企业的阶梯”和“架构师知道经理人不知道的那些事”，他编写了多篇文章和博客，还在在会议上演讲。可以通过 michael.poulin@mpoulin.com 联系到他。

原文英文链接： The Subject and Discipline of Business Architecture

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。