企业架构的概念方法与实践

数字化建设过程中常见一种错位。业务关注流程，信息技术关注系统，数据团队关注口径，研发关注代码，各方都在讨论架构，所指对象却并不相同。

由此带来的结果往往是系统持续增加而流程并未真正优化，数据持续积累而指标口径难以统一，技术投入上升而维护成本同步抬升。

本文按概念界定、价值机制、历史演进、架构域构成、架构关系、实践案例、中国落地与实施路径展开，对企业架构 Enterprise Architecture 作系统梳理。文中关键史实、数据与案例尽量采用可核验来源，文末附参考文献。

1. 企业架构是什么

企业架构（Enterprise Architecture ，简称 EA ）是一套从企业全局视角 出发，对业务能力、流程规则、数据资产、应用系统、技术底座进行系统性梳理、设计与持续治理的管理与工程方法论。

可以把它理解成：

把战略翻译成可执行的经营安排与 IT 支撑，并持续约束「该建什么、不该建什么」。

它不是某一种开发框架，也不是几张漂亮的架构图。

1.1 两种被广泛引用的定义

来源	定义要点
The Open Group（TOGAF）	EA 描述企业中业务、数据、应用与技术等组成部分及其相互关系，并通过架构开发方法（ADM）指导从愿景到实施的迭代过程。 $1$
MIT CISR（Ross / Weill / Robertson）	EA 是企业业务流程与 IT 能力的组织逻辑（organizing logic），反映企业经营模式（operating model）对流程集成与标准化的要求；架构首先是战略执行基础，而不只是 IT 技术设计。 $2$
Tamm 等（学术综述）	EA 是对企业业务流程与 IT 系统及其相互关系、共享程度的高层定义与表达，旨在支撑组织未来目标，并给出迈向目标架构的路线图。 $15$

一句话：企业架构要回答的，不是「用什么技术」，而是「企业按什么方式运转，以及 IT 如何稳定支撑这种方式」。

1.2 核心目标

序号	目标	说明	典型落地表现
1	战略对齐	经营要素与战略目标一致	重大项目先看是否服务战略能力
2	降低复杂度	减少重复建设与数据孤岛	系统边界清晰、主数据统一
3	贯通落地	从战略到执行上下贯通	有目标架构、路线图、治理机制

1.3 一个直觉例子

同一家制造企业，如果没有企业架构视角，常见对话是：

业务说：「给我上一个供应链系统。」
IT 说：「那我们选 SAP / 自研 / 微服务？」
数据说：「先把数仓建起来。」
研发说：「模块怎么拆？」

这些都重要，但顺序错了。更合理的提问是：

我们的核心价值链是什么？哪些能力必须标准化？
订单、库存、采购由谁主责？跨部门规则是什么？
需要哪些系统承载，边界如何切分？
关键数据以谁为准、如何流转？
技术底座与软件结构如何支撑长期演进？

这五步，其实已经覆盖了业务、应用、数据、技术与软件架构。

2. 企业架构的价值创造机制

很多人第一次接触 EA，会以为「企业架构 = 画几张架构图」。这是最常见、也最昂贵的误解。

Zachman 1987 年提出的框架，本质上是一种用于系统描述的分类体系（taxonomy） ，作者明确指出该文讨论的是架构描述，并不等于完整战略规划方法论。 $3$

后续 TOGAF、FEAF 等，才把「怎么描述」扩展为「怎么开发、怎么治理、怎么落地」。

2.1 三项核心价值

价值	内涵	反面案例
翻译	把抽象战略翻译为能力、流程、数据标准、系统支撑	战略口号很多，项目清单却对不上
统筹	把局部工作纳入统一框架	各部门各自最优，整体低效
对齐	先对齐目标架构，再立项建设	先买系统，再补流程与口径

2.2 EA 如何带来组织收益：四个「价值使能器」

Tamm 等学者在综述大量 EA 文献后提出 EA Benefits Model（EABM）：EA 并不直接「变出利润」，而是通过改善四个使能器，间接带来更低成本、更高敏捷性与更可靠的运营平台： $15$

使能器	含义	对应你日常能看到的变化
组织对齐（Organisational Alignment）	业务目标、流程与 IT 投资方向一致	少做「战略无关项目」
信息可用性（Information Availability）	决策所需信息更及时、更一致	少开会对口径
资源组合优化（Resource Portfolio Optimisation）	系统与能力组合更合理，减少重复	少买功能重叠的系统
资源互补性（Resource Complementarity）	业务能力与 IT 能力相互增强	上新业务更快、返工更少

研究也指出：规模大、IT 环境复杂、经营模式需要较高标准化与集成的组织，通常更能从 EA 中获益。 $15$

2.3 经营模式决定架构形态（MIT CISR）

Ross 等人强调：先想清楚企业经营模式对「集成」和「标准化」的要求，再设计企业架构。 $2$

一个简化理解是：

经营诉求	架构倾向
各业务线高度独立	更强调局部灵活，统一要求相对少
需要集团统一客户 / 产品 / 财务视图	必须强化主数据、共享流程与集成标准
既要统一底座、又要前端创新	常见「厚中台 / 共享能力 + 薄前台」

要点：没有唯一正确的架构模板，只有与经营模式匹配的架构选择。照搬别家蓝图，往往先失败。

3. 企业架构的起源与发展

企业架构诞生于 IT 系统复杂化带来的协同困境，随后从技术描述框架 演进为承接战略、贯通业务与技术的企业级方法。主线始终是：

降低复杂度 · 对齐业务目标 · 提升整体效率

3.1 阶段总览

阶段	时间	关键词	核心转变
起源奠基	1980 年代	Zachman Framework	建立信息系统架构描述范式
标准化发展	1990 年代---21 世纪初	TOGAF / FEAF / DoDAF	从描述框架走向方法与治理
普及成熟	约 2000---2010 年	TOGAF 9、四大架构域	成为事实标准，支撑大规模信息化
数字化转型期	2010 年至今	轻量化、敏捷化、业务价值导向	动态迭代，融入经营管理

3.2 起源奠基：1980 年代

背景：大型机普及，信息系统激增，标准不一，数据孤岛与重复建设凸显。

里程碑 ：1987 年，IBM 的 John A. Zachman 在 IBM Systems Journal 发表 A Framework for Information Systems Architecture，提出多视角矩阵式描述框架，成为 EA 领域公认开山之作。 $3$

阶段特征 ：重心仍是信息系统架构描述。

3.3 标准化发展：1990 年代---21 世纪初

背景：IT 投资扩大，业务与 IT 脱节、投资回报偏低；政府与行业组织推动标准化。

关键里程碑

1995 年 ：The Open Group 以美国国防部 TAFIM 为基础发布 TOGAF Version 1 ，并持续演进 ADM 。 $1$ $4$ 早期 TOGAF 更偏技术 / 平台架构；后续版本逐步强化业务与信息体系。
1996 年 ：美国《克林格---科恩法案》（Clinger-Cohen Act, P.L. 104-106）要求联邦机构 CIO 建立并维护一体化信息技术架构。 $5$
1999 年 9 月 ：联邦 CIO 委员会发布 FEAF Version 1.1，提出跨机构架构构造方法，并包含业务、数据、应用、技术等视角。 $5$ $6$
2003/2004 年 ：美国国防部发布 DoDAF 1.0（此前长期使用 C4ISR Architecture Framework）。 $7$

阶段特征：从「怎么描述」升级为「怎么实施与治理」，目标转向业务与 IT 对齐。

3.4 普及成熟：约 2000---2010 年

里程碑

2009 年 2 月 ：发布 TOGAF 9 ，进一步强化业务导向，并系统阐述业务、数据、应用、技术四类相关架构。 $1$ $8$ 四大域并非 TOGAF 9「从零发明」；FEAF 等体系已有相近表述，TOGAF 9 使其成为更稳固的全球共识表达。
银行业实践中，TOGAF 常与行业内容框架结合使用。例如 The Open Group 与 BIAN（Banking Industry Architecture Network）发布协作白皮书：TOGAF 提供通用方法，BIAN 提供银行服务参考内容，可加速银行架构工作并提升一致性。 $16$
中国在 2000 年后逐步引入相关方法，金融、电信、能源等行业率先落地。

3.5 数字化转型期：2010 年至今

云原生、大数据、微服务、中台快速迭代，传统重型 EA「周期长、响应慢」的问题暴露。The Open Group 也发布了面向数字企业与敏捷交付的系列指南。 $1$

变化	说明
方法轻量化	从全量长周期蓝图，转向小步迭代
重心上移	业务架构、数据架构地位提升
受众下沉	从大型企业扩展到中型企业裁剪式实践

4. 四大架构域的构成

在 TOGAF 等主流框架中，企业架构通常覆盖四类相互关联的架构域。 $1$ $8$

先澄清两个容易矛盾的点：

数据架构与应用架构在方法上常并列（TOGAF ADM Phase C 同时覆盖 Data 与 Application），并非永远「数据层压在应用层之上」。分层图是教学表达。
代码 / 软件架构不属于经典 EA 四大域，它是单个系统内部的实现架构，是 EA 向下落地的一层。

4.1 教学用关系图

复制代码

┌──────────────────────────────────────────┐
│            业务架构（Business）             │
│     能力 · 流程 · 组织权责 · 业务规则         │
├──────────────────────────────────────────┤
│     数据架构（Data）  ║  应用架构（Application） │
│   资产·标准·流向·治理 ║  系统·边界·集成·布局    │
├──────────────────────────────────────────┤
│            技术架构（Technology）            │
│     基础设施 · 技术栈 · 安全 · 运维           │
└──────────────────────────────────────────┘
              ↓ 落地实现
┌──────────────────────────────────────────┐
│     代码 / 软件架构（Software Architecture）  │
│     模块边界 · 耦合解耦 · 可扩展性 · 可维护性   │
└──────────────────────────────────────────┘

4.2 四大域对照与「缺了会怎样」

架构域	核心问题	主要产出	缺失时的典型症状
业务架构	靠什么能力创造价值？流程与权责如何安排？	能力地图、端到端流程、权责规则	系统上线后，扯皮依旧；流程被「原样固化」
数据架构	核心数据是什么？如何流转与治理？	资产清单、标准、口径、数据流	同一指标多个数；主数据冲突
应用架构	用哪些系统支撑？边界与集成如何？	系统清单、功能边界、集成关系	功能重叠、重复建设、人工导数
技术架构	底座如何保障稳定、安全、可扩展？	技术标准、部署与运维体系	大促不稳、接口烟囱、扩展成本飙升

关系口诀：业务定义「要什么」，应用决定「谁来做」，数据决定「信息如何一致流动」，技术决定「底座能不能撑住」。

4.3 与 TOGAF ADM 的对应（便于专业读者对齐）

ADM 阶段（简化）	主要关注
Architecture Vision	架构愿景、范围、干系人
Business Architecture	业务架构
Information Systems Architecture	数据架构 + 应用架构
Technology Architecture	技术架构
Opportunities & Solutions / Migration Planning	路线图与迁移
Implementation Governance / Architecture Change Management	落地治理与持续变更

企业不必机械跑完全流程，但**「先业务、再信息系统、再技术、再迁移治理」**的节奏，比「先买平台」稳健得多。 $1$

5. 业务应用数据技术与代码架构的关系

数字化建设中常同时出现五个词：

业务架构 · 应用架构 · 数据架构 · 技术架构 · 代码架构

5.1 为什么会「鸡同鸭讲」

角色	口中的「架构」通常指
业务部门	流程、权责、组织是否合理
系统团队	应用如何建设与协同
数据团队	口径、模型、治理是否统一
开发人员	代码是否可维护、变更是否可控

缺少整体规划时，常见三连困境：

系统越建越多，业务流程却没有真正优化
数据越积越丰富，指标口径却依然不统一
技术投入持续增加，维护成本反而越来越高

5.2 为什么不能一上来就谈技术选型

很多企业默认「架构是技术部门的事」，项目一开始就讨论数据库、语言、云平台或微服务。

举例：制造企业要建供应链管理平台

表面需求：「开发一个采购和库存管理系统。」

真正要先回答：

采购流程如何运行？
订单如何从销售传递到生产？
库存数据由哪个系统主责？
系统间如何共享与同步数据？

如果跳过这些，很容易出现「系统上线了，效率却没提升」：流程被固化、边界不清、数据不通，最后仍靠人工整理报表。

5.3 业务架构：企业如何运行

一句话：回答「企业做什么、按什么方式做」。

关注点不是某个系统，而是能力与流程组织。制造企业从客户需求 → 销售接单 → 计划排产 → 采购备料 → 生产制造 → 仓储收发存 → 财务核算，这条链路就是业务架构的重要内容。

业务域	通常需要明确
采购	供应商管理、采购审批、交付管理
生产	计划排产、生产执行、质量控制
销售	订单管理、客户服务、收入确认

业务流程没梳理清楚就上 ERP / CRM，往往只是把旧问题数字化。很多项目效果不佳，根因不是功能不够，而是业务逻辑本身没有优化。

5.4 应用架构：系统如何支撑业务

一句话：回答「业务由哪些系统承载、如何协同」。

系统	常见职责
ERP	企业资源计划与经营管理
MES	生产过程执行
WMS	仓储作业
CRM	客户与销售管理

关键不在系统数量，而在职责边界与业务闭环。边界不清时，客户主数据同时存在 CRM 与 ERP，两套各自维护，分析结果长期无法统一。

应用体系完善后，瓶颈常转向系统间数据流转：若仍靠 Excel 合并，时效差、口径风险高。此时需要统一集成能力：按业务规则完成采集、转换、同步与调度。

5.5 数据架构：数据如何管理与使用

一句话：回答「数据如何产生、存储、加工、治理并服务业务」。

系统变多后，常见现象是：数据量上升，数据价值不同步上升。根因通常不是缺数据，而是缺统一管理体系。

没有统一数据架构时，「客户价值」可能被各部门各自定义：

部门	常见口径
销售	成交金额
财务	回款情况
运营	活跃程度

再以「销售收入」为例，至少要明确：按订单金额还是收入确认？退款如何处理？跨期如何归属？跨系统如何关联？规则不沉淀，就会出现「同一个指标，三个部门三个数」。

落地难点还在于：源系统结构不同、更新频率不同。需要统一集成与治理，让数据按规则持续流动，而不是一次性堆进仓库。

5.6 技术架构：系统如何稳定运行

一句话：回答「如何具备稳定性、安全性与持续扩展能力」。

重点不是单一选型，而是整套运行环境能否长期支撑业务变化。问题会从「单系统稳不稳」，扩展到应用交互、数据流转与链路运维。缺少统一连接方式时，每新增一批系统，就可能新增一批接口烟囱。

5.7 代码架构：软件如何长期维护

一句话 ：更准确称软件架构------单个软件内部如何组织，才能持续演进。

它不属于经典 EA 四大域，但与 EA 强相关：应用架构定义系统边界与职责，软件架构定义系统内部如何实现这些职责。

设计要点	目的
模块合理拆分	边界清晰，降低变更扩散
降低耦合	减少复杂依赖
支持扩展	新增需求不必大规模推倒重来

5.8 五种架构对照总表

类型	核心问题	典型产出	主要责任方	与 EA 关系
业务架构	企业如何运行？	能力地图、端到端流程	业务 / 战略	EA 核心域
应用架构	系统如何支撑业务？	应用蓝图、集成关系	业务 + IT	EA 核心域
数据架构	数据如何管理使用？	资产目录、指标口径	数据 / 业务	EA 核心域
技术架构	系统如何稳定运行？	技术标准、运维体系	IT / 基础设施	EA 核心域
代码架构	软件如何长期维护？	分层设计、模块边界	研发	EA 的实现层

5.9 贯通关系

复制代码

业务架构（做什么、怎么跑）
    ↓
应用架构（用哪些系统承载）  ←→  数据架构（信息如何统一流转）
    ↓
技术架构（底座如何支撑）
    ↓
代码 / 软件架构（系统内部如何实现与演进）

建设顺序建议：

步骤	动作	目标
1	梳理业务架构	明确经营流程与管理目标
2	规划应用架构	明确系统职责与协同方式
3	建设数据架构	统一标准、口径与数据流
4	完善技术架构与软件架构	保障稳定运行与可持续演进

与 TOGAF ADM「先业务、再信息系统（数据+应用）、再技术」总体节奏一致；可按痛点裁剪，但不宜长期倒置。 $1$

6. 常见认知误区

误区	正确理解
把 EA 等同于 IT 架构	应用 + 技术只是下半部分；业务与数据才是解决经营问题的关键抓手
把 EA 等同于一堆文档	架构应约束投资、项目边界与运营规则
认为只有大企业才需要	中小企业可裁剪聚焦核心流程、核心数据、核心系统
认为架构一次成型	架构能力持续演进；战略变化后目标架构应同步调整
把代码架构当成企业架构	软件架构很重要，但不能替代企业级统筹
照搬完整 TOGAF 才叫专业	专业体现在「匹配经营模式与资源约束」，不是流程跑全

7. 企业架构实践案例

下面按「规模从小到大」展开。前一个是教学推演案例，后几个均有公开资料可核验。

7.1 轻量教学案例：50 人服饰品牌电商

背景

维度	现状
规模	约 50 人服饰品牌电商
渠道	天猫、抖音小店、私域
部门	商品、运营、仓储、客服、财务
支撑方式	零散系统 + 人工对接
痛点	库存超卖、订单漏发、对账慢、客户信息分散

四层怎么落

架构层	做法	直接解决的问题
业务架构	明确 6 项核心能力；拉通「上新→下单→发货→售后→结算」；规定退款审批与库存调整权责	跨部门扯皮
数据架构	统一「销售额=用户实付」「可售库存扣减待发货」；订单一次录入全链路共享	口径打架、超卖、用户分散
应用架构	渠道后台 / ERP / WMS / SCRM / 财务各司其职；订单、库存、物流、财务自动集成	人工导数与重复录入
技术架构	云资源弹性、统一接口规范、备份与防护	大促稳定性与数据安全

启发：中小企业不必上完整 EA 办公室，但至少要把「规则、口径、系统边界、集成」说清楚。这就是轻量化企业架构。

7.2 中小金融：中邮消费金融的「三步走」

中小金融机构常面临预算与人力约束，难复制大型银行的重型 EA。中邮消费金融公开介绍了一套轻量化路径： $12$

步骤	做法	架构含义
第一步	锚定顶层规划，搭建轻量化全域架构：围绕经营全链路梳理市场营销、产品服务、风控内控、经营决策、业务支撑等价值链，并拆解为若干业务领域	先做业务架构，而不是先堆系统
第二步	分级建模 + 功能点拆解，厘清业务与系统边界；搭建「纵向分层、横向分域」应用架构；形成规划---建设---运营---优化闭环	用应用架构卡住重复投入
第三步	聚焦专项工程落地：围绕获客、风控、服务等主线推进系统改造、数据治理与 AI 场景	防止蓝图停在纸面

可复制点：资源有限时，用「价值链拆解 + 边界建模 + 专项见效」代替大而全长周期规划。

7.3 大型银行：中国银行「IT 蓝图」

问题从哪来

公开报道显示，IT 蓝图启动前，中国银行面临核心系统版本不统一（多版本并存）、数据集中度不足、系统偏「以账户为中心」等瓶颈；新产品推广周期长，科技对业务支撑不足。 $9$

做了什么

时间线	关键动作
2003 年	启动 IT 蓝图相关建设与规划
规划阶段	从应用架构、基础设施、IT 治理、安全等方面明确中长期路径；目标应用架构覆盖交付渠道、客户管理、产品管理、财务会计、决策支持等层次
实施阶段	推进核心系统统一、数据集中、流程再造；从「以账户为中心」转向「以客户为中心」
约 2011 年	新一代核心业务系统全辖上线

架构视角解读

架构层	对应动作
业务 / 运营	前后台分离、交易与核算分离、全行一本账等能力目标
应用架构	统一核心、分层应用蓝图
数据架构	客户信息集中、全行唯一客户号等
技术 / 基础设施	「两地三中心」等运维体系规划

准确表述：这是大型银行信息化 / IT 架构转型的标杆工程，为企业架构在中国落地提供了重要实践土壤；不宜简单说成「完整照搬某一国际 EA 框架」。 $9$

7.4 电信央企：中国联通「同舟 ERP」

痛点：传统闭源 ERP 架构封闭、核心逻辑不可见，企业在管理自主权与长期演进上承压。

做法（公开披露） $17$

2022 年启动 ERP 自研攻坚，联通数科主导研发「同舟 ERP」
贯通人力、财务、供应链三大核心价值链，集成九大关键业务模块
覆盖集团及 31 家省级分公司业务场景，承接近 20 年历史数据资产
在年度关账等高并发场景下验证稳定性（公开报道提及覆盖 300 余家核算主体、支撑上万用户作业等）

架构视角解读

架构层	体现
业务架构	以人力 / 财务 / 供应链价值链贯通为目标，推动从分散运营到全域协同
应用架构	以一体化 ERP 承载关键经营管理模块，减少烟囱式管理应用
数据架构	打破业务数据壁垒，支撑穿透追溯与精细管控
技术架构	强调开放、兼容、可扩展，并与国产化底座、性能攻坚绑定

启发：大型集团的架构升级，往往不是「多买一个系统」，而是用统一经营底座重做价值链协同；在中国语境下，还常与信创自主可控叠加。

7.5 电信金融场景：中国电信财司系统国产化重构

中国电信公开披露，其财务公司新一代数智金融系统（「辰玑」等相关品牌与平台）实现从底层基础设施到上层应用的全栈国产化与自主可控，面向资金管理、风险管控与金融服务流程。 $18$

架构视角解读

架构层	体现
业务架构	覆盖财司业务全流程，强化资金管理与风控能力
应用架构	以新一代核心业务系统替代传统依赖外部技术的烟囱体系
数据架构	打破资金管理信息孤岛，支撑智能化升级
技术架构	国产芯片 / OS / 数据库等全栈适配，微服务与容灾能力

启发：当「合规 + 自主可控」成为硬约束时，技术架构升级会反向倒逼应用与数据重构；EA 的价值在于保证重构仍服务统一业务目标，而不是为国产化而国产化。

7.6 基础设施运营：中国铁塔的「战略---价值流---能力产品化」

中国铁塔在数字化建设中提出「五化」运营体系（专业化、集约化、精益化、高效化、数字化），并通过数字化平台提升资产管理与运营效率；同时拓展「数字塔」等对外服务能力。 $19$

中国信通院相关观察报告进一步将其 EA 实践概括为：基于战略规划与价值流分析，推动数智化能力产品化------业务架构界定核心能力，应用架构以中台化实现「能力即服务」，数据架构推进数据能力产品化，技术架构支撑能力封装与生态开放。 $20$

架构视角解读

复制代码

战略目标（五化运营 / 价值创造）
    ↓ 解码
核心价值流（业务流 + 数智能力）
    ↓ 产品化
业务能力 → 应用中台能力 → 数据能力 → 技术封装能力

启发：成熟阶段的 EA，不只是「支撑现有流程」，而是把可复用能力沉淀为产品，同时服务内部运营与外部生态。

7.7 制造集团：中国一汽「5A」企业架构

中国一汽公开介绍，参考 TOGAF 方法论，结合自身数字化转型需求，形成以业务单元为核心的 5A 架构体系： $21$

架构	含义
BA	业务架构
IA	信息架构（偏数据 / 信息视角）
AA	应用架构
TA	技术架构
SA	安全架构

其方法强调：从价值流解耦到业务单元，识别业务要素与对象，推动业务能力化、组件化、服务化，并以业务单元为枢纽融合业务、信息与应用。

启发：

1）四大域不是教条，企业可按风险与合规需要扩展（如安全架构）；

2）「业务单元 / 能力」是连接战略与系统的关键中间层；

3）本土化改造（5A）往往比原样照搬 TOGAF 更可落地。

7.8 案例对照：不同企业在解什么题

案例	企业类型	核心矛盾	架构抓手
50 人电商	中小零售	人工协同导致超卖、漏发、对账慢	轻量规则 + 口径 + 系统集成
中邮消费金融	中小金融	资源有限，难做重型 EA	价值链拆解 + 分级建模 + 专项见效
中国银行 IT 蓝图	大型银行	多版本核心、数据分散、业务响应慢	统一核心 + 数据集中 + 治理机制
联通同舟 ERP	电信央企	经营协同不足 + 自主可控	价值链贯通的一体化经营底座
电信财司系统	电信金融	关键系统外部依赖	全栈技术重构服务业务连续性
中国铁塔	基础设施	从资产运营走向能力变现	战略---价值流---能力产品化
中国一汽 5A	制造集团	业务与系统难原子化协同	业务单元驱动的 5A 体系

8. 企业架构在中国的应用实践

整体格局可概括为：

大型企业体系化落地 · 中小企业轻量化探索 · 行业特征鲜明

8.1 三个阶段

阶段	时间	核心特征
萌芽引入期	约 2000---2010 年	IT 导向，解决孤岛与重复建设
体系化发展期	约 2011---2016 年	从技术工具转向治理手段
数智化创新期	约 2017 年至今	与数字化转型深度绑定

萌芽期关键事实

中行 IT 蓝图（见 7.3） $9$
2010 年 IDC 调查：超过 73% 大型 / 超大型受访企业已开始或已构建企业架构；TOGAF 认知度与接受度较高（约 37.5% 企业构建时会选择 TOGAF）。 $10$

数智化阶段关键事实

2023 年国资委通报：89 家央企明确数字化转型发展规划；90 多家组建「一把手」负责机制；要求业务 / 数据 / 应用 / 技术架构融合一致。 $11$

8.2 行业画像

行业	实践特征	代表路径
金融	起步早、治理要求高	大行重型治理；中小机构轻量化三步走
电信	超大规模 + 信创	经营底座重构、关键系统国产化
央企制造 / 基建	集团管控强	战略解码、能力中台、考核闭环
互联网	敏捷与中台	业务架构 + DDD + 能力复用，反向影响传统企业

8.3 本土化四个特征

特征	说明
强集团管控	统一标准、数据与规范，避免分散建设失控
信创绑定	技术底座重构常与架构升级同步发生
重型与轻量并存	头部做完整方法，中小做痛点裁剪
业务主导增强	从 IT 单干，转向一把手 / 战略 / 运营牵头

8.4 误区与趋势

误区：把 EA 当 IT 项目；追求完美蓝图；照搬西方框架不适配本土管控。

趋势：动态迭代、智能化辅助治理、架构边界向产业链生态延伸。

9. 不同规模企业的落地路径

9.1 中小企业（几十人到数百人）

目标：90 天内解决 1---2 个真痛点，而不是建 EA 部门。

建议最小集：

画清 1 条端到端主流程（含权责）
选定 5 个以内核心数据对象与口径
明确现有系统边界与「必须打通」的 3 条集成
形成「能做什么 / 暂不做什么」清单

9.2 中型企业（多系统、多部门）

目标：建立可复用的架构语言与项目准入机制。

形成业务能力地图（不必一次完美）
应用清单 + 主责系统 + 集成关系图
主数据与核心指标口径治理
设立轻量架构评审（重大项目必须过）

9.3 大型集团 / 受监管行业

目标：架构能力产品化与治理制度化。

明确经营模式对集成 / 标准化的要求
建立目标架构与迁移路线图
架构治理嵌入投资决策与考核
安全、合规、信创纳入统一架构约束
持续度量：重复建设率、主数据冲突、接口烟囱数量、需求交付周期等

9.4 一张可执行清单

先问业务：价值链、能力、权责是否清晰？
再定应用：系统职责与集成边界是否清楚？
同步治数据：主数据、指标、数据流是否统一？
技术托底：稳定、安全、扩展、集成是否可持续？
代码落地：模块边界是否支持演进？
治理闭环：谁决策、谁评审、谁对效果负责？

10. 总结

真正决定数字化水平的，不是系统数量或技术名词密度，而是：

业务、应用、数据、技术是否形成清晰协同，并能落实到可维护的软件实现。

Tamm 等的研究提醒我们：EA 通过「对齐、信息可用、资源优化、能力互补」创造价值； $15$

Ross 等的研究提醒我们：先匹配经营模式，再谈架构形态； $2$

中国实践则提醒我们：在集团管控与信创约束下，EA 必须本土化裁剪，才能既正确又可用。

企业架构不是画图比赛，而是用业务 →（数据 ∥ 应用）→ 技术，并向下落到软件实现的贯通体系，把战略翻译成可执行的全局协同框架。

好的架构，不追求最复杂，而追求在当前需求与未来发展之间找到可执行的平衡。

11. 参考文献

文中统计与案例均尽量采用可公开核验来源；企业成效表述以官方 / 权威媒体披露为准，避免过度外推。

The Open Group. The TOGAF® Standard . https://www.opengroup.org/togaf / https://publications.opengroup.org/c220
Jeanne W. Ross, Peter Weill, David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution . Harvard Business School Press, 2006.

MIT CISR: https://cisr.mit.edu/publication/enterprise-architecture-as-strategy
John A. Zachman. "A Framework for Information Systems Architecture." IBM Systems Journal , 26(3), 1987, 276--292. DOI: 10.1147/sj.263.0276
The Open Group. TOGAF 历史说明：1995 年 Version 1 基于美国国防部 TAFIM（见 TOGAF 标准引言）.
U.S. Congress. Clinger-Cohen Act of 1996 (P.L. 104-106)；及相关联邦架构监管材料（可检索 GAO）：https://www.gao.gov
Chief Information Officers Council. Federal Enterprise Architecture Framework, Version 1.1, September 1999.
U.S. Department of Defense. DoD Architecture Framework (DoDAF) Version 1.0, 2003/2004.
The Open Group. TOGAF® Version 9 （2009）. https://publications.opengroup.org/g091
中国银行「IT 蓝图」公开报道（2003 年启动，约 2011 年新一代核心全辖上线）：

https://www.bankofchina.com/aboutboc/ab8/201201/t20120111_1669779.html
IDC.《架构企业未来------2010 企业架构中国管理者调查报告》公开转述：

https://www.prnasia.com/story/29147-1.shtml
国务院国资委「深入推进国有企业数字化转型专题会」（2023-06-27）相关通报转载：

https://gzw.taian.gov.cn/art/2023/6/30/art_178900_10294440.html
中邮消费金融.「以企业架构为引擎，探索中小金融机构数智化转型新路径」：

https://www.youcash.com/zuixingdongtai/77947.html
ISO/IEC/IEEE 42010. Systems and software engineering --- Architecture description.
国务院国资委等.《国有企业数字化转型工作指南》等政策文件（规划内容通常包含业务 / 应用 / 技术 / 数据等架构安排）.
Toomas Tamm, Peter B. Seddon, Graeme Shanks, Peter Reynolds. "How Does Enterprise Architecture Add Value to Organisations?" Communications of the Association for Information Systems , 28, 2011. DOI: 10.17705/1CAIS.02810
The Open Group / BIAN. TOGAF 与 BIAN 协作白皮书相关介绍：

https://blog.opengroup.org/2012/08/30/togaf-and-bian-a-strong-proposition-for-the-banking-industry/
人民网等关于中国联通「同舟 ERP」的报道：

http://finance.people.com.cn/n1/2026/0114/c1004-40645351.html
中国电信关于财司数智金融系统 / 「辰玑」相关公开报道，例如：

https://www.chinatelecom.com.cn/ct/news/jtxw/161366.html
国务院国资委网站转载：中国铁塔数字化建设与「五化」运营体系：

http://www.sasac.gov.cn/n2588025/n2588124/c30220496/content.html
中国信息通信研究院.《企业架构实践与创新观察报告》（含中国铁塔等案例观察）：

https://www.caict.ac.cn/kxyj/qwfb/ztbg/202602/P020260213391813440785.pdf
中国一汽「以业务单元为核心的 5A 架构」相关公开介绍（参考 TOGAF，扩展 BA/IA/AA/TA/SA）.

作者说明：本文面向知识分享与实践梳理。不同企业约束差异很大，请按规模、监管与组织能力裁剪。转载至 CSDN 时建议保留参考文献，便于读者核验。

企业架构的概念方法与实践