中台之上：企业级业务架构

编者注：

《企业级业务架构设计：方法论与实践》的作者付晓岩，资深的企业级业务架构师，有超过19年的金融行业工作经验，目前就职于建信金融科技有限责任公司。本书是一部从方法论和工程实践双维度阐述企业级业务架构设计的著作。本文节选自原书第 6 章及第 15 章等章节，仅供学习交流使用，原书版权属于机械工业出版社，任何公司未经授权，不得用作商业用途。

重视业务架构，不要让「业务的归业务、技术的归技术」

很多企业都将促进业务与科技的深度融合作为发展战略，也都想学学阿里的中台战略，其实，除了中台战略之外，基于企业级业务架构设计来实现组件化开发也是企业数字化转型的优选路径，是弥合业务与技术之间「数字鸿沟」的有效手段。

寻根溯源，业务架构已有 20 多年的历史，但在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。为什么业务架构总有点儿「虚」？细究其原因，可能有如下几点：

1. 用的少 。原有的单体式或者竖井式开发依然是大家更经常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析足以满足开发需要；
2. 难设计 。业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难，业务架构对战略的分解、业务架构自身的整合与标准化、到 IT 设计的过渡都有不少坑，业务越复杂越宽泛就越难驾驭，因此，即便做过业务架构设计的企业，也有不少将业务架构设计保持在高阶状态，有点儿「虚」；
3. 易跑偏 。施工期间由于客观因素可能导致实施对业务架构的偏离，这种偏离如果没有及时纠正或者调整架构，累积久了会造成业务架构的失真，会变「虚」；
4. 难维护 。少数扛过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。

其实，业务架构从诞生之初就清楚地定义了自己的使命：面向复杂系统构建。业务架构同其他架构一样，目的也是要降低复杂度，更好地规划系统，而其更突出的影响是对参加过业务架构设计工作的业务人员的影响，他们的逻辑思维能力、结构化能力、企业级观念和意识都有明显的改变。所以，应当将业务架构从 IT 战略中独立出来，更多面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构真正要承担起这一职责，还需要改进、简化业务架构设计方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控。

业务架构和中台的难点，都是需要反复锤炼出标准模型

企业级业务模型的建设离不开标准化过程，因为做企业级模型要横向对比分析企业所有业务领域，以期望在设计上实现「以更少支持更多」，这是很多企业级系统建设或者企业级转型工程的目标。希望能够同时实现快速的灵活响应和减少重复开发这两个目标，其中最大难点往往是标准化工作。

1.基本的标准化方法

业务架构模型的标准化包括数据标准化和任务标准化两部分。标准化最重要的是数据标准化，数据建模中已经提到了，企业级数据模型要保证数据实体和属性的唯一性，这样就不会由重复的概念产生，重复的概念会造成数据的「同义不同名」。影响数据的使用和统计结果，数据模型的唯一性从工具角度比较容易控制，通过对定义、取值的比较，能够筛查出多数概念问题，但是依然有些定义问题不易发现，这就需要通过与流程模型的配合，从语义层面逐一澄清了。

标准化的另一部分是任务的标准化，这其实很难操作，没有严格的标准用于做判断，而且，任务标准化也是切忌「机械」操作的。其基本过程如下：

1. 将流程模型与数据模型进行语义对接。 当多数的数据概念重复问题已经通过工具筛查、语义分析解决了，数据实体和属性基本保持唯一，这时可以将数据与流程对应起来，对应的主要方式就是识别任务需要使用的数据实体，包括读和写两类。这种对接要更多地从语义方面去理解流程和数据的关系，而不要简单地执行流程与数据之间的关系「勾挑」，要通过语义分析判断任务、数据实体的颗粒度是否合适。

2. 分 析重复的业务动作。 在对应过程中，经常会遇到多个不同的任务都可能要对同一个数据实体在不同时间进行写操作的情况，比如，个人客户初次到一个银行存钱，申请银行账户时，银行要建立客户的信息，会包括姓名、证件类型、证件号码等基本信息，也会包括电话等联系信息，或者邮寄地址等地址信息，这时的整体业务场景是存款。而客户过了一段时间再次来办理业务时，联系信息可能会有变化，这需要更新客户信息，但是此时的场景有可能发生变化，不再是来存款，可能是来购买实物黄金，从业务的角度看，这就是两个不同的业务领域了。在进行企业级标准化以前，对客户信息的建立和修改完全有可能在存款和实物黄金的业务领域中各有一套流程，可能是任务级别的重复，也能是在不同的任务中包含的内容上有重复，实际上，以前做竖井式开发的时候，这是很常见的现象，每个业务系统都是独立的、完整的，都各自有一套客户信息，不仅重复，最重要的是经常会不一致。当我们通过企业级数据模型去除重复的数据概念之后，通过任务与实体之间的写操作对应关系，会清晰地发现重复的操作。

3. 做出关于标准化的建模判断。找到重复动作后就需要做出建模的决策，是分开建模还是将所有对客户信息进行写操作的部分集中到一起建模。还是参考上文中的例子，在 FSDM 提供的数据模型上，「参与人」这个分类中可以容纳与客户信息相关的所有数据，建模上可以把此类实体聚集在一个主题域下，比如叫做客户主题域，那么从企业级的角度也就可以将各业务领域中与之相关的任务或者涉及到该操作的任务中的客户信息部分全部抽离出来，集中到起来组成一个组件，而其他领域的任务经过调整后，不再包含此类内容，这样就完成了一个标准化过程。

2. 避免「过度整合」

上述操作是相对较为简单、清晰的标准化过程，还有些标准化过程要更难以判断，可能因此出现「过度整合」的问题。这种情况通常出现在流程看似相近的业务领域，以及一个领域内部的多个产品，后者其实更难判断，因为一个业务领域内部的流程本就相近，会很容易让人产生「整合」的冲动，因为业务建模毕竟是一种「纸上操作」，分、合都是很容易的，调整下结构而已，而整合对建模者来讲又有很大吸引力。

为了避免这种错误，需要从业务和数据两方面下手，配合检查。业务上自然是要重新审视、理清业务流程，搞清楚具体差异；而数据上要重新检视数据实体划分的颗粒度是否正确，是否包含的属性太多而导致内聚性不够。数据实体的颗粒度太小，会放大业务差异，而颗粒度太大，则会抹杀业务差异，二者都会导致不合理的标准化结果。流程模型与数据模型之间的语义互查是进行合理标准化的关键，也是一个反复锤炼的过程。

3. 何以解忧，唯有「融合」

尽管标准化问题很重要、很困难，不幸的是，并没有什么很好的方法能够帮助各位快速解决问题，这就又回到了之前说的，模型质量严重依赖建模者的经验，除了经验之外，还要依靠高质量的建模输入，既包括完善的业务资料，更需要有丰富经验的业务人员，看资料是学不会业务的，尤其是业务中经常会有「活情况」。

业务人员与技术人员融合得越好，就越能产生高质量的模型和系统，这也难怪高盛、大摩这些金融机构中数字化转型的坚定执行者，会引入占员工比例约 15% 甚至 20% 的技术人员，并直接派驻到业务部门与之共同工作。相比之下，一般国外金融机构技术人员占比不足 8%，国内通常为 4% 左右，近几年才刚刚有所增加。目前似乎也可以讲，除了科技企业，其他行业中还很少有哪个企业真的达到了与信息时代、数字化时代相称的人员结构。

尽管标准化过程很痛苦、自身又似乎很不「标准」，但是因其对企业级业务系统的构建意义非凡，因此，所有做企业级转型、希望建设企业级业务系统的企业和开发者，都必须认真对待这一过程，尽管这一过程未免有点「纸上谈兵」，但它的优势也在这里，这一阶段的任何调整都是代价极低的，而不合理的设计一旦传导到开发上，就将产生较大的纠正成本。

对于大型复杂系统而言，因其面对的问题域异常庞大，所以需要一套清晰的业务与 IT 的架构映射关系指导企业的持续建设，这就如同人们对地图的需要一样，只有践行标准化才能提供一张准确的地图。这种标准化也是识别中台能力的基础，就算是阿里的中台，也应当是在技术人员与业务人员的不断融合、反复的标准化与去重过程中沉降下来的。

尝试构建轻量级架构设计工具

《企业级业务架构设计：方法论与实践》一书中介绍的构件模型有利于提升设计效率，是业务架构的另一种表达形式。该书所讲的企业级业务架构设计，其特点之一就是业务架构设计元素与IT设计元素之间较为直接的关联关系，构件模型具备这种联系，除了分析、定位需求外，这种联系可以被用于建立轻量级的企业架构及项目管理工具，拓展其应用范围。

1. 构件模型的抽象要素及逻辑关系

（图15-1构件模型的抽象结构）

1. 模板与构件 。每个业务领域下都可能有一到多个模板用于设计业务实例或产品；模板可以包含若干个构件，组装式开发就表达为业务实例或产品与模板、模板与构件间的对应关系。
2. 构件与参数 。构件中可以记录复用推荐度，以方便业务人员后续做设计时使用；构件中会包含多个参数，参数尽量使用数据模型中的数据项，但是实际操作中也可能需要列入一些与业务无关的技术字段，此外，应该给每个参数注明是否为可供业务人员直接配置，不可直接配置的参数则不提供面向业务人员的配置界面。
3. 构件与服务 。一个构件对应一到多个实现上的服务，构件此时代表的是一个服务集合，对构件的复用不是任意去复用 SOA 中的服务，而是构件对应的服务整体对外提供一个能力，这才是「零件」的含义，否则，构件就不是一个真实的存在，如果原有构件中的一部分服务又被集合成了新的能力，则应再增加一个构件进行对应，这样的构件才会真正有部署的含义。
4. 服务与报文。 服务由于可以被调用，因此会对应报文，既包括请求报文也包括响应报文，报文中又会包含构件对应的参数，二者可以合二为一，也可以分开表达。
5. 实例化。 模板在生产中，派生为业务实例或产品，在产品销售前即销售过程中，完成所有参数的赋值。
6. 产品目录每个业务实例或产品会有描述性的标签信息，这些信息的集合就形成了产品目录。

2. 轻量级架构管理工具的设计原理

基于以上构件模型的主要要素及其逻辑关系，结合系统设计原理，可以形成一个轻量级的架构设计和管控工具，其逻辑示意图如图15-2所示。

（图15-2 轻量级架构管理工具的逻辑图）

以金融领域为例，在金融领域中，业务系统的设计主要是为了实现业务实例或金融产品，因此，系统是为了支持一到多个业务实例或产品而存在的，这是用户视角的系统可见部分。

图15-2中的设计部分，业务实例或产品由模板配置而成，模板实际上是一种领域模型，不同领域的产品可能差异较大。模板之下是构件，构件代表了一个领域的具体组成部分，是「零件」，构件中包含数据，也就是参数。

构件又进一步分解为服务，服务实际上既包含了行为，如果是「微服务」设计，则也会包含对应的数据。服务作为设计上的底层核心元素，可以从统计角度包含服务归属的物理组件、引用该服务的用例、语言类型、代码行数、原初开发或累积的人月数、归属的开发团队等等可用于项目管理的信息。其中有些信息可以通过工具或配置信息获得，有些需要人工维护。

3. 采集项目信息的价值

尽管信息采集会采来一定的工作量，但是，其所累积起的项目信息库对于大型企业的项目管理而言非常有价值，毕竟目前的现状是，一个企业可能做了不少项目，其中不乏大型项目，但是积累起来的、可以用于项目快速决策的管理信息却少的可怜，只知道项目最终花了多少钱，但却不知道钱都花到哪里去了，也不知道系统中的核心部分到底花费了多少成本，系统再次进行更新改造、上新功能时，预算基本还是靠功能点估工作量的「拍脑袋」算法。

如果信息采集过程可靠，那么以这个逻辑建立起来的平台不仅可以用于支持快速的架构设计，也可以将项目成本分解至服务层面，甚至基于这个比较团队的开发效能。总之，需要考虑设计一套逻辑进行项目信息的有效收集和分析，否则项目开发永远无法向「精益」靠拢。

4. 轻量级架构管理工具的优缺点

通过将上述逻辑工具化后，可以基于构件模型建立起一个从业务直通底层实现且信息量丰富的轻量级架构工具，从之前的讨论中可以发现，该工具有如下优势：

1. 便于业务人员理解深层设计，从而加大业务人员参与度，提升业务与技术的融合；
2. 能够有效展现系统的构件化程度和组装方式，加快系统分析、定位和设计的速度，提高沟通效率，尤其是对于跨组件、跨部门、跨团队的设计，这种设计实际上将业务架构和应用架构结合在了一起；
3. 通过对底层服务的详细描述，可以累积项目自身的数据信息，便于进行快速的成本测算、可行性评估。项目预算其实一直是企业的困扰，缺乏有效的估算方式，又难以结构化地利用历史数据，通过这种方式，能够提升评估的准确性，减少项目预估结果的波动性，再基于实际支出情况不断调整，可以逐渐提升其精确性。

不足之处，显然，需要投入一定精力去维护，不过这种精力上的支出应该尽可能与项目同步付出的，不要搞成后补之类的处理方式。

5. 应用该工具管理新需求

作为架构设计和管控工具，自然要通过它去分析和管理新需求。通过第 14 章的介绍，构件模型可以形成新的流程表达方式，不同于业务模型是基于角色和职责，构件模型基于系统结构和关系，通过一条顺序流「串」起构件，形成完整的业务处理过程，因此，新需求可以快速定位到系统的修改位置，如果是需要新增构件，则很容易可以定位到需要增加构件的位置，分析新构件与原有构件的关系，最重要的是，这一切可以很方便地由产品经理、业务人员完成，并加快业务人员和技术人员的沟通速度，其工作方式设想图如图15-3所示。

（图15-3 应用轻量级架构管理工具管理新需求）

1. 原有功能改造需求

业务人员在产品销售或服务提供过程过程中产生新需求，通过产品与模板的对应关系，找到实现产品的构件模型，与技术人员共同基于构件模型分析产品需求的实现位置，如果是对原有产品的改造，则可以根据构件的切分，很快找到需求的实现位置，进而定位到需要改造、新增的服务及数据。

2. 新增功能需求

如果是原先没有的业务环节或者全新产品（这种情况其实较少），则会产生构件级别的新增，但是基于原有的业务环节，可以很快定位出新增环节与原有环节的关系，设计前后构件间的数据关系、构件接口。

在这种分析模式下，可以让业务用户以更为「专业」的方式高效参加到业务或产品设计过程中，将更加「精准」的需求传导到开发环节，提升开发效率。

如果企业原先的开发模式中，业务人员要提供较为完备的业务需求文档，那在这种方式下，业务人员的工作量会大大降低；如果企业原先的开发模式中，经常出现「一句话」需求，那在这种方式下，「一句话」会变得更精确。

企业级业务架构的设计成果要想具有生命力，最重要的莫过于经常使用，这一点无论对任何架构设计模式都一样。使用该工具管理新需求，其目的就是将业务架构变成连接业务与技术的「通用语言」，使用越多则沟通越容易，也越容易被各方接受去用于沟通，这是一种正向循环。因此，一旦选择了走企业级业务架构这条路，请务必记住《红楼梦》中贾宝玉的「通灵宝玉」和薛宝钗的「金锁」后边的铭文：「莫失莫忘，仙寿恒昌；不离不弃，芳龄永继」。

作者怎么说？

企业级转型是一个很艰难的过程，它并非一个单纯的技术问题，因为转型涉及企业的方方面面，如果想走通这条路，尤其是对传统企业而言，充分认识自身、寻找适合自身的方法极为重要。笔者多年从事企业级业务架构设计与管控工作，有幸参与了一次历久弥新的企业转型工程，对业务架构在企业级项目和企业转型过程中发挥的作用深有体会，因此，笔者将对业务架构工作的感悟与自身的学习结合起来，超脱原有的工作实践和理论指导，面向可操作的一般方法论写作本书。

本书希望能够成为一本让各类读者都可以读得懂的架构书，因此，书中没有让人拿捏不准的概念。殊少概念可能会因为追求易懂的效果而让部分读者觉得有失严谨，但是，「易懂」也是架构设计应当追求的目标之一。与概念较少相对应，本书的「感受」成分稍多，因为笔者相信融入「感受」比单纯写方法更容易引起读者的共鸣与思考。

更多精彩商业洞见，请关注微信公众号：ThouhgtWorks商业洞见