企业架构规划方法论的底层逻辑-从业务蓝图到技术实现

即整个企业架构规划的核心底层逻辑，从业务战略到业务架构，从业务架构到数据架构和应用架构，从应用架构再到最终的平台和技术架构。

虽然大家可能会觉得我分享的一些内容与 TOGAF 方法论或 IBM 的 CBM 组件化业务模型略有差异，但这并不影响我们对核心逻辑的理解。这些内容是我在过去十多年中，通过大量参与大型集团 IT 咨询规划和 SOA 规划项目的实践总结和复盘得出的。在实践中，我们总是会根据实际情况对方法论进行相应的优化和裁剪。

------------------------------------------------------------------------

第一部分：从业务战略到业务架构的形成逻辑

企业架构的梳理，首先从企业的业务战略和业务目标出发。

当业务战略和业务目标制定后，核心的业务价值就会浮现出来。这个核心业务价值是基于企业核心商业模式和运营模式的。为了分析这一核心业务价值，我们通常会回到价值链分析模型。价值链分析包括研发、生产、内部物流、外部物流、市场营销，以及人力资源管理（HR）、财务管理等支撑过程域。

业务能力地图的形成（从顶朝下）

接下来，我们需要考虑：要实现核心业务价值，这些关键的业务域（如研发、生产、物流）应该提供什么样的业务能力出来。业务能力可以简单理解为对外暴露的 API 接口服务能力。

如果对垂直行业的业务足够熟悉，通过组织人员进行头脑风暴，就可以很快得出需要具备哪些业务能力，因为此时只需要回答“需要什么样的能力”，而不需要回答“这个能力是怎样形成的”。这一步梳理完成后，我们就得到了业务能力地图。这个能力地图是粗粒度的，它会区分各个业务域（如研发、生产、物流），并说明每个域应该对外暴露什么样的业务能力的 API 接口。这标志着业务架构梳理分析的第一步完成，但此时每个业务域仍然是黑盒。

业务功能图的形成（从底朝上）

第二步的重点是实现这些业务能力，即把业务组件和业务域打开。任何一个业务域，如研发业务域，其内部都包含许多业务功能模块。这些功能模块本身实现了相应的能力，有些可能不涉及对外部的能力开放和接口（如用户录入数据存到 DB）。

为了实现业务价值，我们需要分析这个域究竟应该朝上开放哪些业务能力。这些能力可能由单个业务功能包提供，也可能由域内多个业务功能组合提供。要确定一个业务域内究竟应该有哪些业务功能，简单头脑风暴往往容易遗漏大量功能。

因此，到了这一步，我们必须回到传统的业务流程梳理分析维度。

1. 流程分析： 基于业务能力的实现，我们要分析各个业务域中具体的业务流程。我们会进行业务流程的二级、三级分析，包括到最细节的四级 EPC 流程分析。通过流程分析，我们能找到每一个业务流程的业务活动、业务功能和业务操作步骤。流程分析中的每一个方框可能就是一个业务功能点，其输入输出可能就是形成的单据或数据。

2. CRUD 矩阵分析与聚合： 当我们有了业务功能和业务数据后，会进行 CRUD (创建、读取、更新、删除) 矩阵分析。通过分析功能和数据之间的 CRUD 关系，我们可以确定哪些功能应该聚合在一起，以满足软件工程中高内聚松耦合的目的。

3. 形成业务模块： 通过聚合拆散到最细粒度的业务功能，形成上层的业务模块。此时业务域内业务模块的划分不再是简单的从顶朝下，而是基于流程的详细分析、CRUD 矩阵分析以及高内聚松耦合原则，从底朝上逐渐聚合形成的。

最终，我们有了业务战略，形成了业务能力地图，通过流程分析和业务功能的聚合，形成了业务架构中的业务功能图。这个功能图可以从二级到四级逐步展开，形成了完整的业务架构业务功能模型图。

业务架构的规划过程，是一个将价值链分析、业务能力地图、流程梳理分析、业务功能地图和业务架构图融合为一个完整整体的过程。它结合了从顶朝下（寻找关键业务能力）的黑盒过程，以及从底朝上（基于流程分析和功能聚合）的详细实现过程。

---------------------------------------------------------

第二部分：从业务架构到应用架构的形成逻辑

在业务架构梳理完成后，我们自然会过渡到应用架构的梳理。

业务架构与应用架构的区别

虽然业务的功能架构和应用的功能架构看起来相似，但两者之间存在关键区别。

1. 架构图范围差异：

• 应用架构图通常会增加业务架构中没有的内容。

• 在底层，应用架构需要规划 IAAS（如云数据中心资源池）和 PAAS（如技术平台，包括流程平台、集成平台、大数据平台等）。

• 在顶层，应用架构还会增加应用门户和 BI 决策层的内容。

2. 映射粒度差异：

• 从业务架构映射到应用架构中的业务系统时，粒度有可能不同。

• 例如，业务架构中的“供应链管理”在应用架构中可能拆分成“合同管理系统”、“采购管理系统”和“物流管理系统”。

• 反之，也有可能将多个业务域的功能合并成一个大的系统（如将采购管理、物流管理、合同管理合并成一个大的供应链系统）。

3. 现有系统与能力实现差异：

• 企业信息化建设往往从基础的 ERP 系统开始，它是大而全的系统，包含计划、采购、研发、生产、HR 等模块。

• 随着业务发展，企业会在 ERP 外围衍生出其他业务系统，如 APS 系统、MES 系统、财务共享系统等，它们是 ERP 系统的外延。

• 因此，实现业务架构中的一个核心能力（如财务能力），可能既需要 ERP 系统的财务模块，也需要外挂的财务费控、预算、资金等系统。这导致业务架构和应用架构之间的匹配和映射出现较大变化。

应用集成架构与服务架构

完整的应用架构包括应用功能架构和应用集成架构。

集成架构的形成，依赖于跨业务域、跨业务组件的交互流程梳理。在梳理端到端流程的过程中，我们会发现组件 A 和组件 B 之间需要交互接口。通过梳理所有跨组件交互的接口，结合应用架构的规划，就能形成一个完整的集成架构。集成架构图中的每一条横线通常代表一个独立的接口（例如，合同信息需要传给 ERP，生产计划信息需要传给 MES）。

随着 SOA 架构和中台架构的发展，应用架构的规划进一步演进。

• 中台架构： 中台底层仍然是平台，中间是中台的能力层（如订单中心、用户中心、成本中心）。上层是前端应用。中台架构在回答“我究竟应该有什么样的能力来支撑我上面的流程”。

• 服务架构（API 接口库）： 在中台架构的驱动下，集成架构进一步细化形成服务架构库。服务架构图仍然会划分域（如财务域、研发域），但每个小方框都是一个 API 接口。此时，我们不关心任何一个功能操作的实现，而是关心每个业务域应该提供哪些细粒度的 API 接口能力。

在当前的企业架构规划中，应用架构的梳理除了功能架构和集成架构外，会更强调服务架构的规划。通过梳理服务接口，实现组合和组装，以适应上层的应用场景和业务流程。这种思想与 **SOA（面向服务架构）**是完全吻合的。传统老的 ESB 总线可能过时，但 SOA 架构思想从未过时。

--------------------------------------------------

第三部分：数据架构的承上启下逻辑

数据架构是企业架构中一个非常关键的线条，它是业务架构和 IT 架构之间的关键衔接点。

数据架构的内容，上承业务建模阶段，下启 IT 应用架构规范设计。

数据架构的主线：从主题域到物理模型

数据架构最核心的主线是：数据主题域分析 → 数据的概念模型 → 逻辑模型 → 物理模型。

1. 数据主题域分析： 主题域可以理解为业务价值链的业务域（如人力资源、供应链、研发）。在每个业务域内，我们会分析其核心的业务对象或数据对象（如人力资源域的人员、组织；供应链域的订单、合同）。

2. 概念模型： 类似于 IT 软件开发中的业务对象建模或 ER 实体关系图。在概念模型阶段，只需要识别出核心的业务对象以及它们之间的关系（例如，项目与合同是一对多关系）。

3. 逻辑模型： 从概念模型过渡到逻辑模型时，需要拆分到具体的数据表的粒度。例如，采购订单在概念模型中是一个对象，但在逻辑模型中需要拆分为采购订单头、联系行、分配行和发运行等四层表结构。

4. 物理模型： 物理模型阶段是对每一个数据库表、字段类型和约束进行详细设计，设计出来的模型可以直接支持 IT 系统的开发和建设。

数据架构的副线：聚合、主数据与 OLAP

除了主线，数据架构的规划还包括以下重要内容：

1. 数据的聚合和 Owner 识别：

• 通过流程分析和 CRUD 矩阵分析，梳理每一个数据对象和业务功能之间的耦合关系。

• 结合应用架构（合同系统、采购系统等应用功能架构），分析哪些数据会聚合到一个大的数据库中。

• 每一个数据对象都必须找到它实际的 Owner（归属的 IT 系统或应用系统），这是数据架构梳理后必须完成的重要工作。

2. 主数据的规划与建设：

• 通过 CRUD 分析，进行主数据的识别。

• 识别完成后，进行详细的主数据分析和主数据建模。主数据的规划和建设是数据架构中独立的一条线。

3. 从 OLTP 到 OLAP 的过渡：

• 当前的数据架构规划还必须覆盖从业务系统（OLTP）到分析系统（OLAP）的过渡。

• 这涉及到 BI 系统、数据中台或决策支持分析系统的建设。

• 需要设计 BI 架构或数据中台架构，关注如何采集和集成业务系统与主数据，形成统一的 ODS 库。

• ODS 库建好后，进一步结合数据建模，形成上层的数据仓库，以便进行数据的聚合分析和维度分析。

一个完整的数据架构分析内容，必须包括数据主题域到概念/逻辑/物理模型的设计，结合 CRUD 分析考虑数据聚合和主数据识别，以及从 OLTP 到 OLAP 的数据建模。

------------------------------------------

第四部分：技术架构规划的演进逻辑

技术架构规划需要伴随着企业 IT 架构的发展演进、云计算和 SOA 架构规划的发展演进一起去思考。

传统的烟囱式架构规划

在传统的企业信息化 IT 建设中，往往采用烟囱式的建设模式。底层是 IAAS 虚拟化资源池，上层应用是竖井式建设，每个应用都有自己的小技术平台和紧密耦合的功能模块。应用之间通常通过 SOA 集成平台或 ESB 总线实现数据集成和接口交互。

传统的狭义技术架构规划主要包含三个方面：

1. IT 物理部署架构规划： 规划 IAAS 虚拟化资源池，包括数据库集群、应用中间件集群、负载均衡、核心网交换机等。重点关心存储、服务器、交换机和网络。

2. IT 逻辑架构规划： 关心数据库服务器、消息服务器、缓存服务器、APP 应用集群的具体数量和功能架构视图。

3. 狭义的技术栈规划： 形成一个完整的分层技术架构图，确定在应用开发过程中，存储持久化层、应用逻辑层和前端展示层应使用的技术。例如，数据持久层使用结构化/非结构化数据库、Redis 缓存；应用层使用 SpringCloud 微服务框架、API 网关；前端使用 VUE、JS 等技术。

架构转型与云原生技术中台

随着 SOA、云原生和云计算技术的发展，企业逐渐打破烟囱式建设模式，从传统的单体架构转向微服务架构。云计算也从仅管理 IAAS 层提升到管理共性化平台能力。

这种演进趋势催生了“平台+应用”的构建模式，其中平台即 PAAS 技术中台。

• PAAS 技术中台： 传统的单体应用中的小技术平台逐渐被统一的技术平台取代，用于构建共性的技术能力。这个技术平台可以按软件开发生命周期划分为：

◦ 开发平台： 包含微服务开发框架、低代码开发等。

◦ 执行平台： 基于 Kubernetes 容器云资源调度平台，提供消息安全、日志缓存、各种共性技术服务能力。

◦ 运维监控平台： 覆盖从资源到服务再到应用的监控，以及微服务管控治理。

• DevOps 平台： 为了实现上层微服务模块与底层平台更好地集成协同，并实现从需求、设计到部署交付链条的高度敏捷和自动化，需要引入 DevOps 支撑平台。DevOps 平台覆盖整个微服务端到端的开发和交付，实现持续集成和持续部署能力。在当前的云原生平台规划中，DevOps 支撑平台通常被纳入整体平台层的规划体系。

在当前的整体信息化规划中，特别是技术架构层面，已经不能仅仅停留在 IAAS 基础设施部署架构规划，而必须去做云原生技术中台的规划。只有做好技术中台层的能力，才能真正实现“平台+应用”的快速构建模式。

此外，如果企业要向外做互联网 SAAS 应用，规划还需要从 PAAS 进一步转向 SAAS 平台规划。SAAS 平台层规划内容包括多租户设计、多中心设计等。这些都应纳入完整的技术架构规划体系中，以形成完整的技术架构规划底层逻辑。

--------------------------------------

总结

总而言之，企业架构规划是一个系统性的过程，从业务战略出发，通过价值链、流程和 CRUD 分析，形成高内聚的业务架构；然后，通过功能映射、平台化和接口梳理，形成涵盖功能、集成和服务的应用架构；数据架构作为承上启下的关键，通过数据主题域、概念/逻辑/物理建模以及主数据管理，支撑业务与 IT 系统的建设；最后，技术架构则从传统的 IAAS 部署，演进到以 PAAS 技术中台和云原生为核心的“平台+应用”模式，保障快速交付和业务支撑能力。所有这些架构必须融合成一个完整的整体，才能支持上层核心业务目标的实现。

今天的分享就到这里，希望对大家有所启发，再见。

具体AI输出的PPT如下：

今天分享就到这里。再次强烈推荐NotebookLM的AI笔记功能。