转载

企业级业务架构的设计难点

企业级业务模型的建设离不开标准化过程，因为做企业级模型要横向对比分析企业所有业务领域，以期望在设计上实现“以更少支持更多”，这是很多企业级系统建设或者企业级转型工程的目标，希望能够同时实现快速的灵活响应和减少重复开发这两个目标。这个愿望是非常美好的，关于对这一点的体会，本书后边再讲，现在还是先讨论下实现这一目标，业务架构设计所面临的最大难点——标准化工作。

一、基本的标准化方法

业务架构模型的标准化包括数据标准化和任务标准化两部分。

（一）数据标准化

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

（二）任务标准化

任务的标准化其实很难操作，因为没有非常严格的标准用于做判断，而且，任务标准化也是切忌“机械”操作的。其基本过程如下：

1.将流程模型与数据模型进行语义对接

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

2.分析重复的业务动作

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

在进行企业级标准化以前，对客户信息的建立和修改完全有可能在存款和实物黄金的业务领域中各有一套流程，可能是任务级别的重复，也能是在不同的任务中包含的内容上有重复，实际上，以前做竖井式开发的时候，这是很常见的现象，每个业务系统都是独立的、完整的，都各自有一套客户信息，不仅重复，最重要的是经常会不一致。当我们通过企业级数据模型去除重复的数据概念之后，通过任务与实体之间的写操作对应关系，会清晰地发现重复的操作。

3.做出关于标准化的建模判断

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

二、避免“过度整合”

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

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

三、何以解忧，唯有“融合”

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

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

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

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

以上内容摘自《企业级业务架构设计：方法论与实践》一书，经出版方授权发布

《企业级业务架构：方法论与实践》

19年金融行业经验资深架构师撰写，微软、亚马逊、阿里、百度、网易等13家知名企业架构师联袂推荐，业务架构“知行合一”

编辑推荐

（1）作者在金融行业有19年工作经验，2000年加入建设银行，几乎经历了建行所有核心系统的业务架构设计，经验丰富。

（2）本书内容得到了国内外绝大多数互联网公司的资深架构师和技术专家的认可和推荐，比如微软、亚马逊、阿里、百度、网易、滴滴等十几家公司。

（3）本书重思想和方法论，从业务架构“知行合一”的角度阐述业务架构的战略分析、架构设计、架构落地、长期管理，以及架构方法论的持续改良。

作者简介：

付晓岩

资深的企业级业务架构师，有超过19年的金融行业工作经验，目前就职于建信金融科技有限责任公司。 2000年加入建行从事金融业务，2012年调入建行总行成都开发中心，2016年调入建行总行北京开发中心，各中心2018年整体转制，成立建信金融科技有限责任公司。

从事金融业务期间，多次作为核心业务人员参加业务系统开发工作，并就此转入技术开发部门，多年专职从事企业级业务架构设计。

工作期间，认真钻研软件过程、系统设计与分析、架构设计方面的理论知识，将其与实践相结合，不断融合设计思路，逐渐超脱原有工作经历和指导理论的限制，形成对企业级业务架构设计一般方法的认知。