📌 重点知识：架构原则 (Architecture Principles)

❓ 什么是架构原则？为什么架构原则需要与业务原则对齐？

💡 架构原则是一组通用规则和准则，用于指导企业架构的设计和演进。它们必须与业务原则对齐，因为架构的最终目的是支撑业务目标。如果架构原则与业务原则脱节，可能导致技术方案无法满足业务需求，造成资源浪费。

❓ 为什么在 ADM 的早期阶段就需要确立架构原则？

💡 在 ADM 早期阶段（架构愿景阶段A）确立架构原则至关重要，因为原则是所有后续架构决策的基础。早期确立可以避免后期返工，确保利益相关者在方向上达成共识。如果延迟到详细设计阶段才确立，可能导致已做的设计工作需要推翻重来。

❓ 架构原则如何指导后续的技术决策？如果缺乏明确的原则会导致什么问题？

💡 架构原则通过提供一致的决策框架来指导技术选择。例如，'数据共享'原则会推动选择集成度高的系统。缺乏明确原则时，不同团队可能做出相互冲突的技术选择，导致系统集成困难、维护成本升高。

📌 重点知识：架构治理 (Architecture Governance)

❓ 什么是架构治理？为什么架构项目需要治理机制？

💡 架构治理是确保架构工作符合既定原则、标准和战略方向的实践框架。它需要治理机制是因为大型企业的架构涉及多个团队、长周期项目，没有治理就难以保证一致性和质量。

❓ 架构合同在治理中扮演什么角色？为什么需要合规性审查？

💡 架构合同是架构师与实施团队之间的正式协议，明确了交付物、责任和约束。合规性审查用于验证实施是否符合架构设计，防止实施偏离。没有合同和审查，实施团队可能为了便利而偏离架构设计，导致架构意图无法实现。

❓ 如果缺乏有效的架构治理，企业架构会面临哪些风险？

💡 缺乏治理的风险包括：架构碎片化（各项目各行其是）、技术债务累积、重复建设、系统集成困难、安全合规风险等。长期来看会导致 IT 成本失控，无法支撑业务敏捷性。

❓ 架构委员会的职责是什么？为什么架构决策不能仅由技术团队自行决定？

💡 架构委员会负责审批架构决策、解决争议、确保与战略对齐。架构决策不能仅由技术团队决定是因为架构决策影响整个企业的IT投资方向、业务运营模式和长期技术路线，需要业务、技术、运营等多方利益相关者的共同参与和决策。

📌 重点知识：架构委员会 (Architecture Board)

❓ 架构委员会的核心职责是什么？它在企业中应该处于什么层级？

💡 架构委员会的核心职责是：审批架构工作请求、评审架构交付物、监督架构合规性、解决架构争议、维护架构标准和原则。它应直接向CIO或CTO汇报，确保架构决策具有足够的影响力和权威性。

❓ 架构委员会如何运作？为什么它需要跨部门的代表参与？

💡 架构委员会定期召开会议评审架构进展和偏差。需要跨部门代表参与（业务、IT、安全、运营等）是因为架构决策影响整个企业，单一部门视角的决策无法全面考虑各方需求和约束。跨部门参与还增强了架构决策的接受度。

❓ 如果企业没有架构委员会，架构工作会出现什么问题？

💡 没有架构委员会会导致：架构决策缺乏权威性审批、标准无法统一执行、各方利益冲突无法协调、架构违规无人监督、架构资产缺乏持续维护。最终结果通常是IT碎片化，系统间难以集成。

📌 重点知识：目标架构 (Target Architecture)

❓ 什么是目标架构？它与基线架构有什么区别？

💡 目标架构描述企业期望达到的未来状态，它定义了支撑业务战略所需的信息系统和技术基础。基线架构描述当前的现状状态。两者的差距就是架构工作需要弥合的鸿沟。目标架构必须基于业务需求、架构原则和约束条件来定义。

❓ 为什么需要创建多个替代的目标架构方案？

💡 创建多个替代方案的原因是：复杂环境中通常没有唯一最优解，不同方案在成本、风险、时间、性能等维度上有不同的权衡。多个方案允许利益相关者进行比较和选择，确保最终方案经过充分论证。这也符合TOGAF的架构权衡分析方法。

❓ 如何确定哪个替代目标架构是最优的？评估标准应包含哪些维度？

💡 评估标准应包含：业务价值（支撑战略的程度）、可行性（技术和资源约束）、风险水平（实施风险和业务中断风险）、成本（总投资和运维成本）、时间（交付周期）、灵活性（适应未来变化的能力）。这些标准应使用架构愿景、原则和需求来定义，并经过利益相关者正式审查。

📌 重点知识：利益相关者管理 (Stakeholder Management)

❓ 谁是架构工作的利益相关者？为什么需要系统性地识别和管理他们？

💡 利益相关者是对架构工作结果有利害关系的任何个人、团体或组织，包括：高管（关注战略对齐和ROI）、业务经理（关注运营效率）、IT团队（关注技术可行性）、最终用户（关注可用性）、合规部门（关注法规遵从）、供应商（关注商业机会）。需要系统性管理是因为不同利益相关者有不同的关注点和优先级，遗漏关键利益相关者会导致架构不被接受。

❓ 利益相关者地图的作用是什么？如何使用它来指导架构沟通？

💡 利益相关者地图通过权力/影响力与关注/兴趣两个维度将利益相关者分类，帮助架构师确定沟通策略：对高权力高关注的要密切管理，对高权力低关注的要满足他们，对低权力高关注的要告知他们。这确保有限的沟通资源用在最关键的地方。

❓ 业务场景技术如何帮助识别利益相关者的真正需求？

💡 业务场景是一种用于引出和验证业务需求的工具，它描述了一个涉及多个角色和系统的端到端业务流程。通过业务场景，可以自然地暴露利益相关者在流程中的痛点、期望和约束，比直接访谈更容易获得真实需求。业务场景还有助于验证架构是否能支撑关键业务流程。

❓ 为什么利益相关者的关注点之间经常发生冲突？如何解决？

💡 冲突的根本原因是不同利益相关者的目标天然不同：CFO追求成本最低，CIO追求技术领先，业务部门追求功能最多。TOGAF建议通过架构原则和架构愿景来解决冲突——当冲突发生时，回到架构愿景和原则来确定优先级。如果原则无法解决，则需要高层管理者的决策。

📌 重点知识：差距分析 (Gap Analysis)

❓ 什么是差距分析？为什么它在架构开发中是必不可少的？

💡 差距分析是对比基线架构与目标架构，识别需要改变的要素的过程。它必不可少是因为只有清楚知道'从哪里出发'、'要去哪里'、'差距是什么'，才能制定有效的实施计划。没有差距分析，迁移规划就是盲目的。

❓ 差距分析应该在 ADM 的哪些阶段进行？每个阶段分析的重点有何不同？

💡 差距分析在每个架构域阶段都应进行：阶段B分析业务能力差距，阶段C分析数据和应用差距，阶段D分析技术基础设施差距。阶段E（迁移规划）则需要汇总所有域的差距，进行综合分析，确保解决方案考虑了跨域的依赖关系。

❓ 常见的差距类型有哪些？如何根据差距制定解决方案？

💡 常见差距类型包括：人员技能差距（需要培训）、流程缺失（需要新建流程）、系统功能缺失（需要新建或采购）、数据缺失（需要数据迁移或清洗）、技术基础设施不足（需要升级或替换）。解决方案通常分为：构建新的、购买现成的、复用已有的三类，需要综合考虑成本、时间和风险。

📌 重点知识：迁移规划 (Migration Planning) - 阶段E

❓ 迁移规划的核心任务是什么？为什么不能从目标架构直接跳到实施？

💡 迁移规划的核心任务是：将目标架构分解为一系列可管理的、有序的项目和过渡状态，制定实施路线图。不能直接跳到实施是因为大型架构变革涉及众多系统和业务单元，必须有条不紊地推进。没有规划的直接实施会导致资源冲突、业务中断、项目失控。

❓ 什么是工作包？如何将差距分析的结果转化为可执行的工作包？

💡 工作包是迁移规划中的基本执行单元，每个工作包对应一组相关的差距解决方案。转化过程是：先通过差距分析识别所有差距，再将相关差距分组（基于依赖关系和业务优先级），然后为每组差距定义解决方案，最后打包为工作包。每个工作包应有明确的范围、交付物和依赖关系。

❓ 为什么需要过渡架构？直接一步到位实现目标架构会有什么风险？

💡 过渡架构是从基线到目标之间的中间状态，每个过渡状态都应该是一个可运行的、有价值的状态。直接一步到位的风险包括：变更规模过大难以管理、业务一次性中断太久、风险集中爆发无法应对。过渡架构将大变革分解为多个小步骤，每个步骤都可以独立验证和回退。

📌 重点知识：架构路线图 (Architecture Roadmap)

❓ 什么是架构路线图？它与项目计划有什么区别？

💡 架构路线图是按时间顺序排列的架构实施计划，展示了工作包的执行序列、里程碑和依赖关系。与项目计划的区别是：路线图是战略层面的，关注方向和节奏，不包含详细的任务分解；项目计划是战术层面的，关注具体执行。路线图为项目计划提供输入和约束。

❓ 路线图如何帮助管理层理解架构变革的节奏和投资？

💡 路线图通过可视化展示帮助管理层理解：何时能获得业务价值、哪些投资是前置依赖、资源需求的时间分布。一个清晰的路线图能帮助管理层做出明智的投资决策，确保架构变革获得持续的资金和资源支持。

❓ 如何处理路线图执行中的变更？路线图是否需要动态调整？

💡 路线图需要动态调整，因为业务环境、技术条件和组织能力会随时间变化。TOGAF建议定期（如每季度）评审路线图，根据实际情况调整工作包的优先级和时序。但调整时应遵循架构变更管理流程，评估变更影响并获得架构委员会的批准。

📌 重点知识：架构工作请求 (Request for Architecture Work)

❓ 什么是架构工作请求？谁发起这个请求？

💡 架构工作请求是启动一个新的架构开发周期（ADM循环）的正式触发器。它通常由架构委员会、CIO或业务部门发起，用于定义需要解决的架构问题或需要利用的架构机会。每个ADM循环通常对应一个架构工作请求。

❓ 架构工作请求应包含哪些关键信息？

💡 工作请求应包含：业务背景和驱动因素、期望的业务成果、范围和约束、关键利益相关者、时间期望、资源预估。这些信息帮助架构师在阶段A（架构愿景）中快速建立工作方向，避免返工。

❓ 为什么需要正式的工作请求而不是直接开始架构工作？

💡 需要正式工作请求的原因：第一，确保架构工作有明确的业务驱动和高层支持；第二，帮助架构委员会合理分配资源，避免同时启动过多项目；第三，为后续评估架构工作的价值提供基准。没有正式请求的架构工作往往缺乏方向，难以产生业务价值。

📌 重点知识：风险管理 (Risk Management)

❓ 在TOGAF架构工作中，风险管理的核心目标是什么？

💡 风险管理的核心目标是识别、评估和缓解可能阻碍架构成功实施的风险，确保架构变革能在可接受的风险水平下推进。TOGAF要求风险管理贯穿ADM全周期，而非仅在实施阶段才考虑。

❓ 如何识别和评估架构风险？风险缓解策略有哪些？

💡 风险识别通常通过利益相关者访谈、业务场景分析、架构评审来完成。评估维度包括：影响程度（对业务的损害）和发生概率。缓解策略主要有四类：规避（改变方案消除风险）、转移（通过保险或外包转移）、缓解（降低概率或影响）、接受（在可接受范围内承担风险）。

❓ 为什么在架构愿景阶段就需要考虑风险？早期忽视风险管理会带来什么后果？

💡 早期忽视风险管理会导致：架构方案选择了高风险的技术路径而未做准备、关键利益相关者的反对未被及时发现、业务连续性需求未被考虑导致实施时业务中断。在愿景阶段考虑风险可以及早调整方向，避免后续阶段因风险暴露而大规模返工。

📌 重点知识：安全架构 (Security Architecture)

❓ 为什么安全架构需要与业务架构同步设计而不是事后补充？

💡 安全架构如果事后补充，往往只能做到打补丁式的防护，存在安全盲区。与业务架构同步设计可以从根本上将安全融入业务流程，确保安全控制不阻碍业务运作，同时覆盖所有关键风险点。

❓ 在集中化系统中，数据安全和访问控制的核心挑战是什么？

💡 集中化系统的核心挑战包括：多角色的细粒度权限管理、跨地域数据合规（如 GDPR）、数据传输加密、审计追踪等。集中化虽然便于统一管理，但一旦被攻破影响范围更大。

❓ 如何平衡安全性与可用性？过度安全会带来什么问题？

💡 过度安全会导致系统使用复杂、响应速度慢、用户体验差，最终可能导致用户绕过安全控制（如共享密码），反而降低安全性。平衡的关键是基于风险分级，对高敏感操作严格管控，对低风险操作适当简化。

📌 重点知识：互操作性 (Interoperability)

❓ 什么是互操作性？为什么在企业架构中需要特别关注？

💡 互操作性是指不同系统、组织之间交换信息和使用已交换信息的能力。企业架构中特别关注是因为大型企业通常有大量异构系统（不同技术、不同时期建设），如果系统间无法互操作，就会形成信息孤岛，阻碍业务流程的端到端执行。

❓ 互操作性有哪些类型？如何通过架构设计提高系统的互操作性？

💡 互操作性的类型包括：数据互操作（不同系统能理解和交换数据）、技术互操作（不同技术平台能通信）、语义互操作（对数据含义有一致理解）。提高互操作性的架构方法包括：定义统一的数据标准和接口规范、使用中间件和集成平台、采用开放标准、实施企业服务总线(ESB)或API网关。

❓ 如果忽视互操作性，会导致什么具体的业务问题？

💡 忽视互操作性的具体问题包括：数据需要人工重复录入（效率低、易出错）、业务流程因系统不连通而断裂（如订单系统与物流系统脱节）、管理层无法获得统一的全局视图（信息孤岛导致决策基于局部数据）、系统升级或替换困难（牵一发而动全身）。

📌 重点知识：架构开发方法 ADM (Architecture Development Method)

❓ 什么是 TOGAF ADM？它为什么是 TOGAF 框架的核心？

💡 ADM（Architecture Development Method）是 TOGAF 的核心方法，提供了一种可靠的、经过验证的方式来开发企业架构。它是一个分阶段的、迭代的方法，从架构愿景到实施治理覆盖了架构开发的完整生命周期。ADM 是 TOGAF 的核心，因为它提供了可重复、可管理的架构开发流程。

❓ ADM 的各个阶段是什么？每个阶段的核心目标是什么？

💡 ADM 包含以下阶段：预备阶段（准备组织、定义框架）、阶段A-架构愿景（定义范围、利益相关者、愿景）、阶段B-业务架构（定义业务基线和目标）、阶段C-信息系统架构（数据和应用架构）、阶段D-技术架构（技术基础设施）、阶段E-机会与解决方案（确定工作包）、阶段F-迁移规划（制定路线图）、阶段G-实施治理（监督实施）、阶段H-架构变更管理（管理变更）。需求管理贯穿全程。

❓ ADM 是如何迭代的？为什么要迭代而不是一次性完成？

💡 ADM 在三个层面迭代：1）全局迭代——整个 ADM 周期可以重复执行，每次覆盖更大的范围或更深层次；2）阶段迭代——单个阶段内可以反复执行步骤直到满足要求；3）架构域迭代——可以在不同架构域（业务、数据、应用、技术）之间迭代。迭代是因为企业架构是复杂的、持续演进的，一次性完成既不现实也不可行。

📌 重点知识：预备阶段与阶段A (Preliminary Phase & Phase A)

❓ 预备阶段的核心任务是什么？为什么需要预备阶段？

💡 预备阶段的核心任务是：定制 TOGAF 框架、定义架构原则、建立架构组织模型和工具、定义架构工作流程。需要预备阶段是因为在正式开始架构工作前，组织需要做好准备——确定谁负责架构、使用什么方法、遵循什么原则。没有准备，架构工作会缺乏组织支撑和方法论基础。

❓ 阶段A（架构愿景）的关键交付物有哪些？

💡 阶段A的关键交付物包括：架构工作声明（SOW）、架构愿景文档、利益相关者地图、架构原则（如尚未建立）、沟通计划、业务场景（如使用）。架构愿景是最核心的交付物，它高层级地描述了期望的未来状态和业务价值。

❓ 在阶段A如何定义架构工作的范围？为什么范围定义如此重要？

💡 范围定义包括：组织范围（哪些业务单元）、功能范围（哪些业务功能）、时间范围（短期还是长期）、架构域范围（是否涵盖全部四个域）。范围定义重要是因为过大范围会导致项目失控，过小范围会限制架构价值。范围需要与利益相关者充分沟通并获得一致认可。

📌 重点知识：机会与解决方案 (Opportunities & Solutions) - 阶段E

❓ 阶段E的核心目标是什么？它与阶段F（迁移规划）有什么区别？

💡 阶段E的核心目标是：基于差距分析结果，确定实现目标架构的解决方案和工作包。与阶段F的区别是：阶段E关注'做什么'（确定工作包和解决方案方向），阶段F关注'怎么做、何时做'（制定详细的实施路线图和优先级）。

❓ 什么是工作包？如何将差距分析的结果转化为工作包？

💡 工作包是迁移规划中的基本执行单元。转化过程：1）汇总所有架构域的差距；2）将相关差距分组（基于业务依赖和技术依赖）；3）为每组差距确定解决方案（新建、购买、复用）；4）将解决方案打包为工作包，每个工作包有明确的范围和交付物。

❓ 如何评估和选择解决方案方案？

💡 评估维度：1）业务价值——支撑业务战略的程度；2）可行性——技术、资源、时间的约束；3）风险——实施风险和业务中断风险；4）成本——投资和运维成本；5）依赖——与其他工作包的关系。应使用架构权衡分析方法进行系统评估。

📌 重点知识：基于能力的规划 (Capability-Based Planning)

❓ 什么是基于能力的规划？它与传统的项目规划有什么本质区别？

💡 基于能力的规划是一种以业务能力为核心来组织和规划投资的方法。与传统的项目规划（以项目为单位，关注交付物和时间表）不同，基于能力的规划以能力为单位，关注能力的目标状态、当前差距和提升路径。能力是组织为达成业务目标所需具备的技能、流程和技术资源的组合。

❓ 为什么 TOGAF 推荐使用基于能力的规划方法？

💡 TOGAF 推荐基于能力的规划是因为：1）能力比项目更稳定——业务能力不会因组织架构调整而消失，而项目会因人事变动而中断；2）能力提供了跨项目的协调框架——多个项目可以共同支撑一个能力的提升；3）能力与业务价值直接关联——能力提升直接产生业务价值，而非交付了一个系统就算完成。

❓ 如何将业务能力与架构工作关联起来？

💡 关联方法：在阶段B（业务架构）中建立业务能力地图，识别关键能力的当前水平和目标水平；在阶段E（机会与解决方案）中，将能力差距转化为工作包；在阶段F（迁移规划）中，按能力优先级排列工作包的执行顺序。这样确保架构投资始终围绕业务能力提升展开。

📌 重点知识：需求管理 (Requirements Management)

❓ 为什么需求管理在 ADM 中是贯穿全程的而不是一个独立阶段？

💡 需求管理贯穿全程是因为需求不是一次性确定的，而是在整个架构开发过程中持续演进的。每个 ADM 阶段都可能发现新需求、修改已有需求或确认需求已满足。如果需求管理是独立阶段，就切断了需求与各阶段架构工作的联系，导致需求与设计脱节。

❓ 如何确保架构需求被正确捕获和管理？

💡 确保需求被正确管理的方法：1）建立需求登记册，记录所有需求及其来源、优先级、状态；2）使用需求追溯矩阵，追踪需求到架构设计再到实施；3）定期与利益相关者确认需求的准确性和优先级；4）将需求变更纳入正式的变更管理流程，评估变更影响。

❓ 需求变更时应该如何处理？

💡 需求变更处理流程：1）记录变更请求；2）评估变更对架构的影响（范围、成本、时间、风险）；3）通过架构委员会审批变更；4）更新架构文档和需求登记册；5）通知受影响的利益相关者。重要的是不要随意接受变更，每个变更都需要经过评估和审批。

📌 重点知识：数据架构 (Data Architecture) - 阶段C

❓ 数据架构的核心内容是什么？它与应用架构有什么关系？

💡 数据架构描述企业的逻辑和物理数据资产、数据管理结构以及数据流动。它定义了'企业需要什么数据、数据如何组织、数据如何流动'。与应用架构的关系是：数据架构定义了信息的结构，应用架构定义了处理这些信息的应用——数据是输入输出，应用是处理器。

❓ 为什么数据架构需要先于应用架构定义？

💡 数据架构先于应用架构是因为应用是为处理数据而存在的。如果先设计应用，可能发现应用的数据需求与企业的数据标准不一致，导致数据不一致或集成困难。先定义数据架构可以确保所有应用遵循统一的数据标准，便于系统集成和数据共享。

❓ 数据架构的关键交付物有哪些？

💡 关键交付物包括：数据实体关系图（描述数据结构和关系）、数据流图（描述数据在系统间的流动）、数据迁移计划、数据治理框架、数据安全分类。这些交付物共同确保数据资产得到有效管理。

📌 重点知识：应用架构 (Application Architecture) - 阶段C

❓ 应用架构的核心内容是什么？它如何支撑业务架构？

💡 应用架构描述企业的应用系统组合、应用间的关系以及应用与业务功能的映射。它定义了'用什么系统支撑业务'。应用架构通过将业务能力映射到应用系统来支撑业务架构——每个关键业务能力都应有对应的应用系统支撑。

❓ 如何决定是新建应用还是复用已有应用？

💡 决策依据：1）功能匹配度——已有应用是否满足需求；2）成本——新建 vs 复用 vs 定制的总拥有成本；3）时间——新建通常更慢；4）风险——复用降低技术风险但可能功能不足；5）战略——是否要建立核心差异化能力（自建）还是通用能力（采购）。TOGAF 建议优先考虑复用已有资产。

❓ 应用架构设计中的常见陷阱有哪些？

💡 常见陷阱：1）应用数量膨胀——每个需求新建一个应用，导致系统碎片化；2）应用功能重叠——多个应用做类似的事，造成混乱和浪费；3）应用与业务脱节——应用架构没有从业务能力出发设计；4）忽视集成——只关注单个应用功能，忽视应用间的数据流和接口。

📖 本题重点分析理解整理

一、考点分析

• 4 你是保险公司的领头架构师，该保险公司由三个之前独立的保险公司合并而成请阅读以下场景来回答问题你是保险公司的领头架构师，该保险公司由三个之前独立的保险公司合并而成。

• 该公司由三个事业部组成，并继承原来自己的名字和总部地址。

• 三个独立事业部整合的缺乏已经造成处理客户信息和财务信息的问题。

二、术语解释

ADM：Architecture Development Method，架构开发方法，TOGAF的核心方法论，提供分阶段、迭代的架构开发流程

三、应掌握的知识

✓ 掌握架构原则 (Architecture Principles)的核心概念、作用及其在TOGAF ADM中的应用

✓ 掌握架构治理 (Architecture Governance)的核心概念、作用及其在TOGAF ADM中的应用

✓ 掌握架构委员会 (Architecture Board)的核心概念、作用及其在TOGAF ADM中的应用

✓ 掌握目标架构 (Target Architecture)的核心概念、作用及其在TOGAF ADM中的应用

✓ 掌握利益相关者管理 (Stakeholder Management)的核心概念、作用及其在TOGAF ADM中的应用

四、易混淆点提示

注意区分相近概念，结合 TOGAF 框架的定义准确理解。

L1 练习 (AV10 DOCX)