企业架构不是画几张系统图，更不是把所有应用摆在一张 PPT 上。它是一套将战略、业务、应用、数据、技术和治理机制连接起来的方法，让企业在复杂数字化建设中始终回答三个问题：为什么建、建什么、如何持续管住。
当企业系统数量增长、组织层级增多、数据散落在多个平台、项目由不同团队交付时，常见现象是：业务部门觉得系统不支持工作，IT 部门觉得需求永远说不清，数据团队苦于口径不统一，项目团队忙于局部交付，却没有人能说明系统之间如何协同、数据在哪里流转、技术为什么这样选、未来如何演进。《企业架构及典型设计方案》提出以“四横五纵”为核心的企业架构框架，通过业务架构、应用架构、数据架构、技术架构和架构管控五个维度，贯穿策略、管理、设计、实施四个层次，形成从总体规划到系统落地的统一语言和治理闭环。
本文基于该方案整理并扩展，系统讲清企业架构的核心概念、元模型与视图、四大架构设计主线、架构治理方法，以及一套可落地的建设路线。
一、先说结论：企业架构解决的不是“画图问题”
企业架构（Enterprise Architecture，EA）是一种结构化描述企业现状、目标状态和演进路径的管理方法。它将业务目标、组织流程、应用能力、数据资源、技术平台和治理规则连接起来，帮助企业在变化中保持整体协调。
企业架构的价值可以概括为五点：
- 战略可落地：将战略目标拆解为业务能力、应用建设、数据治理与技术投资。
- 建设不重复：明确能力边界、系统职责、数据归属与集成关系，减少重复投资。
- 数据能复用：统一数据主题、实体、标准和流转规则，降低口径冲突。
- 技术可演进：形成技术框架、集成模式、部署策略与基础设施标准。
- 项目可管控：让新项目在立项、设计、开发、验收和运行阶段遵从统一架构。
如果没有架构，企业会在“项目驱动”下不断增加系统；如果架构只停留在规划文档中，则会形成“图纸很漂亮、项目照旧做”的脱节。架构的真正价值，在于成为决策依据、设计约束和持续治理机制。
二、四横五纵：企业架构的总体骨架
方案提出“四横五纵”企业架构框架。四横是架构描述的层次，五纵是架构内容领域；两者组成一个从战略到实施、从业务到技术的矩阵。
1. 四横：按详细程度逐层细化
| 层次 | 关注重点 | 典型产出 |
|---|---|---|
| 策略层 | 全局性、整体性、目标性 | 战略目标、业务能力、应用全景、数据域、技术框架 |
| 管理层 | 关联性、可控性、资源统筹 | 流程体系、应用模块、概念数据模型、系统清单 |
| 设计层 | 可实现性、方案合理性 | 活动设计、功能设计、逻辑数据模型、组件与部署设计 |
| 实施层 | 可操作性、可配置性、可交付性 | 任务步骤、用例、物理数据模型、设备部署与配置 |
四横并不是简单的文档颗粒度划分，而是对应不同决策者：高层关注方向和投资，管理层关注能力与协同，架构师关注方案与标准，项目团队关注具体开发和部署。
2. 五纵：按内容领域分工协同
| 领域 | 核心问题 |
|---|---|
| 业务架构 | 企业要做什么，组织、能力、流程和岗位如何协同？ |
| 应用架构 | 哪些应用和功能支撑业务，系统边界与交互如何定义？ |
| 数据架构 | 有哪些数据资源，数据标准、模型、分布与流转如何设计？ |
| 技术架构 | 系统如何集成、部署、运行，技术平台和基础设施如何支撑？ |
| 架构管控 | 如何定义原则、标准、组织、流程和审查，保证架构落地？ |
企业架构最重要的逻辑是：业务决定应用需求，应用产生和使用数据，数据与应用依赖技术能力，管控体系保证所有建设活动遵从共同目标。
三、V 模型：自上而下设计，自下而上遵从
方案将四横五纵之间的关系概括为架构管理“V 模型”：一侧从战略目标逐步细化到系统设计和实施，另一侧从项目建设、系统研发和运行反向验证是否遵从架构。
战略目标 -> 总体架构 -> 分领域架构 -> 应用群设计 -> 系统设计 \ / \---- 项目建设、系统运行、遵从检查 ----/1. 自上而下：避免技术建设失去业务方向
从企业战略、业务目标和关键能力出发，逐步明确业务流程、应用能力、数据主题、技术框架和项目路线。这样能够避免“先买平台、再找场景”或“系统上线后才发现业务不需要”。
2. 自下而上：避免架构成为空中楼阁
项目实施、系统运行、数据质量、技术性能和用户反馈会暴露架构设计中的假设问题。架构团队应根据实践更新参考架构、标准、模型和路线图，而不是把架构当成一次性定稿文件。
3. 以遵从检查连接规划与项目
项目在立项、方案、采购、开发、测试、上线等关键节点应接受架构检查：是否复用了已有能力？是否新增重复系统？是否采用统一数据标准？接口是否符合规范？是否满足安全、性能、部署和运维要求？没有这一机制，架构很难对项目产生约束。
四、元模型：企业架构的“词典和结构”
方案强调：元模型是企业架构的词典，也是企业架构的结构。它定义架构元素及元素之间的关系，使参与者使用同一套概念，并让架构信息以结构化方式保存。
1. 为什么企业需要元模型
不同部门对“流程”“功能”“系统”“数据”“服务”“接口”等术语常有不同理解。比如，有人把“采购管理”称为系统，有人称为模块，有人称为业务流程。没有统一定义，架构讨论会陷入语言混乱，工具和成果也无法关联复用。
元模型统一定义：
- 架构元素是什么，例如业务域、业务流程、应用、功能、数据实体、系统、组件、接口、部署节点。
- 元素属性是什么，例如责任部门、生命周期、重要等级、数据分类、技术标准、版本状态。
- 元素之间如何关联，例如业务流程由哪些活动组成、应用支撑哪些业务能力、功能操作哪些数据实体、系统部署在哪些节点。
2. 元模型带来的直接收益
统一元模型后，企业可建立架构资产库，并自动生成不同视角的图表；还可进行影响分析，例如某数据实体变更会影响哪些应用、某系统下线会影响哪些业务流程、某技术组件存在漏洞会波及哪些服务。
3. 元模型不宜一开始过度复杂
最小可行元模型应优先覆盖高频对象：业务能力、流程、组织、应用、功能、数据主题、数据实体、系统、接口、技术组件、部署节点和标准。随着架构成熟度提升，再扩展风险、成本、性能、项目、供应商和生命周期等属性。
五、架构视图：企业架构的“图纸和表达”
如果元模型是结构化的后台数据，架构视图就是面向不同对象的可视化表达。方案指出，视图以规范化方式展示架构元素及关系，可通过工具自动生成。
1. 一张图不能解决所有问题
领导需要看能力全景和投资路线，业务负责人需要看流程和职责，应用架构师需要看系统边界和交互，数据团队需要看数据模型和流转，运维团队需要看部署与基础设施。因此，架构图必须“因人而异、因事而设”。
2. 好视图的三个标准
- 目的明确：一张图应回答一个核心问题，例如“哪些系统支持采购流程”。
- 元素规范：图中的对象、连线、颜色、层级和命名遵循统一规则。
- 可以追溯：图上每个元素都能关联到资产库、责任人、标准、项目或详细设计。
3. 视图不是画图工具的产物
用 Visio、PPT 或建模工具都可以画图，但只有基于元模型、标准格式和持续维护的视图，才是企业架构资产。否则图纸很快过期，无法用于决策和治理。
六、业务架构：先搞清“企业要做什么”
方案将业务架构划分为业务能力视图、业务管理视图、业务流程图、业务活动图和业务任务图。业务架构不是部门组织图的翻版，而是描述企业价值创造方式和业务运作逻辑。
1. 业务域与业务职能：描述企业能力地图
业务域是按价值链和业务相关性聚合形成的高阶领域，例如规划计划管理、财务管理、营销管理、生产管理、采购管理和人力资源管理。业务职能则是每个业务域中企业应具备的具体能力，如预算管理、会计核算、综合计划、供应商管理等。
业务能力地图应保持相对稳定。组织可以调整，系统可以更换，但“企业需要具备哪些能力”通常更具长期性，因此适合作为战略和数字化规划的共同语言。
2. 业务流程：描述跨部门协作
流程连接组织、职责、信息和活动。方案列举了端到端流程、跨职能流程和子流程，例如从采购到付款、招标采购等。流程设计要避免只画部门内部步骤，而要识别从触发到交付的完整价值链。
3. 业务活动与任务：连接业务和系统设计
业务活动是流程中的关键节点，具有明确输入、输出、责任组织和开始结束条件；业务任务则是活动的进一步分解，例如“确认比价细则”。业务活动与任务层的设计，可直接衔接应用功能、角色权限、数据实体和系统用例。
4. 业务需求分为功能与非功能两类
功能需求描述系统要做什么，如计划编制、审核、分解与下达；非功能需求描述系统应达到的质量属性，如安全性、响应时间、并发量、可靠性和可用性。很多项目失败不是功能缺失，而是忽略性能、安全、可维护和体验等非功能要求。
七、应用架构：不是系统清单，而是业务能力的数字化承载
方案中的应用架构包括应用视图、应用模块视图、应用交互视图、应用组织分布视图、应用系统分布视图、应用功能视图、应用功能交互视图和应用用例视图。
1. 应用域、应用、模块、功能要分层
- 应用域：按业务耦合度聚合的应用群，如财务管理、物资管理、人资管理、生产管理。
- 应用：支撑一个业务目标的功能逻辑组合，如综合计划管理应用。
- 模块：应用内相对独立的功能集合，如采购管理、合同管理。
- 功能：可被用户或系统调用的最细业务逻辑，如发标管理、开标管理、评标管理。
- 用例：角色在特定场景下使用功能的具体方式，直接服务开发与测试。
这种分层可以防止把系统名称、业务功能、组织职责混为一谈。
2. 应用架构设计的核心是边界
每个应用要回答：它负责什么、不负责什么；它服务哪些业务能力；它拥有哪些功能和数据；与哪些应用交互；谁是责任部门；未来是保留、改造、替换还是下线。边界不清会导致重复建设、数据重复维护和接口混乱。
3. 交互必须定义业务语义
应用间接口不能只写“调用 API”。应明确源功能、目标功能、交换的数据实体、触发时机、处理规则、异常机制、时效要求与责任人。例如招投标系统向采购系统发送招标申请，采购系统返回中标结果，这才是可治理的业务交互。
4. 组织与系统分布反映管控模式
总部、省级、地市或分子公司的功能分布，反映集中管控与属地执行的边界。应用架构应支持“哪些功能统一建设、哪些功能本地使用、哪些数据集中管理、哪些需要本地采集”的治理决策。
八、数据架构：让数据从“系统附属品”变成企业资产
方案将数据架构划分为数据主题域视图、主题域关系视图、概念数据模型、数据流转视图、逻辑数据模型、数据分布视图和物理数据模型。
1. 数据域与数据主题：建立业务数据地图
数据域通常与业务域对应，例如财务、物资、生产等；数据主题则是更具体的业务对象集合，如采购、合同、客户、供应商。通过主题域划分，企业可明确数据责任、数据标准、共享范围和治理优先级。
2. 数据实体：业务信息的规范化表达
采购合同、采购需求、设备基础信息、设备缺陷、设备修试记录等都属于数据实体。数据实体不是某个数据库表，而是对业务对象的统一逻辑定义。只有先统一实体含义，才能让不同系统的数据实现一致交换和共享。
3. 概念、逻辑、物理模型各司其职
| 模型层次 | 关注内容 | 主要使用者 |
|---|---|---|
| 概念数据模型 | 有哪些实体，实体之间有什么关系 | 业务人员、数据治理人员、架构师 |
| 逻辑数据模型 | 属性、主外键、继承关系、范式设计 | 数据架构师、系统分析师 |
| 物理数据模型 | 表、字段、类型、索引、分区和存储实现 | 数据库工程师、开发和运维人员 |
逻辑模型通常追求低冗余和清晰关系；物理模型则需要在规范性与性能之间平衡，不能机械地把范式要求直接套到所有高并发场景。
4. 数据流转与 CRUD 是治理关键
数据不仅要定义“是什么”，还要明确“从哪里来、流向哪里、谁创建、谁读取、谁修改、谁删除”。通过应用间数据流转视图和功能—数据 CRUD 矩阵，可发现重复主数据、无主数据、越权修改和不必要的数据复制。
九、技术架构：支撑系统长期稳定、集成与演进
方案将技术架构分为两条主线：一条围绕技术框架、信息系统、组件、接口、集成和系统部署；另一条围绕基础设施概念、逻辑和物理视图。
1. 技术域与技术能力
技术域可包括开发、信息展现、集成服务、数据资源、安全服务和基础设施等；技术能力包括结构化数据存储、文件存储、内容管理、应用集成、日志处理、身份认证和监控告警等。
技术架构不应从某个厂商产品开始，而应先定义企业需要的公共技术能力，再选择可持续演进的产品与服务。
2. 系统、软件与组件的层次
- 系统：由软硬件组成，分为业务应用系统和公共平台系统，例如 ERP、PMS、企业服务总线。
- 软件：系统软件、应用软件和中间件。
- 组件：应用组件、接口组件、公共组件和平台组件，例如资产台账组件、日志组件、错误处理组件。
组件化的价值在于把可复用能力沉淀为资产，降低重复开发和维护成本。
3. 集成场景要区分集成类型
方案指出集成可分为界面集成、应用集成、数据集成和流程集成。不同场景应选择不同模式：
- 界面集成适合简单跳转与统一门户，但不应依赖页面抓取。
- 应用集成适合实时服务调用，如查询、校验、提交。
- 数据集成适合批量同步、数据仓库和主数据分发。
- 流程集成适合跨系统审批、协同任务和端到端业务编排。
企业应统一接口标准、服务目录、消息规范、版本策略、错误码和安全认证方式，避免形成“烟囱式接口”。
4. 部署架构决定可靠性与可运维性
部署单元是可独立部署的软件包，部署节点是应用服务器、数据库服务器、客户端等最小运行实体；位置则描述数据中心、机房、机柜等物理空间。部署设计需综合可用性、性能、扩展性、安全、容灾、网络延迟、成本和运维能力。
十、架构管控：没有治理的架构，最终都会失效
方案把架构组织、架构资产、架构遵从、能力建设、培养沟通和架构工具列为管控重点。架构管控的目的不是增加审批，而是让企业在持续变化中仍能保持一致性。
1. 架构组织：明确谁决策、谁设计、谁执行
典型组织可包括信息化领导小组、企业架构委员会、总部信息部门、业务部门、分子公司信息化组织、专项设计组、统推项目组和实施团队。
- 高层委员会负责方向、原则、重大投资与跨部门冲突决策。
- 企业架构团队负责方法、标准、蓝图、资产与审查。
- 业务部门负责业务目标、流程确认和业务规则。
- 项目团队负责方案设计、开发交付和遵从证明。
- 运行团队负责系统稳定性、技术债务和运行反馈。
2. 架构原则是取舍依据
常见原则包括业务价值优先、数据共享复用、能力服务化、标准优先、安全内建、云原生或平台优先、最小化定制、可观测与可运营等。原则必须能指导真实决策，例如新项目是否允许自建主数据、是否必须接入统一身份、是否必须复用集成平台。
3. 架构资产要版本化管理
能力地图、流程图、应用清单、系统关系、数据模型、接口目录、技术标准、参考架构、部署图和项目遵从记录都应纳入架构资产库。每项资产应有责任人、版本、生效范围、更新机制和关联关系。
4. 架构遵从检查应嵌入项目流程
建议在以下节点实施架构审查：
- 立项：是否符合战略与能力规划，是否存在重复建设。
- 方案：是否遵从业务、应用、数据、技术和安全标准。
- 采购：产品选型、接口、数据迁移和部署是否符合目标架构。
- 上线：是否完成接口登记、数据标准、监控、备份、权限和文档交付。
- 运行：是否存在架构偏差、技术债务、性能瓶颈和数据质量问题。
十一、参考架构与典型设计：把经验固化为可复用模板
方案将参考框架、参考领域及模式、参考架构及典型设计、软硬件资源目标架构作为 R1 到 R4 的管控资产。其目的，是减少每个项目从零设计的成本。
1. 参考框架提供统一骨架
例如四横五纵、分层架构、分域模型、项目交付物清单和治理流程。它告诉团队“需要考虑哪些方面”，但不直接规定所有技术细节。
2. 架构模式提供常用解法
例如统一身份认证模式、主数据管理模式、API 集成模式、事件驱动模式、数据湖仓模式、微服务治理模式、高可用部署模式和灾备模式。模式应包括适用条件、关键设计、优缺点与反例。
3. 典型设计提供可执行样例
例如采购管理应用群的模块划分、供应商数据模型、ERP 与招投标系统的集成场景、应用服务器与数据库的部署方案。典型设计可加速项目启动，但必须允许按实际业务裁剪，而不是生搬硬套。
十二、从零建设企业架构：一条可落地的路线
阶段一：明确战略与范围
识别企业战略目标、核心业务问题、数字化重点、组织边界和架构治理范围。不要试图在第一期覆盖全部业务，可优先选择投资大、痛点强、跨部门协同复杂的领域。
阶段二：建立最小元模型和架构语言
统一业务域、应用、功能、数据实体、系统、接口、技术组件等关键定义；建立命名规则、分类体系、关系规范和模板，确保业务、IT、数据和项目团队能使用同一语言协作。
阶段三：完成现状架构盘点
梳理业务能力、流程、系统、数据、接口、基础设施、项目和痛点，形成应用资产清单、数据资产清单、技术资产清单和风险清单。现状不清，目标架构容易脱离现实。
阶段四：设计目标架构与路线图
围绕战略能力设计目标业务、应用、数据和技术架构，识别保留、整合、改造、新建和下线的系统，明确数据治理、集成平台、云资源、网络安全和人才能力建设路径。
阶段五：建立管控机制并试点
选择一个业务域或应用群试点，将架构审查嵌入项目全生命周期，沉淀参考架构、标准、模板和检查清单。试点成功后再逐步扩展到全企业。
阶段六：持续运营与迭代
架构团队应定期更新资产、评估项目遵从、治理技术债务、复盘架构偏差，并依据业务战略和技术趋势调整目标架构。企业架构不是项目，而是一项长期管理能力。
十三、一个实战例子：采购数字化如何用四架构协同设计
以“招标采购”场景为例，若只从系统功能出发，容易做出一套孤立的采购系统；用企业架构方法则可形成端到端设计。
1. 业务架构
定义从采购计划、需求提报、招标、评标、定标、合同、订单、收货到付款的端到端流程；明确采购、财务、业务部门、供应商和审批人的职责、输入输出与关键控制点。
2. 应用架构
划分采购计划、招投标、供应商管理、合同管理、订单执行、库存协同和支付对账等模块；明确 ERP、电子招投标平台、合同系统、供应商门户之间的功能边界与交互。
3. 数据架构
定义供应商、采购需求、采购项目、招标文件、评标结果、采购合同、订单和物料等核心数据实体；确定主数据归属、共享规则和数据流转，避免供应商信息在多个系统重复维护。
4. 技术架构
设计 API 或消息集成，统一身份认证和电子签章能力，规划应用服务、数据库、文件存储、日志审计、监控告警与容灾部署，确保系统安全、性能和可运维。
通过四架构协同，采购系统不再只是一个项目，而成为支撑企业采购能力、数据治理与风险控制的长期平台。
十四、最常见的十个误区
- 把企业架构等同于系统架构。企业架构必须以业务和战略为起点，系统架构只是其中一部分。
- 一次性追求全量建模。应从关键领域、核心资产和高价值场景开始，逐步扩展。
- 只画图，不建元模型。没有统一词典、元素关系和资产库，图纸无法复用和维护。
- 只做目标蓝图，不盘点现状。忽视现有系统、数据和组织约束，目标架构难以落地。
- 业务架构照搬组织架构。组织会变，能力和价值链更稳定，应以业务能力与流程为核心。
- 应用架构只列系统名称。必须明确系统能力边界、数据归属、接口关系和生命周期。
- 数据架构只做数据库设计。数据主题、标准、主数据、流转、责任与质量同样重要。
- 技术架构只谈产品选型。技术架构首先定义能力、模式、标准、集成与部署原则。
- 架构审查变成形式审批。审查必须提供可执行的改进意见，并与项目决策和验收挂钩。
- 认为架构由 IT 单独负责。业务、数据、技术、安全、财务和管理层都应参与架构治理。
十五、衡量企业架构是否有效
| 维度 | 参考指标 |
|---|---|
| 业务协同 | 关键流程端到端覆盖率、跨部门流程周期、业务能力缺口关闭率 |
| 应用治理 | 重复系统减少率、应用边界清晰率、系统整合率、复用能力使用率 |
| 数据治理 | 主数据一致率、关键数据标准覆盖率、数据共享复用率、数据质量达标率 |
| 技术治理 | 标准技术栈采用率、接口规范遵从率、关键系统可用性、技术债务趋势 |
| 项目遵从 | 架构审查覆盖率、重大偏差闭环率、项目复用率、上线架构资料完整率 |
| 运营成效 | 架构资产更新及时率、架构决策响应时效、项目交付风险降低情况 |
不要以“画了多少张图、建立了多少目录”作为唯一成果。真正重要的是，企业是否减少重复建设、缩短项目交付、提高数据一致性、改善系统协同，并能更快响应战略变化。
结语：企业架构的本质，是让复杂性可控
随着企业数字化不断深入，业务、组织、系统、数据和技术之间的依赖会越来越复杂。企业架构提供的不是一份静态蓝图，而是一套共同语言、结构化资产和持续治理机制：用业务架构明确价值创造方式，用应用架构定义数字能力边界，用数据架构沉淀核心资产，用技术架构支撑稳定演进，用架构管控保证设计真正落地。
“四横五纵”的价值，在于既能从战略层看全局，也能下钻到系统、数据表、接口与部署节点；既支持自上而下的规划，也支持自下而上的项目遵从与反馈。企业只有把架构嵌入投资决策、项目交付和运行运营，才能从“系统越建越多”走向“能力持续复用、数据持续增值、技术持续演进”。
本文基于《企业架构及典型设计》整理并做通用化扩展。实际企业架构设计应结合行业特点、组织规模、既有系统、云化程度、数据治理成熟度和业务战略进行裁剪。
