企业级-数字化转型-架构驱动设计-总纲

本文主要从架构驱动设计探讨引导企业级的数字化转型

一、关键思想

二、架构

2.1组织架构

组织架构的顶是企业的战略，价值创造过程，可以用价值链这个工具描述，比如以客户为中心的银行价值链设计（简化设计）

2.1.1 自顶向下的设计

企业的价值链是组织架构的顶，顶没有发生变化，组织架构应当保持不变，当企业的价值链发生变化，组织架构应当适当调整，大到集团的组织架构，小到部门的组织架构。

设计的横轴就是价值链，竖轴我们以银行的委员会、一级部门或二级部门为例（简化）

每家银行的组织架构相似但又各不相同，应当基于企业的价值创造过程做出的组织架构设计，某一个价值环节可能需要多个部门协作完成，如果某一个价值环节涉及太多部门协作，应当考虑组织架构的调整，提升价值创造效率，跨部门协作会消耗大量的人力。

2.1.1 自底向上的推演

组织架构的底是各个部门的岗位，关键岗位的设置是否符合企业的价值链，如果不符合，应当调整岗位职责。主要有四种情况：

• 岗位的职责太大，涉及多个价值环节的工作，应当拆分
• 岗位的职责太小，工作内容不足以完成一个价值环节，应当扩大岗位职责
• 岗位的职责太虚，难以界定工作内容属于哪个价值环节，应当明确职责和工作内容
• 岗位的缺失，通常发生在企业发展初期或扩展新业务时，出现有事无人管，需要新设岗位

推演的横轴是价值链，竖轴是关键岗位，以银行的岗位为例（简化）

• 一个岗位如果专属于某个价值环节，可以列为专员岗位
• 一个岗位如果多个价值环节都需要，可以在多个部门都设置相似的岗位，但限定其工作范围为某一个价值环节的内容

在组织协调中，应该把关键岗位的人员列出来，形成价值链的人员地图，这样推动一个业务场景建设时，主导部门就知道该找谁协调。

2.2业务架构

2.2.1 自顶向下的设计

业务架构的顶是企业的价值链，需要对产品或服务（业务领域）进行一级分类，针对不同业务领域的不同价值环节分别进行流程建模，拆解业务活动、任务，对比不同业务领域的流程模型归纳出公共的任务、个性化的任务。

流程模型

存款业务领域-产品服务设计

先进行部门级别的业务活动识别

对于信息技术部而言，重点关注产品实现，因此我们对产品实现进行团队级别任务拆解

贷款业务领域-产品服务设计

我们会发现，贷款业务领域识别的活动、任务的拆解基本跟存款是一致的，那么是否意味着这些任务都是公共的任务，没有个性化的任务？这个问题的答案，需要进一步进行自底向上的推演。

2.2.2自底向上的推演

业务的底是数据，因为任务执行后的结果是产生数据，要识别任务是否可以公共的，得识别分析数据模型

数据模型

存款业务领域-产品服务设计

通过数据模型的识别，我们最终归纳合并出四个业务数据模型：存款产品参数、存款产品申请、存款产品复核、可售产品。

进行数据模型的识别时，我要以数据模型能否支撑任务的思路去设计，在这个思想的前提下我们去做数据模型的归纳合并，这样才能识别哪些任务的数据模型是可以合并的，识别出公共的任务，个性化任务。如果只是从任务角度去识别数据模型，会产生很多大同小异的数据模型，不能形成复用的数据模型，就变成了烟囱式的设计。

贷款业务领域-产品服务设计

我们可以发现贷款业务领域，跟存款业务领域，区别比较大的数据模型是贷款产品参数，其他数据模型基本是一致的。

跨领域的任务组件

我们合并存款、贷款两个业务领域的任务和数据模型，并归纳总结出公共的、个性化的任务组件。

最终我们归纳总结出5个任务组件：贷款产品参数任务组件，存款产品参数任务组件、产品申请任务组件、产品复核任务组件、可售产品任务组件，其中

• 公共任务组件：产品申请任务组件、产品复核任务组件、可售产品任务组件
• 个性化任务组件：贷款产品参数任务组件，存款产品参数任务组件

同时可以归纳出三大数据主题域：产品主题域、产品申请主题域、产品复核主题域

• 产品主题域：贷款产品参数、存款产品参数、可售产品
• 产品申请主题域：产品申请
• 产品复核主题域：产品复核

2.3系统架构

2.3.1 自顶向下的设计

系统架构的顶是任务组件，我们以任务组件为横轴，以团队为竖轴，来设计系统架构

这里我们只识别了开发团队在价值环节-产品服务设计的功能模块，如果整个价值环节都设计完毕，我们能得到各个开发团队的所有功能模块地图，通常一个系统由一个开发团队负责，不同功能模块的组合就会得到一个或多个系统，最终要输出每个开发团队负责哪些系统以及每个系统的功能地图。

2.3.2 自底向上的推演

系统架构的底是功能模块，我们需要画出业务活动的系统交互时序图来推演系统架构是如何支撑业务活动的。

时序图的横轴是各个系统的功能模块，竖轴是时序，业务活动由组织架构的某个岗位发起。以贷款产品为例进行推演，如下图所示。

在进行自底向上推演过程中，我们发现缺了一个行员管理系统对行员进行身份认证的管理，这种现象非常正常，因为我们在自顶向下设计时，关注点在于关键业务活动，对于行员管理系统支撑性的系统识别，没有体现在自顶向下的过程中，很正常，但是要在自底向上推演时补充完整，否则会与实际落地脱节。其中行员管理系统应当是另外一个业务支撑领域的事情，我不做展开讨论，通常对于支撑领域的时序也可以简化省略，但在项目实施的详设阶段是不能省略的，一是这个流程是不可缺少的，二是对接业务支撑领域需要投入人力开发测试的。

2.4应用架构

2.4.1 自顶向下的设计

应用架构的顶是系统的功能模块，系统架构设计时已经给出了，系统功能模块地图，但是哪些功能模块应该聚合在一起组成一个应用，以及理清各个应用的关系，这就是应用架构要做的事

横轴是系统的功能模块，竖轴是数据主题域，如下图所示

我们识别出三个应用：产品服务、产品申请服务、产品复核服务

如果两个应用之间相互双向依赖，建议合并成一个应用，遵循两个应用只有单向依赖的原则，如果有双向依赖说明是强依赖关系，应当内聚在一起，调整后的应用架构如下图所示

最终我们调整为两个应用：产品服务、产品申请复核服务

2.4.2 自底向上的推演

应用架构的底是功能接口，功能接口包括外部接入的API接口，内部功能模块间的接口，外调其他应用的接口

我们以产品申请复核服务为例，去梳理这三种接口，画出接口的调用依赖关系图

识别三种接口的依赖关系，可以确保功能模块的完整性，避免出现漏接口的情况。

这个接口依赖关系图也是项目实施详设阶段的接口框架，新增业务场景的时候，优先考虑已有接口的复用，再考虑已有接口的调整，最后考虑新增接口。

2.5数据架构

2.5.1 自顶向下的设计

数据架构的顶是数据模型，主要从两个方面考虑，一是是否需要切分，二是是否需要缓存

• 数据切分原则：优先考虑垂直切分，再考虑水平切分
• 数据缓存原则：读多写少、热点数据

数据切分

垂直切分，主要是分库、分表两种设计

• 分库，将弱依赖关系的数据主题域分开，相互隔离，避免数据架构的腐化
• 分表，对于非常复杂数据模型，一个表的设计会造成大宽表，表的执行效率会下降，可以将大字段或者低频访问的字段切分到另外一个或多个附加表，提升主表的执行效率

水平切分，主要是分库、分区、单元化三种设计

• 分库，对于数据量会不断增大，且不能删除的数据，数量级会达到千万级以上，应当考虑分库，减少单个数据库的压力
• 分区，对于数据量会不断增大，但是可以按时间删除的数据，应当按时间进行分区，即时删除数据，需要离线备份的进行离线备份，减少数据库的容量压力
• 单元化，单元化是按某一个业务数据字段进行所有关联数据的切分隔离，常见的按用户号进行切分，单元化后，A单元用户所有关联交易的数据都在A单元的数据库集群，B单元用户所有关联交易的数据都在B单元的数据库集群

数据缓存

数据缓存，主要是为了避免数据库的性能瓶颈，降低交易的响应时间，提升交易的TPS

• 读多写少，主要场景有配置参数、基本信息、历史信息等等
• 热点数据，主要场景有首页数据、高频交易账户、热卖产品、抢红包、秒杀等等

根据数据切分、数据缓存的设计原则，我们来设计数据架构，横轴是数据模型，竖轴是数据库、缓存

产品主题域的四个表，都没有进行数据切分的设计，因为产品的数量级不太可能超过一千万，其中可售产品表做了缓存设计，因为可售产品的数据将面向客户，典型的读多写少的应用场景。

产品申请主题域、产品复核主题域，有两个表，虽然数据量不会很大，但是随着时间推移，一般不会去访问一年前的数据，可以按年进行分区，查询条件设置时间区间，提升访问效率，方便清理历史数据，释放数据库的磁盘空间。

2.5.2 自底向上的推演

数据架构的底就是数据流，数据的流入、流出最终会转换成数据库的数据，那么需要进行数据流的推演，确保数据架构设计的准确性，如下图所示。

数据流图能够描述出数据产生、流转、存储，在推演中能够识别数据孤岛、数据缺失等问题，确保数据架构的完整性。

2.6技术架构

2.6.1 自顶向下的设计

技术架构的顶是应用架构，脱离应用谈技术太空泛，结合应用特点设计技术架构才能确保架构的合理性。我们以产品服务为例，技术架构如下图所示。

产品服务的业务模型不复杂，主要矛盾在于读多写少，因此整体思路采用CQRS 模式，对于高频访问走缓存，普通查询维护走数据库。

2.6.2 自底向上的推演

技术架构的底是具体的技术组件，确定好每一层的技术工具，确保技术架构可以落地，如下图所示。

每一层都要相应的技术组件作为支撑，同一个系统的技术组件最好统一规划，避免因为技术组件的兼容性问题导致开发成本增加。