一篇文理解架构：企业架构、技术架构、C4模型、TOGAF、互联网模型

“架构”这个词被频繁提起，却常常被误解。有人把它等同于代码结构，有人以为它只是高层设计。

其实从技术架构、C4 模型、TOGAF 框架，到互联网时代的企业架构，它们共同构成了我们理解复杂系统的不同层次。

这篇文章试图用一篇文，理清架构的全貌：它的来源、演进、分层，以及企业架构背后更深的思考。

关注腾讯云开发者，一手技术干货提前解锁👇

11/6晚7:30鹅厂面对面直播继续！

01

关于架构的理解

架构，是对系统的描述。

维基百科的定义是：软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

系统的三大特征表现在架构上就是：横向可并列，纵向可推导，整体可演进。

互联网软件系统总是朝着复杂度增加的方向发展。所以架构的第一目的是控制复杂，使系统朝着可控的方向发展。

1.1 4+1模式

4+1视图由 Philippe Kruchten 提出的对软件工程逻辑架构的描述，目前已经成为事实上的软件结构标准，分别以终端使用者、开发者、系统工程师、软件经理等不同的视角对软件进行描述。如下图所示：

逻辑视图（Logic View）：终端使用者的视角，从功能角度来描述不同功能组件的层次关系。

开发视图（Development View）：开发者视角下，从实现层面描述不同代码的包、类、库的构成关系。

过程视图（Process View）：不同组件之间的行为关系，通常以时序图的形式来表示，有一定的时序延展性。

物理视图（Physical View）：部署视图，系统所依托的物理视图。

场景视图（Scenarios）：系统所涉及的不同对象之间的关系。通常以用例图的形式来呈现。

基于这5个视角，可以衍生出5种架构模型。场景、功能、实现、过程、部署，一层层的抽象。

1.2 C4模型

C4 模型是由 Simon Brown 在2006年至2011年之间创建，在4+1模型的基础上建立（ https://c4model.com/ ），实际上就是以下4个单词的缩写：

上下文 Context：描述的系统与周边系统、人的关系。重点是该系统与外界的关系。这里的外界包含人、以及其他的系统。

容器 Containers：容器是一个功能的单位，是从技术层面来描述，可以是一个服务，也可以是一个技术组件或者一个功能模块。例如一个基金系统会包含交易服务、订单服务、商品服务等。

组件 Components：组件是容器的的组成，组件是对容器的放大，例如商品服务里包含 sku 管理、行情数据、衍生指标等。

代码 Code：这一层次是代码级别，包含接口、类、对象的继承、组合、包含等。

该模型是对一个系统从宏观到微观逐级展开来描述，犹如拿着放大镜从太空看地球一样。

第一层看到的是地球与其星球的环绕、第二层是看到地球上的山川海河，第三层看到的是不同的国家城市，第四层看到的是不同的房子家庭。

C4 模型基于4+1模型，但是也有些差异。如果说4+1重点是横看成岭侧成峰。那 C4 模型则是一窥到底的放大镜。

C4 模型告诉我们，不同抽象层次的关注点、挑战点、问题域都是不同的，站在不同的层次就要思考对应的事情。

高层次是低一层的抽象，低层次是高一层的具化。

高手应该能够识别不同的抽象层次，并且游刃有余地在不同抽象层次之间穿梭。

1.3 TOGAF-4A 架构

业务架构：业务战略，治理，组织和关键业务流程。从企业视角来看，重在价值、信息、协作，关联多部门。

应用架构：要部署的各个应用程序的蓝图，其交互以及与组织核心业务流程的关系。

数据架构：一个组织的逻辑和物理数据资产和数据管理资源的结构。

技术架构：支持部署业务，数据和应用程序服务所需的逻辑软件和硬件功能。这包括IT基础设施，中间件，网络，通信，处理和标准。

TOGAF 认为架构的目的是为了帮助企业实现如下能力：

异构到同构（塑造同构 IT）、事后到事先（塑造规划 IT）、离散到统一（塑造统一 IT）、无序到有序（塑造有序 IT）

1.4 互联网模型

实际上，相对于传统的软件系统，互联网行业发展比较快，业务存活周期比较短，就形成了互联网行业特定的架构描述方式。更多是以业务架构、技术架构、部署架构三种形式呈现。

业务架构：从业务角度描述系统承载的功能集合、领域边界、各组成部分的逻辑关系。区别于技术架构，业务架构图里避免出现技术类的术语，如 DB、MySQL、CMQ、同步、异步、并发等。

技术架构：从技术角度描述系统各组成部件之间的交互关系，技术架构体现的要具有技术特色，例如同步、异步、消息等。

部署架构：从物理角度描述系统的部署分布。

02

企业架构又是什么？

软件架构解决的是“一个系统”的复杂性问题，但企业的问题往往不止一个系统。

当公司发展到一定规模后，问题不再是“如何设计一个优雅的系统”，而是“如何让数十个系统、上百个流程、数千个员工协同起来工作”。

系统之间的边界、数据之间的流向、部门之间的职责，这些构成了第二层复杂性。

企业架构（Enterprise Architecture, EA） 正是为了应对这种复杂性而生。它从更高层面描述企业的“系统之系统”，让组织在技术、流程与人之间达成长期的一致。

关于企业架构，很多人在工作多年甚至当上架构师以后，还是存在很多的误解。这是因为企业架构本身是一个非常理论化的领域，不同的企业架构师面对不同的企业规模、业务特性，可能都会得出不同的结论。但有一些共性的误解，也许是可以避免的。

误解一：企业架构 = 技术架构。

很多人听到 “架构（architecture）”就联想到技术，什么系统设计、软件平台、模块化、微服务，巴拉巴拉。

这种理解的问题在于范围太窄，实际上EA 的核心不仅是技术，而是人-流程-技术-数据的整体，把企业架构当作大型技术项目的集合，显然忽略了更广的组织难度。

误解二：做图、出模型就是企业架构。

有人认为：只要绘制了 Archimate 模型、建立了元模型、出了一堆架构文档，那就完成了企业架构。

实际上这只是手段，不是终点。真正的企业架构在于用图／模型支持决策、推动组织演进。把“画架构图”当成企业架构目标，是一种形式化误区。

正确做法：关注组织当前面临的问题，问“我们要去哪儿？”、“我们怎样才能到达？”、“我们现在是怎样的？”。架构图只是辅助。

误解三：企业架构只关乎高层战略，不关乎执行／运作层。

有观点认为企业架构是老板／高管的战略工具，而与基层/技术/运维无关。这是错误的，因为企业架构横跨战略、业务、运作、基础设施各层。

真正做好企业架构，既要理解战略层面的方向，也要理解运作如何落实。这意味着企业架构师常常需要走进基层、理解流程、技术、数据是怎样实际运转的。

误解四：企业架构的价值在于“架构模型完善度”或“文档完备性”。

一种常见做法：评价企业架构成熟度、看文档覆盖率／图谱齐全性。

但如果这些指标只是“做给自己看”、或只是“为了出图”，价值有限。真正价值在于是否能支持决策、能推动组织下一步走向。：比起“图画得很漂亮”“模型层次很多”，更重要的是“这些图／模型是否引导了更好决策、是否让组织迈向了更好的状态”。

回过头来，我们再给企业架构做一个定义，或许可以这么表述：

企业架构在组织的人（People）、流程（Processes）、技术（Technology）与信息／数据（Information/Data）之间连结各个点，目的在于帮助组织做出更明智、面向长期的决策——通过绘制“今天是如何运作”的图景，以及引导其迈向“明天可以到达”的状态。

人（People）、流程（Processes）、技术（Technology），是很多企业架构人员经常使用的PPT模型方案，但信息（Information）同样重要，尤其是在国内数字化转型的当下，因为缺少信息互通而造成的信息孤岛效应极大地制约了企业IT能力的发展。

因此，一名优秀的企业架构师，往往在三个层面同时工作：

战略层：用架构方法帮助管理层理解“今天的组织是什么样的”“未来想变成什么样”。

业务层：对业务能力、核心流程进行建模，帮助组织找到瓶颈、优化流程。

技术层：确保信息、数据和系统的设计能支撑战略目标，不成为组织演进的阻力。

企业架构不是一种工具或模型，而是一种“系统思考方式”：它要求你看到全局、理解关系、管理演化。

当架构师成长到一定阶段，真正要理解的不再是某种技术模式，而是系统的边界与组织的边界。

技术只是企业架构的皮，流程和信息才是它的骨。

祝愿每位看到这篇文章的各位，有朝一日都能成为可以去「定义」组织流程的架构师！