TOGAF9.2/10 认证基础知识点概览表

TOGAF9.2/10 认证基础知识点概览表 （考点解析： TOGAF 基础架构是通用服务和功能的架构，为构建更具体的 架构和架构组件提供了基础。这个基础架构体现在技术参考模型（ TRM ）中，它提供了通用平台服务的模型和分类法。 1 、 TOGAF TRM 的目的是 为识别通用平台服务提供可视化参考，以识别通用平台服务的位置和种类 ） 2 、 需求影响评估 的目标是确定当前架构开发的需求和并为后期需求变更提供管理规范 （考点解析：在整个 ADM 中，收集与架构相关的信息。随着这些信息的收集，新的需求事实可能会暴露出来，使架构的现有开发目标失效。需求影响评估方法可以评估当前的架构需求和规范，以确定应该进行的变更以及这些变更影响。） 3 、架构交付物正确的描述： 它们在整个 ADM 开发周期中产出，通常是企业架构开发项目所约定的合同工作产品，需要由利益相关者审查和签署 。（考点解析：TOGAF 标准提供了一个典型的架构交付基线，以便更好地定义 ADM 中所需的活动，并作为特定组织中裁剪的起点。） 4 、最能描述架构构建块的内容是描述架构设计的基础单元，具有相对独立的 基础能力（诸如有用、可复用） 。（考点解析：ABB 具有基本的功能和属性：有价值、有目标，诸如提高安全和改善管理） 5 、 TOGAF 标准将 可重复使用的构建块 视为良好构建块的属性，也即强调可复用性。 6 、干系人关注点是 TOGAF 标准中的关键概念， 涉众可以是个人、团队或组织；关注点是与一个或多个利益相关者相关的关键利益（需求项）；利益相关者在系统中扮演者关键角色，或者关键系统 。（考点解析：“关注点”是一个系统中与一个或多个利益相关者相关的利益，它决定了系统的可接受性。关注点可能与系统功能、开发或操作的任何方面有关，包括性能、可靠性、安全性、分和可演化性等考虑因素。术语“关注”和 “需求”不是同义词。关注点是分解为需求的过程的根源。关注点在架构中由这 些需求表示。需求应该是 SMART 的，并且满足特定的指标。） 7 、架构视图和架构视点由架构师用于捕获或建模架构时应遵循的设计要求， 架构视点是不同干系人或相关方公认的设计知识或法则，有时又成为设计模式 。与前序干系人关注点相对应来讲，关注点来源于一方干系人；架构视点是多方干系人公认的，常称其具有通用性。 8 、 从数据视角来看，架构存储库也需要数据架构，因此数据架构阶段 定义了组织的架构存储库的结构。（考点解析：数据架构阶段将定义组织的企业连续性和架构存储库的结构） 9 、 合规性 架构治理过程确保满足监管要求（考点解析：合规流程确保满足法规要求） 10 、 TOGAF 标准定义了架构合规遵从性一致性的级别，在 一致 情况下，已经实现了规范中的某些特性，但这些特征并没有按照以下规范来实现 11 、根据 TOGAF 标准， 监督治理战略的实施需要的是自上而下的能力，这 是 建立架构委员会的关键缘由 （考点解析：成功大的架构治理策略的一个关键要素是跨组织架构委员会来 监督策略的实施） 12 、差距分析贯穿在架构开发 BCD 阶段，综合差距分析在阶段 E ；因此差距分析最早在阶段 B ：业务架构中验证架构的关键步骤。 差距分析突出了基线架构向目标架构迁移所带来的变化影响 。 （考点解析：不一定是待开发的，有可能是要删除的） 13 、 TOGAF 标准中在强调愿景含混或需要澄清时，推荐 业务场景 技术来识 别和理解架构必须满足的需求。（考点解析：业务场景是一种重要的技术，可以在企业架构的各个阶段使用，主要是架构愿景和业务架构，但如果需要，也可以在其他架构域中使用，以直接从业务的高级需求中派生架构的特征。它们用于帮助识别和理解业务需求，从而派生架构开发必须解决的业务需求） 14 、关于架构原则的陈述： 原则是一条一般的发展规则或指导方针、原则声明应当简洁明了、一套好的原则是完整的、它们以标准的方式描述、原则是要持久的，很少修改 。 15 、 残余风险水平 定义为实施缓解措施后的风险分类，要求识别了主要不确定性因素，强调剩余风险较少。 16 、在 ADM 的 A 阶段 进行业务转型准备的初始评估。（考点解析：业务转型准备情况首先在阶段 A 中进行评估，因此在实施和迁移计划中，可以将操作分为阶段 E 和阶段 F ） 17 、根据 TOGAF 标准，基于能力的规划是 专注于业务成果 。（考点解析：基于能力的规划是一种关注业务结果的业务规划技术。它专注于规划、设计和向企业交付战略业务能力。它是业务驱动和业务主导的，它结 合了所有业务线的必要努力，以实现所需的能力。基于能力的计划能够适应大 多数（如果不是全部的）公司业务模式，并且在需要潜在相应能力（如应急准备单位）且多种能力涉及相同资源的组织中特别有用。） 18 、业务架构是被开展的第一个架构活动，因为 它提供其它架构领域开展工作所需的基础知识，又称为先决条件 。 19 、阶段 A 是在收到 发起组织对架构工作的请求，常常是预备阶段形成架构工作请求 。 20 、在 TOGAF ADM 的 F 阶段（迁移规划） ，活动包括评估迁移项目的依赖性、成本和收益。 21 、 定义企业、确定组织环境中的关键驱动因素和要素、定义要使用的框架、定义你架构工作的需求 ，都是预备阶段工作范围。 22 、在阶段 D 中，在开发技术架构时，应该考虑架构存储库中的 TOGAF技术参考模型 。 （考点解析：在 D 阶段的技术架构开发中应考虑 TOGAF TRM ） 23 、在 ADM 的 E 阶段 ，四个架构领域的差距分析结果被综合考虑在内，又成为综合差距分析。 24 、预备阶段的方法时在相关企业中定义“在哪里、什么地方、为什么、谁 以及我们如何构建架构”。其中 “哪里”可以看作是对相关企业的界定、“为什么”可以被视为组织环境中的关键驱动因素和要素、“谁”是指确定发起人利益相关者和受业务指令影响的其他主要利益相关者，以创建企业架构，并确定他们来自企业的需求和优先级、他们与企业的关系以及彼此之间所需的工作行为 。 25 、在阶段 C 中，当要替换现有的应用时，数据架构应该 确定数据迁移需求 （考点解析：当替换现有应用时，将迫切需要将数据（主数据、事务数据和 引用数据）迁移到新的应用。数据架构应确定数据迁移需求，并提供转换、剔 除和清理级别的指标，这些指标将以满足目标应用要求和约束的格式呈现数 据。） 26 、 资产管理成本降低、新技术报告、标准倡议、技术退出 ，都是架构变革的技术相关驱动因素请求。（考点解析：其中战略变革时业务驱动力。） 27 、一个组织购买力一个大型企业应用。因此， 采购产品的信息 可以包含 在组织的解决方案连续体中（考点解析：解决方案连续系列包含解决方案构建块，解决方案构建块可能与具体的产品或解决方案有关。） 28 、 解决方案构建块 代表了企业连续体中定义的架构的详细构造。（考点解析：解决方案连续体将组织环境中可用的内容定义为可重用的解决方案构建块（SBB ）） 29 、根据 TOGAF 标准， 企业连续体 被描述为架构存储库的视图，并提供在架构和解决方案工件演化过程中对其进行可复用性分类的方法。（考点解析：企业连续体提供了架构存储库的视图，显示了这些相关架构从通用到特定、从抽象到具体、从逻辑到物理的演变过程。） 30 、在架构连续体中，解决详细企业需求和业务需求的架构称为 特定级组 织的架构 。 （考点解析：特定于组织的架构被视为处于架构连续体的右端，并且与 IT 客户社区最相关，因为他们描述并指导特定企业或连接企业的扩展网络的解决 方案组件的最终部署） 31 、随着一个在 ADM 阶段创建的架构交付物和工作产品被后续阶段修改，TOGAF 标准通过 版本号 跟踪这些变化。（考点解析：输出是在 ADM 过程中生成的，早期的输出可以在后期修改。 TOGAF 标准建议通过版本号管理输出的版本。在所有情况下， ADM 编号方案都是作为示例提供的，。架构师应该对它进行调整，以满足组织的需求，并与组织使用的架构工具和存储库一起工作。） 32 、根据 TOGAF 标准， 因为可用的架构资产很少 是 ADM 迭代的第一次执行比后面的迭代更困难的原因，因此此时常采用自下而上基线先行的架构开发策略（考点解析：ADM 的第一次迭代通常是最困难的，因为可重用的架构资产相对较少。然而，即使在开发的这个阶段，也会有来自外部资源（如 TOGAF 库）以及整个 IT 行业的架构资产，它们可以用来支持这项工作） 33 、根据 TOGAF 标准，初始实施计划在 ADM 的 阶段 E （机会和解决方案）（考点解析：阶段 E 机会和解决方案为先前阶段定义的架构执行初始实施规划和确定交付工具） 34 、企业连续系列 提供对工件进行虚拟分类的方法，可复用性视角 。 （考点解析：企业连续体是一个模型，它提供了对架构和解决方案构件进行分类的方法，因为它们从一般的基础架构发展到特定于组织的架构。企业连续体包括两个互补的概念：架构连续体和解决方案连续体） 35 、架构内容框架将 交付物 描述为合同规定、正式评审并由涉众签署的工作产品。 （考点解析：可交付成果是一种工作产品，它由合同规定，然后由涉众正式 审查、同意和签署。可交付成果代表项目的输出，而那些以文档形式存在的可交付成果通常将在项目完成时存档，或转换为架构存储库中，作为参考模型、标准或某个时间点架构景观的快照） 36 、 TOGAF 架构开发的 C 阶段 包括数据和应用架构的开发 37 、 描述提议的能力对利益相关者的好处 ，最能描述架构愿景文档的主要用途。 （考点解析：架构愿景为发起人提供了一个关键工具，可以向企业内的涉众和决策者销售所提议的功能的好处。它描述了新功能将如何满足业务目标和战略目标，并在实现时解决涉众关注的问题） 38 、根据 TOGAF 标准， 常用词汇、推荐标准清单、一种基于构建块的企业目标状态设计方法、一组可用于开发各种架构的框架 ，都是架构框架的建议特征。（考点解析：架构框架是一种基础框架，可用于开发各种不同的架构。它描述了一种方法，用一组构建块来设计企业的目标状态，并展开构建块是如何组 合在一起的。它包含一组工具并提供了一个通用词汇表。它还包括一份推荐标 准和可用于实现架构块的兼容产品的列表。） 39 、 TOGAF 标准的 架构开发方法（ ADM ） 部分提供了一系列架构开发阶段，以及每个阶段的叙述（考点解析：《第二部分：架构开发方法》描述了 TOGAF 架构开发方法ADM——一种在多个阶段中逐步开发企业架构的方法） 40 、 一种架构开发的框架和方法 ，最能描述 TOGAF 标准。 （考点解析： TOGAF 标准是一个用于开发企业架构的框架——一个详细的方法和一组支持工具） 41 、 识别项目架构的错误 ，描述了一个架构合规审查的目的。 42 、在阶段 B 、 C 和 D ， 选择参考模型，视点和工具 ，是每一个阶段的第一步 43 、 一个构建块 被 TOGAF 描述为功能包，它被定义以满足跨组织的业务需求。 44 、 它提供了架构项目完成的一个高层次的理想图 ，最能描述架构愿景的目的。 45 、 TOGAF 架构能力框架建议使用 ADM 循环以建立一个架构实践。在这种情况下， 业务架构 将描述针对这个架构实践的组织结构。组织结构在业务架构中梳理，但是坚持业务架构决定组织构，组织结构适应业务架构。 46 、需求管理过程用来组 织整个 ADM 循环的架构需求，前期重在需求识别筛选、后期重在需求变更控制 。 47 、 基础架构 描述了处于该级别的参考模型，即 TOGAF 技术参考模型。 48 、 支持架构信息库的治理的流程 ，最能描述信息类，它在架构存储库中被称为架构能力。 49 、 确定企业架构的组织模型 是预备阶段的目的 50 、根据 TOGAF ，阶段 G 的目标，实施治理，是 确保通过实施项目，与定义的架构一致 。（考点解析：在 G 阶段（实施治理）编织和发布架构契约） 51 、根据 TOGAF ， 定义一组架构原则 被描述为 ADM 准备阶段的方法的一部分。 52 、 由需求驱动的变更，来减少投资 ，这一项描述了针对简单变更，阶段 H的 TOGAF 分类。 53 、 ADM 可以看作这样的一个过程，它采用从企业连续的、更通用的、方 便拿到的、有关可重用的构建块，来填充企业自身的 架构存储库 54 、根据 TOGAF ， 利益相关者 描述了他们在一个系统有关键的角色或关注点。 55 、 在正确的实践以一个安全、可靠、及时的方式把信息传达给正确的人 ，最能描述无边界信息流的概念 56 、 一个方法，以确保一个组织的架构的有效性 ，最能说明 TOGAF 架构治理框架 57 、 ADM 循环的 阶段 E ，所识别出来的差距型架构构建块是实现无关的，需要进行解决方案研究才能形成实现相关。 58 、根据 TOGAF ， 为项目中创建的制品，作为一个交付的容器 ，最能描述一个架构定义文件的目的。 59 、构建块，被视为在解决方案连续的左手边，它被称为 基础解决方案 。 60 、企业连续为架构制品提供分类的方法，当他们从 通用架构到组织特定的架构 演进 61 、 在实施和迁移计划和其他框架之间协调 ，描述了阶段 F ，迁移规划阶段的目标 62 、 TOGAF 使用版本编号惯例来说明基线和目标架构定义的演变， 版本 0.1 在该惯例中表示架构的高度概括。 63 、根据 TOGAF ， 架构原则 定义了整个企业资产使用的一般规则和指引 64 、 ADM 的 阶段 A 包括了获得架构工作声明的批准 65 、 TOGAF 针对架构原则的模版的 隐含（又称为依据） 部分强调了实施原则的要求 66 、 ADM 的 阶段 A 在收到发起方的架构工作请求时开始 67 、 ADM 的 阶段 H 架构变更管理 的目标是确保架构达到原定的业务价值，又称与保持业务价值一致性 68 、 矩阵 是由 TOGAF 架构内容框架描述为一个类型的制品，它显示了两个 维度事物之间的关系 69 、 TOGAF 为一组好的原则定义了五个标准： 完整的、一致的、稳定的、易懂、强健的 。 70 、 针对既定的标准和业务目标，一个架构项目的审查 ，最好地描述了架构合规审查。 71 、 架构 被 TOGAF 描述为组件的结构构成，它们的相互关系，以及原则，指导了设计和随时间的演变 72 、架构层级分为三个层次，能力、分段和 战略 。 73 、 视点 用于指导构建更可重用的架构制品，常类比如架构开发风格、架构设计模式等规则化知识，它用于创建架构模型来更好地解决利益相关方的关注。 74 、 TOGAF 描述一个架构契约的作用为 架构开发方和交付物发起方之间的协议 。 75 、 TOGAF 的 架构开发方法 描述了一步一步的方法来开发企业架构。 76 、 架构能力框架 是 TOGAF 提供作为一组参考资料，它是用于在组织内部建立一种架构能力。 77 、 TOGAF 架构开发阶段的 架构愿景 是一个架构开发周期的第一阶段，它定义承担的架构工作范围和识别利益相关者。 78 、根据 TOGAF ， 实施和迁移计划 文件中的行动应满足业务转型准备评估的原则，确保每个行动满足业务转型可行性。 79 、就企业连续系列而言，“集成信息基础架构”参考模型，指导应用架构设计完善达到通用级 （考点解析：TOGAF 集成信息基础设施参考模型（ III-RM ）是一种通用的系统架构，它关注于与无边界信息流远景相关的需求、构建块和标准） 80 、 业务场景 被推荐为澄清和细化需求的技术，并阐明在阶段 A 中创建的架构愿景。 81 、在阶段 G ，有 架构契约 文件规定架构组织和实施组织之间的联系。 82 、阶段 H 架构变更管理方法的 包括能力测试（评估对业务能力的影响，诸如不影响则属于简单变更、影响一条线属于增量变更、影响全局属于全局变更）、变更管理和测量业务增长，不包括业务场景 。 83 、在准备阶段，当确定企业架构工作的需求时， 应该考虑企业的当务之急包括业务需求、文化诉求、预测财务要求，但不应该考虑技术的优雅为企业 的当务之急 。 84 、 ADM 的 需求管理阶段 是一项持续的活动，它在贯穿整个 TOGAF 架构项目中被访问。 85 、 各企业架构活动风险无处不在，应该在 ADM 的所有阶段进行管理 ，最能描述在 ADM 的风险管理。 86 、 侧重于业务成果的一个业务规划技术 ，最好的描述了基于能力的计划。 87 、 架构原则 提供了这样的基础，即指导架构开发和规划的决策，制定政策，步骤和标准，并支持相互矛盾的情况的解决。 88 、差距分析是在阶段 B 、 C 、 D 和 E ， 它突出变化的影响 ，这最能说明差距分析技术中使用的一个技巧。 89 、 治理架构 是一个实践，通过它，在企业层面上，管理和控制企业架构和其他架构。 90 、 确保各项遵从企业架构 是架构治理的一个重要方面。 91 、根据 TOGAF ，一个 视图 是用来描述一个利益相关者的 关注 。 92 、 沟通项目的技术准备（这里的技术准备是指系统架构设计遵从企业架构设计的合规性） ，描述了一个架构合规性审查的目的。 93 、 TOGAF 中，每一个架构视图都有一个关联的 视点 来描述它，至少是隐含的方式。 94 、 定量的观点来解决实施的测量的 ，该陈述最好的描述了架构需求规格的目的。 95 、关于 TOGAF 构建块， 它们是一组功能包，旨在满足整个组织的业务需求；它们应该有稳定的，发布的接口，允许其他构建块与它们互操作；它们可 能有多种实现，但具有不同的，相互依存的构建块 。 但它们与软件组件对象或Web 服务等同是错误的陈述 。 96 、在 TOGAF ，遗留系统和流程，将要在未来再次使用，它被认为是 可重复使用的解决方案构建块 。 97 、 确保架构的信息在合适的时候传达给合适的利益相关者 ，最好地描述了沟通计划的目的。 98 、 TOGAF 技术参考模型是 一个例子，应根据组织的需要来裁剪 。 99 、 它是一个基础架构，指导局部保守视角的特定级架构开发者提高设计水平，使得技术架构更具基础架构水平 ，这最能说明 TOGAF 技术参考模型。 100 、 TOGAF 中 综合信息基础架构模型 ，指导应用架构集成优化设计，使得应用架构设计达到通用级，使架构师设计架构解决边界信息流。 101 、 ADM 的 阶段 G 实施治理 ，确保了项目实施符合该定义的架构。 102 、 定义要使用的框架和方法 ，是 ADM 准备阶段的目的。 103 、需求管理阶段是 存储需求，并管理它们到有关 ADM 阶段的流向 。 104 、根据 TOGAF ，创建特定的架构的视图时， 参考现有视点库，发现一个现有的可以重复使用的视点 ，是推荐的第一步。 105 、架构连续中的 基础架构 包含了最可重复使用的架构元素。 106 、 一个高层次的基线和目标架构 的描述了架构愿景文件。 107 、根据 TOGAF ， 它是用来构件可重复使用的架构和解决方案资产 ，这最能描述企业连续如何被用在组织和开发架构。 108 、 架构工作请求 文件是从单位的主管高层角色发送到组织架构委员会，触发 ADM 周期的开始。 109 、根据 TOGAF ， 一个实践，通过它，在一个企业范围上控制企业架构 ，这最能描述架构治理。 110 、架构存储库中 参考库 组件保存最好的实践或模板的材料，可以用来构建架构。 111 、 TOGAF 提供了一组参考资料，来在组织内建立流程化操作的架构能力，它被成为 架构能力框架 。 112 、根据 TOGAF ，架构委员会的职责包括： 架构变化的决策、强制架构 的合规性、提高组织的架构纪律的成熟度。但不包括分配资源给架构项目 。 113 、 帮助识别和理解需求 ，这最能说明业务场景技术的目的。 114 、根据 TOGAF ， 贯穿整个实施过程中来治理架构 ，最能描述一个合规评估的目的。 115 、 定义进入到一系列技术平台的技术组件 ，描述了技术架构阶段的主要目的。 116 、 满足企业的特殊需求 ，最能说明为什么 ADM 应改编。 117 、在 TOGAF ADM 的 阶段 E 机会及解决方案阶段 ，差距分析是前期阶段的综合结果。 118 、 帮助识别和了解架构必须考虑的业务需求 ，最能描述一个业务场景的目的是什么。 119 、根据 TOGAF ， 通过变更管理技术来处理的简单变更 ，最好的描述了架构的变更分类，即多个服务器系统被整合到一个系统。 120 、 TOGAF 的 企业连续和工具部分 描述了分类法，它在重用方面对架构活动的输出进行分类。 121 、一个企业协会已经定义了一数据模型，来共享库存和价格信息。从架构可持续性角度， 行业架构 说明与这个模型的描述最为贴切。 122 、在解决方案连续性方面， 组织特定级、领域级、通用系统级、基础级 ，是从特定解决方案到通用解决方案的正确顺序。 123 、 阐明架构愿景 是 TOGAF ADM 阶段 A 的一个关键目标。 124 、业务转型评估的准备技术的主要关注是 确定该组织是否已准备好接受变更 。 125 、 架构工作的请求 文档用于启动 TOGAF ADM 循环。 126 、根据 TOGAF ，如果没有架构资产或架构资产很少时， 自下而上 是开发基线业务架构的常用方法。 127 、 TOGAF ADM 的 阶段 E 是目标架构实施规划的初始阶段。 128 、在 ADM 的 阶段 G ，工作重点是架构契约的治理和管理，它涵盖了总体实施和部署过程。 129 、服务器整合项目，不改变应用的运行特点， 需要简单变更 。 130 、 定义架构原则 是 ADM 预备阶段的目的。 131 、在预备阶段，描述企业架构工作范围时， 业务必要性 需要进行需求和性能度量。 132 、需求管理阶段是负责 管理需求流 。 133 、 它们被用来在企业内部指导决策 ，最能描述架构原则是如何在 ADM中使用的。 134 、架构原则定义模版的推荐内容包括： 名称、原则说明、合理性分析，但不包括强制执行决策 。 135 、架构原则定义有关的五个质量标准： 稳定的、可以理解的、完整的、健壮的、持续的 。 136 、差距分析的主要目的是 识别潜在的不足或功能重叠 。 137 、在差距分析，构建块出现在目标架构中，但没有出现在架构基线中， 说明 需要构建或获取的一个新功能 。 138 、 TOGAF 架构治理框架的概念结构中的元素 包括内容、上下文、信息库和过程流程控制，不包括愿景 。 139 、架构委员会所负责的目标中 包括确保子架构之间的一致性、执行架构规范、识别和审批可重用的组件，不包括批准在企业内部个别机构单位的所提出的战略业务计划 。 140 、 TOGAF 中，架构视点表示 干系人的通用关注 。 141 、 审查项目是否违背既定的架构准则和业务目标 ，最能描述架构合规性审查的目的。 142 、 架构 是由 TOGAF 定义为：体现在它的组件里的系统基本组织，它们之间的相互关系，以及指导其设计和演化的原则。 143 、 TOGAF 提供了一种向导，说明如何使用 ADM 建立一种架构能力， 正确的指导方针包括与建立任何其他能力一样，使用同样的方法；作为一个持续实践不断进行建设；应用 ADM 与特定的愿景，建立实践。不正确的指导方针是对视为一个一次性的项目 。 144 、 TOGAF 构建块 陈述正确的是它们应该由稳定的，发布接口，允许其他构建块与它们互操作；它们是功能包，旨在满足整个组织的业务需求；它们已定义的边界；错误的陈述是他们不应该在其它企业架构工程计划再用 。 145 、架构构建块 定义功能 ，其他作为解决方案构建块 定义功能的实现 。 146 、根据 TOGAF ， 架构师意图的沟通说明 ，最能描述架构定义文件的目的 147 、 发起组织 通常发起请求架构工作。 148 、根据 TOGAF ，最简单的方法是把企业连续看为 架构存储库视图 149 、 技术参考模型包括一组图解模型和对应的分类学 ，这是关于 TOGAF技术参考模型一个真实的陈述。 150 、随着架构的演进，解决方案连续中的资产会走向 组织特定解决方案 151 、综合信息基础架构参考模型（ III-RM ）是一种 应用参考模型 的一个例子。 152 、架构存储库中的 架构能力 的结构信息定义了支持架构存储库的治理流程。 153 、 基础架构 是架构连续最通用的制品。 154 、 ADM 的 阶段 A ，业务原则，业务目标和战略驱动力首先被验证。 155 、 一个工具，用于对利益相关者推销建议的能力带来的收益 ，最好地描述一个架构愿景文件的主要用途 156 、 综合信息基础设施参考模式 是在阶段 C ，应用架构使用最相关的模型。 157 、阶段 B 业务架构的目标 包括描述基线业务架构、制定目标业务架构、选择相关观点的主要利益相关者，不包括确定战略业务计划 。 158 、 业务场景 是 TOGAF 推荐的技术，以帮助识别和理解需求。 159 、数据架构的目标是确定可以由利益相关方可以理解的架构；定义一个 架构，它是完整和一致的；定义一个架构，它是稳定的。不包括定义规范化的数据实体以减少更新异常。 160 、 TOGAF 建议 基于能力的规划 技术，它侧重于实现业务成果，而不仅仅是技术交付。 161 、 TOGAF 的 综合信息基础架构模式 是与无边界信息流的概念密切相关。 162 、 TOGAF 陈述阶段 A ：架构愿景的目标是 验证业务原则，目标，驱动力和关键绩效指标 。 163 、 TOGAF 使用版本编号惯例来说明基线和目标架构定义的演变，此惯例中 版本 1.0 表示正式审查，详细的架构。 164 、 完成业务架构应在信息系统架构之后 ，最能描述在这样的情况下改编 ADM ，即业务原则要求必须使用打包解决方案。 165 、 用于创建新的架构的指引和模版 ，最能描述信息类，它在架构存储库中被称为参考库。 166 、关于 TOGAF 构建块陈述正确的是 构建块规格应与实施松耦合 167 、根据 TOGAF ， 它包含了构建模块和相应的标准 ，这是一个基础架构的特性。 168 、 存储的一部分，它保持架构必须遵从的规范 ，这最能描述标准信息库。 169 、 选择和实施工具 是描述了准备阶段的目标 170 、 确保与目标架构的一致性 ，描述了阶段 G 的目标。 171 、它定义了完成一个架构项目的范围和方法，最能描述架构工作说明书的目的。 172 、 ADM 周期的 阶段 E 部分，构建块差距与工作包相联，而工作包解决了这样的差距。 173 、根据 TOGAF ，为什么业务架构被建议是先开发的架构，原因是 它提供了在其他架构领域从事工作的预备知识 。 174 、这样的实践，通过它在企业级别上管理和控制企业架构，它被称为 架构治理 。 175 、 开发组织特定的企业架构的一个过程 ，最能说明 TOGAF 架构开发方法。 176 、 由需求驱动的变更来增加投资，以创造新的价值可利用 ，最能描述在阶段 H 针对重新架构的变更。 177 、 确保该方法被正确地应用 ，最能说明 ADM 过程被治理的需求。 178 、 产品目录 是由 TOGAF 架构内容框架描述为一种制品，它显示物品清单。 179 、根据 TOGAF ， 构建块组合在一起形成上下文的一种方式 ，最能说明一个架构模式。 （考点解析：架构的核心是对象和对象关系，明确对象关系就是事情的上下 文 180 、根据 TOGAF ， 基础架构 的主要特点，包括开放系统标准和通用构建模块。 181 、 确定利益相关者和他们的关注 是阶段 A 架构愿景的目标。 182 、 业务场景 是 TOGAF 建议用于开发架构愿景。 183 、有关该组织的行业部门通用技术模型被认为是阶段 D 相关的架构资源。 184 、根据 TOGAF ，一个 视图 是一个系统的表示，它从一组相关的 利益相关者 的视角。 185 、 TOGAF 架构原则的模板的 意义 Implication 部分中，应明确说明采用原则对业务的影响和后果，读者应该很容易辨别出答案：“这对我有什么影响？”。 186 、根据 TOGAF ， 关注 对利益相关者来说极为重要的的关键利益。 187 、最能说明差距分析技术的目的是 突出基线和目标架构之间的缺口 。 188 、阶段 A 采用一个 业务场景 来帮助识别和理解业务 需求 ，而他们必须由架构解决。 189 、缓解措施实施后的 TOGAF 的风险分类被称为 剩余的 风险水平。 190 、 架构 是 TOGAF 形容为一个系统的正式描述，或在组件级别上系统的详细设计来指导其实施。 191 、在阶段 B 、 C 和 D ，每个阶段的最后一步是 创建架构定义文件 。 192 、 制品从通用架构演进到组织特定架构 ，最能描述架构制品的状态，当项目进展从 ADM 阶段 A 到 D 。 193 、根据 TOGAF ，视图是用于描述如何满足利益相关者的 关注 。 194 、架构开发方法产生内容，存储在存储库，并根据 企业连续 分类。 195 、 架构元模型、架构能力、架构愿景、 SIB 、参考库、治理日志 是 TOGAF 架构存储库中的主要组成部分之一。 196 、 根据需要允许调整 ，这项最能说明 ADM 版本编号方案仅是示例区分，而不是强制性的编号。 197 、 它必须被调整以满足组织的特定需求 ，最好的描述了 TOGAF 可以作为一个通用架构。 198 、 技术架构 是描述逻辑软件和硬件功能架构领域。 199 、 企业连续性 描述了架构存储库中架构和解决方案制品的分类方法。 200 、架构框架的元素包括 通用词汇表、推荐标准的列表、一个基于构建块来构建信息系统的方法，但不包括系统开发生命周期的软件工程方法 。 201 、为促进企业内部开展有效的架构活动， TOGAF9 建立一个 企业架构能力 。 202 、架构存储库的 标准信息库 包含必需遵循的架构规约。 203 、 ADM 的 阶段 F 是用来完成一组支持实施的过渡架构。 204 、 战略架构 级别的架构愿景提供了整个企业的长远摘要视图。 205 、 描述新的功能将如何解决利益相关者的关注 ，最好地描述了架构愿景文件。 206 、关于架构原则说明正确的是：他们是最有效的，当涵盖全组织使用时；他们都是基于企业原则；尽管他们可能表现为通用，但是也应该根据组织 的文化与目标进行定制。不正确的是 它们都是有关行为和需求的详细策略 。 207 、 ADM 的 架构愿景 阶段，业务场景技术是最重要的。 208 、 流程模型、最佳实践和资产，用来帮助企业架构的生产、使用和维护 ，最好的描述了 TOGAF 。 209 、 ADM 的 阶段 G 实施治理阶段通过架构契约建立架构机构和实施机构之间的连接。 210 、关于需求管理阶段说法正确的是： 这个阶段管理需求的流动，存储它们，并把它们输入输出到 ADM 的有关阶段 。 211 、 TOGAF 定义原则的模板的 隐含 部分，应突出贯彻原则的需求。 212 、在架构合规审查中，一旦审查的范围已经确定，下一步是 定制清单， 来满足业务需求 。 213 、架构合规审查的目的是确保项目的技术准备、确保最佳实践的应用、发现在一个架构项目的错误，除了 发现一个架构项目的业务转型风险 。 214 、根据 TOGAF ，在阶段 B 、 C 和 D ， 选择参考模型、视点和工具 ，这个步骤在开发基准或目标架构之前发生。 215 、 ADM 的 阶段 H 负责评估架构的性能并提出修改建议。 216 、 ADM 的 阶段 G 提供了实施的架构监督。 217 、 TOGAF 的 文档分类模型 的目的是协助 TOGAF 规范的发布管理。 218 、解决方案连续指 架构连续的 相应级别的架构的实现。 219 、根据 TOGAF ，企业连续序列是 帮助设计师之间的沟通和理解 ，以此被用在组织和开发一个架构的。 220 、根据 TOGAF ， 显示从基准架构到目标架构变化的演进 ，最能描述架构路线图的目的。 221 、 SBB 首次出现在 ADM 循环中的 阶段 E 。 （考点解析： SBB 出现在 ADM 的 E 阶段，其中首次考虑了产品特定的构建 块， SBB 定义将实现功能的产品和组件） 222 、 优化一个企业到快速响应业务需求的环境 ，最能描述企业架构的目的是什么。 223 、 它们被用来在企业内部指导决策 ，最能描述架构原则是如何在 ADM中使用的。 224 、 在阶段 E ，构建块变得更加具体到实现的 ，这是有关 TOGAF 构建块及其在 ADM 循环中的使用描述 225 、 确保正式批准往前推进 ，是 TOGAF ADM 阶段 A 的目标。 226 、 TOGAF 9 第 III 部分提供了一组资源，可以用于适应和修改 架构开发方法 。 227 、 组织的任何集合，有一个共同的目标 ，最能说明 TOGAF 如何定义企业。 228 、 TOGAF 有关架构原则的模版的依据（又称 基本原理或隐含） 部分应 突出秉承原则的业务收获。 229 、 说明利益相关方的关切是如何在业务架构中解决的 ，是阶段 B 业务架构的目标。 230 、在解决方案连续中， 基础、共有的系统、行业、组织特定的 ，说的是从通用的解决方案，到企业特定解决方案的正确顺序。 231 、 视图 是由 TOGAF 定义为一个系统的表示，它是从一组相关的关注的角度。 232 、在 TOGAF 中架构治理框架包括 一个模型，它管理包括流程，内容和 上下文 。 233 、 架构委员会 是负责架构合规审查的验收和签字的。 234 、 定义初步实施计划 ，最好地描述 ADM 阶段 E 的目的。 235 、架构存储库的 架构景观 部分显示构建块，它目前在组织内使用。 236 、根据 TOGAF ，在 ADM 的 A 阶段 业务转型准备的初步评估应当发 生。 237 、差距分析将使架构师：发现已经无意中省略的构建块、发现已经有意 消除的构建块、发现所需的新的构建块。除了 发现潜在的供应商提供新的构建块 。 238 、 创建一个架构愿景，然后详细的业务架构 ，最能描述在这样的情形下 改编 ADM ，即为建立架构的业务用例没有很好地被发现。 239 、 确定和实施缓解措施之前的分类 ，最能描述在风险管理初始风险水平 是什么级别。 240 、 TOGAF 建议 业务转型准备的评估 技术，用于评估一个面临变革的组织的状态。