传统企业数字化架构设计

一、总览

传统企业数字化架构设计可分为2层，4种架构，分别是业务架构，数据架构，应用架构，技术架构。业务架构是上层，他驱动应用、数据、技术架构，反过来，应用、数据、技术架构是下层，他支撑业务架构的实现。除此之外，我们还应该在业务架构之上，再设立战略层，战略层主要由公司高管设计。

1. 业务架构
   业务架构需要知道为什么要做，做什么，怎么做，谁来做四件事。

• 为什么做是一切的缘起，需要理解公司战略目标
• 做什么，即公司想实现或能提供的业务服务
• 怎么做是基于做什么的基础上，细化提供业务服务所需要的业务流程
• 谁来做，指的是业务服务的执行方。

2. 应用架构
   应用架构需要解决应用有哪些，以及对应的功能点。
3. 数据架构
   数据架构需要解决数据的类型、来源，后续还需要针对不同的场景和功能，设计确定数据模型，存储方式，数据处理加工方式。
4. 技术架构
   技术架构需要解决技术需求、选型、发展路径等的问题。诸如，技术栈，技术平台，技术框架，中间件，部署方式等等。

从阶段上看，一般架构设计到实施，可以分为启动阶段，架构设计阶段，研发实施阶段，上线运维阶段。每个阶段要解决的问题重点各不相同。

• 启动阶段，需要做好战略调研，确定方向。为下一阶段做好准备。
• 架构设计阶段，首先根据公司业务模式，商业模式，规划业务架构，分析需求，详细设计功能，流程，数据等。第二步，根据业务架构，设计规划应用，数据，技术架构，还应当评估风险，做可行性分析等。
• 研发实施阶段，根据总体需求规模，研发实施阶段时间长度可能是1年，也可能是5年，所以该阶段需详细拆解任务项，制定时间表。很重要的是，如果涉及公司组织架构调整，商业合作伙伴变更等，也需要制定相对应时间表。另外，很多公司做数字化转型前，经常会存在历史系统，这些系统可能是之前采购的SaaS系统，或是外包研发的系统等，需要对遗留系统进行改造，或是迁移等动作，也均需考虑在内。
• 上线运维阶段，该阶段未必是研发实施后，可能会和研发实施有交叉，研发实施部分功能，上线运维，再研发实施，而后再上线运维。这阶段在维护的基础上，需要收集遗漏或者缺失的功能，以便在后续的优化完善。

可以看出，数字化转型的架构设计，不仅仅是IT部门，或是CTO,CIO的事，而是需要公司达成一致，至少是需要公司高层达成一致。前期的战略设定，后续的人员招聘，组织架构调整，上线培训使用等，都需要各个部门紧密配合。

二、 业务架构设计

业务架构必须基于企业的战略来做，脱离了企业战略，业务架构就无法真正意义上实现其价值，也就成了无源之水，无本之木。基于战略，我们可以知道为什么要做，而后，业务架构还需要解决做什么，怎么做，谁来做的问题。做什么指的是所提供的业务功能，怎么做是业务流程，谁来做是组织架构，此外我们还可以引入商业模式。另外，业务架构的设计，往往牵扯到公司多个部门甚至事业部，而大多数企业在做数字化转型前，或多或少都会有已有系统，无论是采购亦或者外包开发，所以业务架构设计往往是跨部门，跨系统的，这也要求我们在做业务架构设计时需要将这些因素考虑在内。

2.1 企业战略

企业战略往往由公司董事或高层制定，而我们所需要做的，就是对标企业战略目标，理解公司战略驱动因素。我们可以通过与高层进行访谈，了解战略的由来，逻辑。可以通过收集内外部信息，包括政策，友商策略等，再结合案例与最佳实践，最终达到理解战略意图。
理解战略意图后，我们需要分解战略大目标，而后就每个目标进一步分解为达成目标所需要的策略动作，策略动作可以从之前提到的做什么，怎么做，谁来做，商业模式几方面考虑，最后总结即可得到业务架构图。
以数字化转型这个战略目标为例，一般而言，传统企业做数字化转型的三个目标是降本，增效，增收。达成降本目标所设定的服务是，提供某个智能化平台，通过AI算法，达到减少积压库存的目标。达成增效目标是建立采购平台，大客户可通过平台自行下单采购，提高下单效率。达成增收目标所设定的是建立客服主动回访机制，通过主动回访，提高客户复购率。最后，我们需要提取各项因素，分析细化，总结为业务功能，流程，组织架构。

2.2 业务功能

分析业务功能，可以从价值链开始，逐步拆解到功能域，二级功能域等。是一个从大到小逐步细化的过程。我们需要分析拆解公司内所能提供的对内和对外的服务项。
以医药制造企业为例，价值链最顶级是人力行政，研发，采购，生产，物流，销售，售后等。而后需要对每项进行再一次拆解，诸如销售可拆解为大客户渠道，药店渠道，电商渠道等，作为二级功能域。

2.3 业务流程

业务流程也可逐层拆解，诸如线上购买商品，“搜索->进入商品详情页->下单支付”，这是一级主干流程，主干流程内的各个节点可以继续拆解，诸如搜索可能会有筛选项，详情页需要选择型号、规格、尺码，下单支付则可能会出现不同的支付渠道。再往下还需要设定规则，诸如某些场景不允许使用信号卡，或是不允许使用货到付款等。

2.4 组织架构

组织结构需要考虑是否改动或者新增新的组织体系，诸如原有物流部新增电商物流岗位，新增电商客服部等。
其次，组织架构不仅是公司内的调整，可能还会涉外部合作伙伴的变更，合作渠道的变更，都需要考虑在内。诸如新增电商渠道，需要考虑与之相关的渠道链路，考虑组织架构的调整。

• 最上层是个人客户，企业客户。
• 第二层是售卖渠道，有第三方电商平台，自有官网商城等。
• 第三层有客服，物流，售后，运营，品牌，品项等。
• 第四层有财务，人力，行政等基础支持性部门。

2.5 案例

本节以在官方商城购买商品作为虚拟案例。我们从业务功能，业务流程，分支流程进行说明，这几部分是自上而下，逐步拆解的过程。

1. 业务功能
   也即在官方商城购买商品这个服务场景。
2. 业务流程
   主干流程：客户进入商城某个商品详情页，在登录后进行购买并支付。
   分支流程：

• 查找商品流程
• 选择具体SKU流程
• 登录流程
• 选择收货地址流程
• 支付流程
  详细阐述对每个分支流程再次细化，直至全覆盖每个流程的每个分支以及其处理规则。

3. 组织架构
   如涉及组织架构变更，还需明确所产生的调整策略，涵盖时间，范围，方式等。

三、应用架构设计

应用架构包含一系列应用以及之间交互方式，应用架构关注的应用的功能以及之间的交互方式，而不是具体到每个应用内部的实现技术。

3.1 设计步骤

1. 梳理应用架构前，需梳理好业务架构，也即整理好业务功能，细化流程，明确流程内处理规则。比如登录场景，需考虑登录成功与失败的场景，并考虑忘记密码的场景。
2. 识别每个流程，每个分支，处理规则背后的需求点。比如忘记密码，则会产生重置密码的流程，进而会有发送重置密码链接到注册邮箱的需求。
3. 对需求点进行分类，将其归类到各个系统功能，注意这里开始出现偏技术向的内容，诸如，支付管理，用户管理等，此外类似日志管理这类后台功能也是系统的一部分。如果出现各部门业务功能似乎就可以直接划分成系统，这时候可以考虑是否有更优方式组织系统划分方式，优化使用感受。
4. 按照终端->系统以及内部功能->底层后台服务的层次排列，形成功能架构图。注意不应出现过于技术向的构件，诸如不应出现MySQL，ELK这类词汇，而是面向功能进行分层排列。对于过大的构件，也应拆解成小构件，这其实是构件细粒度的问题。
5. 根据之前的需求分类，定义各系统各功能点开发顺序，定义迭代内容。注意，现实情况一般是并非所有功能和需求都是新增的，也可能是对原有系统的重构，完善优化，重写等，也可能是原有系统就已满足的。
6. 定义接口，如果可能的话，可细化输出时序图，数据库表结构等。

四、 数据架构设计

数据架构描述的是企业的主要数据类型和来源，物理和逻辑数据资产，数据管理。

4.1 设计内容

数据架构设计的内容可以归纳为以下5个方面：

• 数据架构类型及其来源，诸如订单库，商品库，操作日志等
• 数据模型，诸如订单模型，BI星型模型等
• 数据存储，诸如，关系型数据库，图数据库
• 数据流，诸如数据治理过程等
• 数据管理，诸如安全规范等。

从落地角度来看，数据架构设计可分为三大块

1. 现有或未来需要的数据，这既是需求，也是现状
   a. 针对不同的部门，不同的业务，分析已有的数据，并通过调研分析未来所需要的数据。
   b. 设计跨部门的数据结构，总结主数据结构
   c. 分析非结构或半结构化的数据的应用场景
2. 设计物理和逻辑数据资产，数据生命周期，数据流
   a. 设计逻辑数据资产模型，可使用ER图表示
   b. 设计物理数据资产结构，可能是OLAP，JSON，XML等
   c. 数据生命周期设计，诸如分库分表场景，热数据定时迁移到历史表中。
   d. 数据流设计。第一应关注用户本身是如何使用数据的，数据应该是从哪个系统往哪个系统流转，直到最后被使用。第二明确数据处理过程，可设计ETL过程，用来将原始数据处理成可展示的目标数据。
3. 设计数据管理规范
   数据管理规范包含三点，一是数据标准，二是数据质量，三是数据安全

4.2 设计步骤

1. 分析现状，识别未来需求
   注意分析和识别需是横跨不同的部门，不同的业务。关注可提取作为主数据的数据类型和来源。
   在识别数据类型时，可借鉴UC矩阵的方式，仔细梳理每个业务产生和消费的数据。
2. 数据建模
   数据建模必须建立在业务的基础上，具体来说，可将业务进行分层，而后进行分析。

• 通过业务域发现数据域
• 通过业务流程，发现数据实体，属性，关系
• 通过功能和处理规则，逐步细化数据实体，属性，关系
  数据建模是数据架构设计的核心，是最重要的一步。

3. 定义数据生命周期
   由于数据量大等原因，可能对系统产生性能产生影响，有时候需要制定数据生命周期，定期清理或迁移数据。也有可能是某些场景，诸如电商抢购，用户下单后30分钟未付款应关闭订单等等。
4. 规划数据存储与分布
   这步决定了数据应该如何存储以及分布，举个例子，数据是结构化还是非结构化的，就要考虑数据存储在某种关系型数据库上，或是非结构化的数据库上。
5. 设计数据流
   针对BI报表甚至是AI的需求，我们往往会需要做数据治理，处理原始数据，最终可能是落地到数仓，或是报表，仪表盘等。
6. 制定数据管理规范
   这点主要是根据企业或实际业务要求，定义数据标准，质量，安全。

五、 技术架构设计

5.1 设计内容

技术架构设计是很多技术人最擅长接触最多的部分，大概涉及以下几方面

• 技术需求，主要分析业务架构，应用架构，数据架构，所设定的需求作为起点
• 技术选型，针对平台，组件，框架等进行选型
• 物理选型，考虑是否使用公有云，或者私有化部署
• 选型管理，针对所需要的技术进行指标评估，制定选型标准

5.2 设计步骤

1. 分析技术需求，主要包含识别需求所需要的技术以及部署位置。
   技术架构设计的第一步，是分析技术需求，技术需求必须以业务架构，应用架构，数据架构为源。如，是否有高并发和弹性伸缩的需求？甲方或公司是否对数据存储安全有要求？现有团队技术栈情况等。

2. 技术选型，盘点现有系统使用的技术，并与需求进行对比，明确差异和差距，最后选择合适的技术
   可以结合横向和纵向进行分析，举个例子，数据库选型，横向可以分析 SQLServer、MySQL、TiDB之间的差异。纵向可以分析各数据库的功能，质量，现状，社区，文档，法律风险，未来发展趋势等。

3. 影响分析，对比技术架构目标和现状，明确成本，规模，学习曲线等影响。