03｜智能原生企业架构的方法论框架

你好，我是灵犀。

在智能原生时代，架构是否会慢慢消亡？这是我们必须首先回答的问题。

因为，结合大模型技术的发展，以及业务响应力和业务体验性不断提升的要求，未来前端将慢慢整合进一个对话框中，后台业务将被解构到一个个智能体中，并且大多数将由业务人员来承担，而数据分析的职责也可以简化为将目标交待给DataAgent，它便能自动完成整个分析过程。

在这样一幅未来演进图景中，IT的核心职责似乎逐渐缩减为平台的运维与运营。那么问题来了：在这样一个“智能驱动”的世界里，架构还有价值吗？架构师的角色是否还有存在的必要？

AI来了，企业架构还重要么？

为了更好地说明这个问题，我们可以借用国家产业链的建设来进行类比。

从理论上讲，除了极少数前沿、高精尖的技术领域之外，现代工业的整个科技树已经高度公开透明。例如轻工业、钢铁、计算机、汽车等成熟产业，其核心能力早已被高度模块化。这意味着，即便一个国家不打算从零开始生产，也完全可以通过整合模块、进行组装的方式来实现工业化。

然而现实是，仍有许多国家在产业链建设方面几乎一片空白。为什么？这显然不只是技术层面的问题。

因为产业链的繁荣并不仅仅依赖于技术和组装能力。它背后真正起作用的，是强大的物流、资金流、信息流，以及来自更上层的“指令流”。如果没有这些“流”的有效串联，即便拥有先进的技术模块，也无法形成一个有机、协同的整体。

这正是顶层设计与系统整合能力的重要性所在。

在企业IT的建设中，架构所扮演的角色，正类似于产业生态中的顶层规划者，企业IT生态中的各种应用、数据和服务，同样需要一个统一的“架构脉络”来进行规划、协调和治理。

而且，正如一棵大树越茂盛，其根系就越深一样。一个越繁荣的生态，越需要一条清晰、稳固的主线或脉络作为支撑。否则，即便表面上看起来百花齐放，实际上都是一个个彼此割裂的“信息孤岛”，无法形成合力。

因此，在智能原生时代，架构的重要性不仅不会减弱，反而会更加突出。

在明确了架构的作用之后，我们现在正式进入“方法篇”。这个章节里，我将提出并详细为你介绍一个面向智能原生时代的企业架构框架（Intelligence-Native Architecture Framework），简称IEAF。

为了方便你对比学习，我们不妨先回顾一下传统企业架构的框架，再来探讨为什么需要建设智能原生时代的新框架。

什么是企业架构？

简单来说，企业架构是一套系统化的方法论体系，其核心作用在于指导企业如何将现实世界中的业务空间，有效映射与转化到数字世界的系统空间。

在这一转化过程中，系统建设的本质，是通过抽象与建模，将现实世界中的对象、流程与关系，转化为可被系统承载与执行的数字表达。

那么，这一过程的关键驱动因素是什么？答案是：模型。

模型不仅是现实世界的抽象表达，更是数字系统中驱动业务逻辑、支撑决策的核心载体。可以说：模型的质量与表达能力，直接决定了系统的构建效率与运行水平。

正因为如此，企业架构的价值得以凸显：它本质上是一个“设计蓝图”，用以指导关键模型的建立，支撑整个系统从规划、设计到持续演进的全过程。

我们可以用一个直观的类比来理解企业架构的作用：就像在建造一座复杂建筑之前，不会直接动工，而是由建筑师先设计出结构图、水电图、施工图等一系列蓝图，经过反复论证与优化后，再依图施工。

企业架构，正是数字化系统建设中的“设计师”。

那么，企业架构通常包括哪些关键模型呢？经过业界多年的探索与沉淀，已逐步形成一套共识性的架构模型体系，即“4A架构”：业务架构、应用架构、数据架构和技术架构。

为了更好地理解这四类架构的定位与作用，我们依然可以通过一个类比来说明：将“4A架构”类比为新能源汽车的生产体系。

业务架构，如同汽车的“整车定义”，决定了这辆车是面向家用、商用，还是高性能市场，明确其核心功能与价值定位。简单来说，业务架构就是“定方向”，确保和企业战略对齐。

应用架构，相当于汽车的“零部件系统”，包括电池管理系统、电驱系统、智能驾驶模块等，并描述各个功能模块如何协作、接口如何设计。简而言之，应用架构是“搭框架”，构建系统的结构。

数据架构，就像汽车的“能量流与信息流体系”，涵盖电池能量的分配、传感器数据的采集、驾驶行为的分析等，确保整车运行中能量与信息的高效流动与精准控制。换句话说，数据架构是“建连接”，只有结构还不够，关键是要有数据流来激活这些结构。

技术架构，则像汽车的“平台与底盘”，为整车的落地提供底层硬件支持、通信协议、软件框架和安全保障等。简单来说，技术架构是“打基础”，为整个系统的落地提供稳定可靠的支撑。

企业架构主流方法论有哪些？

通过上述类比，我们对“4A架构”的定位与作用已经有了初步的理解。而在当前业界的实践过程中，指导企业开展“4A”架构设计的主流方法论主要有两个：一是 TOGAF（The Open Group Architecture Framework），二是 DDD（Domain-Driven Design，领域驱动设计）。

接下来，我们来看看这两种方法论的核心思想，还有它们在实际应用中的局限性。后面提出的面向智能原生时代的企业架构方法论（IEAF），也是在融合这两种理论的基础上进行的演进与创新。

一、TOGAF（企业架构框架）

TOGAF 是业界广为人知的企业架构框架，被称为“架构中的架构”。目前，国内大多数金融机构的企业架构方法论，都是基于 TOGAF 而来的。

以当前仍广泛使用的 TOGAF 9.2 版本为例，如果从整体内容进行概括，可以划分为三个核心部分：ADM 方法、配套工具与组织机制，如图所示。

 
如果对图中内容进行进一步提炼和简化，其实可以将其归纳为一个“双飞轮模型”。其中，三个核心组成部分职责如下。

• 方法（ADM） 是TOGAF的核心内容，是一套结构化的架构开发流程，包含一套系统化、阶段化的实施过程。

• 工具主要用于支持和辅助ADM方法的顺利执行。

• 组织则是为了保障ADM方法的有效落地，明确所需的人员角色、职责分工以及相关规范和制度安排。

在上述“三部分”主体结构之外，模型中还包含了两个“飞轮”机制，用于驱动整个TOGAF框架的持续运转与优化。

• 外侧的迭代飞轮：推动ADM方法不断演进，同时也通过迭代机制持续优化工具和组织，实现整体架构能力的螺旋式提升。

• 内侧的需求飞轮：ADM方法的执行始终由“需求管理”过程所驱动，这是确保方法有效实施、贴合实际业务的关键保障。

TOGAF是一个非常全面、系统的企业架构框架，具有很强的理论完整性和方法论指导意义。然而，在实际应用中，它暴露出的一个明显问题是：其内容偏重原则性指导，整体视角偏宏观抽象，同时体系庞大、内容繁复，往往需要在具体实践中根据不同场景进行大量裁剪与适配。

二、DDD领域驱动设计

DDD是随着微服务架构兴起而广受关注的一种面向业务领域的软件开发方法，主要包括两个设计阶段：战略设计与战术设计。

其中，战略设计侧重于从业务视角出发，通过逐层识别核心领域与子领域，最终明确各限界上下文的边界；而战术设计则聚焦于在限界上下文内部，借助聚合、实体、值对象、领域服务等核心概念，构建出结构清晰、语义明确的领域模型。

从本质上看，DDD提供了一种“分层等级机制”来应对系统的复杂性。它通过一系列结构化概念构建起从宏观到微观的抽象体系，每个层级对应不同粒度的问题域：

• 值对象：解决属性层面的问题。

• 实体：解决对象生命周期的问题。

• 聚合：解决模块内部的封装问题。

• 限界上下文：解决系统边界层面的划分。

• 子领域与领域：应对更高复杂度的系统拆分。

因此，DDD 的最大优势就在于其高度的灵活性与抽象能力，能够有效应对各个复杂业务场景下的建模与系统设计需求。然而，在实际落地过程中，DDD 也暴露出一些明显的局限。

1. 缺乏可操作性

DDD 提出了领域、子领域、限界上下文、聚合等核心概念，但在实践中，并没有提供一套清晰、可复用的划分标准或操作步骤。其效果高度依赖设计者的能力与经验：用得好，价值很大；用得不好，问题很多。

例如，在限界上下文划分过程中，虽然方法强调通过子领域识别和通用语言来界定边界，但子领域的粒度可大可小，而通用语言在大型复杂系统中也未必能有效揭示语义冲突。结果往往是微服务被切分得过细，导致系统复杂度不降反升。

2. 事件风暴门槛高

事件风暴是 DDD 中一个关键的建模手段，但其实门槛很高，需要业务专家深度参与。因为，事件本身通常已隐含了关键实体，若架构师对业务理解不足，很难从中提取出有效的事件。相比之下，从业务流程切入建模，可能更具操作性和实用性。

3、容易陷入“概念驱动设计”的误区

任何一套架构方法论，其实都很难完全适配企业中的业务，最重要的是要领悟其中蕴含的思想，在现实中灵活组合运用。DDD中提出了一套很新颖的概念，然而现实中发现不少架构师都是将这些概念“先入为主”，然后将业务往这些概念中去“套”。

这显然是一种本末倒置的做法。其实，从本质上看，DDD 的战术设计阶段其实与传统的面向对象编程高度重合，大多是将已有思想以新术语的重新包装，例如：

• 聚合类似于面向对象中的“中央控制点”原则，强调对修改入口的统一控制。

• 仓储模式实质上是对“依赖反转”原则的一种实现方式。

• 值对象的思想类似于面向对象中的不可变对象。

真正让 DDD 区别于传统方法的，是其战略设计阶段：它通过明确领域边界、识别子领域和统一语言，有效解决了面向对象在跨领域建模中可能遇到的概念冲突问题。

什么是智能原生企业架构？

刚刚我们初步了解TOGAF与DDD这两类主流企业架构方法论，其实前面谈论的问题还不是最关键的。TOGAF和DDD都出现于信息化时代，到了智能化时代，它们面临的环境已经发生了巨变。

这里可以用传统燃油汽车与新能源汽车简单做一下类比。TOGAF 和 DDD 的方法论原本适用于设计“燃油车”，但在新能源时代，造车的逻辑已经发生了根本性变化。这不仅仅是将燃油替换为电那么简单，而是从设计理念到结构等多方面都需要进行调整。

同样，智能原生对企业架构的影响也遵循类似的逻辑。智能原生与企业架构并非简单的叠加关系，而是需要深度融合，实现协同。

许多人可能会有疑问：这两个看似毫不相干的概念能实现协同吗？

实际上，智能化的本质在于重构人与系统之间的关系。而这种关系，归根结底是一种信息流的交互。当聚焦到信息流这一维度时，就与架构有了关联。因为架构的本质，也在塑造一种关系，这种关系里不仅包括人与系统，还可能包括系统与系统、数据与数据等，而这些关系本质上也是一种信息流的交互。

因此，企业架构与智能化的协同，实际上就是将智能化携带知识的高阶信息流，融合进企业架构原本管理的低阶信息流中，然后由企业架构去统一规划信息流的产生、转化与处理等过程。

接下来，轮到智能原生企业架构框架（IEAF）闪亮登场了，IEAF沿用了业界成熟并广泛使用的“4A”架构体系作为其整体元模型基础。

尽管基本概念维持不变，但在架构设计过程中，面向“智能原生”这一新时代的核心诉求，IEAF 做了针对性的演进和创新，主要包括以下几个方面的关键设计。

• 业务架构：提出“实体Token”概念，为系统设计尤其是中台建设提供全新的思考模式。

• 应用架构：对当前微服务架构的本质进行了深入反思，并厘清微服务与智能体之间的关系。然后，在设计层面，提出两个核心方向：一是面向能力域设计，改变当前微服务粒度过小、服务接口质量低的问题；二是面向智能体设计，分析智能体未来最可能的形态以及架构如何做好前瞻性准备。

• 数据架构：针对目前“以应用为导向”的设计问题，提出“双层价值模型”将数据价值升维。在此基础上，提出一套“以价值为导向”的数据架构设计过程，解决数据模型割裂、数据流转不畅等问题。

• 技术架构：主要探讨当前设计过程中一些最为典型的问题和误区，然后探讨一些基本设计思路。

最后，我们再来简要探讨智能原生企业架构（IEAF）本身所遵循的一些核心设计原则。

1. 简洁性：企业架构设计应简洁直观。每一项设计都应有清晰的目标与边界、重点突出、避免过度抽象与复杂化。

2. 协同性：企业架构设计应顺势而为。正如开篇词中提到的，在大模型浪潮的冲击下，系统建设的起点、模式和形态都将发生变革，企业架构唯有与变革本身保持协同，才能助力变革。

3 前瞻性：企业架构设计应适度前瞻。尽管当前大模型的部分技术尚处于发展阶段，但其演进速度极快、潜力巨大。因此，IEAF 在架构设计中需具备适度的前瞻性，在保障当前方案可落地、可实施的前提下，为未来智能化演进路径提前布局、预留空间。

总结

这节课中，我们首先回答了“AI时代企业架构只会更加重要”这个问题，并在总结回顾传统企业架构的基础上，提出了一个智能原生企业架构框架（IEAF）。

在《技术的本质》一书中提到，技术创新的本质是一种组合的进化。因此，智能原生企业架构也是企业架构在与智能化相遇之后，它自身从设计理念、架构方法到指导原则等一系列的变化。在方法篇的后续课程中，我还会详细展开讲讲IEAF框架，敬请期待。

最后我根据这节课的要点整理了一张复习导图，供你参考。

思考题

有不少人可能会认为，既然AI对架构的影响如此之大，是否应该在“4A”架构之外单独设立一个“AI架构”，你认为是否合理？为什么？

期待你在留言区和我交流互动，如果这节课对你有启发，别忘了分享给身边更多朋友。