简介《华为4A企业架构设计方法论及实例》PPT面向企业架构师、数字化转型管理者及IT规划人员系统讲解业务架构BA、应用架构AA、数据架构DA与技术架构TA协同设计方法。内容基于华为CSG-EAF 2.0框架融合TOGAF 10与领域驱动设计DDD完整覆盖架构愿景制定、现状评估、目标设计、过渡规划与实施治理五阶段并包含供应链、客户服务中心等真实案例。包体为1个pptx文件大小6.77MB配有132类标准化架构制品清单。已有60人学习。通过本资源可掌握企业架构元模型与多视角视图体系理解“四维扫描法”及能力中心建模法并获取9个业务域、380个业务分子、1090条流程、10个数据域等完整EA基线图谱无论是战略对齐、中台建设还是微服务拆分均可从中获得可直接落地的架构设计参考。1. 4A架构不是四张图是一套设计秩序很多人第一次看到“华为4A企业架构设计方法论”这个标题以为是一套画图的规范或者是一堆架构文档模板。实际接触之后你会发现4A更像是一套设计秩序它解决的是企业架构设计里最让人头疼的问题业务部门讲不清楚需求开发部门听不懂业务数据模型和应用系统各做各的技术平台东拼西凑最后整个企业数字化建设变成一盘散沙。4A指的就是四个架构域业务架构BA、数据架构DA、应用架构AA、技术架构TA。这四个域不是并列的四张独立视图而是有一条清晰的设计主线贯穿其中业务架构定义“企业要做什么”数据架构定义“业务过程中会产生和依赖哪些数据”应用架构决定“用什么系统来支撑业务流程和数据流转”技术架构回答“这些系统部署在什么平台和基础设施上”。这条主线背后有一个底层逻辑叫“架构对齐”Alignment。每一层架构都必须是上一层架构的落地承接同时又为下一层架构提供设计输入。换句话说BA定了流程和业务对象AA才能知道要建哪些应用、每个应用管什么功能AA定了应用边界和数据交互TA才能去规划服务器、中间件和部署架构。反向也要成立——当技术架构选型发生变化时应用架构是否需要调整数据是否要迁移业务操作方式是否受影响这些都要能追溯得回去。这套方法论最有价值的点在于它把“架构设计”从个人经验驱动变成了流程和规则驱动。没有4A的时候架构师各画各的评审会上一问“这个系统为什么要拆成两个服务”得到的答案多半是“我觉得应该拆”。有了4A以后每一个应用组件、每一项数据实体、每一个技术组件都要求有上游输入、有归属、有边界评审变成了对齐检查而不是审美辩论。这篇文章就先从4A每个域的核心设计方法说起然后讲四个域怎么串成一条线最后用一个完整的实例把方法论落一遍。适合正在做企业数字化转型规划、准备做架构治理或者刚接手架构设计工作、想建立一套体系化打法的朋友。2. 业务架构BA先定义清楚“企业要做什么”业务架构是整个4A的起点也是绝大多数企业最容易糊弄过去的一层。一提到业务架构很多人第一反应是画组织架构图或者画业务流程图。组织架构表达的是“谁来做”流程图表达的是“按什么顺序做”但这两样都不等于业务架构。业务架构真正要回答的问题是企业到底在经营哪些业务能力这些能力之间什么关系每项能力承载在哪些业务对象上。2.1 业务能力拆解与业务组件识别华为4A方法里业务架构设计的核心动作是业务能力建模。第一步是把企业的业务按价值链从上往下拆拆到“业务组件”这个颗粒度。业务组件是业务能力的最小自治单元它有清晰的职责边界、有独立的业务目标、有明确的输入输出。举个例子一家制造企业的价值链可以拆成客户管理、产品研发、采购管理、生产制造、仓储物流、销售管理、售后服务、财务管理、人力资源。这只是第一层每个一级能力要继续往下拆二级、三级。比如生产制造往下拆可以拆成生产计划、物料齐套、车间执行、质量控制、设备管理。拆到某个颗粒度时你会发现这些能力已经可以被单独考核、单独优化甚至单独做成一个系统这个颗粒度就是业务组件。拆业务组件的核心原则是**“高内聚、低耦合”**和软件设计的思路很像。每个组件内部的业务活动强相关组件之间的交互尽量简单。这样拆出来的组件将来映射到应用架构时才不会出现一个应用包揽所有功能、或者一个功能被七八个系统重复实现的状况。在做能力拆解时我建议先用“业务流程反推法”做交叉验证。也就是把企业的主营业务流程从头到尾跑一遍每一步问这一步属于哪个业务能力这个能力有没有被遗漏流程走完以后再回头补能力地图的缺口。纯靠头脑风暴从零画能力图谱很容易漏掉那些平时不怎么显眼、但关键时刻掉链子的能力。2.2 业务对象数据架构的关键输入业务架构阶段最容易忽略、但对后续影响最大的产出物是业务对象的梳理。业务对象是业务人员日常操作中真正在“处理”的那些实体比如客户、订单、产品、物料清单、设备、员工、发票。业务架构不直接设计数据库表但必须把业务对象识别出来并且定义清楚每个对象从创建到消亡的完整生命周期。为什么业务对象这么重要因为它是业务架构和数据架构之间的桥梁。BA阶段识别出“订单”这个业务对象DA阶段才能围绕订单定义数据实体、属性的归属、数据的流向。如果BA阶段业务对象识别得不全DA阶段就只能靠数据团队自己猜猜出来的数据模型和业务实际就对不上。我记得有个项目客户做的是进出口贸易BA阶段只识别了“贸易合同”和“报关单”忽略了“税则归类”这个业务对象。结果DA阶段数据模型里没有税则维度后续做关税成本分析的时候数据怎么都凑不齐最后只能回过来补BA。所以业务对象这一关宁可多花时间不要图快。3. 数据架构DA把数据当作业务对象的一生来管理数据架构在4A中的位置很特殊业务架构定义业务对象数据架构定义业务对象的数据形态它俩是一一对应的关系。数据架构不是从技术角度设计数据库而是从业务视角回答企业有哪些核心数据域每个数据域包含哪些实体数据在业务流转中经历了什么变化谁产生数据、谁消费数据。3.1 数据域划分与核心实体建模数据域划分和业务组件划分是一套逻辑。业务组件是业务能力的自治单元数据域就是数据世界的自治单元。每识别一个业务组件就该顺着它去识别它主要管理的数据实体。比如采购管理组件对应的数据域就是供应商、采购订单、到货单、质检记录。生产制造组件对应的是生产工单、物料、设备台账、工艺路线。划完数据域以后要做的是梳理每个数据域的核心实体以及实体之间的关系。这一步不一定要到第三范式但要画出概念模型和逻辑模型。概念模型面向业务表达的是“一个客户可以下多个订单”这类业务规则逻辑模型开始向表结构靠拢把属性、主外键关系定下来。这里有一个实操经验数据实体命名的统一比想象中重要得多。很多企业数据倒腾不清楚一半的根因是同一个东西在不同系统里叫法不一样。CRM里叫“客户”ERP里叫“往来单位”B2B平台上叫“会员”数据架构阶段如果不强制拉通统一命名后期做数据集成和数据分析就是灾难。3.2 数据血缘与数据分布矩阵数据架构另一个核心工作是定义数据从哪来到哪去也就是数据血缘。实操中常用的工具是CRUD矩阵把前面识别的数据实体作为列把应用组件或业务流程作为行在交叉点上标C创建、R读取、U更新、D删除。这张矩阵画出来以后谁产生数据、谁修改数据、谁只读数据一目了然。CRUD矩阵最直接的作用是检测数据责任是否清晰。如果同一个数据实体有两个C说明有两套源系统各管一摊未来必然出现数据不一致。这时候要么合并数据源要么明确主数据归属。再往下做ETL设计、数据仓库分层时这张矩阵就是数据集成加工的索引没有它数据管道设计就容易全凭感觉。注意DA阶段不要陷入“建数仓”的思路。数据仓库是技术实现数据架构是业务数据规则的设计。数仓建得好不好取决于DA阶段数据域划分和实体关系是否准确。4. 应用架构AA系统边界不是拍脑袋定的应用架构是4A里最容易被感知的一层因为应用系统是业务人员真实在用的东西。传统的应用规划常常是“业务提需求IT做系统”最后做出一个单体巨石或者一堆重复造轮子的烟囱系统。AA阶段的目标不一样它要回答需要哪些应用系统每个应用的职责边界在哪应用之间如何集成如何做到不重复、不遗漏。4.1 从业务组件推导应用组件应用组件的识别方法非常简单直接一个业务组件原则上对应一个应用组件。因为业务组件是业务能力的自治单元把每个自治单元做成一个可独立部署、独立升级的应用组件业务能力和系统能力就能一一对齐。这就是为什么不建议在BA之前画应用架构图没有业务组件做输入应用边界就是拍脑袋定的。举一个实际的例子。某零售企业BA拆出“会员管理”“商品管理”“订单管理”“库存管理”“营销活动”“对账结算”六个业务组件AA阶段就直接映射成六个应用组件会员中心、商品中心、订单中心、库存中心、营销中心、结算中心。每个中心只管自己的业务组件域通过接口对外提供服务。系统之间的集成关系本质上就是业务组件之间的协作关系在技术层的投影。4.2 接口与集成方式的选择应用组件之间一定有数据交互AA设计里要明确交互方式。备选方案大致有三类一是服务调用适用于强实时、需要立即返回结果的场景比如下单时调库存中心锁库存二是异步消息适用于容忍延时、最终一致的场景比如订单完成后发消息给结算中心触发结算三是批量文件/数据同步适用于大批量、非实时的数据交换比如每晚把当天的订单数据同步到数据仓库。这三类方式没有绝对好坏但有一个原则要坚持接口契约必须由消费方和提供方共同评审不能用“先通再说”的方式边做边改。很多系统集成的坑都是接口定义不严谨——字段含义不清楚、超时时间没约定、异常处理没商量。AA阶段宁可多花一周把接口规格敲定也不要上线后花一个月联调扯皮。谈到系统拆分除了业务组件映射还有一个实际考虑因素是系统的变更频率和团队组织。业务组件相同但变更节奏差异大的通常拆开更合适。比如商品基础信息和商品价格看起来属于一个域但价格变更频繁、影响面大单独拆成一个价格服务发布风险就小得多。这属于AA设计中的经验判断不完全由BA决定。5. 技术架构TA所有上层架构的最终承重墙技术架构是4A里最“实在”的一层因为它直接落到服务器、中间件、网络、存储这些基础设施上。但要注意4A里的TA不是让你堆技术栈而是要回答现有的技术平台能不能支撑AA规划的应用架构计算、存储、网络资源如何布局应用组件部署在什么形态上5.1 技术平台与中间件设计应用架构里的应用组件按业务特征可以分为两类一类是稳态应用比如ERP、财务系统要求稳定可靠变更频率低另一类是敏态应用比如电商前台、营销活动要求快速迭代弹性伸缩能力强。这两类应用对技术平台的需求差异很大——稳态应用更需要数据库事务、消息可靠投递敏态应用更需要容器化、微服务治理、自动化发布。所以TA设计的第一步不是选型而是给应用分档。做完分档以后再决定是采用统一技术栈还是多技术栈并存。统一技术栈的好处是运维简单、人员技能通用坏处是“一把尺子量所有人”敏态业务会被稳态技术栈拖慢多技术栈并存灵活但对运维和人员要求高。中间件规划同理。常用的数据库、缓存、消息队列、注册中心、网关、日志平台哪些统一建设、哪些允许各团队自选TA阶段要有明确边界。我的建议是统建能力坚决统一避免遍地开花。业务团队自己部署一套Redis、一套Kafka看起来效率高长期看运维成本和维护负担是翻倍的。5.2 部署架构与资源规划部署架构层面核心是确定每个应用组件跑在哪里。传统做法是虚机部署一台物理机切多台虚机现在更常见的是容器化平台通过Kubernetes统一调度。架构设计时要结合应用分档敏态应用优先容器化稳态应用如果供应商不支持容器化就继续用虚机托底。资源规划要算三笔账容量、可用性、成本。容量方面按业务峰值估算应用组件的并发量、请求量再用**单机容量 × 节点数 ≥ 峰值流量**的公式去做水平扩展设计。可用性方面核心应用做多节点部署数据库做主备或集群避免单点故障。成本方面不同业务重要程度的应用分配不同规格的资源不要给内部管理系统也配生产级高可用集群。注意TA阶段最忌讳“追新”。技术架构的核心指标是匹配AA的需求不是为了用K8s而用K8s不是为了上微服务而上微服务。一套能稳定运行五年不推翻重来的技术架构胜过一套用了最新技术栈但半年一次故障的架构。6. 四层连贯看到“从业务到技术的一条线”前面四部分分别讲了四个架构域各自怎么做但很多项目即使每个域都做得像模像样最后交付的却是四套割裂的文档。BA画业务流程图DA画ER图AA画系统架构图TA画网络拓扑图四张图互相之间连不起来评审会成了各讲各话。这是4A实践中最普遍的问题。6.1 架构映射关系表要避免这个问题实操中最有效的工具就是架构映射关系表。这张表以业务组件为第一列后面依次列出该业务组件对应的数据实体、应用组件、技术组件。一行下来就能看到这个业务能力的数据落在哪、系统支撑是谁、跑在什么技术平台上。比如“库存管理”这个业务组件映射表可能长这样数据实体是库存余额、库存流水、盘点单应用组件是库存中心技术组件是库存数据库、库存服务容器、消息队列。一旦某个环节有缺失表格里对应的格子是空的评审时一眼就能发现。这张表也是后续做架构变更影响分析的底表——业务流程改一改顺着表就能判断哪些系统要改、哪些数据要迁移。6.2 设计规范与架构管控四层连贯有一个前提每一层都必须有明确的设计规范和评审规则。BA要有业务能力词典和业务对象命名规范DA要有数据域划分标准和实体命名约定AA要有应用组件命名规则和接口规范TA要有技术选型清单和部署规范。没有规范四个架构师可以画出四种风格的图连都连不到一起。规范定了以后配套的架构评审也很关键。评审的重点不是看图好不好看而是检查对齐关系这个应用组件对应的业务组件是哪个这个数据实体在BA和DA里的定义是否一致这个技术组件的选型在不在技术清单内评审通过的标准是映射关系表完整没有悬空项没有超出规范的自创。6.3 架构资产的持续维护架构设计不是一次性交付而是一个持续演进的动态资产。业务调整了、组织变了、系统改造了四层架构图和映射关系表都要跟着更新。我在实际项目中遇到最多的痛点是项目交付时架构文档是齐全的但半年以后就没人维护了再半年以后新来的架构师根本不敢信这些文档因为文档和现实已经对不上了。要解决这个问题没有特别取巧的办法只能靠把架构治理嵌入到项目流程里。开发需求评审时同步评审架构映射变更上线发布时同步更新架构资产定期做架构对账每周抽半小时把近期的变更合入架构全景图。沉没成本是有的但比起后期做架构梳理的返工成本这点维护成本低太多了。7. 实例推演用4A方法设计一套订单履约体系方法论讲再多不如完整走一个实例。下面我用一个简化但有代表性的场景把4A全流程串一遍。假设我们要为一家制造企业设计“订单履约”相关的企业架构目标是支撑从客户下单到交付完成的全过程。7.1 BA拆解订单履约的业务组件和业务对象先从业务架构开始。围绕“订单履约”这个一级业务能力按价值链往下拆二级组件客户下单、订单审核、生产排产、物料齐套、生产执行、成品入库、发货配送、签收确认。每一个二级组件继续拆三级比如发货配送可以拆成装车计划、运输调度、司机接单、送达回传。业务对象梳理跟随组件走下单环节有客户、销售合同、销售订单生产环节有生产工单、物料清单、模具、设备物流环节有出库单、装车单、运单、签收单。这些业务对象构成了订单履约的数据骨架后续DA就围绕它们展开。7.2 DA数据域、实体和CRUD分布把上面的业务对象归类成数据域订单域销售订单、订单行、订单变更记录、生产域生产工单、报工记录、物料消耗、库存域成品库存、在途库存、库存流水、物流域出库单、运单、签收回执。画CRUD矩阵时最核心的规则是“单一创建”。销售订单只能由订单中心创建生产工单只能由生产执行系统创建运单只能由物流系统创建。其他系统要读数据通过接口或数据同步获取不许绕开系统直接改库。这张矩阵确定了数据责任也为后面的集成方式定好了基调。7.3 AA应用组件与集成设计BA的组件映射出AA的应用组件订单中心管销售订单、生产执行中心管工单与报工、库存中心管成品库存、物流中心管配送。集成设计举两个典型场景。客户下单时订单中心调用库存中心的接口实时锁定成品库存这是同步服务调用订单审核通过后订单中心发一条“订单已确认”消息到消息队列生产执行中心订阅后创建生产工单这是异步消息。前者要求强一致后者允许短暂延时。接口契约在AA阶段定义清楚字段、超时、降级策略都在评审会上敲定。7.4 TA技术平台与部署设计应用分档后订单中心属于敏态应用容器化部署在Kubernetes集群上数据库用独立实例配置读写分离生产执行中心属于稳态应用考虑到PLC和数据采集设备的对接要求采用虚机部署数据库用主备模式物流中心涉及与外部承运商系统交互单独规划DMZ区部署中间件用队列做削峰。资源估算订单中心的峰值吞吐按双十一大促流量的8倍冗余设计节点数用“单节点QPS × 节点数 ≥ 峰值QPS”反推物流中心的运单回传流量具有明显的波峰波谷特征通过消息队列削峰资源可以比订单中心低一档。到这里一个订单履约体系的四层架构就全部打通了。8. 落地4A组织、流程与踩过的坑方法论和实例都讲完了最后说几个落地的实操心得。这些是从真实项目里总结出来的踩过坑才记得住。第一4A落地最大瓶颈不在技术在组织。业务架构需要业务部门深度参与光靠IT闭门造车做出来的BA一定失真。比较好的做法是组建联合工作组业务骨干和架构师坐在一起每周固定时间集中研讨。业务负责人不重视4A就走成形式最后变成写文档交差。第二架构评审要“吹毛求疵”但不能“一票否决一切”。常见的反模式是架构评审会上评审委员纠结于某个技术细节而否决整体方案。评审的核心是检查架构对齐和规范遵循至于某个应用是用Java还是Go只要在技术清单内就行。评审把控的是秩序不是口味。第三别指望一次把所有架构都设计完美用迭代的方式推进。推荐的做法是“先画主干再补枝叶”第一轮先把企业级的主价值链跑通把四个域的骨架搭起来映射表填到一级组件第二轮再逐条价值链细化到二级、三级组件同时同步细化数据模型和部署方案。架构作品质是迭代出来的不是一次画出来的。第四架构治理比架构设计本身更需要制度化。很多企业花大力气做了架构设计结果半年以后架构图就被抛之脑后了。问题就出在架构治理没有嵌入研发流程架构资产更新变成了“有空再说”的活。实践下来最有效的是把架构资产变更绑定到发布流程里发布审批时同步提交架构变更说明由架构师确认后方可上线。最后再分享一个工具层面的小技巧映射关系表最好用在线表格维护让业务、数据、应用、技术四类角色在同一张表上协作用不同颜色标识四层内容。相比四套独立的PPT一张可筛选、可追溯的活表格在架构评审和后续运维中好用得多这也是我和团队在多个项目里反复打磨后最终沉淀下来的工作方式。本文还有配套的精品资源点击获取