TOGAF EA®企业架构师认证备考

TOGAF EA 考试总复习笔记

〇、考试速览

• 分值大头：ADM 简介 + ADM 阶段 + ADM 指南技术 + 可交付成果 ≈ 20 题，是 L1 核心。
• L2 口诀：阶段要准、闭环要全、人要回应、人要全要协商。

一、核心概念与术语（L1 Unit1/2）

1. 企业与 EA 定义

• 企业：具有共同目标的、跨系统跨职能的复杂组织体（可含政府机构、公益组织、供应链伙伴），不限于商业公司。
• 企业架构目的：开发 EA 的唯一目的是为有效变革提供指导（规划变革 + 治理变革）。
  • 手段：as-is（现状）→ to-be（目标）→差距分析 gap→路线图 roadmap→ 变革项目。
  • Gartner 定义：创建/传达优化企业未来状态的关键原则和模型的过程。
• EA 关键益处：降本（能力共享）、更有效的战略决策、业务敏捷响应、投资聚焦、降低未来投资风险、采购更便捷、创建协调一致的环境（治理/管理/风险管控三重价值）。
• 架构 = 组件 + 组件关系；既指导变革又限制变革（防止随意变更）。

2. TOGAF 标准组成（易错考点）

• 基础内容（6 模块）：①介绍和核心概念 ②ADM ③ADM 技术 ④应用 ADM ⑤架构内容 ⑥EA 能力和治理。
• 系列指南（23 个，G 编号）：G184（EA 能力/领导者）、G186（从业者应用 ADM）、G20F（敏捷）、G18A（业务模型/商业模式）、G211（业务能力）等。
• 记忆口诀：念（概念）、法（ADM）、技（技术）、用（应用）、型（内容）、连（连续序列）、果（交付成果）、存（架构存储库）、治能（能力治理）。
• TOGAF 库是Open Group 架构库（OG 库）的组成部分。

3. 四大架构域（BAIT，高频考点）

根据 TOGAF 10 的安全架构与业务驱动原则，在B架构阶段处理涉及多国第三方生态和跨组织数据共享的安全风险时，最标准的建模与治理手段就是建立安全域模型（Security Domain Model）以及建立安全联合体（Security Federation）。

4. 架构抽象层次

背景（Why）→ 概念（What）→ 逻辑（How，技术中立）→ 物理（用哪些具体技术）。避免过早陷入技术选型。

5. 企业连续序列（Enterprise Continuum）

• 从抽象到具体的架构资产分类：基础架构 → 通用系统架构 → 行业架构 → 组织特定架构。
• 配套：架构连续序列（ABB，从抽象到具体）+解决方案连续序列（SBB）。

6. 架构存储库（L2 Unit8.5 记忆）

企业存储库 Enterprise Repository，实际实现/部署的知识，架构存储库是企业存储库内部的子集。

架构存储库：在运行良好的架构存储库中，所收集和维护的信息维持在最小限度。

1. 架构元模型（Architecture Metamodel）：定义架构的结构、元素类型、元素之间的关系，用来生成架构景观里的各类架构制品，不存放实例清单。
2. 参考库（Reference Library）：存放外部标准、行业规范、参考模型、产品资料等外部参考素材，非强制。
3. 标准信息库 Standards Information Base（SIB，标准库）：记录新架构必须强制遵守的标准。包含行业标准、指定供应商产品、组织内部共享服务、技术规范；架构评审时校验方案是否符合 SIB。参考库 = 参考建议；SIB = 强制标准。
4. 架构景观（Architecture Landscape）：企业当前（基线）/目标的业务、数据、应用、技术资产实例快照；包含正在使用的应用、系统、组件清单，描述企业现状资产。
5. 解决方案景观（Solutions Landscape）：存放落地的解决方案构件实例；赋能企业，交付业务成果；属于企业连续体概念，和架构景观成对。
6. 架构需求存储库（Architecture Requirements Repository）：存放全周期架构需求，作为企业的驱动因素，输入治理存储库。
7. 治理存储库（Governance Log）：企业架构治理活动的记录集合；包含架构决策、审批记录、风险、豁免 waiver、变更请求、评估记录。
8. 架构能力（Architecture Capability）：定义支撑架构存储库治理的参数、组织、结构、流程、角色，描述企业架构团队与治理能力本身。

精简版本：

1. 架构元模型：架构模板，定义构件结构
2. 架构景观：基线 / 目标架构实例快照（应用清单在这里）
3. 参考资料库：参考模型、最佳实践（参考，非强制）
4. 标准库 SIB：业务 / 数据 / 应用 / 技术强制标准
5. 解决方案景观：落地解决方案构件，交付业务成果
6. 架构需求存储库：战略、分段、能力需求
7. 治理存储库：决策日志、合规评估，向上汇报架构委员会
8. 架构能力：架构团队组织、技能、章程

良好运行的存储库：能管理版本/状态（草拟-已批准）、支持复用、最小化信息支持敏捷。

7. 内容框架与企业元模型

• 内容框架：为架构描述确立结构的分类框架（柜子）；顶层原则/愿景/需求，中层业务/信息系统/技术架构，底层实现。
  
• 企业元模型：元模型用于定义架构信息的结构和关系，以便以有序的方式组织和处理信息。它为不同类型的架构内容提供了标准化的分类和描述，确保能够满足利益相关者的需求。
  

8. 架构能力

企业架构能力指的是一个组织开发、使用和维护其架构的能力，能够有效地利用架构来管理和应对变更。这种能力确保企业能够灵活应对环境变化和内部需求。

• 架构能力：开发、运用、维护企业架构 + 治理架构变革的能力（≠业务能力"做生意"）。
  

9. 风险管理

• 风险（ISO 31000）：不确定性对目标的影响；风险管理 = 指导和控制的协调一致活动，闭环、全过程。
• 初始级别风险：确定和实施缓解行动前的风险分类
• 残余级别风险：实施缓解行动后的风险分类(如有)
  

9. 术语速记（Unit2）

应用架构、架构景观、架构模型、架构工件（制品）、业务架构、商业模式、能力、能力架构、数据架构、可交付成果、差距、元模型、建模、需求、角色、分段架构、利益相关者、战略架构、技术架构、过渡架构、工作包。

二、ADM 架构开发方法（L1 Unit3 核心 + L2 Unit3/4/5）

开发和管理企业架构生命周期的方法

1. ADM 总体特性

• 经测试、可重复的流程，通过迭代周期实现企业转型；以受控方式响应业务目标和机遇。
• 非瀑布式：是"表示基本信息流的程式化呈现"，阶段可裁剪、可跳跃、可并行（B/C/D 可并行）。
• 需求管理位于中心，与所有阶段双向连接，贯穿全程。
• 治理贯穿全周期（不限于 G 阶段）。
• 敏捷支持：架构作为护栏（guardrail）防止敏捷偏离战略；集成标准、安全要求为不可裁剪的优先事项。

2. 可交付成果状态

• 草拟：开发中、未经批准（0.1 版）。
• 已批准：经组织治理流程批准，≠最终定稿，F/H 阶段仍可修改（"获批≠终稿"高频考点）。

3. 架构范围 4 维度

广度（业务/组织覆盖）、深度（颗粒度）、时间区间、架构域。原则：大范围必浅、深层次必窄；子架构必须遵从上级架构。

4. 各阶段速查表（核心记忆）

5. A 阶段方法论（L2 重点）

A 阶段启动标准动作：识别干系人、关注点以及业务需求，定范围（解决什么问题），做评估（是否具备架构开发能力），出愿景。

• 一人：利益相关者（识别要全[利益相关者地图]、分类要科学[权力-利益矩阵]）、关注点、视角、视图、业务需求。
• 一特殊：产出战略架构（草拟的架构定义文档，颗粒度粗），架构工作说明书。
• 四定：定范围、定方案（架构工作说明书）、定愿景（口号+蓝图）、定沟通（沟通计划）。
• 三关键：共识是目标（业务场景法）、沟通是手段（视图/权衡）、转型做评估（业务转型就绪度评估A阶段初始评估→EF 规划→G 执行/残余风险）。
• 安全设计（3.3 记忆）：最终状态消除未知或不可接受的风险，在风险控制、合规要求、业务收益间平衡。

完成阶段A的必要条件: 关键利益相关者在总体目标以及实现目标所需的工作上达成共识

详细步骤：

1. 确立架构项目
2. 识别利益相关者、关注点和业务需求
3. 确认并详尽阐述业务目标、业务驱动因素和约束
4. 开展能力评估
5. 评估业务变革就绪度
6. 确定范围
7. 确认并详尽阐述架构原则，包括业务原则
8. 开发架构愿景
9. 确定目标架构价值主张和KPI
10. 识别业务变革风险和减缓措施
11. 开发架构工作声明并确保其获得批准

6. B/C/D 通用七步骤（L2 4.1 必背，强制性）

1. 选择参考模型、视角和工具（先看架构存储库里有什么）
2. 开发基线架构描述（与 3 可互换）
3. 开发目标架构描述（"恰好足够"原则）
4. 执行差距分析（识别遗留/淘汰/新增构建块，初步评估价值和工作量）
5. 定义候选路线图组件（注意"候选"字样只在 B/C/D）
6. 解决跨架构景观影响
7. 利益相关方评审 → 完成架构定义文档（容器）

• 口诀：“七步三入两出三安”：3 输入（工作说明书/架构愿景/上阶段草稿文档）、2 输出（架构定义文档 + 架构需求规范，均草稿，F 定稿）、3 安全（B 业务信任/C 应用数据安全/D 技术控制）。
• ABB 在 A–D 阶段创建（反映能力需求）；SBB 在 E 阶段创建（对应具体实现）；ABB 指导 SBB。
  

7. E/F/G/H 要点（L2 Unit5）

• E 阶段 找工作包、排路线、定优先级（三步骤）：

  1. 找方案、拆工作包：整合差距分析结果、确定解决方案、形成工作包。
  2. 排路线：工作包依赖分析、过渡架构设计、编排路线图。
  3. 定优先级：给工作包赋值业务价值 → 估算工作量/风险/迁移难度 → 排序 → 与相关方确认。
  • 每个工作包分配业务价值（5.7）：支持优先级排序与投资决策。
    

• F 阶段 （算、排、定、输、达）：

  1. 算收益：评估每个工作包的成本、收益、资源、工期、风险
  2. 排批次：敲定先后顺序、依赖关系，划分迁移批次（增量 / 大 bang 策略）
     • 增量：分批逐步上线，风险低
     • 大 Bang：一次性全部切换，风险高
  3. 定路线：定稿过渡架构、架构路线图
  4. 输出主交付物：定义文档、需求规范、路线图、实施和迁移计划
  5. 达成共识：和组织项目组合管理对齐、干系人达成共识，作为 G 阶段输入

E和F处理转型准备评估产生的行动

• G 阶段 （四手段两要点 ）：
  目标：监督实施，确保项目实施与目标架构的一致性；不亲自做开发实施，只做架构管控
  1. 签署、管理架构契约（Architecture Contract）【G 最核心产出】，架构团队 ↔ 实施交付团队
  2. 执行架构合规评审 Compliance Review，出具合规评估报告
  3. 管控偏离/豁免：偏差要么整改，要么走正式豁免（dispensation），重大偏差提交架构委员会裁决
  4. 收集实施信息，产出 SBB（解决方案构建块，是 ABB 的实际落地实物）
  5. 实施后复盘，更新 ADD、过渡架构文档
  6. 更新架构资源库、记录治理日志；产生变更请求（给到 H）

签契约、审合规、管偏离、收 SBB，复盘、更架构库
出现偏差先评审、考虑豁免，而不是直接改架构、发起新 RFAW。

• H 阶段 (两找一提两处里)（L2 Unit6）：
  1. 找问题：实施中发现架构缺陷、风险、业务/技术环境演进、架构不适
  2. 找方案：业务连续性需求、差距分析找解决方案
  3. 提变更：提出新的变更请求
  4. 处理审核：架构委员会评审审批
  5. 处理变更：简化决策 / 增量变更 / 重新架构；需评估影响并更新架构文档；重大变更触发新 ADM 周期。

• 需求管理（L2 Unit7）：
  • 输入：各阶段需求、变更请求、业务环境变化。
  • 步骤：评估影响→消除歧义→分级→优先级→排序→将结果传回各阶段→在架构存储库归档（与各阶段双向信息流）。
  • 输出目的：保证需求可追溯至愿景/战略，支撑各阶段一致决策。

三、ADM 技术（L1 Unit4）

1. 三者关系（4.1）

ADM 是核心方法；ADM 指南（应用指南）说明如何裁剪应用；ADM 技术是支持各阶段的具体工具方法。应用指导建议来自TOGAF 系列指南。

2. 架构原则 ——“一四四五”

• 一开发：企业架构师与需求方/干系人协同开发，架构委员会批准。
• 四目的：推动决策（打破平局，最重要）、对齐企业、确保治理、理解价值观。
• 四要素模板：名称（不用技术专有名词）、声明（明确无歧义）、理由（业务术语说明收益，说明与其他原则的关系）、影响（对业务和 IT 的要求）。
• 五特征：可理解、健壮、完整、连贯一致、稳定。

理解看用户、健壮看复杂、完整看覆盖、一致看冲突、稳定看变化。

3. 业务场景法（原型法，识别/澄清模糊需求）

PEVOA：Problem 问题、Environment 环境、Value stream 价值流（端到端闭环）、Outcome 结果、Actor 施动者（人员和计算机组件）。

4. 差距分析

差距分析主要目的是评估现有架构与目标架构之间的差距，特别是识别在目标架构中遗漏的功能或组件。这有助于确保架构的完整性与有效性。记录基线与目标架构差异：

• 目标有基线无 =新增
• 基线有目标无 =删除/淘汰
• 都有相同 =保留
• 都有不同 =改进
• 基线有但目标未考虑 =意外遗漏（重要考点）

产出支持工作量与成本估算、迁移规划。

5. 互操作性

三层：业务（共享业务流程）、信息（共享数据标准）、技术（系统集成方式）。贯穿 ADM：A 阶段识别交换需求→B 业务术语定义→C 应用/数据→D 技术→E/F COTS 决策。

6. 业务转型就绪度评估

• 维度：执行能力、治理/领导力、资源、变革意愿（金钱只是基础，能力与意识是关键）。
• 时机：A 阶段初步评估→E 阶段设计应对→F 阶段纳入计划→G 阶段执行减缓、考虑残余风险。

7. 风险管理（ADM 中使用位置）

风险管理的目标是优化业务结果，使业务价值最大化，业务损失最小化
A 阶段识别（风险评估工作单）→ E/F 阶段纳入规划 →G 阶段执行减缓，G 发现未减缓重大风险可触发新周期。

8. 架构权衡

符合架构愿景、原则与需求的目标架构往往不止一种。最重要的是确定替代目标架构和了解不同的可能性架，构师需要梳理各类备选方案，分析差异并开展权衡取舍。架构设计本身就是在各类相互冲突的影响因素间做平衡；向干系人展示备选方案与权衡分析，有助于挖掘隐含条件、原则和需求，从而优化最终目标架构。

四、ADM 应用 （L1 Unit5）

1. 指导来源（5.1 记忆）

TOGAF 系列指南（敏捷、业务能力、价值流、安全等专项）。

2. 迭代（5.2，四种）

迭代决策因素：范围广度、详细程度、时间区间、可利用架构资产。多项目 ADM 周期可共时并行、互相触发。

3. 架构景观 3 层级（5.3 记忆）+ 3 维度

• 战略架构（最粗，A 阶段产出，定方向）/分段架构（条线级）/能力架构（最细，E 阶段过渡架构、能力增量）。
• 3 维度立体模型：广度、深度（颗粒度）、长度（时间）。参考模型不属于架构景观。

4. 架构分区（5.4）

为便于开发和管理而分割的架构子集；反映企业运营模型，支撑团队分工与治理复用。反例：从 IT 视角而非业务切分导致系统越界冲突。

5. 架构项目 4 目的（5.5 记忆）

战略（端到端目标架构 + 3-10 年路线图）、谱系（项目组合 Portfolio/项目群，跨部门多阶段）、项目（单一项目交付）、解决方案（具体方案部署）。决定范围/广度/深度。

6. 数字化企业（5.6）

业务与 IT 高度融合、敏捷响应；架构提供可复用组件缩短周期 +护栏管控技术债；架构需求规范是敏捷开发的约束条件。

五、架构治理（L1 Unit6）

1. 概念

治理 =指导和控制组织的高层次决策过程（ISO/IEC 38500：指引并控制当前和未来状态的系统）。治理 ≠ 管理（具体执行）。

架构治理并非作为独立个体，而是在一系列分层级的治理结构内运行，特别是在大型企业中，下列不同领域可能均包括在内，各自具备相应规程和流程：
●公司治理
●技术治理
●IT治理
●架构治理

2. 三对象 + 三手段

对象：

1. ADM 过程：依据流程标准，对 ADM 过程进行治理的主要目的是确保该方法得到正确和一致的应用，这样可以保证架构开发的质量和有效性。
2. 架构本身：依据利益相关者需求，B/C/D 阶段差距验证；管控架构制品、基线 / 目标架构、架构原则，保证架构符合业务目标与标准库（SIB）要求。
3. 实施项目：依据架构契约 / 需求规范，监督项目落地遵从架构设计，管控实施中产生的架构变更请求，保障交付成果与架构对齐。

手段：

1. 合规性检查、2. 审查（正式会议）、3. 走查（非正式）。

3. 治理六益处（高频记忆）

纪律性、透明度、独立性、可问责性（Accountability）、责任性（Responsibility）、公平性

• 纪律性 (Discipline)：所有相关方承诺遵守组织建立的规程、流程与权力结构；
• 透明度 (Transparency)：所有执行行动及其决策支撑材料，可供授权组织和供应商核查；
• 独立性 (Independence)：所有流程、决策和机制的设计，最大限度减少 / 规避潜在利益冲突；
• 可问责性 (Accountability)：组织内可识别主体（治理委员会等）拥有授权，对其决策与行动承担后果；
• 责任性 (Responsibility)：各缔约方，需对组织及其利益相关方尽责履职；
• 公平性 (Fairness)：所有决策、流程及实施，不得为任何一方带来不公平优势。

六大特征是治理本身的属性（纪透独责可问责公平）；收益是做完治理之后得到的好处

4. 架构委员会

保证业务 / 数据 / 应用 / 技术各个子架构之间保持统一、不冲突。

• 预备阶段成立；成员代表全部关键利益相关方。
• 职责：保障子架构一致；识别复用构件；保障架构合规；批准架构产物；解决架构冲突；管控架构契约；分配架构任务；提升组织架构成熟度；架构变更决策的基础；提供决策上报通道。
• 无最终决策权——目标架构的决策权始终属于利益相关者（易错）。
• 豁免条件：CIO/利益相关者同意 + 不损害战略目标 + 后续补救或纳入新标准。

统架构，审合规，批产出，解冲突；抓复用，管契约，分任务，促成熟

5. 架构契约

• 定义：开发合作伙伴与发起人就架构可交付物、质量和适用性达成的（多方）协议。
• 多阶段产生：A 阶段（工作说明书）、B/C/D（外包合同）、G 阶段（实施合同，含 SLA）。
• 层级：架构蓝图 → 架构需求规范 → 合同条款。

6. 合规性

• 6 个符合度水平（记忆）：无关 Irrelevant → 一致 Consistent → 合规 Compliant → 符合 Conformant → 完全符合 Fully Conformant → 不符合 Non-conformant。
  • 一致 = 部分特性按规范实施；合规 = 实施的都涵盖在规范中但规范未全实施；符合 = 规范全实施但有额外特性。
• 两类清单：目标清单（架构治理，干系人批准状态）、实施及变更清单（项目治理，合规情况）。
• 审查目的：尽早发现并纠正错误、评估标准适用性、识别差距、向管理层汇报。执行者：架构职能部门提供视图，IT 治理部门/独立审计执行审查。
  

六、架构内容（L1 Unit7）

1. 核心四概念链（ISO 42010）

利益相关者 →（产生）关注点 →（决定）视角 →（产出）视图。

• 关注点：比需求粗的"主题"（安全性、集成性…），可细化为需求。
• 视角：创建和使用视图的角度（含角色、关注点、建模技术）。
• 视图：从一系列相关关注点对系统的呈现；向干系人展示"关注点已得到回应"。
• 架构师责任：保证完备性（回应所有干系人全部需求）和完整性（视图间相互印证、逻辑一致）。

2. 构建块（7.2）

• 定义：构建块(Building Block)为满足企业业务需求而定义的一套功能包，是可复用的架构组件；可与其他构建块组装，用来搭建架构与解决方案。
• 分为两类：ABB（架构构建块）：反映能力需求，A–D 阶段创建；SBB（解决方案构建块）：具体采购/开发实现，E 阶段创建。ABB 指导 SBB。

3. 架构制品（Artifacts）三类

目录（一维列表，如原则目录、流程清单）、矩阵（二维关系，如干系人映射矩阵、业务交互矩阵）、图形（可视化，如价值链图、流程图）。
一个可交付物 = 单个或多个制品的组合；只有合同约定的制品才成为可交付物。

4. 各阶段可交付成果（7.3 记忆，L1 高频）

• 架构工作要求书 RFAW（Request for Architecture Work）：是提需求，别人发给架构团队，发起请求、高层业务指令（预备 / A 阶段输入）
• 架构工作说明书 SAW：是定方案，架构团队输出，承诺交付的计划与约定（A 阶段输出、批准后正式启动）
• 架构愿景 Architecture Vision：讲蓝图，高层视角，未来目标长啥样、价值收益
• 架构定义文档 ADD（Architecture Definition Document）：长啥样，基线、过渡架构、目标架构长什么样（蓝图）
• 架构需求规范 ARS（Architecture Requirements Specification）：要满足啥、怎么验收，架构层面必须满足的硬性要求、验收准则
• 架构路线图 （Architecture Roadmap）：时间轴，按顺序展示架构增量 / 过渡版本的演进路线（高层看）
• 实施和迁移计划 Implementation and Migration Plan（IMP，F 核心产出）：落地执行明细：项目包、依赖、资源、风险、迁移策略（增量 / Big Bang）
• 架构契约 （Architecture Contract）：架构团队 和 实施交付团队（内部 / 外包）之间的正式约定，要求实施必须照着架构来做，约定合规、验收、权责

七、L2 专项：企业架构背景环境（Unit1）

• 有效变革是 EA 的目的（L2 版核心表述）。
• EA 形态 = 模型 + 组件 + 关系构成的景观；管理四种状态：当前（基线）、候选、过渡、目标——多状态管理必要性：支持渐进演进与治理决策。
• 架构师角色：帮助组织探索潜在方向（不是推销既定方案）；是干系人的代理人而非所有者；同时是风险管理者（促进权衡、消除风险）。
• 敏捷对齐：架构要求（集成、安全）作为护栏；架构对齐组织目标与价值。
• 企业安全架构：信息安全 + 风险管理两个不可分割的方面；安全是跨领域关注点（横切业务/应用/数据/技术四域）；各阶段安全关注递进：A 风险目标→B 业务信任→C 数据泄密→D 技术控制→E 解决方案→F 迁移分析→G 实施培训。
• 管理不确定性：最大化业务收益、降低损失（构建管理变革不确定性的环境）。
• 数字企业环境下架构师角色：从小（个人：沟通工具）到大（长青企业：完整 ADM + 架构能力）逐级演进。

八、L2 专项：利益相关者管理（Unit2）——“四要素一关键两要点”

• 四要素：利益相关者、关注点、视角、视图
• 一关键：架构权衡——用愿景/原则/需求定标准→生成备选→评估→选择或组合；在互不兼容的偏好间促成妥协（决策机制让干系人共同选择，而非架构师技术独断）。
• 两要点：权力、兴趣
• 配套工具：权力利益矩阵、RACI、利益相关者地图（使用这个工具就已经代表能全部识别利益相关方了）、沟通计划
• 权力 - 利益矩阵四类：重点管理、保持满意、保持告知、最小努力

九、L2 专项：风险管理

• 风险 4 步骤：识别、评估、缓解、监控
• 风险评估维度：可能性、影响
• 风险 4 应对策略：规避、转移、减轻、接受
• 工件：风险登记册
• 风险分类：业务风险、技术风险、项目风险、组织风险、合规风险
• 更新阶段：A-H 持续维护，重点 E/F/G

十、L2 专项：迁移四件套(E、F)

1. 实施因素矩阵（依赖、价值、风险）｜E 阶段
   作用：评估所有会影响落地的约束、风险、业务价值，是给工作包打分、排序的输入
   → 对应 E：赋值业务价值、评估风险难度
2. 差距解决方案和依赖关系矩阵｜E 阶段
   作用：合并 B/C/D 差距，把差距打包成解决方案、梳理依赖，生成工作包
   → 对应 E：整合差距、识别方案、拆工作包、依赖分析
3. 架构增量表（Architecture Definition Increments Table）｜E 初稿 → F 细化定稿
   作用：项目对应各个增量，每个增量产出什么架构成果
   → E 搭增量框架；F 把增量绑定时间、资源，放进 IMP 迁移计划
4. 架构过渡表（Transition Architecture State Evolution Table）｜E 初稿 → F 细化定稿
   作用：记录每一个中间过渡架构状态（保留 / 新增 / 替换）
   → E 设计过渡架构；F 固化到路线图

全部属于【迁移规划四大技术】，主产出在 E；F 做细化定稿

十一、L2 专项：架构治理

• 架构委员会：审批架构方向、原则、愿景
• Sponsor 架构发起人（高管）
• 架构原则特征：可理解、稳健、完整、一致、可实施
• 架构原则结构：名称、陈述、理由、影响

十二、L2 专项：架构存储库

架构元模型、架构资产库、架构库、参考库、治理记录

十三、L2 专项：架构工件 3 大类

目录 Catalogs、矩阵 Matrices、图 Diagrams

十四、L2 专项：L2 工具清单

业务场景法、差距分析、权力利益矩阵、RACI、CRUD 矩阵、风险矩阵、风险登记册、架构合规检查表、架构合同、迁移四件套、视点视图方法

十五、L2 专项：易混考点

架构委员会：审批方向原则；AIB：落地架构合规评审
过渡架构：中间临时状态
增量：分阶段交付架构包
视点≠视图
业务能力≠业务流程

十六、L2 情景题答题方法论（SPQK）

四步：

1. S 定阶段：判断情景处于 ADM 哪个阶段（“差距已批准→E”；“详细迁移计划制定中→F”；“实施中审查→G”；“架构跟不上业务→H”）。
2. P 定人员：识别全部关键利益相关者（含新收购方、预算控制者、上级架构方）。
3. Q 定问题：聚焦题干末尾问题（采纳度？风险？优先级？豁免？）。
4. K 对知识：映射考点（治理/干系人管理/权衡/迁移规划技术/合规豁免）。

满分选项特征（五分答案）：

• 阶段匹配（不超前做后续阶段的事，不无理回退）
• 闭环完整（识别→评估→缓解→监控；EF 规划 + G 执行）
• 人员全覆盖 + 多方协商共识（不是单方提交）
• 含关键构件（如 E/F 题必含过渡架构、依赖矩阵、工作包、价值/风险/工作量三要素评估）
• 回应利益相关者关切（安全、成本、时间）

低分选项特征：人员覆盖不全、仅技术视角、缺权衡框架、缺过渡架构、无协商闭环、阶段错位（A 阶段做试点、G 阶段才做规划等）。

豁免题套路：业务优先（CIO 明确指示 + 时间成本约束）→ 可豁免标准但须干系者批准 + 新旧标准共存 + 后续通过架构契约/培训/合规审查纳管。

预备：搭建架构环境、设立架构委员会、定义架构原则
A：项目启动、确定范围干系人、输出 SAW、审批架构愿景
B：梳理业务基线 / 目标、业务能力价值流、业务侧差距分析
C：数据、应用组件，应用和数据层面差距分析
D：基础设施、网络云平台、技术构件，技术差距分析
E：差距汇总完毕、识别解决方案、形成工作包、初步路线
F：编排依赖、划分迁移批次、确定增量 / BigBang、编写 IMP 实施迁移计划
G：落地实施过程、签署架构契约、合规评审、处理架构偏离 / 豁免、接收 SBB
H：系统已上线运行、持续监控、业务变化引发架构变更
需求管理：持续维护架构需求，贯穿全部阶段

频坑补充（L2 最爱考的易混短句）

• 有过渡架构构想、只是打包方案 → E
• 细化过渡架构、排上线顺序切换策略 → F
• 文档写完、准备给实施方遵守（草稿）→ F
• 实施的时候拿这个文档做审查、签契约 → G
• 项目落地期间的管控是 G；落地结束后长期迭代变更才是 H

十七、考前最后冲刺清单（高频记忆点）

1. 四架构域 = 业务/数据/应用/技术（BAIT）。
2. ADM 非瀑布，是信息流的程式化呈现；需求管理居中。
3. 获批 ≠ 终稿。
4. A 阶段输出：架构愿景 + 架构工作说明书 + 沟通计划（战略架构为草稿）。
5. "候选"路线图只在 B/C/D；路线图定稿在 F。
6. 过渡架构、SBB 首次出现在 E。
7. E 三种实施方法：重建/革命/演进。
8. F 优先级 = 业务价值 + 工作量 + 风险。
9. G 治理依据 = 架构契约 + 架构需求规范；手段 = 合规审查（6 级 + 豁免）。
10. 架构委员会无最终决策权；干系者是架构所有者。
11. 治理六益处：纪律/透明/独立/可问责/责任/公平。
12. 合规 6 水平：无关/一致/合规/符合/完全符合/不符合。
13. 架构存储库 7 组成；架构景观 3 层级（战略/分段/能力）+ 3 维度。
14. 架构原则"一四四五"；业务场景 PEVOA。
15. 构建块：ABB（A–D，能力）→ SBB（E，实现）。
16. 制品三类：目录/矩阵/图形。
17. 差距分析五种情形（含"意外遗漏"）。
18. 四种迭代：能力/开发/规划/治理。
19. 架构项目 4 目的：战略/谱系/项目/解决方案。
20. 指导建议来源 = TOGAF 系列指南。
21. E/F 迁移规划四件套：实施因素目录、综合差距解决方案依赖矩阵、架构定义增量表、状态演进表。
22. H 变更三处理：简化/增量/重新架构。
23. 有效开展架构活动需要建立企业架构能力，这包括组织结构、角色、职责、技能和流程的综合配置，以确保架构活动的高效执行。
24. 业务转型准备评估是一个协作过程，旨在确保不同部门之间的协调，以有效支持业务转型的目标
25. 业务原则、业务目标和业务驱动为架构工作提供背景，通过描述企业的需求和工作方式
26. 预备阶段的目的之一是确立架构能力，其中包括定义和确立架构治理的详细流程和资源。
27. L2 答题：阶段要准、闭环要全、人要回应、人要全要协商。