4.3　元模型详解

业务架构元模型包括战略元模型、组织元模型、业务元模型、业务构件元模型四个部分。

4.3.1　战略元模型

战略是企业发展的方向性指导，也是凝聚企业力量的关键，很多互联网企业都非常重视自身战略管理能力的建设，尤其是会影响企业文化的愿景、价值观等的能力。战略元模型如图4-3所示。

图4-3　聚合架构方法论的战略元模型

关于战略元模型，笔者考虑了“愿景、价值观”“战略”“战略能力”“用户”“空间”五个要素。

1.愿景、价值观

愿景和价值观通常是企业的长期目标，而且可以是少量“名言金句”类的表述，用于在深层次的认知层面统一企业所有人的意识形态，让所有人知道企业的长期发展方向，知道企业的“性格”。无论是传统企业还是互联网企业都很重视企业文化的建设，这是一种软环境，而文化的核心是认同感，认同感也就代表了一种价值判断，认为什么样的行为对于企业而言是合适的。提炼不出合适的愿景和价值观，就难以形成企业内部长期而一致的认同感，也势必影响企业中各级员工对战略主张的认同。但是，价值观又不能仅仅是提炼的文字，它是从企业领导者开始亲身实践的行为总结，没有领导者带头实践的价值观，就会成为仅要求员工遵守的行为准则，可以产生约束，难以产生动力。

2.战略

战略是企业未来一段时间要实现的内容，可以表现为目标、任务、结果等。战略是受到“愿景、价值观”影响的，因为“愿景、价值观”决定了企业该做什么、不该做什么。战略是用来支持“愿景、价值观”的，因为没有付诸实践，愿景就成了空话；没有行动中体现出来的取向，价值观也就成了口号。

战略可以按时间划分为短期、中期、长期，一般对应1年、3年、5年的规划。战略绝对不可以做成“标题党”，而是必须成为企业真正的工作目标。由于现在的时代变化速度非常快，所以很多人认为1年以上的战略往往风险很大，调整的概率极高。但这并非企业可以不做战略的原因，反而说明企业需要加强战略管理能力，加强信息收集和判断能力。对于战略，我们不能因噎废食，就像我们不会因为航班会延误就选择不出行一样。对待风险通常有转移、分散、接受等基本策略，对待战略风险也一样，风险出现时，选择合适的应对策略即可。在战略的制定中最重要的是做好自己的判断，如果我们一味地追着别人的风向标跑，很容易面临不可预期的调整风险。战略的实现是依赖战略能力的。

3.战略能力

我们经常批评“假大空”的战略，造成“假大空”的主要原因是没有对战略进行细化的能力分解，没有把战略落实为一项一项可以建设、可以实现的能力，没有来自于战略能力的支持，战略当然无法实现。所以，“假大空”问题的责任不在于战略，而在于没有对战略的实现进行更深入的思考。

4.用户

现在很多商业理论都在强调“用户第一”“极致体验”，对用户的重视程度越来越高。的确，企业能够存在的基本条件之一就是可以持续为用户创造价值，因此应该将用户放在其战略设计部分中，明确企业准备服务哪些用户。企业与用户之间是一种互动关系，所以，企业的“愿景、价值观”会受到其服务的用户的类型、范围、文化特征等方面的影响。当然，这种影响并非单向的，而是双向的。

5.空间

空间是笔者面向数字化转型强调的战略级元素。按照笔者在《银行数字化转型》一书中的定义，数字化转型在技术实现上最核心的就是将人类在物理世界的生产和生活行为转向虚拟空间中进行，所以我们不能仅将空间看作渠道，而是要将其提升到企业战略设计中。这种提升可以是当前二维渠道向三维空间的跃迁，反过来讲，没有处理好可能会面临“降维打击”。读者可以参考之前银行与互联网企业在移动端的用户、场景争夺战，如果对空间的重视程度不够，无论是在用户服务方面还是在内部生产效率提升方面，都可能受到“降维打击”，用户、岗位、业务服务都是活动于“空间”之上的。

4.3.2　组织元模型

根据TOGAF的定义，企业是具有相同目标的一系列组织的集合。这是一个外延很宽的定义，并非特指通常认为的生产性、经营性企业。根据这个定义，企业其实本就没有内外部之分，而是一个目标导向的非固化集合体，很有今天常说的生态型、开放型企业的意味。

基于这种对企业概念的理解，组织元模型中包含的内容如图4-4所示。

组织设计是为了支持战略设计的实现，因此我们将组织元模型中各项内容结合战略元模型进行介绍。

1.治理体系

治理体系描述的是企业的权力分配机制，主要是所有权、经营权和监督权之间的分配关系。治理体系在一定程度上会受到“愿景、价值观”的影响，尤其是“价值观”，如果利益相关方对组织价值观的认可不一致，通常会反映到权力分配关系上。

2.组织单元

组织单元可以理解为事业部、部门、团队、临时团队等各种可以将多个岗位聚合在一起的形态。组织单元的设计由治理体系约束，治理体系的分权设计会约束各个获得相关权力的利益相关者在自己职权范围的组织设计能力。同时，组织单元的设计也是由战略决定的，是为了践行战略而存在的。因此，组织设计是目标导向，即以战略为导向设计组织结构。组织结构可以是灵活的，因为组织是岗位的聚合，聚合关系表示岗位是更独立、更稳定的存在；而组织则可以根据需要灵活调整，也必须拥有这个能力。数字化企业应当采取开放式架构模式，因此，组织单元不分企业内外，只要是在生态建设中进行了某种连接的组织都可以体现在企业架构设计中。

图4-4　聚会架构方法论的组织元模型

3.岗位

岗位代表的是在业务活动中出现的各类角色。岗位是能力和职责的集合，战略能力必须细化到具体的岗位，以保证能力建设有明确的指向和载体。岗位是相对稳定的，因此，岗位可以根据需要聚合成组织。随着数字化的发展，岗位已经可以转变为自动化岗位，对自动化岗位而言，战略能力的指向更强，一旦形成也会更稳定。由软件或硬件设备履行的具体职责都可以视为岗位，自动化岗位的增多已经逐渐成为趋势，例如不断深化的对RPA的认识。岗位的清晰定义有利于能力的积累和识别。

4.3.3　业务元模型

业务是企业实际的价值创造过程，是岗位通过一定的服务方式为用户（含内部）实现价值的过程。在某些行业中，这个过程可能很长，比如医疗行业为慢性病患者提供的治疗服务；而在另一些行业，这个过程可能非常短暂，比如互联网内容服务商提供的短视频服务。但是抽象来讲，所有的业务都是由用户、岗位、规则、服务、数据和空间等元素组织起来的。这些内容加起来，更像是今天大家常提及的“场景”，“场景”其实是一个影视剧术语，指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系而构成的具体生活画面。业务元模型中包含的内容如图4-5所示。

图4-5　聚合架构方法论的业务元模型

1）业务规则。业务规则是由岗位制定的，是业务服务过程中必须遵守的约定，既包括常见的业务制度，如银行中大量的内部经营管理制度，也包括产品服务承诺，比如快递送达时间的承诺，以及数字化产品中经常出现的算法规则，比如用户画像到产品推荐过程中的各种算法，这些算法并没有被抽象成制度，但实际上比制度的可执行性、约束力更强。业务规则一旦形成，也会形成对岗位的约束。

2）业务活动。业务活动通常是由岗位遵循一定的业务规则执行的业务过程。从抽象角度讲，企业对外的营销活动、产品服务、售后服务、监管报送等，企业内部的战略制定、落实监督、目标制定、目标考核、架构设计、方法论研究等都属于业务活动。业务活动的服务对象可以是外部用户，也可以是内部岗位，业务活动总是在一定的空间中进行的。

业务活动会生产或消费（经常同时进行）业务对象。业务活动可以根据需要聚合成业务领域，也即，业务领域实际上是多个业务活动的聚类。从抽象角度讲，如果一个领域内的多个活动可以“无缝”连接，那一个业务领域实际上就是一个很长的、端到端的业务活动。经常有读者询问笔者关于业务领域的定义原则，在笔者看来，业务领域其实不需要特别明确的定义，它是业务活动的灵活聚合，类似组织单元与岗位的关系，细分的业务活动和业务对象是相对稳定的，业务领域可以根据战略、组织单元和对用户的理解进行灵活的定义与调整。

3）业务对象。业务对象指的是高阶逻辑级的数据模型，除了常见的申请表、报告单、用户信息等业务对象外，业务经验、架构设计成果、方法论等业务知识也都属于业务对象。面向数字化转型，笔者认为，一切业务服务最好都能产生可数据化的业务对象，业务活动与业务对象的关系识别就是实现“一切业务数据化，一切数据业务化”的起点。知识服务是企业转变成知识型企业所必须建立的业务活动，所以，知识也是很重要的业务对象。严格来说，“愿景、价值观”“战略”“战略能力”也属于业务对象，但考虑到上述元素的重要性以及让元模型更容易理解等因素，我们将它们与业务对象分开描述。

业务对象（Business Object，BO）一词在软件设计中也指对数据进行检索和处理的组件，包含状态与行为两部分，但是笔者本处使用该词仅指业务人员对业务处理对象的认知，是数据模型建立初期的识别过程的产物，是用于后续细化数据实体的输入。

业务对象也有聚合能力，可以向上聚合成更高阶的业务对象主题域，而是否要执行这一聚合则是可选项，执行聚合通常是指为了更好地确认业务对象之间的关系和业务对象识别的完整性。

4.3.4　业务构件元模型

业务构件是业务架构中构件设计的关键，是提炼用于组装业务服务的基础元素。业务构件元模型中包含的内容如图4-6所示。

图4-6　聚合架构方法论的业务构件元模型

1）业务构件。业务活动可以发生一定的变化，与支持活动的基础能力相比，业务活动是不够稳定且可变的，如同岗位与组织之间的关系。业务构件是对业务行为和业务数据的“封装”，战略能力通过岗位传递到岗位执行的业务活动上，进而沉淀在业务构件中包含的业务能力上。业务构件可以按照业务活动的需要进行组装，这是对业务的结构化。业务构件可以聚合成业务组件，聚合的依据则是不同业务构件包含的业务数据之间的业务关系。这种定义要遵从业务的理解，其表达也应是业务人员可以理解的。业务构件的设计要尽可能减少行为重叠，行为重叠会造成资源浪费。但在实际业务中，完全不重叠可能较难实现。尽可能避免数据重叠，数据重叠会造成耦合，并向开发侧传递数据一致性问题。业务构件应尽可能被技术人员以系统化的方式实现，但并非所有业务构件都可以实现系统化。

2）业务任务。业务任务是实现业务预想结果所必须执行的一系列动作，可以固化成一段操作过程、一个具体的操作动作或一连串软件行为。业务任务在执行过程中会消费或产生一定的业务数据，无论是否是由业务系统支持的执行过程。可能有一些业务行为不易数据化，比如与用户共情，但是不应放弃以数据进行描述的努力。业务规则也可以被直接实现为业务行为，比如特定风控规则的实现会表现为针对特定场景的风控行为。

3）业务数据。业务数据是对业务对象状态以及业务任务执行过程与结果的描述。业务数据可以组成业务对象，这意味着不同的业务对象可能具有部分相同的业务数据。业务对象是概念级的数据模型，而业务数据是逻辑级的数据模型。业务数据应当具备企业级的唯一性，以满足数据标准化的要求，建议遵从三范式的要求。业务数据可以聚合成主题域，以表现具有一定联系的数据集合，并为业务构件的聚类提供判断依据。

4.3.5　业务架构元模型

业务架构设计是结构化分析、设计企业整体业务能力的过程，包括了对战略、组织、业务、构件的分析与连接。本书提出的业务架构元模型所代表的业务架构设计模式并非全新的、颠覆性的业务架构设计模式，依然是在传统企业架构方法论上的演进，其自身的特点主要集中体现在对业务的深入构件设计上，这是实现真正的构件开发模式的基础。以往的构件开发实践（模块化、SOA、微服务等）在业务侧的分析不足，更多聚焦在技术侧的设计，缺少对业务人员结构化思维的培养和对业务自身的构件设计。如果业务自身没有很好地进行构件设计，通常技术侧也不会产生好的构件设计。

与其他企业架构方法论相比，本书提出的业务架构元模型弥补了FEA、DoDAF、DDD等方法论在企业整体分析方面的不足；与Zachman框架、TOGAF、CBM等方法论相比，提高了业务分析方面的结构化程度，提高了业务与数据在分析过程中的结合程度；与中台方法论相比，对业务分析具有更清晰的指导作用；与BIAN相比，更注重业务与数据的结合，更注重战略、组织、业务之间的连接，并且希望将这种连接显性化，同时也更注重与技术侧的连接。本书提出的业务架构元模型也涵盖了对知识的管理。

业务架构元模型包含的内容如图4-7所示。

图4-7　聚合架构方法论的业务架构元模型

4.3.6　应用架构元模型

应用架构是业务架构与技术架构的连接环节，业务的结构化分析成果通过应用架构转化为逻辑服务、逻辑数据并由技术架构最终实现。经过应用架构设计，业务需求转化为技术需求，尤其是功能性需求，因此元模型也聚焦于功能性需求的连接上。应用架构元模型如图4-8所示。

1）逻辑功能。逻辑功能是根据业务任务设计的，逻辑功能会生产或消费一定的逻辑数据，因为是面向系统设计的，所以逻辑功能必须生产或消费逻辑数据。逻辑功能会组成应用构件。业务任务与逻辑功能之间可以不是严格的一对一关系，但考虑到整体能力地图的清晰性，应该尽可能保持业务能力对逻辑功能的一对一、一对多关系（以一对一关系为主，一对多关系主要是考虑实现的制约）；应尽可能减少业务能力对逻辑功能的多对一关系，这种关系意味着业务构件的边界重叠。

2）逻辑数据。逻辑数据同样是逻辑级数据模型，但是考虑到设计实现，与业务数据相比，可以适当进行“降范”，考虑派生数据等，并允许一定程度上的冗余，但这不意味着无限放开冗余，而是在考虑设计必要性时放开。主题域由业务数据聚合而成，逻辑数据是“降范”的业务数据，因而不再考虑通过聚合的方式定义这一层级的主题域。

3）应用构件。应用构件是对逻辑功能和逻辑数据的“封装”，是技术层面设计的“积木块”，是构件设计在技术侧的体现。应用构件的设计要以业务构件为指导，尽可能保持一致，以确保业务侧对业务构件的可组装预期能够顺利过渡到技术侧对应用构件的可调用设计。应用构件可以聚合成应用组件（相当于逻辑子系统），组件可以辅助开发任务的分工。组件可以再聚合成应用架构的分层，但是应用架构的分层无须在元模型层级展现。

图4-8　聚合架构方法论的应用架构元模型

4）应用编排。业务活动通常是经过一定的过程来实现的，在业务侧，笔者将其定义为业务活动对业务构件的组装；在技术侧，笔者将其定义为应用编排对应用构件的调用。应用编排反映了技术侧对业务活动过程的实现，但需要注意的是，业务活动的范围可能大于应用编排，这意味着存在线上线下协同的场景。此外，应用编排也有可能出现不同层级的调用，也即，应用编排可能调用其他应用编排，这通常意味着更大范围的业务活动之间的组合。但是，考虑到应用的不稳定性，设计过于复杂的应用间调用需要慎重。

4.3.7　技术架构元模型

技术架构是对应用架构的物理实现。技术架构本身是非常复杂的，但是考虑到元模型面向的是企业中业务和技术两侧，因此技术架构中对元模型要素进行了高度简化。技术架构元模型如图4-9所示。

1）物理构件。物理构件是应用构件的物理实现，物理构件也包含功能和数据，但是技术架构并非本元模型的重点关注内容，因此无须在元模型层级详细展现。物理构件可以聚合成物理组件。

2）技术平台。技术平台用于实现物理构件（或者聚合后的物理组件），可以基于特定技术类型建立平台，如人工智能、区块链、大数据等平台；也可以基于语言类型划分业务功能平台，如C语言、Java语言等平台；也可以基于特定目的建立平台，如监控平台、任务调度平台等。技术平台还可以聚类成技术架构的分层，但技术架构的分层属于聚合元素，无须在元模型层级展现。

图4-9　聚合架构方法论的技术架构元模型

出于对数字化转型的特殊考虑，虚拟空间构建技术是未来技术发展的焦点，因此，战略元模型中的“空间”元素越过了“应用架构元模型”，直接对应到了“技术架构元模型”中的“技术平台”上，这也反应了业务架构与技术架构之间的联系方式。搭建虚拟空间需要的技术平台应该在企业实力允许的情况下，以战略级的发展要求进行尝试。

4.3.8　元模型中的关键链条

构件设计并非只是技术侧的问题，而是需要业务与技术两侧的共同努力，因此，从业务架构开始，有一条关键链条影响着构件设计的最终实现效果，如图4-10所示。

图4-10　聚合架构方法论元模型的关键链条

这个关键链条上元素定义的一致性或者说映射关系的清晰性决定了构件设计的最终效果，以往的企业架构设计或者软件设计没有很好地解决从战略分析开始到最后技术实现方面的一致性问题。

元模型并不意味着软件设计会被复杂化，因为无论采用何种策略进行软件开发，最终开发结果都会映射到这些元素上，而难以令人满意的开发结果往往会缺少该链条中的某些元素，或者没有做好某些元素的设计。我们没有任何理由忽略这些设计元素，任何对这些元素的忽略最终都会导致技术债务。

同样，元模型也不意味着软件设计会大幅度简化，而是更加清楚地展示了重要的元素及其关系，加强架构师、开发人员对设计重点的关注，提供一个更有效率的分析路径。

从这个链条上看，详细分解战略能力、标准化岗位设计、持续优化业务流程、标准化管理企业数据、与业务保持一定程度的一致性去设计应用构件，是实现高效的构件开发的必要条件，这也是其他开发模式不可忽略的要素。

当然，这并不意味着没有对这些元素的万全设计，就不能进行软件开发，而是应当通过元模型使我们对架构关键点的认识更清晰，知道有哪些“坑”需要持续去填，也知道填“坑”的意义。