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

痛定思痛。 2022-02-22 00:54 307阅读 0赞

企业级业务模型的建设离不开标准化操作，因为做企业级模型要横向对比分析企业所有业务领域，以期望在设计上实现“以更少支持更多”，这是很多企业搞企业级系统建设或者企业级转型的目标，希望能够同时实现系统实现的快速灵活和减少重复开发以降低成本这两个目标。这个愿望是非常美好的，也是很多企业级架构设计追求的目标，关于对这一点的体会，留待以后再讲，这节我们还是一起讨论下为实现这一目标所需要进行的标准化工作。

### 基本的标准化方法 ###

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

数据模型是标准化的基础，我们先假定多数数据概念重复问题已经通过工具筛查解决，数据实体和属性基本保持唯一，这时我们可以将数据与流程对应起来，对应的主要方式就是识别任务需要使用的数据实体，包括读和写两类，上文说过，对组件的识别就是先通过数据聚类，进而到任务聚类实现的，任务聚类主要就是对写操作的任务进行聚类，因为读操作不会改变数据，可以由负责写操作的组件提供读取服务实现，所以，写操作是聚类任务的基本原则，这样是为了保持数据的一致性。

在对应过程中，经常会遇到多个不同的任务都可能要对同一个数据实体在不同时间进行写操作的情况，比如，个人客户初次到一个银行存钱，申请银行账户时，银行要建立客户的信息，会包括姓名、证件类型、证件号码等基本信息，也会包括电话等联系信息，或者邮寄地址等地址信息，这时的整体业务场景是存款。而客户过了一段时间再次来办理业务时，联系信息可能会有变化，这需要更新客户信息，但是此时的场景有可能发生变化，不再是来存款，可能是来购买实物黄金，从产品的角度，这就是两个不同的业务领域了。

那么，在进行企业级标准化以前，对客户信息的建立和修改完全有可能在存款和实物黄金的领域各有一套流程，可能是任务级别的重复，也能是在不同的任务中各自的内容有重复，实际上，以前做竖井式开发的时候，这是很常见的现象，每个业务系统都是独立的、完整的，都各自有一套客户信息，不仅重复，最重要的是经常会不一致。

当我们通过企业级数据模型去除重复的数据概念之后，通过任务与实体之间的写操作对应关系，会清晰地发现重复的操作。这时我们就需要做出建模的决策，是分开建模还是将所有对客户信息进行写操作的部分集中到一起建模。在FSDM提供的数据模型上，参与人这个分类中可以容纳与客户信息相关的所有数据，建模上可以把此类实体聚集在一个主题域下，比如叫做客户主题域，那么从企业级的角度也就可以将各业务领域中与之相关的任务或者涉及到该操作的任务中的客户信息部分全部抽离出来，集中到起来组成一个组件，而其他领域的任务经过调整后，不再包含此类内容，这就完成了一个标准化过程。

### 可能会遇到的问题 ###

上述操作是相对较为简单、清晰的标准化过程，还有些标准化过程要更难以判断，这种情况通常出现在流程看似相近的业务领域，以及一个领域内部的多个产品之间，后者其实更难判断，因为一个业务领域内部的流程本就相近，会很容易让人产生“整合”的冲动，尤其是对于业务建模来讲，因为业务建模毕竟是一种“纸上操作”，分、合都是很容易的，调整下结构而已，而整合对建模者来讲又有很大吸引力。为了避免这种错误，需要从业务和数据两方面下手，业务上自然是要重新审视、理清业务流程，搞清楚具体差异；而数据上要重新检视数据实体划分的颗粒度是否正确，是否包含的属性太多而导致内聚性不够。数据实体的颗粒度太小，会放大业务差异，而颗粒度太大，则会抹杀业务差异，二者都会导致不合理的标准化结果。

因此，流程模型与数据模型之间的配合检查是一个反复锤炼的过程。尽管标准化问题很重要、很困难，不幸的是，并没有什么很好的方法能够帮助大家快速解决问题，这就又回到了之前说的，模型质量严重依赖建模者的经验，除了经验之外，还要依靠高质量的建模输入，既包括完善的业务资料，更需要有丰富经验的业务人员，看资料是学不会业务的，尤其是业务中经常会有“活情况”。

业务人员与技术人员融合得越好，就越能产生高质量的模型和系统，这也难怪高盛、大摩这些金融机构中数字化转型的坚定执行者，会引入占员工比例15%、甚至20%还多的技术人员，并直接派驻到业务部门与之共同工作。一般国外金融机构技术人员占比不足8%，国内通常为4%左右，近年才刚刚有所增加。

尽管标准化过程很痛苦、自身又似乎很不“标准”，但是因其对企业级系统的构建意义非凡，因此，所有做企业级转型、希望建设企业级系统的企业和开发者，都必须认真对待这一过程，尽管这一过程未免有点“纸上谈兵”，但它的优势也在这里，这一阶段的任何调整都是代价极低的，而不合理的设计一旦传导到开发上，就将产生较大的纠正成本。本人原来所在单位规模很大，业务庞杂，因此这一过程耗时两年，其后仍在持续优化、完善。对于大型复杂系统而言，因其面对的问题域异常庞大，所以需要一套清晰的业务与IT的架构映射关系指导企业的持续建设，这就如同我们对地图的需要一样，只有践行标准化才能提供一张准确的地图。

这种标准化也是识别中台能力的基础，其实阿里的中台也是在不断的标准化和去重过程中沉降下来的。  
\\t  
**相关文章：**  
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”  
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？  
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素  
中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路

**作者介绍：付晓岩**，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。