【TOGAF系列】架构开发方法（ADM）第一章

本章介绍了架构开发方法（ADM）周期，调整ADM、架构范围和架构集成。

1.1 ADM概述

TOGAF ADM描述了一种开发和管理企业架构生命周期的方法，并构成了TOGAF标准的核心。
它集成了TOGAF标准的元素以及其他可用的架构资产，以满足组织的业务需求。

1.1.1 ADM、企业连续体和架构存储库

企业连续体提供了一个框架和上下文，以支持在执行ADM时利用相关架构资产。这些资
产可能包括来自各种来源的架构描述、模型和模式，如TOGAF标准——架构内容中所述。
企业连续体对架构源材料进行分类，包括组织自己的企业存储库的内容以及行业中相
关的可用参考模型和标准集。

企业连续体的实际实现通常采用架构存储库的形式（参见TOGAF标准——架构内容），
其中包括已被企业内部接受使用的参考架构、模型和模式，以及之前在企业内部完成的实际架构
工作。架构师将寻求尽可能多地重用架构库中与手头项目相关的内容。（除了收集架构源材料外，
存储库还将包含正在进行的架构开发工作。）

在整个ADM的相关位置，有提醒要考虑架构师应该使用架构库中的哪些架构资产（如果有的话）。

在某些情况下，例如在技术架构的开发中，这可能是TOGAF基础架构。在其他情况下，例如在业务架构的开发中，它可能是整个行业电子商务的参考模型。将源材料纳入组织架构库的标准通常将构成企业架构治理过程的一部分。这些治理过程应考虑企业内外的可用资源，以确定何时可以调整一般资源以满足特定的企业需求，并确定在哪里可以推广特定的解决方案以支持更广泛的重用。
在使用ADM时，架构师正在开发企业决策的快照，它们在特定时间点的影响。ADM的每次迭代都将填充一个特定于组织的环境，其中包含在整个过程中识别和利用的所有架构资产，包括最终交付的特定于组织架构。

架构开发是一个连续的、循环的过程，随着时间的推移，在反复执行ADM的过程中，架构师逐渐向组织的架构库添加越来越多的内容。尽管ADM的主要重点是开发特定于企业的架构，但在更广泛的背景下，ADM也可以被视为用从企业连续体的“左侧”、更通用的一侧获取的相关可重用构建块填充企业自己的架构存储库的过程。

事实上，ADM的第一次执行通常是最困难的，因为可供重用的架构资产将相对稀缺。然而，即使在开发的这个阶段，也会有来自外部来源（如TOGAF标准）以及整个IT行业的架构资产可用于支持这项工作。

随着越来越多的架构资产被识别出来，用于填充组织的架构存储库，并因此可供将来重复使用，
后续执行将更容易。

1.1.2 ADM和基础架构

ADM对于填充企业的基础架构也很有用。企业的业务需求可用于确定基础架构中必要的定义和选择。这可能是一组可重复使用的通用模型、政策和治理定义，甚至与覆盖技术选择一样具体（例如，如果法律强制要求）。基础架构的填充遵循与企业架构类似的原则，不同之处在于，整个企业的需求仅限于整体关注点，因此不如特定企业完整。

重要的是要认识到，来自这些不同来源的现有模型在集成时，不一定能形成连贯的企业架构。第
1.7节考虑了架构描述的“可集成性”。

1.1.13 ADM、支持指南和技术

TOGAF ADM的应用得到了一组扩展资源的支持——指南、模板、清单和其他详细材料。这些包括在：

• TOGAF标准——ADM技术
• TOGAF系列指南——标准的指导部分（关于如何根据特定需求使用和调整TOGAF标准的指导材料）
• The Open Group发布的白皮书和指南，在TOGAF库中分类和引用（www.opengroup.org/togaf-library）

单独描述各个指南和技术，以便在必要时可以从ADM中的相关点引用它们，而不是让详细的文本弄乱ADM本身的描述。

1.2 架构开发周期

1.2.1 关键点

以下是ADM的关键点：
■ ADM在整个过程中、阶段之间和阶段内都是迭代的（参见TOGAF标准-ADM技术）
对于ADM的每次迭代，必须就以下方面做出新的决定：
— 企业的覆盖范围
— 详细程度
— 目标时间段的范围，包括任何中间时间段的数量和范围
— 要利用的架构资产，包括：
— 在企业内ADM周期的先前迭代中创建的资产
— 行业其他地方可用的资产（其他框架、系统模型、垂直行业模型等）
■ 这些决策应基于对资源和能力可用性的实际评估，以及从所选架构工作范围中可以实际预期
为企业带来的价值
■ 作为一种通用方法，ADM旨在供各种不同地区的企业使用，并应用于不同的垂直部门/行业类
型

因此，它可以但不一定必须根据具体需求量身定制。例如，它可以与另一个框架的一组可交
付成果结合使用，这些成果被认为更适合特定组织。（例如，许多美国联邦机构已经制定了
单独的框架，根据其特定的部门需求定义了可交付成果。）

第1.3节详细讨论了这些问题。

1.2.2 基本结构

ADM的基本结构如下图所示。在整个ADM周期中，需要经常验证结果是否符合最初的预期，包括整个ADM周期的预期和流程特定阶段的预期。

ADM循环的阶段进一步分为步骤，这些步骤在每个阶段的详细描述中进行了定义。
需求管理阶段是一个持续的阶段，确保对需求的任何更改都通过适当的治理流程进行处理，并反
映在所有其他阶段。企业可以选择通过单个需求库记录所有新需求，包括当前架构工作说明书范
围内的需求。

以下章节详细描述了循环的各个阶段。请注意，输出是在整个过程中生成的，早期阶段的输出可能会在后期进行修改。在ADM中，定义了每个阶段的输出状态。

输出的生命周期必须通过版本编号策略进行管理，由架构师调整以满足组织的要求，并与组织使
用的架构工具和存储库配合使用。

在ADM中，正在开发且未经过任何正式审查和批准程序的文件被指定为“草案”。根据组织的治理
实践，已审查和批准的文件被指定为“已批准”。批准并不一定意味着最终确定。文档可能会在
后续阶段发生变化，但只能通过适当的变更控制和治理流程进行更改。这在ADM中特别用于说明基线和目标架构定义的演变。

1.3 调整ADM

ADM是一种通用的架构开发方法，旨在处理大多数系统和组织需求。然而，通常需要修改或扩展
ADM以满足特定需求。应用ADM之前的任务之一是审查其组件的适用性，然后根据单个企业的情况进行适当的调整。这项活动很可能会产生“企业特定”的ADM。

想要调整ADM的一个原因是，ADM中阶段的顺序在某种程度上取决于企业内架构学科的成熟度，这一点很重要。例如，如果做架构的商业案例没有得到很好的认可，那么创建架构愿景几乎总是必
不可少的；接下来通常需要一个详细的业务架构，以支持架构愿景，详细说明剩余架构工作的业
务案例，并确保关键利益相关者积极参与该工作。在其他情况下，可能会选择稍微不同的顺序；
例如，在进行业务架构之前，可以对基线环境进行详细的盘点。

阶段的顺序也可以由企业的架构原则和业务原则来定义。例如，业务原则可能要求企业准备调整
其业务流程以满足打包解决方案的需求，以便快速实施，从而能够快速响应市场变化。在这种情
况下，业务架构（或至少是它的完成）可能很好地遵循信息系统架构或技术架构的完成。

想要调整ADM的另一个原因是，如果TOGAF框架要与另一个企业框架集成（如TOGAF标准-介绍和核心概念中所述）。例如，企业可能希望将TOGAF框架及其通用ADM与Zachman®框架结合使用，或者使用另一个企业架构框架，该框架具有一组特定于特定垂直部门的可交付成果：政府、国防、电子商务、电信等。ADM的设计考虑到了这种潜在的集成。

想要调整ADM的其他可能原因包括：

■ ADM是构成公司治理模式的众多公司流程之一
它补充并支持其他标准项目管理流程，如授权、风险管理、业务规划和预算、开发规划、系
统开发和采购。

■ ADM被授权由主承包商或主要承包商在外包情况下使用，需要量身定制，以在承包商的现有
做法和承包企业的要求之间实现适当的妥协

■ 该企业是一家中小型企业，希望使用一种“精简”方法，以更适应这种环境中典型的资源和
系统复杂性的降低水平

■ 企业非常庞大和复杂，在一个整体的协作业务框架内由许多独立但相互关联的“企业”组成，
需要调整架构方法来认识到这一点

在这种情况下，可以使用不同的规划和整合方法，包括以下方法（可能结合使用）：
— 自上而下的规划和开发——将整个相互连接的元企业设计为一个单一的实体（这项工
作通常会超出实用性的极限）

— 开发一个“通用”或“参考”架构，这是组织内企业的典型，但不代表任何特定的企
业，然后期望各个企业进行调整，以产生适合特定企业的架构“实例”

— 复制——为一个企业开发一个特定的架构，将其作为概念验证来实现，然后将其作为
“参考架构”在其他企业中克隆

■ 在供应商或生产环境中，一系列相关产品的通用架构通常被称为“产品线架构”，与上述类
似的过程被称为（基于架构的）产品线工程。ADM主要针对IT用户企业中的架构师，但其产
品基于IT的供应商组织可能希望将其作为产品线架构开发的通用方法。

ADM各阶段的描述包含适用于任何企业的可交付成果和工件列表。调整可交付成果和工件以反映企业对所需架构的特定需求非常重要。

调整内容框架和企业元模型，定义特定于组织的可交付成果和工件，以及ADM阶段描述中引用的特定可交付成果的详细描述，可以在TOGAF标准-架构内容中找到。

ADM还可以进行调整，以支持敏捷企业架构交付风格，并实现企业敏捷性。有关如何调整ADM的详细指导，请参阅以下文件：
■ TOGAF®系列指南：实现企业敏捷性
■ TOGAF®系列指南：使用敏捷Sprints应用ADM
关于调整ADM流程的更多指导，请参阅TOGAF标准——应用ADM，以及TOGAF®系列指南：遵循TOGAF ADM开发企业架构的从业者方法。

1.4 架构治理

ADM，无论是由组织改编还是如本文所述使用，都是一个关键过程，需要以与通过企业连续体分类并保存在架构存储库中的其他架构工件相同的方式进行管理。架构委员会应确信该方法在架构开
发迭代的所有阶段都得到了正确应用。遵守ADM是架构治理的基础，以确保考虑所有因素并产生所有必需的交付成果。

所有架构工件、治理和相关流程的管理都应该得到受控环境的支持。通常，这将基于一个或多个
支持版本化对象、流程控制和状态的存储库。

治理存储库管理的主要信息区域应包含以下类型的信息：

• 参考数据（来自组织自己的存储库/企业连续体的抵押品，包括外部数据；例如COBIT®、IT4IT参考架构）：用于项目实施期间的指导和说明。这包括上述信息的细节。参考数据包括对治理程序本身的描述。
• 流程状态：将管理有关任何治理流程状态的所有信息，这方面的例子包括未完成的合规请求、豁免请求和合规评估调查。
• 审计信息：这将记录所有已完成的治理过程操作，并将用于支持：已通过治理流程批准的任何架构项目的关键决策和负责人；未来架构和支持流程开发、指导和优先级的参考

治理工件和流程本身就是架构存储库内容的一部分。

架构治理在TOGAF标准《企业架构能力和治理》中有详细介绍。

1.5 架构范围界定

限制（或约束）要进行的架构活动的范围有很多原因，其中大多数与以下方面的限制有关：

• 构建架构的团队的组织权威
• 架构内要解决的目标和利益相关者关注的问题
• 人员、资金和其他资源的可用性

理想情况下，为架构活动选择的范围应该允许企业内所有架构师的工作得到有效的管理和整合。
这需要一组对齐。

“架构分区”，确保架构师不会从事重复或冲突的活动。它还需要定义架构分区之间的重用和合
规关系。
TOGAF标准——应用ADM中更详细地讨论了企业的划分及其架构相关活动。
通常使用四个维度来定义和限制架构的范围：
■ 广度：企业的全部范围是什么，这种架构工作将处理该范围的哪一部分？
— 许多企业规模庞大，实际上由一系列组织单位组成，这些组织单位本身就可以被视为
企业
— 现代企业越来越超越其传统界限，拥抱传统企业与供应商、客户和合作伙伴的模糊组
合
■ 深度：架构工作应该达到什么样的细节水平？
多少架构是“足够的”？架构工作和其他相关活动（系统设计、系统工程、系统开发）之间
的适当界限是什么？
■ 时间段：架构愿景需要明确的时间段是什么，在详细的架构描述中涵盖同一时间段（在实用
性和资源方面）是否有意义？
如果没有，要定义多少过渡架构，它们的时间段是什么？
■ 架构域：一个完整的企业架构描述应包含所有四个架构域（业务、数据、应用程序、技术），
但资源和时间限制的现实通常意味着没有足够的时间、资金或资源来构建一个自上而下、包
罗万象的架构描述，涵盖所有四个体系结构域，即使选择的企业范围小于整个企业的范围。

通常，架构的范围首先用广度、深度和时间来表示。一旦理解了这些维度，就可以选择适合所解
决问题的架构域的适当组合。TOGAF标准——应用ADM中讨论了使用ADM开发许多相关架构的技术。

下文将详细探讨架构范围的四个维度。在每种情况下，特别是在必须以联邦方式开发架构的大规
模环境中，架构师都有可能在自己的活动范围内进行优化，而不是在整个企业层面进行优化。为
了在企业层面进行优化，通常需要在特定领域进行二次优化。目标应该始终是寻求最高级别的通
用性，并专注于可扩展和可重用的模块，以最大限度地提高企业级的重用率。

1.5.1 广度

关键决策之一是架构工作的重点，即要覆盖的整体企业活动的广度（哪些特定的业务部门、职能、
组织、地理区域等）。

通常需要在整个企业中存在许多不同的架构，专注于特定的时间框架、业务功能或业务需求。
对于大型复杂企业来说，联邦架构是典型的——独立开发、维护和管理的架构，随后集成到集成
框架中。这样的框架规定了互操作性、迁移和一致性的原则。这允许特定的业务部门将架构作为
独立的架构项目进行开发和管理。有关为不同解决方案指定互操作性要求的更多详细信息和指导，
请参阅TOGAF标准-ADM技术。

为每个业务功能或目的建立一个单一的企业级架构的可行性可能会因为过于复杂和笨重而被拒绝。
在这种情况下，建议企业中存在许多不同的企业架构。这些企业架构侧重于特定的时间框架、业
务部门或功能以及特定的组织要求。在这种情况下，我们需要将总体企业架构创建为这些企业架
构的“联盟”。管理和利用这些企业架构的一种有效方法是采用发布和订阅模型，该模型允许将
架构纳入治理框架。在这种模型中，项目中的架构开发人员和架构消费者（架构工作的供需双方）
签署了一个互惠互利的治理框架，以确保：

■ 架构材料质量好、最新、适合用途，并已出版（经过审查并同意公开）

■ 可以通过以下方式监控架构材料的使用情况，并展示其是否符合标准、模型和原则：
— 合规性评估流程，描述用户订阅的内容，并评估其合规性水平
— 在特定情况下（通常具有强烈的业务必要性），可以免除遵守架构标准和指导方针的
豁免流程

发布和订阅技术正在开发中，作为一般IT治理的一部分，特别是针对国防领域。

1.5.2 深度

应根据企业架构的预期用途和在此基础上做出的决定，谨慎判断要捕获的适当细节级别。重要的
是，在架构工作中包括的每个架构领域（业务、数据、应用程序、技术）中都要完成一致和相等
的深度。如果省略了相关细节，架构可能没有用。如果包含不必要的细节，架构工作可能会超过
可用的时间和资源，和/或由此产生的架构可能会令人困惑或混乱。TOGAF标准——应用ADM中更详细地讨论了在企业内开发不同细节级别的架构。

预测架构的未来用途也很重要，这样在资源有限的情况下，架构的结构可以适应未来的定制、扩
展或重新设计-使用。企业架构的深度和细节需要足以满足其目的，仅此而已。

ADM的迭代将建立在先前迭代中创建的工件和功能的基础上。

需要记录企业中的所有模型，其详细程度应适合当前ADM周期的需要。关键是要了解企业架构工作的状态，以及利用可用的资源和能力可以实际实现的目标，然后专注于识别和交付可实现的价值。

利益相关者价值是一个关键焦点：范围太广可能会阻碍一些利益相关者（没有投资回报）。

1.5.3 时间段

ADM是按照架构愿景的单个周期和一组实现愿景的目标架构（业务、数据、应用程序、技术）来描述的。

在这种情况下，可以采取更广泛的视角，即企业由几个不同的架构实例（例如，战略、细分、能力）表示，每个实例代表企业在特定时间点的情况。一个架构实例将表示当前企业状态（“原样”或基线）。另一个架构实例（可能仅部分定义）将代表最终的目标最终状态（“愿景”）。在这两者之间，可以定义中间或“过渡架构”实例，每个实例都包括自己的一组目标架构描述。TOGAF标准-ADM技术中给出了如何实现这一目标的示例。

通过这种方法，目标架构工作分为两个或多个离散阶段：

• 首先，为整个（大规模）系统制定目标架构描述，展示在相对较远的时间范围内（例如六年）对利益相关者目标和关切的回应。
• 然后开发一个或多个“过渡架构”描述，作为增量或平台，每个描述都与目标架构描述一致并趋同，并描述相关增量的细节。

在这种方法中，目标架构本质上是渐进的，需要根据不断变化的业务需求和技术发展进行定期审
查和更新，而过渡架构（按设计）本质上是增量的，原则上不应在增量的实施阶段演变，以避免
“移动目标”综合症。当然，只有在实施进度受到严格控制且相对较短（通常不到两年）的情况
下，才有可能实现这一点。

目标架构仍然相对通用，因此比过渡架构更不容易过时。它们只体现了关键的战略架构决策，从
一开始就应该得到利益相关者的支持，而过渡架构中的详细架构决策则被故意尽可能推迟（即在
实施之前），以提高对新技术和产品的响应能力。

企业通过依次迁移到这些过渡体系结构中的每一个来发展。随着每个过渡架构的实施，企业在实
现最终愿景的过程中实现了一致的运营状态。然而，这一愿景本身会定期更新，以反映商业和技术环境的变化，实际上可能永远无法实现，正如最初所描述的那样。只要企业存在并不断变化，整个过程就会持续下去。

当然，将架构描述分解为一系列相关的架构产品需要对集合及其关系进行有效的管理。

1.5.4 体系结构域

一个完整的企业架构应该解决所有四个架构领域（业务、数据、应用程序、技术），但资源和时
间限制的现实往往意味着没有足够的时间、资金或资源来构建一个自上而下、包罗万象的架构描
述，涵盖所有四个体系结构领域。

架构描述通常会在构建时考虑到特定的目的——一组推动架构开发的特定业务驱动因素——并澄
清架构描述旨在帮助探索的具体问题及其有望帮助回答的问题，这是ADM初始阶段的重要组成部分。

例如，如果特定架构工作的目的是定义和检查实现特定功能的技术选项，并且基本业务流程不可
修改，那么很可能不需要完整的业务架构。然而，由于数据、应用程序和技术架构是建立在业务
架构之上的，因此业务架构仍然需要深入思考和理解。

虽然有时情况可能要求构建一个不包含所有四个架构域的架构描述，但应该理解的是，根据定义，
这样的架构不能成为一个完整的企业架构。其中一个风险是缺乏一致性，因此缺乏整合能力。集
成要么需要稍后进行——有其自身的成本和风险——要么架构师需要阐明不开发完整和集成架构
所涉及的风险和权衡，并与企业管理层沟通和理解。

1.6 架构备选方案

通常有多个可能的目标架构符合架构愿景、架构原则和要求。重要的是要确定备选的目标架构，
建立对不同可能性的理解，并确定备选方案之间的权衡。创建架构通常需要在相互竞争的力量之
间进行权衡。向利益相关者展示不同的替代方案和权衡，有助于架构师提取可能影响最终目标架
构的隐藏议程、原则和要求。

1.6.1 方法

最常见的情况是，不存在一种能够满足所有利益相关者关切的单一替代方案。TOGAF标准（见
TOGAF规范-ADM技术：体系结构备选方案和权衡）提供了一种研究不同备选方案并与利益相关者讨论这些方案的技术。

通常，每个域都定义了备选方案。这样做是为了简化对不同替代方案的分析。当然，每个域的备
选方案可以合并到对整个架构的备选方案的总体分析中。

该方法的第一部分使用愿景、原则、要求和其他信息来选择适合不同备选方案的标准集。该方法的第二部分根据标准定义备选方案，并建立对每种方案的理解。该方法的第三部分将选择一个备选方案，或者将多个特征组合在一起，以创建拟议的备选方案。以足够的细节执行以下活动以支持该决定。该方法可用于架构任何级别的任何阶段。

1.7 架构集成

为解决企业内一部分问题而创建的架构需要一个一致的参考框架，以便它们可以被视为一个组以
及点交付成果。用于定义单个架构的范围边界的维度（例如，细节级别、架构域等）通常与考虑
集成许多架构时必须解决的维度相同。下图说明了不同类型的架构需要如何共存。

目前，最先进的技术是，架构集成只能在可集成性谱的低端完成。需要考虑的关键因素是每个工件的粒度和细节级别，以及架构描述交换标准的成熟度。

随着组织解决共同的主题（如面向服务的体系结构（SOA）和集成信息基础设施）以及通用数据模
型和标准数据结构的出现，将促进向高端的集成。然而，始终需要有效的标准治理，以减少手动
协调和解决冲突的需要。

1.8 摘要

TOGAF ADM为开发架构所涉及的各个阶段和步骤定义了一个推荐的顺序，但它不能推荐一个范围——这必须由组织本身决定，同时要记住ADM过程中推荐的开发顺序是迭代的，范围和可交付成果的深度和广度随着每次迭代而增加。每次迭代都会将资源添加到组织的架构存储库中。

虽然将一个完整的框架作为最终的长期目标是有用的（实际上是必不可少的），但在实践中，对
于特定的企业架构工作的范围，需要做出一个关键的决定。在这种情况下，至关重要的是要了解
做出范围界定决定的基础，并为工作目标设定明确的期望。

主要指导方针是关注什么为企业创造价值，并相应地选择横向和纵向范围以及时间段。无论这是
否是第一次，都要明白，这个练习将被重复，未来的迭代将建立在当前工作中创建的基础上，增
加更大的宽度和深度。