TOGAF 9.2 企业架构专业实践

1. 定位与适用边界

基于 The Open Group《TOGAF 标准 9.2 版》开展企业架构（Enterprise Architecture，EA）工作。将 TOGAF 视为一套可裁剪的企业架构框架，核心采用架构开发方法（Architecture Development Method，ADM）；不得将 ADM 机械地当作线性、一次性的项目瀑布流程。

适用于：

• 规划、裁剪、执行或审查 ADM 周期（预备阶段、A–H、贯穿式需求管理）；
• 编制或评审架构原则、架构工作请求书、架构工作说明书、架构愿景、架构定义文件、架构需求规约、架构路线图、实施和迁移计划、架构契约、合规性评估等交付物；
• 开展利益相关者、能力、业务转型准备度、风险、差距、需求影响、迁移规划等分析；
• 设计架构内容框架、企业连续统一体、架构分区、架构存储库、架构治理与架构委员会；
• 解释 TOGAF 9.2 术语、比较概念或开展认证学习。

不将本技能替代为：详细解决方案设计、软件需求规格说明、项目管理方法论、信息安全/数据治理/行业合规的独立方法论。涉及这些主题时，明确其与 TOGAF 的接口、约束和待补充的专业方法，不虚构 TOGAF 未规定的结论。

2. 权威性、证据与表达规则

2.1 证据层级

1. 以本技能 references/ 中基于 TOGAF 9.2 口袋书整理的内容作为 TOGAF 方法和术语的直接依据。
2. 将用户提供的战略、制度、流程、系统清单、访谈、数据、项目材料视作企业事实来源；逐项标注来源、版本与日期。
3. 将架构师判断、建议、假设、示例与企业已确认事实严格区分；不得把假设写成基线事实、把建议写成已批准决策。
4. 用户材料不足以支撑结论时，使用“待确认”“假设”“建议”标签，并列出需补充的最小信息集。

2.2 强制表达约束

• 首次使用关键术语时写明中文、英文及缩写；术语定义以 references/glossary.md 为准。
• 保持 TOGAF 四域顺序：业务、数据、应用、技术；阶段 C 必须明确区分数据架构与应用架构。
• 将“架构定义文件”表述为解决方案的定性视图，将“架构需求规约”表述为实施须满足的定量视图；两者须建立交叉引用。
• 区分架构构建块（Architecture Building Block，ABB，逻辑能力及架构描述）与解决方案构建块（Solution Building Block，SBB，特定实现）；SBB 首次在阶段 E 的具体产品/构件选择中出现。
• 区分 View（视图，呈现给相关关注点的架构表示）与 Viewpoint（视点，构建和使用视图的约定规范）。
• 不声称 TOGAF 强制某种建模语言、工具、供应商、产品或组织结构；需要时提出中立的选择准则。

3. 项目启动与需求分流

3.1 获取最小架构工作包

在开始实质性架构工作前，获取或显式记录下列信息；缺失时仅提出必要问题，其他项以“待确认”登记：

将该工作包转化为可追溯的“架构工作请求书/架构工作说明书”要点，分别对应预备阶段和阶段 A。详见 references/deliverable-templates.md。

3.2 按工作类型分流

4. ADM 专业工作流

加载 references/adm-phases.md，按 ADM 的目标、步骤、输入和输出组织工作。需求管理（Requirements Management）贯穿所有阶段并驱动回溯，不作为孤立的末尾步骤。

4.1 阶段编排

4.2 ADM 裁剪决策

先进行企业级裁剪，再进行项目级裁剪；不得直接删减阶段而不记录影响。对每项裁剪明确记录：

• 裁剪对象（阶段、活动、制品、视点、元模型扩展、治理关口）；
• 裁剪原因（范围、成熟度、速度、资源、监管、与既有流程接口等）；
• 保留的控制措施和风险；
• 适用边界、批准人及复审触发条件。

根据目标确定迭代策略：目标状态不清晰时优先基线优先；高层已就目标状态达成一致、且需避免将现状固化进目标时优先目标优先。涉及多层级或多团队工作时，明确战略架构、分段架构、能力架构的边界与上下游约束。

5. 架构内容与可追溯性控制

5.1 内容框架

加载 references/content-framework.md。按交付物（Deliverable）→制品（Artifact）→构建块（Building Block）的层次组织内容；制品使用目录、矩阵、图三种基本形态。根据利益相关者关注点选择视点，再产出相应视图；不要为“完整”而无目的地堆砌模型。

5.2 最小追溯链

对实质性架构工作，至少建立并维护下列链路；加载 references/deliverable-templates.md 中的追溯矩阵模板：

业务驱动因素 / 目标 → 利益相关者关注点 → 架构原则与需求 → 目标架构 ABB / 视图 → 差距 → SBB / 工作包 → 过渡架构 → 路线图与实施计划 → 合规性评估 / 价值度量

每条链路应具备唯一标识、责任方、状态、来源、版本/日期及依赖关系。若某项无法追溯，不把其作为已确认的架构决策或路线图承诺。

5.3 差距、构建块与迁移

• 在 B、C、D 和 E 阶段使用差距分析；区别“计划移除”“意外遗漏”“新增能力”。
• 在 A–D 阶段定义/选择 ABB，描述能力、属性、接口、互操作性、依赖和业务映射；在 E 阶段识别具体 SBB 及其与 ABB 的映射。
• 以工作包和过渡架构把差距转化为可执行增量；每个工作包说明业务价值、依赖、风险、资源/成本、验收度量与目标架构映射。

6. 交付物质量门禁

交付前执行与工作类型相适应的检查；缺项必须显式披露，不能以空泛语句掩盖。

6.1 通用质量门禁

• 范围一致性：范围、深度、时间段和架构领域与架构愿景/工作说明书一致；超范围内容已通过变更控制。
• 事实边界：企业事实、假设、建议、待确认项和示例分开标注，来源明确。
• 完整性与一致性：术语、域边界、对象命名、版本、模型间关系无矛盾；四域输出相互约束而不相互替代。
• 可追溯性：业务价值、需求、架构决策、差距、工作包、验收度量至少形成端到端链路。
• 可治理性：责任、审批、评审点、例外与变更处理方式明确。
• 可实施性：路线图有依赖、资源、风险、过渡状态、实施优先级和可测量的价值假设。

6.2 关键交付物专项门禁

7. 架构治理与能力建设

加载 references/capability-framework.md 与 references/enterprise-continuum.md。建立架构能力时至少界定：

• 组织模型、角色职责与决策权；
• 架构委员会的成员覆盖、授权边界、评审与升级机制；
• 架构原则、标准信息库、参考库和架构需求的维护责任；
• 架构存储库的八个构件：架构元模型、架构能力、架构景观、标准信息库、参考库、治理日志、架构需求存储库、解决方案景观；
• 合规性评审、架构契约、偏差特许、变更请求与经验反馈机制；
• 架构能力成熟度、资产复用、合规性、价值实现等度量指标。

8. Reference 索引

按任务加载，避免一次性载入全部材料：