系统架构设计方法论——TOGAF

https://blog.csdn.net/watermelonbig/article/details/77620847

1、ADM的架构开发阶段

ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。通过这些开发阶段的工作，设计师可以确认是否已经对复杂的业务需求进行了足够全面的讨论。TOGAF中最为著名的一个ADM基础结构图如下所示：

ADM方法被迭代式的应用在架构开发的整个过程中、阶段之间和每个阶段内部。在ADM的全生命周期中，每个阶段都需要根据原始业务需求对设计结果进行确认，这也包括业务流程中特有的一些阶段。确认工作需要对企业的覆盖范围、时间范围、详细程度、计划和里程碑进行重新审议。每个阶段都应该考虑到架构资产的重用（以往ADM迭代成果、其它框架、系统模型、行业模型等）。

因此，ADM便形成了3个级别的迭代概念：

• 基于ADM整体的迭代，用一种环形的方式来应用ADM方法，表明了在一个架构开发工作阶段完成后会直接进入随后的下一个阶段。
• 多个开发阶段间的迭代，例如在完成了技术架构阶段的开发工作后又重新回到业务架构开发阶段。
• 在一个阶段内部的迭代，TOGAF支持基于一个阶段内部的多个开发活动，对复杂的架构内容进行迭代开发。

2、ADM方法各阶段中的活动

ADM阶段	ADM阶段内的活动
准备阶段	为实施成功的企业架构项目做好准备，包括定义组织机构特定的架构框架、架构原则和工具。
需求管理	完成需求的识别、保管和交付，相关联的ADM阶段则按优先级顺序对需求进行处理。 TOGAF项目的每个阶段，都是建立在业务需求之上并且需要对需求进行确认。
阶段A：架构愿景	设置TOGAF项目的范围、约束和期望； 创建架构愿景； 定义利益相关者； 确认业务上下文环境； 创建架构工作说明书； 取得上层批准。
阶段B：业务架构 阶段C：信息系统架构（应用&数据） 阶段D：技术架构	从业务、信息系统和技术三个层面进行架构开发，在每一个层面分别完成以下活动： 开发基线架构描述； 开发目标架构描述； 执行差距分析。
阶段E：机会和解决方案	进行初步实施规划，并确认在前面阶段中确定的各种构建块的交付物形式； 确定主要实施项目； 对项目分组并纳入过渡架构； 决定途径（制造/购买/重用、外包、商用、开源）； 评估优先顺序； 识别相依性。
阶段F：迁移规划	对阶段E确定的项目进行绩效分析和风险评估； 制订一个详细的实施和迁移计划。
阶段G：实施治理	定义实施项目的架构限制； 提供实施项目的架构监督； 发布实施项目的架构合同； 监测实施项目以确保符合架构要求。
阶段H：架构变更管理	提供持续监测和变更管理的流程，以确保架构可以响应企业的需求并且将架构对于业务的价值最大化。

3、ADM方法的详细说明

在以下的表格中从目标、步骤、输入和输出几个方面对ADM环中的每个阶段进行了分析和描述。

3.1 准备阶段

目标	步骤
对进行企业架构活动的组织的背景和环境进行审查 ； 确认利益相关者、他们的需求、优先级和需要承担的义务； 确定并审视企业机构中受到影响的部分，并对其范围进行界定，定义约束条件和假设条件，这一点在使用联邦式体系结构环境的大型机构中特别重要； 定义组织的“架构足迹”，包括确定执行架构开发工作的人是谁、他们在哪里以及他们的责任是什么； 定义用于进行企业架构建设的框架和详细方法，这里通常是对ADM进行适应性的改变； 确定一个治理和支持框架，用来在整个ADM过程中为架构治理提供业务流程和资源方面的支持，此种框架将会确保目标架构的适用性（fitness-for-purpose），并对其在进行过程中的效能进行评测； 选择和落实用于支持架构活动的各种工具和基础设施； 定义架构原则，而这些原则将会成为约束架构工作的一个部分 。	界定将要受到影响的企业组织的范围 ； 确定治理和支持框架； 建立企业架构团队； 定义架构原则； 选择架构框架并剪裁定制； 落实相关架构工具。
输入	输出
TOGAF架构框架资料； 其它的架构框架资料； 业务原则、业务目标和驱动力； 架构治理策略； IT战略； 当前企业架构组织模型； 当前企业架构框架； 当前企业架构原则； 当前企业架构资源库。	企业架构的组织模型； 定制的企业架构框架，包括架构原则； 企业架构资源库的雏形； 针对业务目标、原则和驱动力的声明或引用 ； 治理框架； 架构工作要求书。

3.2 阶段A——架构愿景

在架构愿景阶段，将启动一次架构开发过程的迭代，设置迭代工作的范围、约束和期望，创建架构愿景、验证业务上下文，创建架构工作说明书并取得大家的一致认可。

愿景表达了我们对架构的期望结果，阐明重要涉众关注的问题和目标，可帮助团队关注架构的核心领域。

目标	步骤
获取管理层对这次特定的ADM循环的相关承诺； 制订一个架构开发周期； 确认业务原则、业务目标、驱动力和KPI（key performance indicators） 定义基线架构的范围，明确其所包含的组件以及组件的优先级； 确认相关干系人、他们的关注点和目标； 定义架构工作所要解决的关键业务需求，以及必须应对的各项约束； 阐明架构愿景，并定制价值主张，这些价值主张被用来阐述对于那些需求和约束的回应； 创建一个符合企业项目管理框架要求的综合计划； 取得继续下一个步骤工作的正式批准； 理解与其他并行的企业架构开发循环之间的相互影响。	成立架构项目； 识别干系人、关注点和业务需求； 确定并阐述业务目标、驱动力和约束； 评估业务能力； 评估业务转型的准备情况； 定义范围； 确认并阐述架构原则，包括业务原则； 开发架构愿景； 定义目标架构的价值主张和KPI； 识别业务转型风险和应对措施； 开发企业架构计划和架构工作说明书，并确保被批准。
输入	输出
架构工作要求书； 业务原则、业务目标和驱动力； 企业架构的组织模型，包括受影响的组织范围、成熟度评测、差距及解决办法、架构团队所担当的角色和职责； 定制的架构框架，包括定制的架构方法、架构内容、架构原则和配置部署工具； 初具内容的架构资源库（包含初始的框架说明、架构描述和基线描述内容）	得到批准的架构工作说明书： 范围和约束 架构工作计划 角色和职责 风险与应对措施 工作产品效能评测 业务案例与KPI指标 改善的业务原则、业务目标和驱动力说明； 架构原则； 能力评估； 定制的架构框架（方法、内容、工具）； 架构愿景： 改善的关键高层次干系人的需求 基线业务架构0.1版 基线数据架构0.1版 基线应用架构0.1版 基线技术架构0.1版 目标业务架构0.1版 目标应用架构0.1版 目标数据架构0.1版 目标技术架构0.1版 沟通计划 纳入到架构资源库中的新增内容

3.3 阶段B——业务架构

在业务架构阶段，将开发一个支持架构愿景的业务架构。架构愿景中概括的基线和目标业务架构将在此被细化，从而使它们可以作为技术分析的有用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术，这又包含了所期望状态的差距分析。

本阶段的核心内容包括组织如何满足业务目标；企业静态特征（业务目标、业务组织结构、业务角色）；企业动态特征（流程、功能、服务）。

目标	步骤
描述基线业务架构； 开发目标业务架构； 执行以上二者间的差距分析； 选择和开发相关的架构视角，通过这些视角架构师可以阐述业务架构是如何对各干系人的关注点进行解答的； 确定与架构视角相关的工具和技术。	选择参考模型、视角和工具； 开发基线业务架构描述； 开发目标业务架构描述； 执行差距分析； 定义架构路线图组件； 分析对整个架构的影响； 涉众评审； 最终确定业务架构； 创建架构定义文档。
输入	输出
架构工作要求书； 业务原则、业务目标和驱动力； 能力评估； 沟通计划； 企业架构的组织模型； 得到批准的架构工作说明书； 业务架构原则，包括在此之前已经存在了的业务原则； 定制的架构框架； 企业连续体： 架构资源库； 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准 架构愿景，包括： 经过改善的关键高层次干系人的需求 基线业务架构0.1版 基线数据架构0.1版 基线应用架构0.1版 基线技术架构0.1版 目标业务架构0.1版 目标应用架构0.1版 目标数据架构0.1版 目标技术架构0.1版	架构工作说明书（Update）； 经过验证的业务原则、业务目标和驱动力； 详细的业务架构原则； 架构定义文档草稿： 基线业务架构1.0版本，如果有的话； 目标业务架构1.0版本 组织结构 业务目标 业务功能 业务服务 业务流程，包括测评和交付物 业务角色，包括相关技能需求的发展与改进 业务数据模型 组织和功能之间的相互关联 主要涉众关注的业务架构视图； 架构需求说明书草稿： 差距分析的结果； 技术需求； 更新的业务需求； 架构路线图的业务架构组件。

3.4 阶段C——信息系统架构

在信息系统架构设计阶段，确定主要的信息类型和处理这些信息的应用系统。在本阶段有两个主要的步骤，数据架构设计和应用架构设计，二者既可以依次开发，也可以并行开发。核心内容为：IT系统如何满足企业的业务目标；信息以及信息之间的关系；应用以及应用之间的关系。

3.4.1 数据架构

目标	步骤
定义业务运行所需的数据源和数据类型。	选择参考模型、视角和工具； 开发基线数据架构1.0版； 开发目标数据架构1.0版； 执行差距分析； 定义组件； 分析对整个架构的影响； 涉众评审； 确定最终的数据架构； 完善架构定义文档。
输入	输出
架构工作要求书； 能力评估； 沟通计划； 企业架构的组织模型； 定制的架构框架； 数据原则（如果有的话）； 架构工作说明书； 架构资源库： 可重用的构建块 公开可得的参考模型 组织特定的参考模型 组织标准 架构定义文档草稿，包括： 基线业务架构1.0版； 目标业务架构1.0版； 基线数据架构0.1版； 目标数据架构0.1版； 基线应用架构（0.1或1.0版）； 目标应用架构（0.1或1.0版）； 基线技术架构（0.1版）； 目标技术架构（0.1版）； 架构需求说明书草稿，包括： 差距分析结果； 适用于此阶段的相关技术需求； 在架构路线图中的业务架构组件。	经过改善或更新的架构愿景阶段中的各交付物： 架构工作说明（Update）； 经过验证的数据原则或新增的数据原则； 更新的架构定义文档草稿： 基线数据架构1.0版； 目标数据架构1.0版： 业务数据模型 逻辑数据模型 数据管理流程模型 数据实体/业务功能矩阵 主要涉众关注的数据架构视图； 更新的架构需求说明书： 差距分析结果； 数据集成需求； 适用于当前阶段的相关技术需求； 对于下一步将要设计的技术架构的约束； 更新的业务需求； 更新的应用需求； 架构路线图中的数据架构组件。

3.4.2 应用架构

目标	步骤
定义处理数据并支撑业务运行所需的各种应用系统。	选择参考模型、视角和工具； 开发基线应用架构1.0版； 开发目标应用架构1.0版； 执行差距分析； 定义组件； 分析对整个架构的影响； 涉众评审； 最终确定应用架构； 完善架构定义文档。
输入	输出
架构工作要求书； 能力评估； 沟通计划； 企业架构的组织模型； 定制的架构框架； 应用原则； 架构工作说明书； 架构资源库： 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准 架构定义文档草稿，包括： 基线业务架构1.0版； 目标业务架构1.0版； 基线数据架构（0.1版或1.0版）； 目标数据架构（0.1版或1.0版）； 基线应用架构0.1版； 目标应用架构0.1版； 基线技术架构0.1版； 目标技术架构0.1版； 架构需求说明书草稿，包括： 差距分析结果； 适用于此阶段的相关技术需求； 架构路线图的业务架构组件和数据架构组件。	经过改善和更新的架构愿景阶段中的各交付物： 架构工作说明（Update）； 经过验证的应用原则或新增的应用原则； 更新的架构定义文档： 基线应用架构1.0版 目标应用架构1.0版 主要涉众关注的应用架构视图 更新的架构需求说明书： 差距分析结果 应用交互需求 适用于当前阶段的相关技术需求； 对于将要设计的技术架构的约束； 更新的业务需求； 更新的数据需求； 架构路线图的应用架构组件。

3.5 阶段D——技术架构

在技术架构阶段，完成对IT系统基础服务设施的设计，定义了架构解决方案的物理实现，包括硬件、软件和通信技术。

目标	步骤
开发一个目标技术架构，并以此作为后续的实施和迁移计划的基础。 将应用架构中定义的各种应用组件映射为相应的技术组件， 这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。	选择参考模型、视角和工具； 开发基线技术架构1.0版； 开发目标技术架构1.0版； 执行差距分析； 定义组件； 分析对整个架构的影响； 涉众评审； 技术架构定稿； 完善架构定义文档。
输入	输出
架构工作要求书； 能力评估； 沟通计划； 企业架构的组织模型； 定制的架构框架； 技术原则； 架构工作说明书； 架构资源库（4方面）； 架构定义文档草稿，包括： 基线业务架构1.0版 目标业务架构1.0版 基线数据架构1.0版 目标数据架构1.0版 基线应用架构1.0版 目标应用架构1.0版 基线技术架构0.1版 目标技术架构0.1版 架构需求说明书草稿，包括： 差距分析结果 来自于之前各阶段的相关技术需求 架构路线图的业务、数据和应用架构组件。	经过改善和更新的架构愿景阶段中的各交付物： 架构工作说明（Update） 经过验证的或新增的技术原则； 更新的架构定义文档： 基线技术架构1.0版 目标技术架构10.版 各技术组件以及他们与信息系统之间的关系 各技术平台以及它的结构组成 环境和位置 期望的处理负荷以及技术组件间的负荷分布 物理（网络）通信 硬件及网络说明 主要涉众关注的技术架构视图 更新的架构需求说明书： 差距分析结果 从业务架构和信息系统架构阶段输出的需求 更新后的技术需求 架构路线图的技术架构组件。

3.6 机会及解决方案

这是第一个直接关注实施的阶段，该阶段主要描述确定目标架构交付物（项目、程序或文件）的过程。

目标	步骤
重新审查业务目标和业务能力，合并从阶段B到阶段D的差距分析，确定主要工作包并分组； 重新审查并确认企业承受变化的能力； 获得一系列过渡架构，它们可以通过对各种机会的开发利用，来为各构建块的实现提供持续的业务价值； 产生概要性的实施与迁移策略，并取得共识。	确定关键的公司变更属性； 确定项目实施的业务约束； 审查并合并从阶段B到阶段D的差距分析结果； 从功能的角度审查IT需求； 确定并加强交互需求； 改善并验证依赖关系； 确认业务转型的准备情况和风险； 制订高层次的实施和迁移策略； 识别主要的工作包并进行分组； 确定过渡架构； 创建项目投资组合和项目章程，同时对架构进行更新。
输入	输出
产品信息； 架构工作要求书； 能力评估； 沟通计划； 规划方法； 企业架构的组织模型； 定制的架构框架； 架构工作说明书； 架构愿景； 架构资源库； 架构定义文档草稿（v1.0版的4个基线架构和4个目标架构）； 架构需求说明书草稿： 差距分析结果（业务、数据、应用和技术架构） 架构需求 IT服务管理一体化要求 现存业务程序或项目的变更请求。	经过改善和更新的架构愿景、业务架构、信息系统架构和技术架构阶段中的各交付物： 架构工作说明（Update）； 架构愿景（Update）； 架构定义文档草稿： 识别出的增量内容 交互和共存需求 实现和移植策略 项目清单和项目章程 架构需求说明书草稿（Update）； 能力评估： 企业架构成熟度概况 转型准备工作报告 过渡架构1.0版： 确定的关于差距、解决方案和依赖性的评估 风险注册表1.0版本 影响分析（项目列表） 依赖性分析报告 实施因素的评估和推导矩阵(Deduction Matrix) 实施和迁移计划0.1版本（概述）

3.7 阶段F——迁移规划

该阶段通过制订一个详细的实现和迁移计划完成从基线架构向目标架构的转变。

目标	步骤
确保实施和迁移规划与企业中正在使用的各种管理框架相协调； 通过分配业务价值和执行业务成本分析，划分所有工作包、项目和构建块的优先级； 最终确定架构愿景和架构定义文档，使其与共同商定的实施方法一致； 与相关干系人一起确认在机会和解决方案阶段中定义的过渡架构； 创建、演进并监控详细的实施和迁移规划，提供实现过渡架构所需的各种资源。	确定管理框架与实施和迁移规划之间的相互作用； 为每个项目指定业务价值； 估算资源需求、项目时间和交付工具； 通过绩效评估和风险验证，确定迁移项目的优先级； 确定过渡架构的增量内容并更新架构定义文档； 生成架构实现路线图（有时间标识）和迁移计划； 创建架构演进循环并记录收到的经验教训。
输入	输出
架构工作要求书； 能力评估（企业架构成熟度概况和转型准备报告）； 沟通计划； 企业架构的组织模型； 治理模型和框架： 企业架构管理框架 能力管理框架 投资组合管理框架 项目管理框架 运营管理框架 定制的架构框架； 架构工作说明； 架构愿景； 架构资源库； 架构定义文档草稿： 迁移规划策略 影响分析（项目列表和章程） 架构需求说明书草稿： 差距分析结果（业务、数据、应用和技术架构） 架构需求 IT服务管理一体化要求 现存业务程序和项目的变更请求； 经过确认和验证的架构路线图； 过渡架构1.0版： 确定的关于差距、解决方案和依赖性的评估 风险注册表1.0版本 影响分析（项目列表） 依赖性分析报告 实施因素评估和推导矩阵 实现和迁移计划0.1版。	实施和迁移计划1.0版； 定稿的架构定义文档； 定稿的架构需求说明书； 定稿的架构路线图； 定稿的过渡架构； 可重用的架构构建块； 架构工作要求书（各实施项目，如果有的话）； 架构契约（关于各实施项目）； 实施治理模型； 从经验教训中产生的变更请求。

3.8 阶段G——实施治理

该阶段定义了实施项目的架构约束，提供项目构建的架构监督，产生一个架构契约。

目标	步骤
为每个实施项目给予建议； 对涵盖整个实施和部署过程的架构契约进行治理； 在解决方案正在实施和部署时，行使恰当的治理职责； 确保各实施项目符合于规定的架构； 确保按工作计划成功部署了解决方案的相关程序； 确保已经部署的解决方案与目标架构一致； 组织各种支持性行动，确保被部署的解决方案长期有效。	通过开发管理工作，确认部署的范围和优先级； 明确用于部署的资源和技能； 指导部署解决方案的开发工作； 执行企业架构合规审查； 实施业务和IT运营； 执行实施后审查并结束实施工作。
输入	输出
架构工作要求书； 能力评估； 企业架构的组织模型： 受影响的组织范围 成熟度评测、差距及解决方法 架构团队所担当的角色和职责 架构工作的约束 预算需求 治理和支持策略 定制的架构框架： 定制的架构方法 定制的架构内容（交付物和制品） 配置和部署工具 架构工作说明书； 架构愿景； 架构资源库： 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准 架构定义文档； 架构需求说明书： 架构需求 差距分析结果（业务、数据、应用和技术） 架构路线图； 过渡架构； 实施治理模型； 架构契约； 架构工作要求书（经过机会与解决方案和迁移规划阶段明确的）； 实施和迁移计划。	架构契约（签字）； 变更请求； 影响分析（实施）； 建议； 可部署的符合架构要求的解决方案： 实现的符合架构要求的系统 填充了相关资料的架构资源库 架构合规性建议与特许 对服务交付需求的建议 关于效能指标的建议 服务水平协议（SLAs） 在实施后经过更新的架构愿景 在实施后经过更新的架构定义文档 在实施后经过更新的过渡架构 已实施解决方案的业务和IT运营模型

3.9 阶段H——架构变更管理

该阶段确保能够以一种可控制的方式对架构的改变进行管理。

目标	步骤
确保基线架构持续符合当前实际情况； 评估架构性能并提出改进建议； 评估在之前阶段中制定的框架和原则的变化； 为实施治理阶段建立的新的企业架构基线建立一个架构变更管理流程； 将架构和运营的业务价值最大化； 运用治理框架。	建立价值实现过程； 部署监控工具； 管理风险； 提供架构变更管理分析； 开发变更需求以满足性能目标； 管理治理过程； 启动实施变更的流程。
输入	输出
在阶段E和F中确认的架构工作要求书； 企业架构的组织模型； 架构工作说明书； 架构愿景； 架构资源库； 架构定义文档； 架构需求说明书； 架构路线图； 由技术变化产生的变更请求： 新技术报告 资产管理成本削减措施 技术退出报告 各标准举措 由业务变化产生的变更请求： 业务发展 业务异常 业务革新 业务技术革新 战略变化发展 由经验教训产生的变更请求； 过渡架构； 实施治理模型； 架构契约（签字）； 合规性的评估； 实施和迁移计划。	架构的各种更新； 对架构框架和原则的变更； 新的架构工作要求书，用于发起另一次ADM循环； 架构工作说明书（Update）； 架构契约（Update）； 合规性的评估（Update）。

3.10 需求管理

架构需求管理适用于ADM的所有阶段，这是一个动态的过程，完成对企业需求的识别、存储并把它们插入或取出相应的ADM阶段。需求管理是ADM流程的中心。处理需求变化的能力对于ADM过程是非常重要的，架构通过其天然处理不确定性和变化的能力在涉众诉求之间架起桥梁并交付一个可实践的解决方案。

目标	步骤
定义一个可以贯穿ADM循环各个阶段的管理架构需求的过程； 识别和存储企业需求并与相应的ADM阶段进行交互。	通过业务情景或其它模拟技术来识别并记录需求（ADM各阶段）； 建立需求基线： 确定产生于当前架构开发方法阶段的各优先级事项 确认干系人认可各个结果优先级事项 记录需求优先级并将其放入需求库 监控需求基线； 识别发生变更的需求（ADM各阶段）： 增、删、改处理并重新评定优先级 识别并解决冲突 生成需求影响说明 评估变更的需求对现在和之前的ADM阶段产生的影响（ADM各阶段）； 实施架构变更管理阶段的需求（ADM架构变更管理阶段）； 更新需求资源库； 实施当前阶段的需求变更（ADM各阶段）； 评估并修订先前阶段的差距分析（ADM各阶段）。
输入	输出
各个ADM阶段中与需求相关的输出就是需求管理流程的输入； 最初高层次的需求是作为一部分的架构愿景所产生； 每个架构领域都有相应的详细需求，之后的ADM阶段交付物也包含了对新的需求类型的映射（如一致性需求）。	更新的架构需求说明（如有必要）； 需求影响的评估，识别出需要回到的ADM阶段。最终版本必须包含需求的全部含义（如成本、时间范围和业务流程）。

3.11 建立架构活动的范围

ADM方法不能够确定架构活动的范围，这必须由企业自己确定。需要限定架构活动范围的原因与以下因素有关：

• 创建架构的团队所具备的组织权力；
• 需要在架构中实现的目标和干系人的诉求；
• 可利用的人、资金以及其它资源。

选定的架构活动范围理论上应该地支持企业中的架构师高效地完成治理和整合工作。这需要一套一致的“架构分区”，确保架构师不会从事重复劳动或冲突的活动。这同样需要定义重用和多个架构分区间的服从关系。下表从四个维度对架构活动范围的限定进行了说明。

维度	考察
企业范围或焦点	企业最大的业务范围是什么？其中又有多少是需要架构工作聚焦的？ 许多企业的规模非常大，实际上形成了一个组织单位成员的联盟，每个成员都有自己独立的企业权利。 现代企业越来越突破它的传统界线，包括了一个由供应商、客户和合作伙伴形成的模糊的传统行业企业联盟。
架构领域	一个全面的企业架构描述应该包括全部四个架构领域（业务、数据、应用、技术），但是实际的资源和时间约束经常意味着没有充分的时间、资金或其它资源去设计一个自顶而下的、包含全部四个架构领域的架构描述。即使在选定的架构活动范围小于企业整体业务范围时也是这样。
详述垂直范围或级别	架构工作应该细化到第几层？怎么样的架构工作才算充分的？ 架构工作和其它相关工作（系统设计、系统工程以及系统开发）的界线是什么？
时间周期	架构愿景的准确时间周期是什么？它是否意味着要在这个时间期间内用详细的架构描述填充满？如果不是，那么需要定义多少个中间级别的目标架构，并且它们的时间周期是多少？

转载于:https://www.cnblogs.com/xiang--liu/p/9710229.html