企业级业务架构设计（4） 改良篇

企业级业务架构设计

改良篇

支持面向构件的设计

软件设计中应对复杂问题的“永恒之道”就是“拆”，软件实现就是通过拆分的方式来降低复杂度，从而为复杂问题域找到合适的解域。然而，“拆”的学问，从软件设计诞生起直到今天，也未能形成一个公理。

乐高式软件设计

软件设计一直希望能够通过对原有成果的复用来实现新的需求，从而达到快速响应和降低代码资源“浪费”的目的。如果代码片段能够像“乐高积木”一样通过标准化接口“自由”组装，那么软件开发的灵活性将大为上升，这也将使得沉淀在软件设计中的领域知识不必一而再再而三地被重复实现。

这种“乐高积木”式的设计思路在软件领域中早已存在，并且还有一个很“高端”的名字——CBD（Component-Based Development，基于构件的开发）。

颗粒度问题

面向构件的设计在理论上似乎是非常完美的，但是操作上却有一个很直接的问题：到底要将什么东西设计成构件？（微服务其实也是构件的一种）。

构件开发并不是服务之间可以互相通信、互相调用就万事大吉了，这样的逻辑对于技术人员而言好像还可以接受，但是却无法传递给业务人员，这种逻辑成了单纯的技术组装。另外，如果服务“颗粒度”划分过细，那么这样的构件开发将会拖累死通信机制，最后形成一个混乱的网状通信，使得迭代、升级变得异常复杂。

不少实践采用DDD方法指导微服务设计，并取得了一些成果。但是DDD方法本身的学习门槛比较高，不容易掌握，规模不大且较为成熟的架构师团队，要在内部对其方法理念达成基本一致的理解，大概也需要半年左右的时间。

业务模型的建模过程很注重标准化，标准化就是一个去重的过程，其会尽可能地保证流程构成元素的唯一性，以免重复建设。但是，任务这个层级对前文讨论的服务“颗粒度”划分或者面向构件的开发而言，粒度的“粗细”未必合适，它更符合业务视角的企业级架构设计。

构件模型设计

可以在之前设计的业务模型中再增加一个面向构件的表达，并通过这一表达形成面向业务实例或者产品的构件化设计。构件模型中应当包含模板、构件、参数三个部分：

• 1 构件：构件化开发要求更强的结构化，设计时应将设计对象切分成“零件”，通过组装“零件”、调整“零件”来快速实现新设计。

• 2 参数：构件模型中的参数与一般项目上所做的参数化设计类似，可以通过参数配置快速刷新产品。

• 3 模板：带有参数的构件加在一起就形成了一个有结构的装配模板，用于“组装”业务实例或产品，这样的模板即表达了构件化设计，又可以用于参数配置，而模板本身也可以起到另外一个作用，那就是服务的编排或者“粘接”。

虚拟案例

【采用非构件模式实现的金融产品竞价功能】

涉及竞价业务的金融产品可能会有这样的流程，即资金拥有方，比如银行体系中的总行，总行具有较大的资金调度权力，可以通过对某笔闲置资金进行内部竞价，从而确定出价最高的分行可以运用该笔资金去经营业务以获取收益。

因为通过竞价决定资金归谁使用其实是有机会成本的，因此竞价过程中可能还需要通过计算EVA（经济增加值）的方式，进一步衡量其经济贡献。

竞价过程业务模型简化示意图：

竞价过程的流程模型假定包含了3个任务，数据模型简化处理后设计了4个数据实体。

总行发布竞价通知，这时可能会创立总额度，一个总额度可能拆分成多个竞价通知，每个竞价通知包含不同的额度；

之后分行根据竞价通知申报竞价意向，报出自己的价格；总行将各分行的意向申请综合审核，计算并比对EVA值，然后确定最终的竞价结果。

该业务模型进入开发环节，炒粉后的服务设计如下：

3个任务可能会拆分成9个服务，这是很常见也很正常的拆分方式。通过对用例进行分析，做操作级的设计实现，即可能将任务拆分成很多细粒度的服务

【采用构件模式实现的金融产品竞价功能】
如果不做企业级考虑，仅从一个或者少数几个产品的角度来看，实现到上文所描述的程度，尽管在维护上有些麻烦，却也没有什么太大的问题。但是如果做企业级设计，从多个产品线的角度，深入理解业务的话，则很可能会与业务人员认为的“组装”存在差异。

比如，业务人员需要的很可能是将“竞价通知”和“意向管理”分别作为2个可以组装的“构件”，因为有的产品可能有竞价和意向2个环节，而有的产品则可能没有竞价，但需要意向环节，还有的产品可能两个环节都不需要。

同为操作级的EVA计算则可能比其他服务具有更广泛的复用能力，可以在其他领域出现在很多不同的流程环节上。

从这个角度来看，业务需要的可能不是面向操作步骤的过“细”的服务划分，而是面向如何更好地响应业务变化的服务划分方式，这就是上文提到的，基于已经完成标准化的业务架构模型，在对任务进行实现时，从企业级视角通盘考虑，如何才能设计出更有业务含义的“构件”。

此时构件模型可能设计如下：

业务很可能只需要两个看起来较“粗”的流程构件和一个具有更强通用性的纯粹能力构件，这种划分思路更加面向业务对“组装”（或者说“复用”）的实际需求，而非常见的、面向操作实现的、较“细”粒度的服务划分方式，不只是要满足技术视角的“组装”，同时也要满足业务视角的“组装”。

在这个简化模型中，由于“申报竞价意向”和“确定竞价结果”在数据方面是相同的，因此这两者也具备整合的基础。如果基于上述“构件模型”进行服务的重构，则服务划分结果可能只需要包含3个服务，这一点非常类似于基于DDD的微服务划分结果，但是相较而言，这种更容易上手。

这种设计结果在项目开发初期似乎很难直接形成，因为其需要更多设计层面的思考，需要反复理解业务人员的想法，尤其是在涉及跨领域需求的情况下。

【小结】
构件模型的思路非常符合企业级业务架构的设计目标，其本身相较于流程模型来说更贴近IT设计，因此构件模型在业务架构向IT架构过渡方面可能会发挥更大的作用。由于其视角更加面向业务，因此其仍然可以被视为业务模型，尽管其设计难度远大于流程模型和数据模型。

这种模型打破了原来业务模型较为单纯的业务属性，将业务含义与具体实现直接结合在了一起，而且是基于构件串起来的执行流程，其是一种可以在一定程度上满足流程与能力解耦的表达方式。

构件模型也会因此打破原来流程模型中的任务边界，产生新的模型表述方式，这种情况下，可以选择是否将其视为流程模型的一次新视角的迭代，替换掉原有的流程模型。

下面是通过构件模型展示的流程图：

与业务人员原来的流程表达习惯相比是有较大调整的，但是这些调整将非常有利于业务和技术之间的沟通。业务架构整体逻辑关系图如下：

活动由构件串联而成，构件中既可以包含行为，也可以包含数据，这个数据既可以是完整的数据模型，也可以是只选择参数部分。

构件模型的技术设计建议

基于构件模型的技术设计可以参考下图：

• 参数的实现：构件化设计产生的模板可用于实例化成业务实例或产品，实例化的结果中包含参数清单，其中可配置的参数可以基于业务操作形成的赋值结果生成参数记录，用于在服务被调用时提供参数。参数中包含的界面数据项则可以用于界面的动态生成。

• 构件的实现：实例化的结果中还包含构件清单，构件清单可以用于服务编排。

小结

这种构件设计方式是一种可选的设计方式。也就是说，如果不做这种面向组装的构件模型，只用之前介绍的业务架构方法，也足以实现企业级设计；做好参数化，也可以完成一定程度的灵活配置，只不过对于构件化设计的表达有一定的欠缺，这就要看企业希望实现的设计目标了。

这种方法在业务建模过程中显然是难以一次性完成的，尤其是在企业初次进行企业级转型，做最初的业务架构设计时。

同时这种方法也无法以业务人员为主去做，因为有较多的系统分析与设计方面的考虑，更偏向于技术人员的工作范畴，因此，必须要有技术人员深入参与，与业务人员一起共同完成设计。

从模型的角度来讲，“构件”仍然是逻辑的，要落实到“服务”才是物理的，而服务的实现很多时候会依赖于开发团队的设计习惯和经验。

对于大型企业级项目来讲，如何在企业范围内逐步实现合理的颗粒度判断原则是个难题，要靠过程和沟通去逐步形成，而良好的构件模型对于实现开发风格的一致性也是有很大的帮助的

构件化设计的关键因素其实还是对业务的深入理解，这不仅是要求业务人员应尽可能充分地提供业务知识，也是要求IT人员应主动地深入学习业务。

构建轻量级架构管理工具

构件模型有利于提升设计效率，是业务架构的另一种表达形式。

构件模型抽象

设计架构管理工具之前，我们再来总结下构件模型的抽象结构：

• 1 模板与构件：每个业务领域下都可能有一到多个模板用于设计业务实例或产品；模板可以包含若干个构件，组装式开发可以表达为业务实例或产品与模板、模板与构件间的对应关系。

• 2 构件与参数：构件中可以记录复用推荐度，以方便业务人员后续做设计时使用；

构件中还会包含多个参数，参数应尽量使用数据模型中的数据项；应该为每个参数注明是否可供业务人员直接配置，若是不可直接配置的参数则不提供面向业务人员的配置界面

• 3 构件与服务：一个构件可以对应一到多个实现上的服务，构件此时代表的是一个服务集合。

• 4 服务与报文：由于服务可以被调用，因此服务会对应报文，报文既包括请求报文，也包括响应报文。

• 5 实例化：模板在生产中会派生为业务实例或产品，在产品销售前及销售过程中，所有的参数都将完成赋值。

• 6 产品目录：每个业务实例或产品都会有描述性的标签信息，这些信息通过集合形成产品目录。

架构管理工具设计原理

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

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

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

构件又可以进一步分解为服务，服务实际上就包含了行为，如果是微服务设计，则也会包含对应的数据。

服务作为设计上的底层核心元素，可以从统计角度包含服务归属的物理组件、引用该服务的用例、语言类型、代码行数、初始开发或累积的人月数、归属的开发团队等可用于项目管理的信息。

其中一些信息可以通过工具或配置信息来获得，另一些则需要人工维护。

采集项目信息的价值

尽管信息采集会带来一定的工作量，但是，其所累积起的项目信息库对于大型企业的项目管理而言是非常有价值的。
一个企业可能做了不少项目，其中不乏大型项目，但是积累起来的、可以用于项目快速决策的管理信息却少得可怜。

只知道项目最终花了多少钱，却不知道钱都花到哪里去了，也不知道系统中的核心部分到底花费了多少成本。系统再次进行更新改造、新功能上线时，预算基本上还是采用功能点估工作量的粗略估算方法。

如果信息采集过程可靠，那么以这个逻辑建立起来的平台不仅可以用于支持快速的架构设计，还可以将项目成本分解至服务层面，甚至基于这一点来比较团队的开发效能。

总之，需要考虑设计一套逻辑进行项目信息的有效收集和分析，否则项目开发永远无法向“精益”方向靠拢。

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

【优点】

• 1 便于业务人员理解深层设计，从而提高业务人员的参与度，加深业务与技术的融合度

• 2 够有效展现系统的构件化程度和组装方式，加快系统分析、定位和设计的速度，提高沟通的效率，尤其是对于跨组件、跨部门、跨团队的设计，实际上是将业务架构和应用架构结合在了一起。

• 3 对底层服务进行详细描述，可以累积项目自身的数据信息，以便进行快速成本测算、可行性评估。

项目预算其实一直都是企业的困扰，因为其缺乏有效的估算方式，又难以结构化地利用历史数据。这种方式能够提升评估的准确性，减少项目预估结果的波动性，再基于实际支出情况不断进行调整，可以逐渐提升其精确性。

【缺点】
其需要投入一定的精力去维护。不过这种精力上的支出应该尽可能地与项目同步，不要变成后补之类的处理方式。

应用工具管理新需求

作为架构设计和管控工具，轻量级架构管理工具自然要用于分析和管理新需求。

构件模型可以形成新的流程表达方式。不同于业务模型是基于角色和职责的，构件模型是基于系统结构和关系的，其通过一条顺序流“串”起构件，形成完整的业务处理过程。因此，新需求可以快速定位到系统的修改位置。

如果需要新增构件，则可以很容易定位到需要增加构件的位置，分析新构件与原有构件的关系。最重要的是，这一切可以很方便地由产品经理、业务人员来完成，并提高业务人员与技术人员的沟通效率，其工作方式设想图如下：

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

• 2 新增功能需求：如果是原先没有的业务环节或者是全新产品，则会产生构件级别的新增。但是基于原有的业务环节，可以很快定位出新增环节与原有环节的关系，设计前后构件间的数据关系、构件接口。

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

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

业务架构的设计成果要想具有生命力，最重要的莫过于经常使用，这一点对任何架构设计模式来说都是一样的。使用该工具管理新需求，其目的就是将业务架构变成连接业务与技术的“通用语言”，使用越多则沟通越容易，也就越容易被各方接受以用于沟通，这是一种正向循环。

传统企业产品创新

信息传导

信息传导就是打造信息的告诉公路，推荐使用产品目录这一工具来进行。

产品目录不是简单的产品清单，实际上它可以包含很多信息，比如可以包含设计者、管理者、销售方、合作方、产品特征、适用客户群体等各类描述信息，也就是“标签”。

产品目录可以仿照互联网产品管理方式，构建“海量”标签库，再通过产品销售信息关联客户，形成一个庞大的“图谱”，一张通过产品目录连接起来的信息网。当这个网络具备企业级规模时，它所产生的信息传导能力将是惊人的，而信息正是创新产生的基础。

产品目录能够连通公司内外，连通业务和技术，将市场信息、客户信息、销售信息、伙伴信息等各种信息通过高维数据结构组织起来，让海量信息分门别类地流向信息需求方，成为一个高效的信息传输渠道，这才是企业级产品目录真正的价值，并非仅是分类和统计产品。

如果能够按照产品目录汇集起海量、多维、完整的产品信息，就可以通过大数据和AI技术，进行更为广泛、深入的信息挖掘，产生超过单点分析的业务效果，包括产品之间的相关性、客户行为的相关性、内外部事件与产品的相关性等一系列综合分析，这是需要通过产品进行串联的分析工作。

有效应用产品目录来组织信息，可以更加贴近业务对信息的理解；经过整理的产品分析信息也可以直接推送给项目开发团队，完善项目效果反馈机制，提高设计人员了解市场信息的及时性。

信息分析

想要做好信息分析，需要高纬度的数据，这就需要充分利用信息传导中，为产品目录打标签，通过打标签来打造高维度的数据。

形成信息归集、整理和传导能力的关键因素是数据维度，而最能有效支持信息分析的也是数据维度，只有具备高维度特征的产品信息库才具备构成产品大数据能力的基本条件。大数据的价值不仅在于数据量，更在于数据维度。维度才是描述对象特征最重要的手段，而每一个标签都是一个产品维度。

从实现上来讲，标签数据包含标签、产品，以及标签与产品的关系三个部分。

标签根据产生方式的不同一般分为用户打的标签和系统打的标签两类，前者根据用户（包括内部用户和外部用户）的需要，在用户使用界面由用户添加，后者则根据预设的判断规则由系统自动添加，比如若点击率超过某一限定次数，则判断为热点等。

企业需要构建技术与业务兼顾的产品目录，构件模型本身就是IT侧需要看到的“产品目录”。

这种方式比传统的基于分类的目录结构更具有扩展性和弹性，可以兼顾业务和技术的不同需要，同时其更有助于通过产品目录建设“产品信息传递高速公路”的设想。

创新平台

产品是一个企业的价值载体，是为客户服务的实例化表现形式，无论是生产类企业还是服务类企业都是如此。产品将企业与客户紧密联系在一起，其也是企业内外部信息的重要连接点，因此，应当在产品的系统化管理及实现方面多花一些精力。

很多企业都关心创新及创新的效率问题，特别是总觉得自己比互联网企业跑得慢的传统企业。创新是一个复杂的大问题，人、制度、内外环境等要素缺一不可。

完整的由业务延伸到技术的链条：业务信息→产品目录（标签化）→业务实力或产品→模板→构件→服务→项目信息。通过这个链条，可以将一个产品的需求、设计、核算、反馈、改进都汇聚起来。因此，以这些信息为基础，可以搭建一个产品创新管理平台：

核心域：平台的核心域为产品设计域，产品设计域包括产品目录和构件模型两部分，前者是面向业务端的高维数据实现和信息汇聚，后者是面向开发端的产品实现

支持域：产品创意域、产品评价域、产品监测域

• 产品创意域：使用标签可以更好地引导创意的流向。如果有相当一部分业务人员都能够（或者在业务架构人员的协助下）了解自己领域的业务模型以及对应到构件级的系统结构，那么创新的效率一定会大幅提升。

• 产品评价域：自上而下地去做企业级产品评价的操作难度太大，还是DDD建模的理念比较靠谱。

从单个领域出发，一个领域一个领域地构建评价模型。领域内部则要一个产品一个产品地进行分类。归类后，再一个类别一个类别地与业务人员去尝试建立评价模型。单产品的评价模型顺利运行之后，再逐渐汇集领域视角的评价方法。而企业级的评价最终应当来自于可靠的领域评价指标体系的汇总与整合。

评价的数据来源通常是生产系统或者数据仓库的数据，大多还会附带少量主观评价指标，需要人工打分处理。

• 产品运行效率监测域：主要依赖于构件模型的特殊性，构件与服务之间拥有明确的联系，而构件可以按照执行顺序形成设计视角的流程模型。

如果架构设计得当，那么运维数据其实可以包含更多的业务含义，或者可以反映一定的业务问题，这都需要多加关注。

以产品设计域为核心，产品创意域导入新需求、新理念，产品评价域考核产品绩效，通过产品串联起需求、设计、评价形成闭环，产品运行效率监测域则用于提供辅助的效率改进点。以这个抽象结构为基础的产品创新平台应该可以用于传统企业的产品管理工作。

构建模型一些不足

• 不易于在企业级项目初期产生相对成熟的设计，而是需要经过反复精炼
• 架构设计的模型形态与业务人员较容易理解的流程模型形态之间存在较大的差异，因此需要一定的学习成本
• 构件类型作为架构管理工具，需要经过一定时间的数据积累才能实现，且成本统计可能会由于数据录入结果等人为因素而不准确
• 产品目录的信息传导能力也需要较长时间的建设才能形成

每一个企业在企业级转型的过程中，都应当基于自身经验进行方法论的创新和调适。在企业级转型项目结束之际，形成自己的方法论，培养出自己的方法论专家，这是知识沉淀与升华的过程，不能只关注“行线”的完成，而不关注“知线”的建设。

此外，应将“知线”逐渐开放，这是对社会的最大回馈，在架构领域尤其如此。能构成长期优势的并不是技术上的“独门秘籍”，而是享誉天下的“武德”，这才是数字领袖最难得的境界，也是所谓“侠之大者，为国为民”的精神所在。

总结

业务架构离不开业务模型，所以要想讲解业务架构就得搬出一堆枯燥的模型，甚至会让人误以为业务架构就是建模。

实际上，建模只是进行业务架构的手段，建模的目的是将现象总结成模式，再从模式中找到结构，将业务上看到的结构传递给技术。

如果业务人员和技术人员能够基于同一结构进行思考，那么沟通上将具备最大的便利，这就是通用语言的基础。

建模的原则无非是把握整体、穿透现象、保证落地，建模既不能死守规则、冥顽不化，也不能脑洞大开、信马由缰，必须从一开始就关注如何落地。建模不是建立一个自给自足的“世外桃源”，而是为后续过程传导总体的设计图纸。业务建模可以有前瞻性，但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。

企业级业务架构是在不断演进和迭代的，它拥有生命力，可以成长。业务架构的形成过程的确是在一种看起来科学的方法论下，不完全科学地进行操作的。

做软件架构的其实很羡慕做建筑架构的，觉得建筑架构有力学基础做支持，有很多可以计算的东西，软件架构却没有多少能够计算出来的成分。

对业务架构进行设计可能很快，也可能很慢。快无非出于两种情况：一是架构师自身的技术已达到炉火纯青的境界，设计能力超强；二是原有业务模型本身就已经很清晰了，可以快速分析业务变化，形成架构设计。

我们更应该追求的是第二种情况，这也意味着首次建模，尤其是首次建设企业级模型，不要过快，对模型设计方法、业务流程分析、标准化过程，都要认真细致对待，只有基本功扎实了，才能有后面的“敏捷”。

企业级转型不可能是轻轻松松就能完成的，不少企业只是将企业转型当成一个项目，而忽视了对自身的调整。一个普通士兵要想变成一个特种战士，不是因为给了他一身价值高昂的装备，而是经过了地狱般的训练。上至最高管理者，下至普通员工，若人的思维不发生转变，则不会带来企业的转变。

为了推动企业进行真正的数字化转型，业务架构设计人员永远不要忘记，业务架构最重要的职责不是传递需求，而是藉由自身的努力，推动业务和技术的深度融合，业务架构最重要的职责是起到桥梁连通的作用。如果不能实现这一目标，也就不能真正实现一个快速响应内外部变化的企业级业务系统。