简介这是一份围绕华为企业架构方法论的业务架构设计课件面向企业架构师、流程与IT规划人员以及数字化转型相关从业者帮助解决业务与战略脱节、部门壁垒与信息孤岛等问题。内容系统梳理了业务架构的定义与价值、TOGAF对业务架构的结构化解读并逐条展开战略驱动、反映业务本质、提升业务能力、促进业务集成、弱耦合组织架构、端到端信息贯通、稳定与持续改进等设计原则。设计过程部分则完整呈现价值流梳理、业务能力梳理、业务流程梳理、业务对象识别与关键要素梳理五个步骤配有企业级与专业级价值流图、业务能力框架、流程架构图、业务对象及指标清单等产出示例还涉及识别业务步骤风险点与制定控制措施。资源包内为1个pptx文件约2.98MB结构紧凑、页数集中适合直接用于汇报宣讲或培训讲解也是拆解业务架构设计思路、迁移到智慧城市等场景的参考范本。已有210人学习下载可作为从战略到执行的方法落地参照。1. 业务架构设计方法在企业架构里先解决哪件难事很多团队推企业架构习惯从应用系统和数据流画起结果业务部门看不懂、IT 部门落不了地评审会上两边各说各话。卡住的地方通常不在工具选型而是业务架构这一层没有被认真设计过。华为在企业架构实践中把业务架构摆在应用架构、数据架构、技术架构之前逻辑很直接业务能力决定系统边界价值流决定流程编排。业务架构设计方法要回答的就是三个问题——业务靠什么能力创造价值、这些能力由哪些流程承载、流程里的业务对象如何被系统支撑。做企业架构的架构师、做需求拆解的业务分析师还有被要求“先出一版架构蓝图”的 IT 负责人基本都绕不开这套方法。它适用的场景很具体战略方向已经定了但拆到部门就各自为政上系统之前想先看清业务全貌或者做数字化转型规划时需要一张让业务和技术同时认可的图纸。跳过业务架构直接进应用架构后面大概率要返工而且返工成本很高。这一章先把业务架构设计方法的定位说清楚后面几章分别讲价值流与业务能力怎么拆、流程和业务对象怎么建模、业务架构与应用架构怎么对齐以及交付前用什么方式验证。每步都会给出可执行的模板、参数和检查点。2. 用价值流和业务能力拆出业务架构第一版蓝图业务架构的第一版蓝图通常不是从组织架构出发而是从价值流和业务能力两条线交叉出来。常见做法是先用价值流把“客户从接触到获得结果”的全过程拉直再用业务能力地图把“企业需要具备哪些本事”分层列清楚。两条线交叉之后哪些能力支撑哪个价值阶段、哪些阶段存在能力空白一眼就能看出来。2.1 价值流识别从客户触点倒推业务阶段价值流识别的关键是切换视角。不要问“我们部门做什么”要问“客户从提出需求到拿到结果中间经历了哪些阶段”。华为业务架构实践里常见的价值流阶段划分一般控制在 5 到 9 个太多会碎太少会糊。我一般用下面这张表的字段来采集价值流阶段信息字段含义示例阶段编号价值流阶段顺序VS-01阶段名称动宾结构面向结果受理需求客户触点客户在哪个渠道感知线上门户关键输入进入该阶段的前置物客户申请单关键输出离开该阶段的产物受理确认单承载能力需要哪些业务能力需求受理能力支撑系统当前由哪些系统承载客户管理系统这张表填完之后容易出现两个问题一是某个阶段找不到承载能力说明能力地图有缺口二是某个阶段挂了三四个系统说明系统边界和业务阶段不对齐。两种情况都值得在架构评审前先标记出来。提示价值流阶段名称不要写成部门名比如“市场部阶段”就是典型的错误写法它会把流程视角重新拉回组织视角。2.2 业务能力地图的粒度控制与 L1/L2 分层业务能力地图的常见分层是 L1 和 L2。L1 是能力域比如“客户管理”“产品管理”“订单履约”L2 是能力项比如“客户信息维护”“客户分级”“客户流失预警”。L3 一般不再往能力地图里放而是落到流程和功能点里。粒度控制有个经验值L1 控制在 8 到 15 个L2 控制在每个 L1 下 3 到 8 个。超过这个范围通常是把流程步骤误当成了能力项。判断标准是——能力项应该是“企业持续具备的本事”而不是“一次性的动作”。比如“审批合同”是流程动作“合同管理能力”才是能力项。下面这段 Python 用来校验能力地图的分层覆盖度输入是一份 YAML 格式的能力清单import yaml from collections import defaultdict # 读取能力地图定义结构为 {L1: [L2, L2, ...]} with open(capability_map.yaml, r, encodingutf-8) as f: capability_map yaml.safe_load(f) issues [] for l1, l2_list in capability_map.items(): # 检查 L1 下 L2 数量是否在 3~8 之间 if not (3 len(l2_list) 8): issues.append(f{l1} 的 L2 数量为 {len(l2_list)}超出 3~8 的建议范围) # 检查 L2 命名是否包含动词含动词说明可能是流程动作而非能力 for l2 in l2_list: if any(v in l2 for v in [审批, 提交, 发起, 执行]): issues.append(f{l1} - {l2} 命名含动作词建议改为能力名词) if issues: print(发现以下问题) for i in issues: print( -, i) else: print(能力地图分层校验通过)这段脚本的逻辑是先加载能力地图再按两个规则检查L2 数量范围和 L2 命名。参数说明上3和8是建议阈值可以按企业规模调整但不要放得太宽否则校验就失去意义。动作词列表也可以按行业习惯扩充。2.3 用交叉矩阵定位能力空白把价值流阶段和业务能力放进同一张矩阵交叉点上标注“强支撑 / 弱支撑 / 无支撑”无支撑和弱支撑的格子就是能力空白或短板。这张矩阵不需要很精细重点是让业务和技术在同一张图上达成共识。矩阵里如果某个能力被超过 5 个价值阶段标记为“强支撑”说明这个能力是核心能力应用架构阶段要优先保障它的系统支撑。3. 业务流程与业务对象建模的可执行步骤价值流和能力地图解决的是“做什么”流程和业务对象解决的是“怎么做、靠什么数据做”。这两块如果建模不清晰到了应用架构阶段就会出现系统功能重复、数据口径打架的问题。常见做法是先把流程分级再从流程节点反推业务对象最后用模板把映射关系固定下来。3.1 流程分级的四层模型与命名规范流程分级一般分四层层级名称说明数量级L1流程域按业务领域划分8~15L2流程组域下的流程集合每域 3~6L3流程端到端可执行流程每组 3~8L4活动流程内的具体步骤每流程 5~15命名上L1 和 L2 用名词比如“订单管理”“订单履约”L3 用动宾结构比如“创建订单”“取消订单”L4 用动词短语比如“校验库存”“锁定额度”。这个命名规范的好处是从名字就能判断层级评审时不容易混。3.2 业务对象识别从流程节点反推实体业务对象不是拍脑袋想出来的而是从流程节点的输入输出里反推出来的。具体做法是遍历每个 L4 活动看它的输入和输出分别是什么名词同一个名词在多个活动里反复出现就说明它是一个稳定的业务对象。比如“创建订单”活动输入是“客户信息”“商品信息”输出是“订单”“校验库存”活动输入是“订单”“库存记录”输出是“库存校验结果”。这里“订单”反复出现就是核心业务对象。下面是一份 YAML 模板用来沉淀流程与业务对象的映射关系# process_object_mapping.yaml process: code: L3-ORDER-01 name: 创建订单 level: L3 activities: - code: L4-ORDER-01-01 name: 校验客户资质 inputs: [客户信息] outputs: [资质校验结果] - code: L4-ORDER-01-02 name: 校验库存 inputs: [商品信息, 库存记录] outputs: [库存校验结果] - code: L4-ORDER-01-03 name: 生成订单 inputs: [客户信息, 商品信息, 资质校验结果] outputs: [订单] business_objects: - name: 订单 source_activity: L4-ORDER-01-03 key_attributes: [订单号, 客户号, 商品编码, 数量, 金额] - name: 客户信息 source_activity: L4-ORDER-01-01 key_attributes: [客户号, 客户名称, 资质等级]这份模板的价值在于它把流程活动和业务对象绑在一条链上。后续应用架构做系统功能划分时可以直接按业务对象归集功能避免同一个对象被多个系统各维护一份。参数说明上key_attributes只放标识属性和关键业务属性不要把所有字段都塞进去否则模板会变重。3.3 流程与对象映射的三条检查规则映射填完之后用三条规则做快速检查第一每个业务对象至少要有一个活动负责创建它否则这个对象没有来源第二每个业务对象至少要有一个活动负责更新或消费它否则它是僵尸对象第三同一个业务对象如果被超过三个 L3 流程同时创建说明对象边界有问题需要拆或需要合并流程。这三条规则不需要工具在评审会上人工过一遍就能发现大部分问题。真正麻烦的是对象属性级别的冲突比如两个流程对“订单状态”的定义不一致这种要在业务架构阶段就统一术语表不能留到数据架构阶段。4. 业务架构与应用架构对齐时必调的参数业务架构做完下一步是和应用架构对齐。对齐不是把能力地图直接翻译成系统清单而是要在映射关系上做几轮收敛。收不收敛得住取决于三个参数映射粒度、交互点数量、以及能力覆盖阈值。4.1 能力-应用映射矩阵的填写规则能力-应用映射矩阵的行是 L2 能力项列是应用系统交叉点填“负责 / 参与 / 不涉及”。填写规则有三条一个 L2 能力只能有一个“负责”系统这是唯一性原则“参与”系统可以有多个但要有明确的数据流向或调用关系如果某个能力出现两个“负责”系统说明系统边界需要重新划分。下面这段 SQL 用来从映射表里查出违反唯一性的记录-- 查出同一能力被多个系统标记为“负责”的冲突记录 SELECT capability_code, capability_name, COUNT(*) AS owner_count, GROUP_CONCAT(system_name) AS owner_systems FROM capability_system_mapping WHERE mapping_type 负责 -- 只检查负责关系 GROUP BY capability_code, capability_name HAVING COUNT(*) 1 -- 超过一个负责系统即为冲突 ORDER BY owner_count DESC;逻辑说明先按能力分组统计每个能力被标记为“负责”的系统数量再用HAVING过滤出大于 1 的记录。参数说明mapping_type的取值要和映射表里的枚举一致常见取值是“负责 / 参与 / 不涉及”。这条查询建议在每次架构评审前跑一遍冲突记录直接进会议议程。4.2 流程-系统交互点的粒度选择流程和系统的交互点粒度太粗会导致系统职责不清太细会导致接口数量爆炸。我一般按 L3 流程来切交互点每个 L3 流程和系统的交互点控制在 3 到 5 个。超过 5 个说明这个流程被系统切得太碎要考虑合并系统功能少于 3 个说明流程和系统的耦合关系没梳理清楚。交互点上要标注三样东西触发方式人工 / 定时 / 事件、数据流向单向 / 双向、以及关键数据对象。这三样对齐了后面做集成设计时基本不会跑偏。4.3 常见错配与排查顺序业务架构和应用架构对齐时常见的错配有三类能力空白业务能力没有系统支撑、能力重叠多个系统做同一件事、能力错位系统做的事和能力定义不匹配。排查顺序建议是先查空白再查重叠最后查错位。空白是硬伤必须先补重叠是浪费可以通过系统整合解决错位往往是因为能力定义本身就不清楚要回到业务架构层重新对齐。注意不要在对齐阶段顺手改能力定义。能力定义一旦定了改一次就会连带影响价值流、流程和对象映射成本很高。发现能力定义有问题单独开一次业务架构评审改完再回到对齐。5. 业务架构设计方法的验证技巧与交付前检查业务架构交付前最怕的是“看起来完整用起来对不上”。我一般用三个动作做验证走查一条端到端价值流、做一次能力覆盖度统计、以及让业务方用自己的话复述能力地图。走查价值流时从第一个阶段走到最后一个阶段每个阶段的输入输出、承载能力、支撑系统都要能对上。中间任何一处断链都说明业务架构还有缺口。这个动作最好拉上业务方一起做因为很多断链只有业务侧才能发现。能力覆盖度统计可以用一个简单比例来看被至少一个应用系统“负责”支撑的 L2 能力数除以 L2 能力总数。这个比例低于 70% 时说明业务架构和应用架构之间还有较大鸿沟高于 90% 时要反过来检查是不是有系统在“假装支撑”也就是系统功能名对上了但实际能力没落地。最后一个技巧是术语表前置。业务架构阶段就要把核心业务对象的术语定义固定下来订单、客户、产品这些词在不同部门往往含义不同。术语表不用很长20 到 30 个核心词就够但每个词要有明确定义和所属业务对象。术语表定得越早后面数据架构和应用架构的返工越少。交付前把术语表、能力地图、价值流矩阵、流程对象映射这四份东西放在一起对一遍基本就能判断这版业务架构能不能往下走了。本文还有配套的精品资源点击获取