【TOGAF系列】总结TOGAF从业级核心内容

1. 企业架构的背景环境

   1. 为有效变革提供指导：企业架构的目的
      1. 为有效变革提供指导
         1. 开发企业架构（EA）的唯一目的很简单：为有效变革提供指导
         2. 将获得批准的EA付诸实施的活动过程中为有效变革提供指导
         3. 在实施过程中，利益相关者运用EA治理变革
      2. 企业架构如何为有效变革提供指导
         1. 架构途径提供严谨的计划和变革管理方法论
         2. 企业架构促进有效治理、管理、风险管理和机会的挖掘
         3. 描述企业的未来状态和当前状态
         4. 企业未来状态和当前状态之间的差距突出了必须实施的变革
   2. 企业架构以怎样的形式存在？
      1. 企业架构以怎样的形式存在
         1. 企业架构（EA）是一系列模型、组件及相互间的关系，这些要素构成了所涉及的EA景观范围
         2. 企业架构旨在指导和限制变革计划以及实现变革的工作
         3. 架构工作请求中的工作范围应当明确适用的EA景观特性
      2. 模型
         1. 模型持续描述当前架构及目标架构
         2. 模型的首要目的是帮助架构师理解所研究的系统
         3. 次要目的是复用
   3. 架构能力
      1. 架构能力（亦称EA能力）
         1. 为在组织中有效开展架构活动，需要通过组织结构、职责、技能和流程，将恰当的架构业务能力落实到位
         2. EA能力即开发、运用和维护具体的企业架构，并运用架构治理变革
         3. 此处的EA能力是一个管理学概念，“有助于作出改善计划，以提升开展能够达成更优结果的活动的能力”
      2. 四个目的的EA能力模型
         1. 支持战略的架构
         2. 支持谱系的架构
         3. 支持项目的架构
         4. 支持解决方案的架构
   4. 架构治理及企业架构师的角色
      1. 治理
         1. ISO/IEC 38500:2015将治理定义为“一个指引并控制当前和未来状态的系统”
         2. 治理是一个决策过程，以确定的关系结构来指引并控制企业，从而达成所声明的目标
      2. 架构治理及企业架构师的角色
         1. 企业架构师必须治理并支持以下两项活动，二者彼此不同
            1. 目标架构的开发
            2. 目标架构范围内的所有变更
      3. 企业架构师的角色
         1. 企业架构师通过治理目标架构开发来支持组织领导者的指引和控制
         2. 通过治理目标架构范围内的所有变更，能够形成合适的目标，在可能实现的前提下为组织开发最佳路线
         3. 通常情况下，企业架构师和实施者接受指引，并且二者均受利益相关者的控制
   5. 架构合规性、符合性水平、审议及架构师的角色
      1. 架构合规性
         1. 确保各个项目与企业架构相符是架构治理的重要方面
         2. 这通常包括两个互为补充的流程：
            1. 架构职能部门须准备一系列项目架构
            2. 企业和IT治理职能部门将确定一个正式的架构合规审查流程，用于审查全部项目与企业架构的相符情况
      2. 符合性水平
         1. 架构与实施之间的关键关系之一在于“符合”、“一致”等词语的定义
         2. 不同组织的术语使用情况可能有所不同，但以下6种符合性水平概念对制定IT合规战略应当有所帮助：
            1. 无关：实施与架构规范不具备共同特性（因此不涉及到符合性问题）
            2. 一致：实施与架构规范具备某些共同特性，并且这些共同特性根据规范得以实施。但架构规范中的某些特性未实施，且实施的某些其他特性未涵盖在规范中
            3. 合规：架构规范中的某些特性未实施，但所实施的全部特性均涵盖在规范中并遵照规范
            4. 符合：架构规范中的全部特性均遵照规范实施，但所实施的另外一些特性为遵从规范
            5. 完全符合：架构规范与实施完全相等。所具体指明的全部特性均遵照规范实施，并且所实施的特性中不存在未涵盖在规范中的情况
            6. 不符合：上述情况中，架构规范的某些特性未遵照规范实施
      3. 审查
         1. 架构合规性审查即按照确立的架构标准、精神和业务目标，检验某个具体项目的合规性
         2. 企业架构合规性战略的核心通常由这类审查的正式流程构成
      4. 清单
         1. 目标清单用于开展架构治理，只有利益相关者有权批准架构
         2. 实施及其他变更清单，旨在帮助从业者理解治理过程中必须展示哪些内容来应对不合规报告
      5. 使用目标清单的说明
         1. 最后一个问题是“利益相关者是否批准了视图？”
         2. 如答案是肯定的，则治理流程已完成；如答案是否定的，则需要作出决定：从业者应当修改架构或架构项目应当取消
      6. 架构师在架构合规性中的角色
         1. 两个常见的治理角色分别是审计师和架构师
         2. 合规评估是审计师的职责。一旦识别出不合规情况，架构师即需要开展影响评估并给出行动建议
         3. 对影响的评估必须与确立目标的标准相一致。若根据其他任何标准进行评估，则评估和建议无效
   6. 架构如何与组织目标相对齐（以敏捷开发为例）
      1. 敏捷企业中的架构
         1. 敏捷开发与ADM中的阶段G（实施治理）对齐
         2. 良好的架构（在阶段A-F中开发）将识别企业所需的产品，产品界限以及产品负责人受到的约束
         3. 架构的一系列约束条件限制了敏捷团队的选择，这通常称为护栏
      2. 聚焦于风险减缓
         1. 从业者需要为变革活动提供支持
         2. 应当聚焦于风险减缓以确保项目达成目标
         3. 从业者需要扮演利益相关方代理人的角色
   7. 管理多个架构状态的需要
      1. 多个架构状态
         1. 当前，或基线架构：目前已有的
         2. 备选（备选过渡架构和备选目标架构）：尚未获得批准的过渡或目标架构。研究假设
         3. 过渡和目标架构：阶段F中“架构获得批准”后所拥有的
         4. 目标架构：当前架构开发时间范围结束。一个获批准的目标状态，随后可能出现新的目标
         5. 过渡架构：当前/基线与目标之间的合理位置，可以停止继续推进但仍能获得价值
      2. 管理多个架构状态（备选、当前、过渡、目标）
         1. 从业者必须在两个维度上跟踪架构状态：时间、符合性测试
         2. 跟踪符合性有助于实施项目和运营变革治理
      3. 管理复杂路线图
         1. 添加以下因素时，复杂性将增加：
            1. EA景观的四个特性：广度、深度、时间和新近性
            2. 能够在不同时间和不同详细程度上将作用于同一对象的不同架构项目
      4. 增加复杂性的因素
         1. 企业外部的进步和变革
         2. 共享服务
         3. 与供应商和合作伙伴的协作，包括谱系负责人模式
         4. 不可动摇的依赖关系
         5. 多重地缘政治界限（财年、法规、文化）
         6. 成熟度的差异和团队的成长
         7. EA团队模式（联邦式、中心化等）
         8. 存在多个可用的解决方案，或宣布使用中的产品生命周期已到尽头
   8. 企业安全架构
      1. 安全架构
         1. 一整套组织、概念、逻辑和物理组件，以连贯一致的方式彼此交互以实现并维持风险和安全（或信息安全）受管理的状态
         2. 驱动并赋能安全、安定、有韧性且可靠的行为，并且应对整个企业的风险领域
      2. 企业安全架构
         1. 企业安全架构并非孤立存在
         2. 将安全架构紧密融入企业架构是有益的
         3. 基于企业架构中已有的企业信息，并且产生的信息对企业架构造成影响
         4. 与随后采取安全补救措施相比，“第一次就做对”可以节约成本并提升有效性
   9. 安全：一个横切关注点
      1. 安全作为横切关注点
         1. TOGAF ADM涵盖了通常被视为企业架构子集的四个架构领域的开发：业务、数据、应用和技术
         2. 安全架构与这四个领域均发生交互，因此称为横切(Cross-Cutting)
   10. 优化最大业务收益和最小业务损失而管理不确定性
       1. 风险和不确定性
          1. 风险即不确定性对业务目标达成的影响
          2. 不确定性通常涉及到信息不足，导致知识或理解不充分或不完整
          3. 由于做出业务决策时可用信息有限，不确定性与预测未来结果相关
          4. 这种信息不可能尽善尽美，虽然我们期望更高质量的信息将帮助我们作出更高质量的决策
       2. 基于风险管理的决策
          1. 每个决策都基于以下因素的评估：
             1. 潜在机会和威胁之间的平衡
             2. 有益结果vs.有害结果的可能性
             3. 这些潜在的积极或消极事件的程度
             4. 与每个识别出的结果相关的可能性。对这些因素的识别和评估称为“风险评估”或“风险分析”
       3. 风险相关概念
          1. “风险管理”是在决策过程中应用这些概念的科学和艺术
          2. 风险可以在长期战略层面（业务的整体方向）、中期战术层面（转型项目和项目群）和运营层面（日常运营决策、流程和实践）上看待
          3. 风险管理的目标是优化业务结果，使业务价值最大化，业务损失最小化
       4. 风险和业务栈
          1. 可以在业务栈的任何层级上观察风险，但风险自始至终从业务价值评估和优化开始，自上而下地驱动
   11. 数字化企业中的企业架构师和企业架构
       1. 数字化从业者知识体系中的规模化模型
       2. 场景一：个人/初创者
          1. 个人/创始人场景针对“开发和维持一项基本数字化产品所必须应对的最小基本关注点”
          2. 这一场景表示交付数字化价值的最低限需求
       3. 场景一：个人/初创者架构和架构师的角色
          1. 架构的角色
             1. 作为沟通媒介。架构模型有助于清晰沟通
             2. 为沟通可用的基础设施及其在开发和交付中的恰当使用而提供必要的描述
             3. 用于支持敏捷开发和持续交付并回答相关问题
          2. 架构师的角色
             1. 沟通者，并且被视为关键的企业联络者
             2. 协助识别规模更大的组织中可能嵌入的现有基础架构方法，与基础设施组织沟通经严格审查的技术需求，以确保为新增工作量做好准备
             3. 可根据其实践经验，按需提供这些领域的指导意见
       4. 场景二：团队
          1. 团队拥有唯一的使命和有凝聚力的身份，但完成工作尚还不需要高额简介费用
          2. 团队场景覆盖了彼此协作的产品团队在人员管理可控前提下取得成功所需的基本要素
          3. 将团队协作作为基本指导价值对于成功开发数字化产品而言必不可少
          4. 团队有共同的办公地点，仍可进行非正式沟通，但就工作量而言需要更有序的组织来完成工作
       5. 场景二：团队架构和架构师的角色
          1. 架构的角色
             1. 企业架构提供映射到给定的数字化产品配置文件的模型，从而协助产品管理团队
             2. 明确相互依赖关系，确保从全局视角看待数字化产品
             3. 在从十分简单到十分复杂的不同细节水平上描述流程和工作流
             4. 提供模型以描述期望的运行方式
          2. 架构师的角色
             1. 确保有效沟通工作
             2. 有助于沟通风险和减缓措施
             3. 能够以按需并面向服务的方式提供该项支持，符合团队的运营节奏
       6. 场景三：复杂团队
          1. 复杂团队场景是团队场景自然演进的结果，但涉及的人员和数字化产品的数量导致其复杂性
          2. 主要关注点是复杂团队内的协调
          3. 同样，沟通是确保成功协作并交付加值的关键
       7. 场景三：复杂团队架构和架构师的角色
          1. 架构的角色
             1. 企业架构有助于应对更加复杂的组织中与文化相关的关注点
             2. 用于描述：产品谱系、流程和控制机制、识别并消除阻碍点、持续改善流程、相互依赖关系、价值的产生和成本
             3. 支持谱系管理决策
          2. 架构师的角色
             1. 继续确保风险得到理解且沟通有效
             2. 确保数字化产品共同发挥作用，彼此借力并适当耦合，从而将这一活动从一项具体的数字化产品扩展到需要互操作性的数字化产品谱系，对其建模并以文档形式记录
       8. 场景四：长青企业
          1. 长青企业场景针对管理到目前为止取得成功，面临在超出下一个产品周期的更长时间内可持续运营业务这一现实挑战的企业
       9. 场景四：长青企业架构和架构师的角色
          1. 架构的角色
             1. 有助于风险管理
             2. 通过数据和应用架构指导信息管理
          2. 架构师的角色
             1. 支持长青企业在超过下一个产品周期的更长时间内实现可持续的业务运营
       10. 研究性学习实践企业架构背景环境
2. 利益相关者管理
   1. 如何识别利益相关者及其关注点和视角，以及相关的沟通
      1. 建模方法
         1. TOGAF标准通过正式建模方法来理解利益相关者、关注点和视图
      2. 实践中的关注层级
         1. 利益相关者：有权批准当前架构项目所探究的目标架构，因而对实施的适合性拥有决策权的人员
         2. 关注点：一系列前后一致，引发利益相关者的兴趣并整合需求的主题
         3. 视图：回应利益相关者一系列关注点的企业架构景观的呈现，描述架构如何回应这些关注点，或者展现相关需求如何得到满足
      3. 关注点
         1. 从实践角度，我们将关注点理解为主题
         2. 关注点回应利益相关方就这一主题而言的权力、兴趣和需求
         3. 这一方法显明了基于主题的决策权，并且得以在相互竞争的需求之间权衡
         4. 一系列与企业有限事项对齐，彼此一致的核心关注点有助于聚焦于优先事项
      4. 利益相关者映射图举例
         1. 利益相关者/关注点矩阵：横轴有关注点1（权力、兴趣、需求，值都是低中高）；纵轴是利益相关者1、利益相关者2...
      5. 视图和视角
         1. 视图单单回应利益相关者对某个架构的关注点
         2. 通常，潜在架构及视图对利益相关者的潜在目标和相关变革有所助益，利益相关者得以置身于场景之中，对目标和变革胸有成竹
         3. 当利益相关者理解架构、变革及权衡时，便可对实施开展治理
         4. 每个视角都应当识别关注点、（一个或多个）利益相关者、如何构建视图以及应对问题所需的信息

   2. 架构视图的运用

      1. 架构视图的开发
         1. 架构师必须做出的关键决策之一是选择开发哪些架构视图
         2. 架构师有责任确保：架构的完备性(completeness)、架构的完整性(integrity)
      2. 练习：简单的机场系统
      3. 利益相关者参与和需求管理
         1. 利益相关者参与
            1. TOGAF框架中，需求管理和利益相关者参与居于架构开发的中心位置
            2. 从业者根据其组织的利益相关者偏好和有线事项来开发企业架构
            3. 利益相关者是架构的所有者，也是架构期望实现的价值偏好和优先事项的所有者
         2. 利益相关者管理
            1. 优秀的从业者积极投身于组织的未来，并参与目标状态的定义实现
            2. 从业者通常身兼多重角色：除架构开发者之外还担任主题专家(SME，领域专家)以及利益相关者的代理人
            3. 作为主题专家，从业者提供专家建议；作为代理人，从业者可以代表利益相关者发言
         3. 需求管理
            1. 有效的需求管理取决于
               1. 清晰的可追溯性，始于组织愿景
               2. 使命
               3. 业务模式
               4. 和战略
            2. 并通过尽可能详细的需求声明
         4. 有效参与
            1. 有效果通是有效参与的基础
            2. 而视图和视角的概念则是有效沟通的基础
            3. 不同的利益相关者对架构的关注点彼此不同。这些关注点必须得到有效回应并向利益相关者说明，使目标架构得到利益相关者批准
      4. 运用权衡支持架构开发
         1. 架构权衡方法
            1. 愿景、原则、需求->评价标准A-备选项A、评价标准B-备选项B、评价标准C-备选项C->选择->已选项
         2. 方法
            1. 该方法的第一部分使用愿景、原则、需求及其他信息选择适用于不同备选项的评价标准
            2. 该方法的第二部分根据评价标准确定备选项，并且建立对各个备选项的理解
            3. 该方法的第三部分选择备选项之一，或者将一个以上备选项的特性相结合创建一个新的建议备选项
         3. 权衡
            1. 权衡需要在审慎考虑一个利益相关者的不同偏好，以及不同利益相关者的偏好基础上作出选择
            2. 有效的权衡需要理解价值偏好和优先事项，以及实现目标所需的变更范围
            3. 架构从业者促成不同利益相关者之间的权衡，并且跨越组织界限而使不同利益相关者有效衡量其无法形成直观理解的偏好、优先事项和成本，这一点最能够体现从业者的价值
         4. 权衡决策
            1. 对权衡最常见的解释包括：
               1. “在两个值得拥有但互不兼容的特性间作出平衡，即妥协”以及
               2. “放弃某事物的某个特质、方面或数量，以获得另一特质、方面或数量”
         5. 研究性学习实践利益相关者管理
   3. 利益相关者参与和需求管理

3. 阶段A：起点

   1. 开展架构愿景阶段所需的信息
      1. 识别信息的关键步骤
         1. 识别利益相关者、关注点及业务需求
         2. 定义范围
         3. 评估能力
      2. 开展该阶段所需的信息（1）
         1. 识别利益相关者、关注点及业务需求
         2. 在企业架构存储库中寻找高级架构约束和指南，绘制利益相关者视图。关于必须服务于哪些利益相关者，以及利益相关者的担忧，需要有完全清晰的认识
         3. 定义范围
         4. 评估能力
      3. 开展该阶段所需的信息（2）
         1. 识别利益相关者、关注点及业务需求
         2. 定义（架构项目的）范围：待解决的问题是什么？就企业架构景观（广度和计划展望期）以及目的而言，哪一项倾向于决定所需的详细程度？关于该架构将用于业务周期的哪个部分，需要有完全清晰的认识
         3. 评估能力
      4. 开展该阶段所需的信息（3）
         1. 识别利益相关者、关注点及业务需求
         2. 定义（架构项目的）范围
         3. 评估（EA团队的）能力
         4. 仔细观察企业架构团队并确认团队具备交付该架构开发项目的能力。高质量的企业架构团队能够弥合经验、技能和偏见的差距，交付有用的架构，克服服务团队成员的弱点
      5. 通过迭代获取更多信息
         1. 通过实施架构开发工作的各个架构域的迭代与关键利益相关者沟通如何应对问题，以及变革的范围
         2. 对目标、目标的价值和变革工作有清晰认识
         3. 完成阶段A的输出需要探究所有架构域——这种探究可能旨在理解哪些方面需要变革，而哪些领域无法开展变革，从而确定保留当前架构的影响
         4. 初次探究之后可能发现多个潜在目标
   2. 如何应用阶段A，以及该阶段对架构开发工作的应用
      1. 阶段A：架构愿景——起点
         1. 构建阶段A的必要条件
            1. 确定架构项目的范围
            2. 识别利益相关者及其关注点，以及相关需求
            3. 评估企业架构团队能力
         2. 完成阶段A的必要条件
            1. 关键利益相关者在总体目标以及实现目标所需的工作上达成共识
      2. 如何应用该阶段
         1. 阶段A的详细程度取决于架构工作请求的范围和目标，或与架构开发该轮迭代相关的范围和目标的子集
         2. 阶段A中各步骤的顺序也以及正式开始时间应从实际情况出发并且符合也已确立的架构治理
      3. 阶段A：架构愿景建议采用的步骤
         1. 确立架构项目
         2. 识别利益相关者、关注点和业务需求
         3. 确认并详尽阐述业务目标、业务驱动因素和约束
         4. 开展能力评估
         5. 评估业务变革就绪度
         6. 确定范围
         7. 确认并详尽阐述架构原则，包括业务原则
         8. 开发架构愿景
         9. 确定目标架构价值主张和KPI
         10. 识别业务变革风险和减缓措施
         11. 开发架构工作声明并确保其获得批准
   3. 特定于安全且充分的架构设计——阶段A
      1. 阶段A：特定于安全且充分的架构
         1. 阶段A中应展开特定于安全且充分的架构设计，从而：
            1. 最终状态无未知或不可接受的风险，并且与公司方针政策、标准和原则相一致，从而使利益相关者满意
            2. 安全架构对赋能和支持所需的整体架构，交付在风险、合规及业务收益三者间取得平最佳平衡的业务机会和收益起到重要作用，从而使业务利益相关者，特别是其中的预算控制者满意
      2. 利益相关者批准
         1. 所有利益相关者都有安全和风险关注点以及相关需求。需要收集利益相关者需求以决定所需的安全蓝图，以应对利益相关者的各个关注点
         2. 通常，利益相关者有和安全架构相关的价值关注点。此处的价值可能是降低风险和实现整体架构等衡量因素
         3. 视角和业务案例必须以安全原则、驱动因素、关键风险和风险容忍度为基础，并且作为整体架构愿景可交付物的有机组成部分
   4. 继续推进架构开发所需的输出
      1. 阶段A：架构愿景——建议的输出
         1. 获批准的架构工作声明
         2. 细化的业务原则、业务目标和业务驱动因素声明
         3. 架构原则
         4. 能力评估
         5. 按需定制的架构框架
         6. 架构愿景
         7. 草拟的架构定义文件
         8. 沟通计划
         9. 收入架构存储库的附加内容
      2. 架构工作声明
         1. 架构工作生命定义了完成架构开发周期将采用的范围和途径
         2. 通常，架构工作声明是评价架构项目执行是否成功的依据，并且可能作为架构服务提供方和消费者之间合同协议的基础
      3. 架构愿景
         1. 概括了企业在目标架构的成功部署中逐渐产生的变革
         2. 架构愿景的目的是为关键利益相关者提供正式达成一致的结果。尽可能就结果达成一致有助于架构师聚焦于细节以确认可行性
         3. 架构愿景提供了完整架构定义的概括版，因此有助于利益相关者沟通
      4. 沟通计划
         1. 企业架构包括大量复杂且相互依存的信息
         2. 在恰当的时间向合适的利益相关者有效沟通目标信息是企业架构的关键成功因素之一
         3. 为架构开发沟通计划使沟通得以按计划，有条理地进行
      5. 关键输出
         1. 利益相关者、发起人和管理层希望得到规划和实施有效变革的指导，而非架构本身
         2. 通常，企业所重视并利用的与从业者所产出的并不一致。从业只交付的是关键输出
         3. 目的是聚焦于所追求的加过而非已完成的工作
      6. 阶段A总结：输出、结构和关键知识
         1. 输出和结果
            1. 充分的文档记录，以获得继续开发的批准
            2. 获得批准，可继续开发所概述的目标架构
         2. 关键知识
            1. 问题范围得到确认
            2. 利益与问题具有根本性练习的群体得到确认（利益相关者和关注点）
            3. 对于利益相关者，对问题给出怎样的概括性答案是可接受的？
            4. 利益相关者的优先事项和偏好
            5. 概括性答案能够提供什么价值？

4. 架构开发

   1. 适用于全部ADM阶段的步骤
      1. 阶段B、C、D——共同步骤
         1. TOGAF标准概述的阶段B、C、D中架构开发步骤相同
         2. 相同的原因在于开发架构、确认所开发的工作产品适合其目的并确认获得批准的方法是相同的
         3. 同时，这些步骤具有强制性。如跳过某些步骤则将为最终结果带来风险
      2. 选择参考模型、视角和工具
         1. 从业者需要思考下列问题
            1. 面对一系列利益相关者和关注点，关于所研究的系统，您需要了解哪些信息来应对这些关注点？
            2. 面对一系列信息，您将如何对其建模、呈现、获取和分析？
            3. 是否存在某些参考模型，使您直接进入获取和分析步骤，而非从零开始创建？
            4. 目前企业架构景观中缺失了哪些信息？
      3. 开发目标、基线和差距
         1. 对于目的而言“恰好足够”即可
         2. 将描述对象限定于差距，这种做法的局限性需要考虑：如果企业架构景观的某个部分保持不变且无需追踪，则从业者为何要花时间描述这一部分？
         3. 差距即发生变化的一切事物
      4. 确定达到目标所需的工作，并考虑成本和价值
         1. 如果不了解达成目标所需的工作，利益相关者则会批准不可能完成的任务
         2. 从业者有责任维护价值
         3. 目标意味着付出变革的代价来增加价值
      5. 对影响进行解析
         1. 从业者以其他备选架构、过渡状态、目标状态及进行中的实施项目为参照，探究其提出的备选架构将带来怎样的影响
         2. 从业者借助企业风险管理流程评估对企业风险的影响；这是深度参与项目的高效能企业EA团队最复杂的活动之一
      6. 批准
         1. 从业者帮助其所在组织面对一系列随时间推移彼此竞争的偏好，选择最佳路径。此时从业者已花费时间探究备选项及其影响
         2. 目标架构获得批准，则：
            1. 未来得到定义
            2. 具备通向目标的可追溯性
            3. 已作出权衡
      7. 企业架构存储库
         1. 从业者应当以EA存储库中的内容为起点和终点
         2. 从业者应当思考以下问题：
            1. 是否已有用于解决当前问题的信息？
            2. 是否有知道和约束当前任务的高级架构？
            3. 为弥补EA存储库中的缺陷，最基本的信息是什么？
   2. 架构开发过程中的风险和安全考量（ADM阶段B至阶段D）
      1. 阶段B：业务架构风险和安全考量
         1. 阶段B的安全要素包括：业务层级上的信任、风险、控制
         2. 以上要素独立于具体的IT或架构工作具体范围内的其他系统
      2. 阶段C：信息系统风险和安全考量
         1. 阶段C的安全要素包括功能性安全服务及其安全等级
      3. 阶段D：技术架构风险和安全考量
         1. 大部分情况下，只要技术架构中包含此前阶段定义的相关安全控制和机制，则无需开发特定的技术架构安全制品
         2. 安全制品必须确保技术架构中包含所需的控制措施，并且确认这些控制措施的使用是否达到效果并保证效率
   3. 与得到对架构开发有价值的输出相关的信息
      1. 业务原则、业务目标、业务驱动因素
         1. 要确保架构工作与业务对齐，对这些因素的理解必不可少
         2. 为架构工作设立背景环境
         3. 描述了企业的需求和工作方式
      2. 来自阶段A的相关信息
         1. 所处理的问题范围
         2. 利益相关者及其关注点
         3. 对于问题，给出可被利益相关者接受的概括性答案（架构愿景）
      3. 架构开发：阶段B的输入
         1. 企业外部的参考资料
         2. 非架构输入
            1. 架构工作请求
            2. 业务原则、业务目标和业务驱动因素
            3. 能力评估
            4. 沟通计划
      4. 架构开发：阶段B的架构输入
         1. 企业架构的组织模型
         2. 按需定制的架构框架
         3. 获批准的架构工作声明
         4. 架构原则
         5. 企业连续序列
         6. 架构存储库
         7. 架构愿景
         8. 草拟的架构定义文档
   4. 如何应用阶段B、C、D以及这些阶段对架构开发工作的作用
      1. 结果和输出
         1. 由利益相关者批准，用于应对问题的一系列领域架构
         2. 得到利益相关者理解的一系列差距以及弥合差距所需的工作
      2. 关键知识
         1. 当前企业在哪些方面未能满足利益相关者的偏好？
         2. 为确保企业满足利益相关者的偏好，需要作出哪些变更（差距）？
         3. 为实现变更并确保与创造中的附加价值相符，哪些工作是必要的？（工作包）
         4. 面对价值、工作量和变更风险，利益相关者的优先事项和偏好又怎样的调整？（利益相关者需求）
      3. 步骤的顺序
         1. 各个步骤的顺序以及正式开始和完成的时间应当因地制宜，根据具体情况而定
         2. 在这些步骤中发起的全部活动都应当于“最终确定架构”步骤中结束
      4. 架构存储库
         1. 架构团队需要在每个阶段中考虑组织的架构存储库中有哪些相关的 架构资源可以利用
      5. 阶段B的应用：业务架构
         1. 范围取决于现有的战略和规划
            1. 更新和验证
            2. 将高层级业务驱动因素及战略
            3. 与目标及具体业务需求相联系
            4. 现有的架构发现必须包括全部相关细节信息
         2. 如尚无战略或规划
            1. 识别现有的架构定义，然后验证和更新
            2. 新的流程定义可能需要细化工作
         3. 详细程度取决于整体架构工作的范围和目标
         4. 用于定性描述业务需求的新模型需要在阶段B中详细定义
         5. 将转移到目标环境并得到支持的现有业务制品可能已经在之前的架构工作中充分定义，否则需在阶段B中定义
      6. 阶段B的应用：信息系统架构
         1. 阶段C涉及到数据和应用架构，二者先后顺序可调换，两种顺序均有支持者
         2. 例如：
            1. Spewak的企业架构计划建议采用数据驱动的顺序
            2. 主要应用系统（ERP、CRM）等通常将技术基础设施与应用逻辑相结合
            3. 应用驱动的方法将核心应用（支撑关键业务流程）作为架构工作的首要焦点；集成问题常常构成重大挑战
         3. 数据架构的关键考量因素包括：数据管理、数据迁移、数据治理
      7. 阶段D的应用：技术架构
         1. 新技术的演进是企业求新求变的主要驱动因素之一，促使企业寻找创新运营方法并改善业务
         2. 技术架构需要通过采纳新技术抓住企业面临的转型机遇
   5. 为产出与架构开发相关的输出，阶段C（数据和应用）所需的信息
      1. 信息系统架构阶段C的输入
         1. 企业外的参考资料
         2. 非架构输入
            1. 架构工作请求
            2. 能力评估
            3. 沟通计划
         3. 架构输入
            1. 企业架构组织模型
            2. 受影响的组织范围
            3. 按需定制的架构框架
            4. 数据原则
            5. 架构工作声明
            6. 架构愿景
            7. 架构存储库
            8. 可复用的构建块（特别是对目前数据的定义）
            9. 草拟的脚骨定义文档
            10. 草拟的架构需求规范
            11. 架构路线图的业务架构组件
      2. 阶段C的关键知识
         1. 当前企业在哪些方面未能满足利益相关者的偏好？
         2. 为确保企业满足利益相关者的偏好，需要作出哪些变更（差距）？
         3. 为实现变更并确保与创造中的附加价值相符，哪些工作是必要的（工作包）？
         4. 面对价值、工作量和变更风险，利益相关者的优先事项和偏好有怎样的调整（利益相关者需求）？
   6. 为产出与架构开发相关的输出，阶段D所需的信息
      1. 技术架构阶段D的输入
         1. 企业外部参考资料
            1. 架构参考资料
            2. 备选产品信息
         2. 非架构输入
            1. 架构工作请求
            2. 能力评估
            3. 沟通计划
         3. 企业架构组织模型，包括
            1. 受影响的组织范围
            2. 成熟度评估、差距和弥合途径
            3. （一个或多个）架构团队的角色和责任
            4. 架构工作的约束条件
            5. 预算需求
            6. 治理和支持战略
         4. 按需定制的架构框架，包括
            1. 按需定制的架构方法
            2. 按需定制的架构内容（可交付物和制品）
            3. 配置和部署的工具
         5. 技术原则，如有
         6. 架构工作声明
         7. 架构愿景
         8. 架构存储库，包括
            1. 可复用的构建块
            2. 公开可用的参考模型
            3. 特定于组织的参考模型
            4. 组织标准
         9. 草拟的架构定义文档，其中可能包含任一架构域内的基线和/或目标架构
         10. 草拟的架构需求规范，包括：
             1. 差距分析结果（出自业务、数据和应用架构）
             2. 此前阶段的相关技术需求
         11. 架构路线图的业务、数据和应用架构组件
      2. 阶段D的关键知识
         1. 当前企业在哪些方面未能满足利益相关者的偏好？
         2. 为确保企业满足利益相关者的偏好，需要作出哪些变更（差距）？
         3. 为实现变更并确保与创造中的附加价值相符，哪些工作是必要的（工作包）？
         4. 面对价值、工作量和变更风险，利益相关者的优先事项和偏好有怎样的调整（利益相关者需求）？
   7. 继续推进架构开发工作所需的阶段B、C、D输出
      1. 阶段B、C、D的输出
         1. 架构愿景阶段可交付物经细化和更新后的版本
         2. 草拟的架构定义文档
         3. 草拟的架构需求规范
         4. 架构路线图的业务架构组件
      2. 结果和输出
         1. 用于应对当前问题的一组领域架构获得利益相关者批准
         2. 一组差距及弥合差距所需的工作得到利益相关者理解
      3. 研究性学习实践架构开发
5. 实施架构
   1. 阶段E、F、G的风险和安全考量因素
      1. 风险和安全——阶段E：机会和解决方案
         1. 确保在分析中回应利益相关者的安全和风险关注点。确认已经征求风险所有者的意见
         2. 期望通过工作包交付的价值应当包括与安全和风险价值相关的措施，从而确保路线图涵盖全部业务目标和驱动因素
         3. 此前阶段中定义的安全构建块成为这一阶段的SBB，从而确定面向实施的，更加具体的需求和规范
         4. 基线安全架构的安全服务目录可能包含满足要求的当前安全服务或安全构建块
      2. 风险和安全——阶段F：迁移计划
         1. 迁移战略应当包含风险评估和风险减缓计划
         2. 在阶段F，风险减缓计划仅限于过渡
         3. Live环境的迁移应当无一例外地包含回归计划，以备迁移失败时退回到原来状态。这是风险管理必不可少的部分之一
         4. 此外，迁移计划还应包含安全影响分析，这有助于理解变革目标状态对安全的影响
      3. 风险和安全——阶段G：实施治理
         1. 安全架构实施治理保证细化的设计以及所实施的流程和系统符合整体安全架构
         2. 这确保了偏离架构原则和实施知道方针的情况不会引发不可接受的风险
   2. 创建实施和迁移战略的步骤（阶段E）
      1. 阶段E：机会和解决方案——步骤（1）
         1. 确定/确认公司变革的关键属性
         2. 确定实施的业务约束条件
         3. 审查并整合阶段B至D的差距分析结果
         4. 审查各相关业务职能部门已整合的需求
         5. 整合互操作性需求并达成一致
         6. 喜欢并确认依赖关系
      2. 阶段E：机会和解决方案——步骤（2）
         1. 确认业务转型就绪度和风险
         2. 制定实施和迁移计划
         3. 对主要工作包进行识别和分组
         4. 识别过渡架构
         5. 创建架构路线图及实施和迁移计划
   3. 实施的基本方法
      1. 实施方法
         1. 三种基本方法
            1. Greenfield（绿地）：全新实施
            2. 革命性：根本性的变革（即开启-关闭）
            3. 演进性：聚合策略，例如平行运行或分阶段引入新能力
         2. 最常见的实施方法
            1. 快速取胜（快照）
            2. 可实现的目标
            3. 价值链法
   4. 对工作包进行识别和分组
      1. 运用“整合的差距、解决方案和依赖关系”矩阵和实施因素目录，以合乎逻辑的范式将各项活动分组为工作包
      2. 在“整合的差距、解决方案和依赖关系”矩阵中的“解决方案”一栏填入内容，介绍所提议的解决方案机制
      3. 对于每项差距/活动，指明其解决方案是应当面向新的开发，或是基于现有产品，并且/或是使用可购买的解决方案
      4. 对每个纳入考虑的当前系统作如下分类：
         1. 主流：未来信息系统的一部分
         2. 受限：在计划周期（未来三年）内预计被替代或更改
         3. 替代：在计划周期内将被替代或更改
      5. 因此，对顶层工作包的支持应当分解为一系列增量，以交付能力增量
      6. 从业务变革事项和战略实施方法的角度分析并细化这些工作包或增量
      7. 最后，将工作包分为组合和组合中的项目，需要考虑到依赖关系和战略实施方法
   5. 创建并以文档形式记录过渡架构
      1. 过渡架构
         1. 适用于实现目标架构所需的变更范围要求采用增量式方法的情况
         2. 识别实现目标架构的路线图中的一个或多个清晰目标
         3. 过渡架构的开发必须基于所偏好的实施方法、整合的差距、解决方案和依赖关系矩阵、项目群和谱系列表以及企业促成和采纳变化的能力
         4. 确定活动中的难点，除非存在有说服力的理由，否则应当在其他更容易补足缺失能力的活动完成后再攻坚克难
   6. 迁移项目对组织的影响以及所需的协调工作
      1. 阶段F：迁移计划——步骤
         1. 确认实施和迁移计划的管理框架交互为每个工作包分配一项业务价值
         2. 估测资源需求、项目群时间节点和可用性/交付载体
         3. 通过成本/收益评估和风险验证确定迁移项目群的优先级
         4. 确认架构路线图，更新架构定义文档完成实施和迁移计划
         5. 完成架构开发周期并以文档形式记录经验教训
      2. 阶段F总结：输出、结果和关键知识
         1. 输出和结果：获得批准的一组项目，包含目标和必要的约束、所需资源、开始和结束时间
         2. 关键知识：实施变更的可用资源，利益相关者的优先事项和偏好如何根据变更的价值、工作量和风险作出调整（利益相关者需求）
      3. 通过架构支持项目：最终确定范围和预算
         1. 对于谱系的各个项目
            1. 最终确定估测指标和时间安排
            2. 更新企业路线图
            3. 在治理和批准计划中填入内容
      4. 通过架构支持项目：为解决方案交付治理做准备
         1. 项目群背景：
            1. 开始完成架构工作
            2. 定义目标解决方案架构
            3. 最终确定对工作量和资源的估测
            4. 在具体到项目的治理模型中定义变量的测度方式
            5. 更新风险矩阵
      5. 实现解决方案
         1. 从契约角度而言，这是试运行后的质保期。该阶段将解决方案交于受益者（用户、支持人员、合作伙伴等）
         2. 该阶段结束后应在已实现的架构与即将用于交付解决方案的基线架构间开展差距分析
         3. 以文档形式记录经验教训，主要是在解决方案架构交付过程中，主要是在解决方案架构交付过程中，上级架构描述中的哪些差距得到弥合
      6. 关闭
         1. 实现的解决方案成为新的基线。为目标架构路线图的演进和分析提供了基础
         2. 架构从业者开展评估，证实当前架构项目科关闭
         3. 使所有利益相关者、决策者和实施者参与评估，获得签核以关闭该项工作
   7. 将业务价值分配到各个工作包的原因和方法
      1. 阶段F：迁移计划将业务价值分配到各个工作包
         1. 确定组织内业务价值的组成部分和衡量方法，并将其应用于各个项目和项目增量
         2. 将工作包作为识别实施和迁移计划中包含的项目的基准
         3. 识别出的项目将在阶段F其他步骤中充分展开
         4. 接下来应当通过总结“整合差距、解决方案和依赖关系矩阵”（阶段E）中识别出的风险，将风险分配到项目和项目增量中
         5. 运用业务价值估算技术估算每个项目的业务价值
      2. 该项活动中待解决的问题
         1. 绩效评价标准
         2. 投资回报标准
         3. 业务价值
         4. 关键成功因素
         5. 有效性度量指标
         6. 战略匹配度
      3. 与利益相关者沟通
         1. 实施者需要对项目形成理解
            1. 项目处于路线图的哪个位置，在价值创造中扮演怎样的角色
            2. 项目负责哪些工作包和差距，以及不负责哪些相关的差距
            3. 如何进行符合性评估
      4. 为实施变革而管理当前方法
         1. 从业者的任务是展现架构项目的可交付物经过充分审查，使解决方案交付架构得以成功
         2. 向利益相关者证明当架构项目为解决方案交付架构所用时，其需求得到满足，并且企业变革将得到有效的指导和约束
         3. 识别并确保开始为解决方案交付架构的启动分配预算所需的资源得到批准
   8. 如何确定迁移项目的优先级（阶段F）
      1. 为迁移项目确定优先级——成本/收益评估
         1. 以交付成本为参照确定项目的业务价值，从而确定项目的优先级
         2. 方法如下：首先应尽可能清晰地确定项目交付的全部SBB的净收益，之后验证风险已得到有效减缓并将其计算在内
      2. 为迁移项目确定优先级——风险确认
         1. 审查风险以确保尽可能减缓项目可交付物的风险。随后更新项目清单，添加风险相关的备注
         2. 促使利益相关者就项目优先次序达成一致
         3. 正式审查风险评估并按需修订，确保充分认识与优先次序以及预计资金额度相关的风险
   9. 确认架构路线图（阶段F）
      1. 确认架构路线图
         1. 更新架构路线图，包括全部过渡架构
         2. 审核截至目前的工作以评估过渡架构之间应当采取怎样的时间跨度，将业务价值、能力及风险等其他因素的增量考虑在内
         3. 一旦能力增量最终确定，则整合项目的可交付物
         4. 从而得到修订后的架构路线图
      2. 更新架构定义文档
         1. 如实施方法由于确认实施增量而发生变化，则须更新架构定义文档
         2. 这可能包括指定项目目标，将项目及其可交付物与过渡架构对齐，从而创建/更新架构定义增量表
   10. 继续推进架构实施工作所需阶段F的输出
       1. 阶段F（迁移计划）的输出：实施和迁移计划
          1. 获批准的实施和迁移计划包括：
             1. 实施和迁移战略
             2. 实施工作按照项目和谱系分解
                1. 将工作包分配给项目和谱系
                2. 由项目交付的能力
                3. 与目标架构以及任何过渡架构的关系
                4. 里程碑和时间线
                5. 工作分解结构
             3. 项目章程（可选）
                1. 相关工作包
                2. 业务价值
                3. 风险、事项、假设和依赖关系
                4. 资源需求和成本
                5. 迁移收益
                6. 迁移备选项的成本估算
       2. 阶段F（迁移计划）的输出：其他
          1. 最终定稿的架构定义文档，包括：最终确定的过渡架构，如有
          2. 最终定稿的架构需求规范
          3. 最终定稿的架构路线图
          4. 可复用的ABB（架构构建块）
          5. 为ADM周期的新一轮迭代提出架构工作请求（如有）
          6. 实施治理模型（如有）
          7. 在经验教训基础上的架构能力变更请求
       3. 阶段F（迁移计划）结果总结
          1. 获得批准的一系列项目，包括目标及任何必要的约束条件、所需的资源、开始和结束时间
   11. 阶段G（实施治理）的输入
       1. 阶段G（实施治理）的输入
          1. 企业外部参考资料
          2. 架构参考资料
          3. 非架构性输入
          4. 架构工作请求
          5. 能力评估
       2. 阶段G（实施治理）的架构性输入
          1. 企业架构组织模型，包括：
          2. 按需定制的架构模型，包括：
          3. 架构工作声明
          4. 架构愿景
          5. 架构存储库，包括：
          6. 架构定义文档
          7. 架构需求规范，包括：
          8. 架构路线图
          9. 架构治理框架
          10. 实施治理模型
          11. 架构契约（标准）
          12. 阶段E和F识别出的架构工作请求
          13. 实施和迁移计划
   12. 如何开展实施治理（阶段G）
       1. 阶段G（实施治理）的步骤
          1. 为开发管理者共同确认部署的范围和优先事项
          2. 识别部署资源和技能
          3. 指导解决方案部署的开发
          4. 开展企业架构合规性审查
          5. 实施业务和IT运行
          6. 开展实施后审查并完成实施
       2. 阶段G总结：输出、结果和关键知识
          1. 输出和结构：达到调整后的目标状态所需的变更项目实施完成
          2. 关键知识：实施团队的目的和约束（差距、架构需求规范、控制）；利益相关者的优先事项和偏好如何根据变更的成功、价值、工作量和风险作出调整（利益相关者需求）
       3. 为变革提供支持
          1. 需要为变更活动提供支持
          2. 利益相关者通常对该项目能否在预计时间内以预期成本交付期望价值的信心不足
          3. 缺乏信心意味着架构与实现组织目标相关的不确定性或风险增加
          4. 此时应以风险减缓为重点
       4. 阶段G（实施治理）的指导
          1. 为实施项目提供指导
          2. 从业者必须
             1. 聚焦于实施计划的范围
             2. 在实现企业收益而非项目收益的背景下促进高质量决策
             3. 确保利益相关者和实施者理解其作出的选择对企业收益的影响，而非驱动其作出不同的选择
       5. 实施项目及其他变革
          1. TOGAF标准提供了两个关键概念，用以治理实施项目及其他变革：架构契约和架构需求规范
          2. 架构契约用于指导和控制实施团队以经过充分考虑的未来为目标开展工作
          3. 架构需求规范用于为实施团队的创造力指明方向并加以控制
   13. 支持架构治理所需的输出
       1. 架构契约（已签订），根据付诸实施且合规的架构所建议
       2. 合规评估
       3. 变更请求
       4. 架构合规的解决方案部署包括：
          1. 架构合规的部署系统
          2. 内容充实的架构存储库
          3. 架构合规建议和特许
          4. 关于服务交付需求的建议
          5. 关于绩效指标的建议
          6. 服务水平协议（SLA）
          7. 实施后更新的架构愿景
          8. 实施后更新的架构定义文档
          9. 付诸实施的解决方案之业务和IT运行模型
          10. 架构构建块（ABB）
       5. 阶段G（实施治理）结果总结：达到调整后的目标状态所需的变革项目实施完成
   14. 如何使用架构契约与实施者沟通
       1. 与实施者沟通
          1. 面相实施者的服务常常不够充分。一种司空见惯的做法是向实施者递交一系列代表架构的图表
          2. 实施者被期望从这些图表中领会应当弥补的差距、必须遵循的架构规范以及必须实施的控制措施
          3. 明确提供背景、差距、架构规范和控制措施，对实施者有很大的帮助
       2. 对于实施者的关键事项
          1. 项目实施背景：该项目位于路线图的哪个部分，将提供哪像价值或价值依赖关系？
          2. 范围：实施项目负责哪些工作包和差距，不负责哪些与项目范围相关联的架构组件相关差距？
          3. 符合性：对实施项目的评估将以哪些具体的架构规范和控制措施为参照？
       3. 进一步探究与实施者的沟通
          1. 约翰卡弗的方针治理方法有两个强制性要求：
             1. 首先，规范应当是排斥性的，强调禁止什么，而非准许什么
             2. 第二，对合规性的评估应当由恰当的人士进行合理的阐释测试而得以完成
       4. 架构职能和业务利益相关者之间的契约
          1. 业务利益相关者的架构契约可能包括：
             1. 简介和背景
             2. 协议的本质
             3. 范围
             4. 战略需求
             5. 满足业务需求的架构可交付物
             6. 符合性需求
             7. 架构采纳者
             8. 时间窗口
             9. 架构业务指标
             10. 服务水平协议（SLA）
             11. 该契约也用于阶段H中的企业架构变更管理
       5. 研究性学习实践实施架构

6. 架构变更管理

   1. 触发变更管理的输入——变更请求
      1. 阶段H：架构变更管理输入
         1. 企业外部参考资料
         2. 架构参考资料
         3. 非架构性输入
         4. 架构工作请求
      2. 阶段H：架构变更管理的架构性输入
         1. 企业架构的组织模型
         2. 按需定制的架构框架
         3. 架构工作声明
         4. 架构愿景
         5. 架构存储库
         6. 架构定义文档
         7. 架构需求规范
         8. 架构路线图
         9. 变更请求——技术变更
         10. 变更请求——业务变更
         11. 变更请求——基于经验教训
         12. 实施治理模型
         13. 架构契约（已签订）
         14. 合规性评估
         15. 实施和迁移计划
      3. 触发变更管理的输入
         1. 阶段H要求从业者识别：
            1. 自下而上的变更驱动因素
            2. 由于可用技术、运营管控条件或企业所处环境改善而发生的变更
         2. 接下来为下一个目标过渡状态（自上而下的驱动因素）开展架构工作
      4. 变更请求
         1. 架构实施过程中，原有架构定义和需求可能不再适用或不再足以完成解决方案实施
            1. 在此类情况下，实施项目需要偏离所提议的架构途径，或要求扩展范围
         2. 此外，外部因素——例如市场因素、业务战略变化和新的技术机遇——可能开辟新的机会以扩展和细化架构
   2. 有效变更管理所需的活动（利益相关者管理）
      1. 阶段H：架构变更管理的步骤
         1. 建立价值实现
         2. 部署监控工具
         3. 管理风险
         4. 为架构变更管理提供分析
         5. 确立达成绩效目标所需的变更需求
         6. 对治理过程进行管理
         7. 激活变更实施流程
      2. 有效的变更管理
         1. 将变更决策与分配资源的业务周期相匹配
         2. 识别自下而上的变更驱动因素
         3. 定义“恰好足够的架构”以及EA景观的特性
         4. 将EA团队与组织的计划、预算、运营和变更流程相对齐
   3. 与继续推进变更相关的输出
      1. 阶段H：架构变更管理的输出
         1. 架构更新（用于维护变更）
         2. 架构框架和原则的变更（用于维护变更）
         3. 为进入另一个周期提出新的架构工作请求（用于重大变更）
         4. 架构工作声明，视需要而更新
         5. 架构契约，视需要而更新
         6. 合规性评估，视需要而更新
      2. 阶段H：架构变更管理结果总结
         1. 继续推进并着手开发一个目标架构的指令，以弥补企业与利益相关者偏好之间的预知、实际或逾期差异
7. 需求管理
   1. 需求管理阶段的输入
      1. 需求管理的输入
         1. 内容充实的架构存储库
         2. 企业架构组织模型，包括：
            1. 受影响的组织范围
            2. 成熟度评估、差距和解决途径
            3. 架构团队（一个或多个）的角色和职责
            4. 架构工作约束
            5. 预算要求
            6. 治理和支持战略
         3. 按需定制的架构框架，包括
            1. 按需定制的架构方法
            2. 按需定制的架构内容（可交付物和制品）
            3. 配置和部署的工具
         4. 架构工作声明
         5. 架构愿景
         6. 填入架构需求规范，作为其内容的架构需求
         7. 需求影响评估
      2. 有效的需求管理
         1. 有效的需求管理依赖于从组织愿景、使命、业务模型和战略开始，通过尽可能详细的需求声明而实现的清晰的可追溯性
         2. 与利益相关者接触时，从业者必须捍卫每位利益相关者的全部偏好，以及这些偏好的影响
   2. 如何将需求管理步骤对应到ADM各阶段的步骤
      1. 架构需求管理步骤与ADM阶段步骤
         1. 需求管理阶段的目标如下：
            1. 确保需求管理流程仍然持续，并在ADM所有相关阶段中实施
            2. 管理ADM周期或其中某个阶段实施过程中识别出的架构需求
            3. 确保在各个阶段实施过程中相关架构需求可用
         2. 步骤对应：

            1. 	需求管理步骤	ADM阶段步骤
               步骤一		识别需求（通常通过分析如何以设计价值流、业务场景、用户体验或管理信息的提供为手段满足业务目标/目的），并在架构需求规范和需求存储库中以文档形式记录这些需求
               步骤二	建立基线需求，确定优先事项，确认利益相关者就优先事项达成一致，并在架构需求规范和需求存储库中以文档形式记录这些需求
               步骤三	监控基线需求
               步骤四		识别新增和变更的需求： 删除或重新评估有限事项 增加需求并重新评估优先事项 修订现有需求
               步骤五	识别变更后的需求并记录优先事项： 识别变更后的需求，确保负责当前阶段的架构师已和利益相关者共同确定这些需求的优先级 记录新的优先事项

   3. 需求管理输出的目的
      1. 架构需求管理的输出
         1. 需求影响评估
         2. 更新后的架构需求规范：架构需求规范（如有需要）
      2. 需求影响评估目的
         1. 在整个ADM中，收集与架构有关的新信息可能使新的事实浮现，导致架构某些现有部分失效
         2. 需求影响评估对当前架构需求和规范展开评估，从而识别所需的变更以及这些变更的影响
      3. 架构需求规范目的
         1. 提供一系列定量描述，概括指出实施项目必须做什么，从而与架构保持一致
         2. 通常构成实施契约或更加详细的架构定义契约中的主要部分
      4. 需求管理流程
         1. 当新的需求出现或现有需求变更时，则须生成一份需求影响声明以识别需要回顾ADM的哪些阶段以应对变更
         2. 声明贯穿多轮迭代直到最终版本，该版本包含需求对架构开发的完整影响（例如成本、时间线和业务指标）
         3. 一旦对当前ADM周期的需求最终确定，则应当更新架构需求规范
      5. 研究性学习实践需求管理

8. 支持ADM工作

   1. 如何使用The Open Group TOGAF资料库支持从业者的工作
      1. 标准之外，TOGAF资料库中还包括附加资源
      2. TOGAF系列指南是指经过证实并保持稳定的最佳实践，但TOGAF资料库同时还提供新涌现的想法、指南、模式及其他形式的参考资料，为企业创建新架构提速
   2. 业务场景
      1. 业务场景目的
         1. 是一种有助于识别和理解架构必须满足的业务需求的技术
      2. 方法
         1. 对驱动背景的问题进行识别、以文档形式记录并排序
         2. 以文档形式记录问题情境发生的业务和技术环境，作为高级架构模型
         3. 识别并以文档形式记录所期望实现的目标：成功处理问题的结构（确保目标符合SMART原则）
         4. 识别人员施动者（参与者）及其在业务模型中的位置
         5. 识别计算机施动者（计算元素）及其在技术模型中的位置
         6. 检查适用性，仅在必要情况下改进
      3. 创建业务场景
         1. 问题（痛点、障碍、关切）-> 环境（业务和技术、价值流、业务能力）->结果（SMART-具体、可度量、可执行、切合实际、有时限）->人员施动者（能力、角色、职责）-> 计算机施动者（能力、角色、职责）
         2. 阶段（每个阶段重复应用上面的方法）
            1. 创建前提阶段：计划、收集信息、分析/处理、文档记录、审查
            2. 初步确认阶段：计划、收集信息、分析/处理、文档记录、审查
            3. 细化阶段：计划、收集信息、分析/处理、文档记录、审查
   3. 合规性评估的目的
      1. TOGAF ADM中合规性评估的目的
         1. 最佳实践的合规性评估与TOGAF中的架构契约概念紧密相连
         2. 在TOGAF阶段G中识别出两个合规性评估的领域
            1. 首先是项目范围
            2. 其次是实际实施，无论是预先设计实施的或是绩效变化
         3. 阶段H包含另一项基于价值的合规性评估
      2. 合规评估的目标
         1. 尽早发现项目架构中的错误，从而降低生命周期随后阶段所需的成本和变更风险
         2. 确保在架构工作中应用最佳实践
         3. 为架构符合企业强制性标准的情况提供概览
         4. 与管理层沟通项目状态
   4. 如何运用迁移规划技术审核并整合此前阶段的差距分析结果
      1. 迁移规划技术
         1. 实施因素目录：用于以文档形式记录影响架构实施和迁移计划的因素
         2. 整合的差距、解决方案和依赖关系矩阵：架构师运用这一方法将领域架构差距分析结果中识别出的差距分类并评估对应一个或多个差距的潜在解决方案和依赖关系
         3. 架构定义增量表
         4. 过渡架构状态演进表
         5. 业务价值评估技术
      2. 迁移技术
         1. 架构定义增量表：架构师运用这一方法计划一系列过渡架构，这些过渡架构用于概述企业架构在具体时间点上的状态
         2. 过渡架构状态演进表：架构师运用这一方法呈现架构按照给定的分类法（例如TOGAF TRM），在不同层级上的推荐状态
         3. 业务价值评估技术：通过绘制包含价值指数和风险指数两个维度的矩阵评估业务价值
   5. 如何以TOGAF架构存储库为例构建存储库
      1. TOGAF架构存储库
      2. 架构信息分类
         1. 架构元模型：描述了根据组织需求定制的架构框架应用，包括架构开发方法和架构内容元模型
         2. 架构能力：定义了支持架构存储库治理的参数、结构和流程
         3. 架构景观：是企业在特定时间点在用或计划资产的架构呈现
         4. 标准资料库：汇集了新架构必须遵循的标准，其中可能包括行业标准、从供应商处选择的产品和服务或已经在组织内部署的共享服务
         5. 参考资料库：提供了企业为加速创建架构可利用的指南、模板、模式及其他形式的参考资料
         6. 治理存储库：提供了整个企业治理活动的记录
         7. 架构需求存储库：提供了所有与架构委员会达成一致并获得批准的架构需求视图
         8. 解决方案景观：构建块的架构呈现，这些构建块用于支持企业计划或部署的架构景观
   6. 对运行良好的架构存储库有怎样的期望
      1. 建议
         1. 支持工具：一个高效能的团队应当得到建模和分析软件，以及文档管理系统的支持
         2. 支持工具：从业者需要任何模型与文档记录之间的联系，以及进行分析所需的空间
         3. 充分的细节：运行良好的存储库应包含充分的细节，证明向利益相关者呈现的视图确实来源于架构
         4. 充分的细节：全部利益相关者的关注点均须得到回应
         5. 聚焦于EA存储库的三大组成部分：架构需求规范、控制措施和差距
         6. 聚焦于良好的信息管理，包括良好的信息呈现实践
   7. 如何运用架构层级概念构建景观
      1. 概念
         1. 在典型的企业中，架构景观在任何时间点均可描述多个架构
         2. 为应对这一复杂性，TOGAF标准采用层级和企业连续序列这两个概念，为架构景观的构建提供概念框架
         3. 层级提供了一个框架，将架构景观分为三个粒度（详细程度）水平
      2. 在不同层级上开发架构
         1. 架构通常并非鼓励存在，而是必须位于治理层接结构内。范围宽泛的概括性架构为范围狭窄的详细架构确定了方向
         2. 可以采取两种策略：
            1. 不同层级的架构可以通过ADM流程一个周期内的迭代来开发
            2. 不同层级的架构可以通过同时开展的一系列ADM流程层级来开发
      3. 构建架构景观
         1. 广度：广度（主题）领域通常是描述架构景观的首要构建特征。架构从功能上被分解为一系列具体的主题领域或切分层级
         2. 深度：为确保架构规模和复杂性可管理，较宽泛的主题领域所需的详细程度较低。而较具体的主题领域则通常允许（并要求）更细化的架构
         3. 时间：在广度和深度给定条件下，企业可以创建基线架构和一系列趋向未来的目标架构。通常，较为宽泛、详细程度较低的架构有效期更长，能够为企业提供面向更远未来的愿景
         4. 新近性：最后，每个架构视图都将通过开发周期取得进展，准确性随之提升，直到最终获得批准。获批准的架构如未经积极维护，则准确性将开始下降。在某些情形下，可以将新近性作为历史架构的构建因素之一
   8. 组织中存在的不同架构层级
      1. 架构景观
         1. 战略架构：为运营和变革活动提供组织框架，从而得以在领导层级确定方向
         2. 分段架构：为运营和变革活动提供组织框架，从而得以在项目群或谱系层级确定方向并开发有效的架构路线图
         3. 能力架构：为变更互动和有效的架构路线图开发提供组织框架，从而实现能力增量
      2. 架构连续序列
         1. 提供了通过抽象将架构景观的各个层级相区分的方法
         2. 为确定和理解架构中的通用规则、陈述和关系（包括可追溯性和衍生关系）提供了一致的方法
         3. 展现了从基础要素到具体到组织的架构之间的关系
   9. 确定架构在哪个层级上开发
      1. 带有架构项目的EA景观
         1. 关键点是架构项目涵盖了EA景观的某个特定部分——该确定部分关于广度、计划范围和详细程度。范围内可能以存在此前完成的工作......
   10. 架构构建块（ABB）的作用
       1. 架构构建块
          1. 架构构建块（ABB）与架构连续序列相关，其定义和选择是ADM应用的结果
          2. 用于为需求构建架构，例如业务、数据、应用和技术需求
          3. 指示和引导SBB的开发
   11. 业务架构的准则和技术
       1. 应用业务能力
          1. 在架构愿景阶段发现或绘制的业务能力映射图提供了一个自洽的业务视图，不依赖于当前组织结构、业务流程、信息系统和应用，不依赖于当前组织结构、业务流程、信息系统和应用，以及产品或服务谱系的其余部分
          2. 这些业务能力应当反向映射到企业架构项目范围内的组织单元、价值流、信息系统和战略计划
          3. 这种关系映射为其中每个领域的对齐和优化提供了更精辟的洞察
       2. 示例：业务能力映射图
       3. 示例：业务能力热力图
       4. 应用价值流
          1. 价值流为组织为何需要业务价值提供重要的利益相关者背景环境，而业务能力则满足组织为成功实现某个具体的价值阶段的需要
          2. 从架构愿景阶段以文档形式记录的业务最初一组价值流模型开始，在这一具体的企业架构项目范围内，如果广度扩展到足够大，则可能需要尚未纳入存储库的新的价值流
          3. 可通过热力图（价值流阶段）或围绕完整的价值流定义开发用例，在项目范围内对新增或现有价值流进行分析
       5. 示例：将能力映射到价值流阶段
       6. 应用组织映射图
          1. 组织映射图呈现了构成企业生态系统的主要组织单元、合作伙伴和利益相关者群体
          2. 映射图应当描述这些实体之间的关系，这是组织映射图与组织图的明显区别，后者仅呈现层级报告关系
          3. 业务单元室建立组织映射图所运用的主要概念
          4. 映射图是业务架构的关键要素，为整个企业架构工作提供了组织背景环境
       7. 示例：组织映射图
       8. 应用信息映射图
          1. 业务架构阶段的信息定性描述始于和业务相关度最高的要素，例如产品、客户、工厂等
          2. 随后可在映射图中增补信息领域间的关系，将对良好的基线信息映射图的理解提升到更高层面
          3. 最显著的益处来自信息和业务能力之间创建的矩阵
          4. 这些信息视图以及与业务能力之间的关系将在接下来的架构阶段用于数据定性描述、应用和基础设施
       9. 示例：信息映射简图
       10. 应用建模技术
           1. 建模和映射技术属于扩展，用于实施业务能力、价值流和组织映射图
           2. 活动模型（亦称为业务流程模型）描述了企业的业务活动，各项活动之间交换的数据和/或信息（内部交换）以及与模型范围以外的其他活动之间交换的数据和/或信息（外部交换）
           3. 用例模型从业务流程和组织参与者（人、组织等）相对应的用例和施动者角度描述了企业的业务流程
           4. 逻辑数据模型（或类别模型）逻辑数据模型描述实体机其属性和属性可接受的价值，以及不同实体之间的关系
           5. 业务模型为帮助组织聚焦于战略愿景和执行并实现对齐提供了坚实的架构
       11. 示例：业务模型画布
   12. 应用差距分析
       1. 差距分析
          1. 架构开发的一个关键步骤是运用差距分析识别基线需要开展哪些变更方能达到目标架构
          2. 差距分析技术用于思考遗忘、遗漏或必须的要素
          3. 简言之，差距即发生改变的一切事物
       2. 步骤
          1. 绘制一个矩阵，其中基线架构全部ABB位于纵轴，目标架构全部ABB位于横轴
          2. 在基线架构轴上添加最后一行，标签为“新增”，目标架构轴上添加最后一列，标签为“删除”
          3. 如某个ABB同时存在于基线和目标架构，则在交叉单元格标注为“包含”
          4. 如基线架构某个ABB未包含于目标架构中，则两个架构均需审核
          5. 如目标机构某个ABB未包含于基线架构中，则在与“新增”行的交叉处标注差距，该差距需通过开发或采购构建块弥合
       3. ADM阶段B、C、D确立目标、基线和差距
          1. 足以达成目的即可
          2. 如当前状态得到接受，则描述基线的唯一原因是开发差距
          3. 需考虑将描述限定于差距存在之处这一做法的局限性
          4. 在相同的详细程度上采用相同技术加以描述，使差距得到识别：差距即发生变更的一切事物
   13. 如何在架构实践中运用迭代
       1. 实践中的迭代
          1. 可通过两种方式运用迭代：
             1. ADM的迭代：以ADM的活动、再排序和循环来描述
             2. 信息流层面的迭代：通过探索基于所需信息的EA景观。如所需的信息可用，则继续，如不可用，则通过实施ADM阶段得到相应资料
       2. ADM的迭代
          1. ADM通过若干种方式支持迭代：
             1. 迭代通过若干个ADM周期描述综合的架构景观，这些周期基于架构工作请求范围内的单个举措
             2. 迭代描述架构开发的集成过程，其中ADM不同阶段内描述的活动彼此交互以形成集成架构
             3. 迭代描述组织架构能力变更管理的过程
       3. 迭代用于开发综合架构景观
          1. 项目将在从阶段A开始的整个ADM周期中执行
             1. 将每个ADM周期均受架构工作请求的约束
             2. 作为充实架构景观的内容，架构输出将扩展所描述的景观或在必要时对景观作出修改
          2. 彼此独立的项目各自的ADM周期可能共时进行，不同项目间具有联系
          3. 一个项目可能触发另一个项目的开展
       4. ADM周期内的迭代（架构开发迭代）
          1. 项目可能：
             1. 有多个ADM阶段共时开展
             2. ADM阶段的周期处于涵盖多个阶段的计划周期内
             3. 回到之前的阶段，以新信息更新工作产品
       5. 建议的迭代周期（目标为先）
       6. 迭代用于管理架构能力（架构能力迭代）
          1. 项目可能需要：
             1. 预备阶段的新迭代，以（重新）构建阶段A中识别出的，能够满足架构工作请求的架构能力之某些方面
             2. 预备阶段的新迭代，以调整组织架构能力，满足因阶段H中的变更请求而识别出的架构能力新需求或变更后的需求
       7. 涉及到架构的领域类型
          1. 根据标准中的定义，主要有三个方面与架构关系密切：
             1. 识别所需的变革
             2. 定义变革
             3. 实施变革
       8. 各类涉及架构的领域之迭代重点（选摘）

          1. 涉及	迭代重点	范围
             支持业务决策	架构能力 架构开发（基线为先）	对架构景观宽泛的千层考量，旨在回应具体战略问题并为战略实施确立更详尽的架构工作的条件
             景观的架构组合管理	架构能力 架构开发（基线为先）	聚焦于基线应用和技术基础设施的“体格评估”，用以识别改善机会，其约束条件通常是维持业务正常开展
             项目的架构组合管理	过渡规划 架构治理	聚焦于项目、项目依赖关系和对景观的影响，以架构优化的方式将项目排序对齐

       9. 信息流角度的迭代
          1. 在TOGAF ADM内的迭代常常涉及到重新排序和循环
          2. 迭代也可能以信息流的形式，其中项目的信息需求驱动迭代
          3. 如所需的信息不可用，则通过TOGAF ADM某个阶段的执行产出该信息
       10. 示例
   14. 如何运用实施因素目录
       1. 实施因素目录
          1. 该目录用于以文档形式记录影响实施和迁移计划的因素
          2. 创建于阶段E开始时，作为实施和迁移决策的存储库
          3. 阶段E中，随着信息进一步挖掘，将重新考量该目录
       2. 整合差距、解决方案和依赖关系矩阵
          1. 该矩阵作为创建工作包时的计划工具
          2. 使架构师对领域架构差距分析结果中识别出的差距进行分组并针对一个或多个差距评估潜在的解决方案以及依赖关系
       3. 架构定义增量表
          1. 该表用于计划一系列过渡架构，概括特定时间点的架构状态
          2. 可用于将增量式项目可交付物分配至各个过渡架构中
   15. 内容框架与企业元模型
       1. 内容框架和企业元模型的必要性
          1. 在ADM预备阶段构建具体到企业的企业架构能力的一项基本任务是确定：
             1. 用于将架构描述、用于表达架构的工作制品以及描述架构的一系列模型组成体系的分类框架：内容框架
             2. 立即企业内部实体类型以及实体间需要采集、存储和分析的关系，以创建架构描述；企业元模型将该信息描述为正式模型
       2. 企业元模型的价值
          1. 为架构师提供一系列初始类型，这些类型在模型中探讨并涵盖
          2. 提供一种完整性——寻找企业中提议使用的任何架构建模语言或架构元模型
          3. 有助于确保：
             1. 一致性
             2. 完整性
             3. 可追溯性
       3. 建模方式
   16. 需要在整个ADM周期内为架构内容框架（ACF）填入内容的情况
       1. 在整个ADM周期内为ACF填入内容
          1. ADM各阶段均需要信息输入，并在执行一系列步骤后创建输出
          2. 内容框架为ADM提供了一个根本性的结构，用于更详尽地定义输入和输出，并将每个可交付物置于企业整体架构视图的背景环境中
       2. TOGAF内容框架
          1. 架构原则、愿景、动机和需求模型旨在捕捉形式化的架构模型的周边背景环境，包括通用架构原则、为架构建模构成输入信息的战略背景，以及由架构产生的需求。通常在预备阶段及架构愿景阶段，对产生架构工作请求的业务背景环境相关方面进行研究、细化、证实和记录
          2. 业务架构捕捉业务的架构模型，特别关注企业及其结构和能力的驱动因素
          3. 信息系统架构模型捕捉IT系统的架构模型，审视与TOGAF ADM各阶段一致的应用和数据
          4. 技术架构模型捕捉用于实施和实现信息系统解决方案的技术资产
          5. 架构实现/转型模型捕捉变革路线图，显示架构状态之间的过渡以及用于引导和治理架构实施的约束性声明
          6. 架构变革管理模型捕捉对企业架构以及行动需求的产生构成影响的价值实现管理事件，这些事件可能在企业内部或外部
       3. 将EA能力开发映射到ADM各阶段

          1. 主题	映射到TOGAF ADM阶段
             企业背景环境和EA背景环境	部分战略层，阶段B 企业背景环境： --目的、目标、举措、竞争和战术分析 --运营模式（合作伙伴、供应商） --探索“如果......会怎样”的情境以及记分卡 特定于EA能力的EA背景环境： 目的
             EA能力的业务目标	能力层，阶段A 对于EA能力： --提供初始目的和目标 --选择一个参考EA能力成熟度模型 --备选EA能力 --备选运营模型 --EA能力差距和优先事项路线图
             架构治理	部分分段/能力层，阶段B 对于企业： --企业风险管理模型 --治理模型 对于EA能力： --风险管理模型 --治理模型

   17. 运用企业元模型
       1. TOGAF企业元模型
       2. 企业元模型——实体（选摘）

          1. 元模型实体	描述
             施动者	扮演开展活动或与活动交互角色的人员、组织或系统；例如出差拜访客户的销售代表。施动者可能在组织内部或外部。在汽车行业，与供应链活动形成交互的汽车销售商可能将原厂设备制造商视为施动者
             应用服务	业务服务中自动化的要素。应用服务可能交付或支持部分或全部、一项或多项业务服务
             假设	对由于外部约束条件，在现阶段尚未完全证实的可能事实的声明。例如，假设某个现有应用将支持一系列功能需求，虽然尚未对这些需求中的每一项加以证实

       3. 企业元模型——属性（选摘）

          1. 元模型实体	属性	描述
             所有元模型实体	ID	架构实体的唯一标识符
             	名称	架构实体的简短名称
             	名称	架构实体的文字描述
             	类别	每个元模型实体可由用户定义的分类法
             	来源	信息收集自何处
             	所有者	架构实体的所有者
             能力	业务价值	描述该项能力如何为企业提供价值
             	增量	列举该项能力可能的成熟度/质量水平

       4. 企业元模型——关系（选摘）

          1. 源实体	目标实体	名称
             施动者	施动者	分解
             施动者	业务服务	消费
             施动者	数据实体	提供或消费
             施动者	事件	产生
             施动者	事件	解决
             施动者	功能	交互
             施动者	功能	执行

   18. 运用分类法
       1. TOGAF企业元模型分类法
          1. TOGAF企业元模型为大多数企业的分类法提供了一个良好的起点
          2. 定义了一系列企业可能希望持续跟进的常见组件和常见的可能关系（动机、角色、事件、活动、位置、资源、平台服务），以及一系列联系
       2. 实体、属性和关系
          1. TOGAF企业元模型描述了实体、属性和关系
   19. 如何运用风险评估
       1. 公认的安全架构师关注领域
          1. 资产保护
          2. 风险评估
          3. 访问控制
          4. 审计
          5. 可用性
       2. 定义：风险评估
          1. 确定了我们面临哪些风险，度量这些风险以确定其可能性和影响，随后根据组织的风险容忍度接受、减缓或转嫁风险
       3. 风险分类方案
          1. 对效果和频度的度量并无一定之规。以下准则基于现有的风险管理最佳实践：
             1. 效果
             2. 频度
             3. 分类方案
       4. 风险评估行动
          1. 风险评估指确定与某资产或目标相关的风险的活动
          2. 定性风险分析列举一系列相关的风险场景，并概括确定其优先次序（高——中——低），而定量方法则旨在从数量上确定风险
          3. 风险分析的可交付物之一是业务风险模型
       5. 风险减缓计划
          1. 风险减缓计划包含了减缓风险的活动。该计划是风险减缓战略的实施，旨在通过业务活动变更、风险延迟、风险补偿等手段提高控制水平，将风险转嫁到其他方或避免风险
          2. 阶段E中的企业风险管理（ERM）流程针对更广泛意义上的风险
          3. 其范围包括此前在阶段B的风险评估过程中识别出的最新信息安全风险
       6. 阶段F：迁移规划
          1. 迁移本身是一个需要确保安全的业务流程
          2. 迁移战略应当包括风险评估和风险减缓计划
          3. 在阶段F中，风险减缓计划仅限于过渡
          4. 此外，迁移规划应当包括安全影响分析，这有助于理解变革的目标状态有怎样的安全影响