TOGAF10标准--架构开发方法

第一章：介绍

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

1.1 ADM 概览

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

1.1.1 ADM，企业连续体，架构仓库

企业连续体（Enterprise Continuum）提供了一个框架和上下文，以支持在执行架构开发方法（ADM）时利用相关的架构资产。这些资产可能包括架构描述、模型和从各种来源获得的模式，如 TOGAF 标准——架构内容中所述。

企业连续体对架构源材料进行分类——包括组织内部企业仓库的内容和行业中可用的相关参考模型和标准的集合。

企业连续体的实际实施通常会采用架构仓库（参见 TOGAF 标准——架构内容）的形式，其中包含在企业内被认可使用的参考架构、模型和模式，以及企业中之前完成的实际架构工作。架构师会尽可能重用架构仓库中与当前项目相关的内容。（除了架构源材料的集合外，仓库还包含正在进行的架构开发工作。）

在 ADM 的相关阶段中，会提醒架构师考虑应当使用架构仓库中的哪些架构资产（如果有的话）。在某些情况下，例如开发技术架构时，可能会使用 TOGAF 基础架构（Foundation Architecture）；在其他情况下，例如开发业务架构时，可能会使用来自行业的大型参考模型，如电子商务的参考模型。

将源材料纳入组织的架构仓库的标准通常是企业架构治理流程的一部分。这些治理流程应考虑企业内外的可用资源，以确定何时可以将一般资源调整为特定企业需求，也可以确定哪些特定解决方案可以泛化以支持更广泛的复用需求。

在使用 ADM 的过程中，架构师是在特定时间点上开发企业决策及其影响的快照。每次 ADM 迭代都会填充组织特定的架构蓝图，包含所有在过程中识别并利用的架构资产，包括最终交付的组织特定架构。

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

实际上，ADM 的首次执行通常是最困难的，因为可供重用的架构资产相对较少。然而，即便在这个开发阶段，也可以利用来自外部来源的架构资产，如 TOGAF 标准以及整个 IT 行业中的资源，以支持工作。

随着越来越多的架构资产被识别出来，用于填充组织的架构仓库并供将来重用，后续的执行将变得更加容易。

1.1.2 ADM和基础架构

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

需要注意的是，来自这些不同来源的现有模型在整合后，可能不会自然形成一个连贯的企业架构。关于架构描述的“可集成性”问题，在第1.7节中有详细讨论。

1.1.3 ADM及其支持指南和技术

TOGAF架构开发方法（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的基本结构如图1-1.

在整个ADM（架构数据管理）周期中，需要频繁地将结果与最初的预期进行对照验证，这既要验证整个ADM周期的预期，也要验证流程中特定阶段的预期。

图1-1 架构开发周期

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）各阶段的描述包含了一系列可交付成果和工件，这些可能适用于任何企业。重要的是，要对可交付成果和工件进行调整，以反映企业对所需架构的具体需求。

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

ADM还可以进行调整，以支持敏捷企业架构交付风格，并实现企业敏捷性。关于如何调整ADM的详细指导，可参见以下文档：
        ■ TOGAF®系列指南：实现企业敏捷性
        ■ TOGAF®系列指南：使用敏捷冲刺应用 ADM

关于调整ADM过程的额外指导，可参见TOGAF标准——应用架构开发方法，以及TOGAF®系列指南：《遵循TOGAF ADM的企业架构开发实践者指南》。

1.4 架构治理

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

所有架构工件、治理和相关过程的管理都应在一个受控环境中进行。通常，这将基于一个或多个支持版本控制对象、过程控制和状态的仓库。

治理仓库管理的主要信息领域应包含以下类型的信息：

■ 参考数据（来自组织自己的仓库/企业连续体的抵押品，包括外部数据；例如，COBIT®、IT4IT参考架构）：在项目实施期间用于指导和说明

这包括上述信息的详细信息。参考数据包括治理程序本身的描述。

■ 过程状态：将管理有关任何治理过程状态的所有信息

这包括未决的合规请求、豁免请求和合规评估调查等示例。

■ 审计信息：这将记录所有已完成的治理过程操作，并将用于支持：

        — 经治理过程批准的任何架构项目的关键决策和责任人

        — 未来架构和支持过程开发、指导和先例的参考

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

《TOGAF标准——企业架构能力和治理》详细阐述了架构治理。

1.5 界定架构边界

有许多原因需要限制（或约束）即将开展的架构活动的范围，其中大部分原因与以下方面的局限性有关：
        ■ 负责架构团队的组织权限
        ■ 架构内需要解决的目标和利益相关者的关注点
        ■ 人员、资金和其他资源的可用性

理想情况下，为架构活动所选择的范围应能够使企业内所有架构师的工作得到有效管理和整合。这需要一套协调一致的“架构分区”，以确保架构师不会从事重复或相互冲突的活动。此外，还需要定义架构分区之间的重用和合规关系。

关于企业的划分及其与架构相关的活动，在TOGAF标准——《应用ADM》中有更详细的讨论。

通常使用四个维度来定义和限定架构的范围：

        ■ 广度：企业的完整范围是什么？此次架构工作将处理其中的哪些部分？
                ——许多企业规模庞大，实质上由多个组织单元组成，这些单元本身就可以被视为独                             立的企业。
                ——现代企业越来越超越其传统边界，融合了传统企业与供应商、客户和合作伙伴之                             间模糊的结合体。

        ■ 深度（Depth）：架构工作需要深入到什么程度？
           多少架构工作才算“足够”？架构工作与其他相关活动（系统设计、系统工程、系统开                       发）之间的适当界限是什么？

        ■ 时间周期（Time Period）：需要明确架构愿景的时间周期是什么，以及对于同一时间周                   期，在详细的架构描述中涵盖是否合理（从实用性和资源角度来看）？
           如果不合理，需要定义多少个过渡架构，以及它们的时间周期是什么？

        ■ 架构领域（Architecture Domains）：一个完整的企业架构描述应包含所有四个架构领域。              （业务、数据、应用、技术），但资源和时间的限制往往意味着没有足够的时间、资金或资                源来构建一个自上而下、包含所有四个架构领域的全面架构描述，即使企业范围的选择小              于整体企业的全部范围。

通常，架构的范围首先通过广度、深度和时间这三个维度来表达。

一旦理解了这些维度，就可以选择一种合适的架构领域组合，以适应所要解决的问题。使用ADM来开发一系列相关架构的技术，在TOGAF标准——《应用架构开发方法》中有所讨论。

下面将详细探讨架构范围的四个维度。在每种情况下，尤其是在大型环境中，架构必然是以联邦的方式开发的，架构师可能会在自己的活动范围内进行优化，而不是在整体企业层面进行优化，这是存在风险的。为了在企业层面进行优化，往往需要在特定领域进行次优化。目标始终是寻求最高程度的共性，并关注可扩展和可重用的模块，以最大限度地在企业层面实现重用。

1.5.1 宽度

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

在企业内部，通常需要存在多种不同的架构，这些架构聚焦于特定的时间段、业务功能或业务需求。

对于大型复杂的企业而言，联邦式架构（即独立开发、维护和管理，随后在集成框架内整合的架构）是典型的选择。此类框架规定了互操作性、迁移和一致性的原则，从而允许特定的业务单元将架构作为独立项目进行开发和治理。有关不同解决方案的互操作性要求的更多详细信息和指导，可参阅 TOGAF 标准——ADM 技术部分。

对于每个业务功能或目的都采用单一的企业级架构可能因过于复杂和笨拙而被认为不可行。在这种情况下，建议在企业内部存在多种不同的企业架构。这些企业架构聚焦于特定的时间段、业务细分或职能以及特定的组织需求。在这种情况下，我们需要创建一个总体企业架构，作为这些企业架构的“联邦”。管理和利用这些企业架构的有效方法是采用发布和订阅模型，使架构置于治理框架之下。在此模型中，项目中的架构开发者和架构使用者（即架构工作的供需双方）加入一个互利共赢的治理框架，确保：

        ■ 架构材料质量良好、及时更新、适用并得以发布（经过审查并同意公开）

        ■ 可以通过以下方式监控架构材料的使用情况，并展示对标准、模型和原则的遵守情况：

           —合规性评估流程，用于描述用户订阅的内容，并评估其合规水平

           —豁免流程，可能在特定情况下（通常出于强烈的业务需求）授予不遵守架构标准和指南                   的豁免

发布和订阅技术正在作为一般IT治理的一部分以及专门针对国防领域进行开发。

1.5.2 深度

应谨慎判断需捕获的细节的适当程度，这取决于企业架构的预期用途以及基于其作出的决策。在架构工作中包含的每个架构领域（业务、数据、应用、技术）中，都需完成一致且同等的深度。如果省略了相关细节，架构可能无法发挥作用。如果包含了不必要的细节，架构工作可能会超出可用的时间和资源，并且/或者最终得到的架构可能会令人困惑或杂乱无章。在TOGAF标准《应用架构开发方法（ADM）》中更详细地讨论了在企业内部以不同详细程度开发架构的内容。

预测架构的未来用途也很重要，以便在资源有限的情况下，对架构进行结构化处理，以适应未来的定制、扩展或重用。企业架构的深度和细节需要足够满足其目的，并且不要过多。

架构开发方法（ADM）的迭代将基于先前迭代中创建的工件和能力进行构建。

需要记录企业中的所有模型，详细程度需符合当前架构开发方法（ADM）周期的需求。关键是了解企业架构工作的现状，以及利用现有资源和能力实际可以实现的目标，然后专注于识别和交付可实现的价值。利益相关者的价值是一个关键焦点：范围过广可能会使一些利益相关者望而却步（投资回报率不高）。

1.5.3时间周期

ADM 被描述为一个架构愿景的完整循环，以及一组实现该愿景的目标架构（业务、数据、应用、技术）。

在这种情况下，可以采取更广阔的视角，将企业表示为多个不同的架构实例（例如战略、业务片段、能力），每个实例代表企业在某一特定时间点的状态。一个架构实例表示当前的企业状态（“现状”或基线），另一个可能仅部分定义的架构实例表示最终的目标终态（“愿景”）。在这两者之间，可以定义中间或“过渡架构”实例，每个实例包含自己的一组目标架构描述。如何实现这一点的示例在 《TOGAF 标准—ADM 技术》部分中有介绍。

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

1. 首先，为整个（大型）系统开发目标架构描述，展示针对较长时间周期（例如六年）内利益相关者目标和关注点的响应。

2. 然后开发一个或多个“过渡架构”描述，作为阶段或平稳期，与目标架构描述一致并趋向目标架构，描述各阶段的具体内容。

在这种方法中，目标架构具有演进性质，需要根据不断变化的业务需求和技术进展定期进行审查和更新，而过渡架构则（按设计）具有增量特性，原则上不应在实施阶段发生变化，以避免“移动目标”现象。当然，这只有在实施计划受到严格控制且时间相对较短（通常少于两年）时才可能实现。

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

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

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

1.5.4 架构域

一个完整的企业架构应涵盖所有四个架构领域（业务、数据、应用、技术），但资源和时间的限制通常意味着无法构建一个自上而下、包含所有四个架构领域的全面架构描述。

架构描述通常会基于特定目的构建——即一组驱动架构开发的具体业务驱动力——明确架构描述旨在探索的特定问题以及期望帮助解答的问题，这是 ADM 初始阶段的重要部分。

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

虽然在某些情况下，架构描述可能不包含所有四个架构领域，但应认识到，这样的架构本质上不能算作完整的企业架构。其风险之一是缺乏一致性，从而难以实现集成。集成可能需要在后期进行，伴随其自身的成本和风险，或者，未开发完整且集成的架构所带来的风险和权衡，需要由架构师明确，并传达给企业管理层以确保理解。

1.6 架构备选方案

通常，可能存在多种符合架构愿景、架构原则和需求的目标架构。识别备选的目标架构、理解不同的可能性，并在备选方案之间权衡利弊至关重要。创建架构通常需要在相互竞争的因素之间做出权衡。向利益相关者展示不同的备选方案和权衡取舍，有助于架构师挖掘可能影响最终目标架构的潜在议程、原则和要求。

1.6.1 方法

最常见的情况是，单一备选方案无法满足所有利益相关者的诉求。《TOGAF标准》（参见TOGAF标准——ADM技术：架构替代方案与权衡）提供了一种技术，旨在研究不同的替代方案，并与利益相关者讨论这些方案。

通常，替代方案是按领域定义的。这是为了简化不同替代方案的分析。当然，按领域定义的替代方案可以合并为对整个架构的替代方案的综合分析。此方法的示意图如图1-2所示。

该方法的第一部分使用愿景、原则、需求和其他信息来选择适用于不同替代方案的标准集。

方法的第二部分基于标准定义替代方案，并对每个方案进行理解。

方法的第三部分将选择其中一个替代方案，或者结合多个方案的特点，提出建议的替代方案。执行以下活动，详细程度应足够支持该决策。该方法可以在架构的任何阶段和任何层级使用。

图 1-2  架构备选方案法

1.7 架构集成 

为了解决企业中部分问题而创建的架构需要一个一致的参考框架，以便能够作为一个整体进行考虑，同时也可以作为独立的交付成果来审视。定义单一架构范围边界的维度（例如详细程度、架构领域等）通常也是在考虑多个架构的集成时必须处理的维度。图1-3展示了不同类型的架构如何共存的方式。

目前，最先进的技术水平只能实现在可整合性谱系低端完成架构整合。需要考虑的关键因素包括每个成果物的粒度与详细程度，以及架构描述交换标准的成熟度。

目前，架构集成技术的发展水平仅能在集成性谱系的较低端实现。需要考虑的关键因素包括每个构件的粒度和细节层次，以及用于架构描述交换的标准的成熟度。

图 1-3 架构工件的集成

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

1.8 总结

TOGAF ADM（The Open Group Architecture Framework - Architecture Development Method）定义了制定架构过程中各个阶段和步骤的推荐顺序，但它不能推荐范围——范围需要由组织自身决定。要牢记的是，ADM 过程中的推荐开发顺序是迭代性的，每次迭代都会在广度和深度上逐渐增加范围和交付成果。每次迭代都将为组织的架构资源库增添内容。

尽管拥有一个完整的框架是有用的（事实上，这是实现长期目标的必要条件），但在实践中，关键决策是确定特定企业架构工作的范围。在这种情况下，理解范围决策的基础并为此工作设定清晰的目标是至关重要的。

主要的指导原则是关注能够为企业创造价值的内容，并相应地选择横向和纵向的范围以及时间周期。无论这是否是首次进行架构开发工作，都应理解此过程将会重复进行，而未来的迭代将基于当前的工作成果，逐步拓宽和深化。

第二章：预备阶段

本章描述了满足新企业架构业务指令所需的准备和启动活动，包括定义组织特定的架构框架和制定原则。

图 2-1 预备阶段

2.1 目标 

预备阶段的目标包括：

1. 确定组织所需的架构能力：

             ■ 审查进行企业架构的组织背景

             ■ 确定并界定受架构能力影响的企业组织要素的范围

             ■ 识别与架构能力相交叉的既定框架、方法和流程

             ■ 确立能力成熟度目标

2.  建立架构能力：

                ■ 定义并建立企业架构的组织模型

                ■ 定义并建立架构治理的详细流程和资源

                ■ 选择并实施支持架构能力的工具

                ■ 定义架构原则

2.2 输入

本节定义了预备阶段的输入。

2.2.1 企业外部的参考资料

        ■ TOGAF 库

        ■ 其他架构框架（如有需要）

2.2.2 非架构输入

        ■ 现存董事会战略和董事会业务计划、业务战略、IT战略、业务原则、业务目标和业务驱动力
        ■ 业务中运行的主要框架；例如，项目/投资组合管理
        ■ 现存治理和法律框架，包括架构治理战略
        ■ 架构能力
        ■ 合作伙伴关系和合同协议

2.2.3 架构输入

现存企业架构能力运营模式可以作为预备阶段的基线。输入内容包括：

        ■ 企业架构的组织模型（参见TOGAF标准——架构内容），包括：
                — 受影响组织的范围
                — 成熟度评估、差距及解决方案
                — 架构团队的角色与职责
                — 预算要求
                — 治理和支持战略

        ■ 现有的架构框架（如果有的话），包括：
                — 架构方法
                — 架构内容
                — 配置和部署的工具
                — 架构原则
                — 架构库

2.3 步骤

TOGAF ADM（架构开发方法）是一种通用方法，旨在供各种不同类型的企业使用，并可根据需要在与其他多种架构框架相结合的情况下使用。因此，初步阶段涉及开展任何必要的工作，以启动和调整ADM，从而定义一个特定于组织的框架。关于将ADM调整到特定组织环境中的相关问题，第1.3节将进行详细讨论。

预备阶段所探讨的细节程度将取决于总体架构工作的范围和目标。

预备阶段中各步骤的顺序，以及它们正式开始和完成的时间，应根据既定的架构治理机制，适应当前情况。

预备阶段的步骤如下：
■ 确定受影响的企业组织范围（见第2.3.1节）
■ 确认治理和支持框架（见第2.3.2节）
■ 定义并建立企业架构团队和组织（见第2.3.3节）
■ 确定并建立架构原则（见第2.3.4节）
■ 调整TOGAF框架以及任何其他选定的架构框架（如有）（见第2.3.5节）                                      ■ 制定工具和技术策略及实施计划（见第2.3.6节）

2.3.1 确定受影响的企业组织范围

■ 确定核心企业（单位）——这些企业（单位）受影响最大，并且从工作中获得最大价值

■ 确定软性关联企业（单位）——这些企业（单位）的能力和工作将与核心单位发生变化，但其他方面不受直接影响

■ 确定扩展型企业（单位）——即范围之外但在其自身企业架构中会受到影响的企业（单位）

■ 确定涉及的社群（企业）——这些利益相关者将受到影响，并且属于社群团体

■ 确定涉及的治理方，包括法律框架和地域范围（企业）

2.3.2 确认治理和支持框架

架构框架将成为架构治理组织和所需指导方针的核心，决定其形式（集中式或联合式、轻量或重量级等）。本阶段的主要成果之一是架构治理框架。我们需要了解如何将架构素材（标准、指南、模型、合规性报告等）纳入治理范围；即，需要什么样的治理仓库特性，以及需要哪些关系和状态记录来确定哪个治理过程（例如豁免、合规、引入、退役等）对某个架构工件拥有所有权。

组织的现有治理和支持模型可能需要进行调整，以支持新采纳的架构框架。

为了管理采用新架构框架所需的组织变革，需要对当前的企业治理和支持模型进行评估，以了解其整体结构和内容。此外，还需要就可能产生的影响与架构的发起人和利益相关者进行协商。

完成此步骤后，相关利益相关者应了解并同意架构的关键节点和可能产生的影响。

2.3.3 定义和建立企业架构团队和组织

■ 确定现有企业及业务能力
■ 如需，进行企业架构/业务变革成熟度评估
■ 识别现有工作领域的不足
■ 为企业架构能力管理和治理分配关键角色与职责                                                                            ■ 定义对现有业务计划和项目的变更请求：
        — 向现有的企业架构和IT架构工作团队通报利益相关者的需求
        — 请求评估这些需求对其计划和工作的影响
        — 确定共同的兴趣领域
        — 识别任何关键的差异和利益冲突
        — 制定针对利益相关者活动的变更请求
■ 确定企业架构工作的限制因素
■ 与赞助者和董事会进行审查并达成一致
■ 评估预算需求

2.3.4 确定并建立架构原则

架构原则（参见TOGAF标准——ADM技术）是基于业务原则制定的，对于奠定架构治理的基础至关重要。一旦理解了组织背景，就需要定义一套适合该企业的架构原则。

2.3.5 定制TOGAF框架及其他所选架构框架（如有）

在这一步骤中，需要确定对TOGAF框架进行哪些定制。考虑以下需求：

■ 术语定制：架构从业者应使用在整个企业中普遍理解的术语。

调整应形成一套用于描述架构内容的商定术语集。应考虑创建一个企业术语表，并在整个架构过程中不断更新。

■ 过程定制：TOGAF ADM提供了一个通用的架构实施过程。

过程定制提供了删除组织中已在其他地方执行的任务、添加特定于组织的任务（如特定检查点）以及使ADM过程与外部过程框架和关键节点保持一致的机会。需要解决的关键节点包括：

— 与（项目和服务）组合管理过程的链接

— 与项目生命周期的链接

— 与运营交接过程的链接

— 与运营管理过程（包括配置管理、变更管理和服务管理）的链接

— 与采购过程的链接

■ 内容定制：以TOGAF架构内容框架和企业连续体为基础，对内容结构和分类方法进行调整，可以采用第三方内容框架，并允许根据组织的特定需求对框架进行定制。

2.3.6 为工具和技术制定策略与实施计划

在多个领域开发企业架构时，可以使用许多工具和技术。建议制定一个工具策略，以反映企业利益相关者所需的理解水平和形式化程度。架构内容将高度依赖于利益相关者及组织内架构能力的规模、成熟度和文化。制定一个能够满足利益相关者表达需求的工具策略，将帮助利益相关者更有效、快速地进行决策，并促进他们对架构成果的认同。

该策略应涵盖管理技术、决策管理、研讨会技术、业务建模、详细的基础设施建模、办公产品、语言、库管理，以及更正式的架构工具。例如，平衡计分卡技术是一种业界最佳实践的绩效衡量工具，常用于商学院和众多企业，并可在架构项目中成功应用。

工具策略的实施可以基于常用的桌面和办公工具，也可以基于专业管理和架构工具的定制化部署。对架构成果的变更管理是一个重要考量，需要对成果的管理控制和治理进行相应的考量。由于许多架构成果可能包含敏感信息，决策的访问权限需要谨慎管理。因此，工具的实施、内容访问以及安全性应符合敏感性要求。

2.3.6.1 工具标准化问题

在当前的工具市场中，许多开发企业架构的公司在工具标准化方面面临挑战，无论是追求单一的“通用”工具，还是使用多工具套件来建模架构并生成所需的不同架构视图。

选择单一工具似乎有一些明显的优势。遵循这种政策的组织可以期望获得诸如减少培训成本、共享许可证、批量折扣、维护简化和数据交换便捷等好处。然而，也有一些拒绝指定单一工具的理由，包括原则上的原因（推行单一架构工具不利于促进竞争性的商业创新或高级工具功能的开发）；此外，单一工具无法满足企业中各类架构开发的“成熟度水平”和特定需求。

成功的企业架构团队通常能够将其架构工具与架构的成熟度水平、团队/组织能力以及目标或关注点协调一致。如果企业中的不同组织处于不同的架构成熟度水平，且具有不同的目标或关注点（例如，企业架构、业务架构和技术架构），那么一款工具很难满足所有组织的需求。

2.4 输出

初始阶段的输出可能包括但不限于以下内容：

        ■ 企业架构的组织模型（参见 TOGAF 标准 — 架构内容），包括：

                — 受影响的组织范围

                — 成熟度评估、差距及解决方案

                — 架构团队的角色与职责

                — 架构工作的限制

                — 预算需求

                — 治理和支持策略

        ■ 定制的架构框架（参见 TOGAF 标准 — 架构内容），包括：

                — 定制的架构方法

                — 定制的架构内容（交付物和工件）

                — 架构原则（参见 TOGAF 标准 — 架构内容）

                — 已配置并部署的工具

        ■ 初始架构库（参见 TOGAF 标准 — 架构内容），填充了框架内容

        ■ 重申或参考业务原则、业务目标和业务驱动因素（参见 TOGAF 标准 — 架构内容）

        ■ 架构工作请求（可选）（参见 TOGAF 标准 — 架构内容）

        ■ 架构治理框架（参见 TOGAF 标准 — 企业架构能力和治理）

        ■ 企业架构能力的架构（参见 TOGAF 标准 — 企业架构能力和治理）

这些输出可能包括以下部分或全部内容：

        ■ 目录： — 原则目录

2.5 方法

预备阶段的重点在于定义企业中“我们在何处、做什么、为什么、由谁以及如何进行架构”。主要方面如下：

        ■ 定义企业
        ■ 确定组织环境中的关键驱动因素和要素                                                                                          ■ 定义架构工作的需求
        ■ 定义指导任何架构工作的架构原则
        ■ 定义将要使用的框架
        ■ 定义管理框架之间的关系
        ■ 评估企业架构的成熟度

企业架构提供了组织的战略性自上而下视角，使高管、规划人员、架构师和工程师能够协调一致地整合和开展活动。企业架构框架提供了一个团队可以运作的战略背景。

因此，开发企业架构并非单独的活动，企业架构师需要认识到其框架与业务其他部分的互操作性。

需要满足战略性、过渡性和战术性的业务目标和愿望。同样，企业架构也需要反映这一需求，并支持在组织内不同层次上进行架构工作的开展。

根据企业的规模和对企业架构工作的预算投入，可以采取多种方法来细分或分区架构团队、流程和交付物。架构分区的方法在《TOGAF标准 — 架构内容》中进行了讨论。预备阶段应用于确定期望的分区方法，并为所选方法的实施奠定基础。

预备阶段可能会在架构愿景阶段（参见《TOGAF标准 — 应用ADM》）中再次访问，以确保组织的架构能力适合解决特定的架构问题。

初始阶段的重点是为组织中的企业架构能力创建架构。因此，此处应采用任何架构开发中使用的最佳实践。有关应用TOGAF ADM以建立企业架构能力的说明，请参见《TOGAF标准 — 企业架构能力和治理》。

构建企业架构能力的进一步指导可参见以下文件：

        ■ TOGAF® 系列指南：《TOGAF领导者关于建立和发展EA能力的指南》

2.5.1 企业

企业架构的主要挑战之一在于企业范围的界定。

企业的范围以及其是否是联邦式结构，将决定哪些利益相关者将从企业架构能力中获得最大收益。在此阶段必须指定一位发起人，以确保后续活动具备所需资源并获得业务管理的明确支持。企业可能涵盖多个组织，而发起人的职责是确保所有利益相关者都参与到架构能力的定义、建立和使用过程中。

2.5.2 组织背景

为了针对特定企业内将要使用的架构框架做出有效且明智的决策，有必要了解架构框架所处的背景。需要考虑的具体领域包括：

        ■ 企业架构的商业模式以及企业架构活动的预算计划；若不存在此类计划，则应利用初步阶段来制定预算计划。

        ■ 企业中的架构利益相关者；他们的关键问题和关注点。

        ■ 组织意图和文化，这些体现在董事会业务指令、业务迫切需求、业务战略、业务原则、业务目标和业务驱动力中。

        ■ 支持企业变革执行和运营的当前流程，包括流程的结构以及组织内部应用的严谨性和正式程度。

        应重点关注的领域包括：

                — 当前的架构描述方法

                — 当前的项目管理框架和方法

                — 当前的系统管理框架和方法

                — 当前的项目组合管理流程和方法

                — 当前的应用程序组合管理流程和方法

                — 当前的技术组合管理流程和方法

                — 当前的信息组合管理流程和方法

                — 当前的系统设计与开发框架和方法

        ■ 基线架构概况，包括企业的现状以及当前如何在文档中呈现这一概况。

        ■ 将采用该框架的企业和特定组织的技能和能力。

对组织背景的审查应提供有价值的需求，以便在以下方面调整架构框架：

        ■应用的正式程度和严谨程度

        ■所需的复杂度和支出水平

        ■与其他组织、流程、角色和职责的交点

        ■内容覆盖的重点

2.5.3 架构工作的需求

企业架构工作背后的业务需求驱动着架构工作的要求和性能指标。这些需求应足够明确，以便本阶段能够确定业务成果和资源需求，并定义企业业务信息需求的概要以及将要进行的企业架构工作的相关策略。例如，这些可能包括：

        ■ 业务需求
        ■ 文化愿景
        ■ 组织意图
        ■ 战略意图
        ■ 财务预测需求

需要明确阐述这些要素的重要部分，以便发起人能够识别出所有参与定义和建立架构能力的关键决策者和利益相关者。

2.5.4 原则

预备阶段定义了架构原则，这些原则将构成企业内进行任何架构工作的约束条件之一。此中涉及的问题在TOGAF标准——架构开发方法（ADM）技术中有所解释。

架构原则的定义是企业架构的开发的基础。架构工作既受业务原则的指导，也受架构原则的指导。架构原则本身通常也部分基于业务原则。定义业务原则通常不属于架构职能的范畴。然而，根据这些原则在企业内部如何定义和颁布，架构原则集也有可能重新阐述或交叉引用在企业内部其他地方定义的业务原则、业务目标和战略业务驱动力。在架构项目中，架构师通常需要确保这些业务原则、目标和战略驱动力的定义是最新的，并澄清任何模糊之处。

架构治理问题与架构原则问题密切相关。负责治理的机构通常也负责批准架构原则，并解决架构问题。治理所涉及的问题在TOGAF标准——企业架构能力和治理中有所解释。

2.5.5 管理框架

TOGAF ADM是一种通用方法，旨在被各种行业和地域的企业所使用。如果需要，它还可以与其他多种企业架构框架配合使用（尽管它本身也可以无需调整而独立使用，效果良好）。

TOGAF框架需要与任何组织内正式或非正式存在的其他管理框架共存并提升其运营能力。除了这些框架外，大多数组织都有一种解决方案开发方法，其中大多数都包含IT组件。系统的重要性在于，它们将各个领域（也称为人员、流程以及材料/技术）结合在一起，以提供业务能力。

建议与TOGAF框架协同使用的主要框架包括：

        ■ 业务能力管理，它确定为实现业务价值所需哪些业务能力，包括定义投资回报率和所需的控制/绩效指标
        ■ 项目/组合管理方法，它确定公司如何管理其变革举措
        ■ 运营管理方法，它描述公司的日常运营是如何运作，包括IT
        ■ 解决方案开发方法，它使业务系统的交付方式符合IT架构中开发的结构

如图2-2所示，这些框架并非彼此独立，它们与业务能力管理之间存在显著重叠。后者还包括交付经过绩效衡量的业务价值。

总体而言，应用TOGAF框架的企业架构师不能仅局限于关注IT实施，而必须意识到架构对整个企业的影响。

图 2-2 与TOGAF框架协同的管理框架

2.5.6 管理框架的关联

图 2-3 展示了各个框架与业务规划活动之间的更详细依赖关系，业务规划活动包含了企业的战略计划和方向。企业架构可以为所有公司级的计划提供结构，投资组合管理框架可以用来交付架构的各个组成部分，而运营管理框架支持将这些新组件整合到公司基础设施中。

业务规划人员在整个过程中都在场，他们可以通过在规划和开发的各个阶段保留资源审批权来支持和强化架构。

在投资组合管理框架中使用解决方案开发方法来规划、创建并交付在项目和投资组合章程中指定的架构组件。这些交付成果不仅限于 IT，还包括例如新建筑、一套新技能、生产设备、招聘、市场营销等。企业架构为所有企业活动提供了潜在的背景。

这些管理框架需要相互补充，紧密协作，以实现企业的整体利益。

图 2-3 管理框架之间的互操作性和关系

业务规划在战略层面为企业架构提供初步方向。在年度规划层面的更新则提供了更精细的持续指导。基于能力的规划是业务规划中的众多流行技术之一。

企业架构将业务规划构建成一个综合性框架，该框架将企业视为一个系统或系统的系统。这种集成方法可以验证业务计划，并向企业规划人员提供有价值的反馈。在一些组织中，企业架构师被调至或与战略方向团队紧密合作。TOGAF 方法为企业架构提供了一个框架。

项目/项目组合管理是接收结构化、详细方向的交付框架，使其能够计划和构建所需内容，同时确保每个分配的交付成果都符合背景（即，它们所交付的部分能够拼入企业架构这一企业层面的拼图中）。这一框架通常基于项目管理协会（Project Management Institute）或英国政府商务办公室（UK Office of Government Commerce）的PRINCE2®项目管理方法论。项目架构和脱离背景的详细设计通常基于系统设计方法论。

关于如何将 TOGAF ADM 与项目管理框架一起使用的指导，可以参见《TOGAF 系列指南：架构项目管理》。

运营管理接收交付物，然后将其集成并维护在公司基础设施中。通常，IT 服务管理基于 IT4IT 参考架构、ITIL® 和 ISO/IEC 20000:2011。

2.5.7 企业架构/业务变革成熟度评估的规划

能力成熟度模型是评估企业执行不同能力的一种有效方法。

能力成熟度模型通常识别出实现某种能力所需的特定因素。组织执行这些特定因素的能力可以衡量其成熟度，并可用于推荐一系列有序的步骤以提高能力。它是一种评估方法，使管理者能够洞察到如何切实地改进一项能力。

一个良好的企业架构成熟度模型涵盖了开发和使用企业架构所需的特征。组织可以自行确定因素并推导出合适的成熟度模型，但建议采用现有模型并根据需要进行定制。

目前有多个优秀的模型可供参考，包括美国国家州首席信息官协会（NASCIO）和美国商务部的架构能力成熟度模型。其他例子还包括美国联邦企业架构成熟度模型。尽管这些模型最初来源于政府，但同样适用于工业界。

第三章：阶段A：架构愿景

本章描述ADM的初始阶段。内容包括定义范围，识别利益相关者，创建架构愿景和获得授权的信息。

图 3-1 阶段A：架构愿景

3.1 目标

阶段A的目标：

        ■ 制定一个关于拟议的企业架构所能实现的能力和业务价值的高级愿景
        ■ 获得架构工作说明书的批准，以定义一项工作计划，用于开发和部署架构愿景中概述的架构

3.2 输入

本节定义了阶段A的输入。

3.2.1 企业外部参考资料

        ■ 架构参考资料（参见TOGAF标准——架构内容）

3.2.2 非架构输入

        ■ 架构工作请求（参见TOGAF标准——架构内容）
        ■ 业务原则、业务目标和业务驱动力（参见TOGAF标准——架构内容）

3.2.3 架构输入

        ■ 企业架构的组织模型（参见 TOGAF 标准 —— 架构内容），包括：
                — 受影响组织的范围
                — 成熟度评估、差距及解决方案
                — 架构团队的角色和职责
                — 架构工作的约束条件
                — 重用需求
                — 预算需求
                — 变更请求
                — 治理和支持策略

        ■ 定制的架构框架（参见 TOGAF 标准 —— 架构内容），包括：
                — 定制的架构方法
                — 定制的架构内容（交付物和工件）
                — 架构原则（参见 TOGAF 标准 —— 架构内容），包括现有的业务原则
                — 配置和部署的工具

        ■ 已填充的架构库（参见 TOGAF 标准 —— 架构内容）——现有的架构文档（框架描述、架构描述、基线描述、架构构建块（ABBs）等）

3.3 步骤

在阶段A中处理的细节层级将取决于架构工作请求的范围和目标，或与本次架构开发迭代相关的部分范围和目标。
阶段A中的步骤顺序以及其正式开始和完成的时间应根据当前情况并依照已建立的架构治理进行调整。

阶段A的步骤如下：
        ■ 建立架构项目（见第3.3.1节）
        ■ 识别利益相关者、关注点和业务需求（见第3.3.2节）
        ■ 确认并详细说明业务目标、业务驱动因素和限制条件（见第3.3.3节）
        ■ 评估能力（见第3.3.4节）
        ■ 评估业务转型的准备情况（见第3.3.5节）
        ■ 定义范围（见第3.3.6节）
        ■ 确认并详细说明架构原则，包括业务原则（见第3.3.7节）
        ■ 制定架构愿景（见第3.3.8节）
        ■ 定义目标架构的价值主张和关键绩效指标（见第3.3.9节）
        ■ 识别业务转型的风险和缓解措施（见第3.3.10节）
        ■ 制定架构工作说明书并获得批准（见第3.3.11节）

3.3.1  建立架构项目

企业架构是一种业务能力；ADM的每个周期通常应作为项目处理，使用企业的项目管理框架。在某些情况下，架构项目将是独立的；在其他情况下，架构活动将是一个更大项目中的一部分。无论是哪种情况，架构活动都应使用企业认可的实践进行规划和管理。

执行必要的程序，以确保项目得到认可，获得公司管理层的支持以及相关业务管理部门的支持和承诺。应包括企业内部使用的其他管理框架的参考，说明该项目与这些框架的关系。

3.3.2 确定利益相关者、关注点及业务需求

确定关键利益相关者及其关注点/目标，并定义在架构工作中需要解决的关键业务需求。此阶段的利益相关者参与旨在实现以下三个目标：

         ■ 确定候选愿景组件和需求，以便在架构愿景开发过程中进行测试
         ■ 确定工作范围的候选边界，以限制所需的架构研究范围
         ■ 识别利益相关者的关注点、问题和文化因素，这些将影响架构的呈现和沟通方式

此步骤的主要成果是参与的利益相关者图，显示哪些利益相关者参与了项目、他们的参与程度以及他们的主要关注点（见TOGAF标准——ADM技术）。利益相关者图用于支持架构愿景阶段的各种输出，并用于确定：

         ■ 与本项目相关的关注点和观点，这些在架构愿景中进行记录（见TOGAF标准——架构内容）
         ■ 参与项目的利益相关者，并因此成为制定沟通计划的起点（见TOGAF标准——架构内容）           ■ 项目中的关键角色和职责，这些应包含在架构工作说明书中（见TOGAF标准——架构内容）

另一项关键任务是考虑需要开发哪些架构视图和视角来满足各利益相关者的要求。如TOGAF标准——ADM技术中所述，在此阶段了解需要开发哪些利益相关者和哪些视图对于设定参与范围至关重要。

在架构愿景阶段，对于选定要求范围内为未来架构工作产生的新需求，需要在架构需求规范中进行记录，而对于超出选定要求范围的新需求，必须输入到需求库中，通过需求管理过程进行管理。

3.3.3  确认并详细说明业务目标、业务驱动因素和限制条件

确定组织的业务目标和战略驱动因素。
如果这些因素已在企业的其他部分得到定义，请确保现有的定义是最新的，并澄清任何模糊之处。否则，请回到《架构工作说明书》的原始制定者处，与他们合作定义这些关键要素，并确保获得企业管理层的认可。
定义必须处理的约束条件，包括全企业范围的约束条件和项目特定的约束条件（时间、进度、资源等）。全企业范围的约束条件可能在预备阶段制定的业务原则和架构原则中得以说明，或者在A阶段加以澄清。

3.3.4 评估能力

了解企业内的能力集合具有重要价值。其一部分是指企业开发和利用架构的能力，另一部分是指企业的基线和目标能力水平。在架构能力中识别出的差距需要在架构愿景和预备阶段之间进行迭代，以确保架构能力适合解决架构项目的范围（参见《TOGAF标准——ADM的应用》）。

在评估业务模型或澄清业务战略优先级的工件之后，关键步骤是识别企业为执行战略优先级而必须具备的业务能力。业务能力差距的详细评估属于B阶段的核心部分，即业务架构，在此阶段，架构师可以帮助企业识别各类需要在架构后续阶段解决的业务差距。

然而，在架构愿景阶段，架构师应考虑企业在当前计划或项目中自行开发企业架构的能力。ADM进展中的能力差距，无论是由于技能短缺、所需信息、流程缺陷或系统和工具的不足，都是架构工作是否应继续的重要考量。架构师可以在第3.5节找到指南，以在此早期评估中收集现有的企业业务能力框架。

在企业执行变革的能力中识别出的差距或限制将为架构师提供信息，用于描述目标架构及E阶段和F阶段创建的实施与迁移计划（参见《TOGAF标准——架构内容》）。此步骤旨在以适当的抽象层次了解企业的能力和需求（参见《TOGAF标准——ADM的应用》）。考虑企业基线能力与目标能力之间的差距至关重要。可以通过创建展示相关能力关联的价值链图来支持展示整体企业背景下的基线和目标能力。评估结果将记录在《能力评估》中（参见《TOGAF标准——架构内容》）。

3.3.5 评估业务转型的就绪情况

业务转型就绪情况评估可用于评估和量化组织进行变革的就绪情况。该评估基于一系列就绪因素的确定与分析/评级，这些因素在TOGAF标准——ADM技术中有所描述。

就绪评估的结果应添加到能力评估中（参见TOGAF标准——架构内容）。然后，利用这些结果来界定架构的范围，确定架构项目中所需的活动，并识别需要解决的风险领域。

3.3.6 定义范围

明确基线架构和目标架构工作所涵盖的范围及不包括的内容，需理解基线架构和目标架构不必以相同的详细程度进行描述。在许多情况下，基线架构以更高的抽象层次进行描述，因此有更多的时间来详细规定目标架构。与此相关的问题将在第1.5节中讨论。具体而言，需定义以下内容：

        ■ 企业覆盖的广度

        ■ 所需的详细程度

        ■ 架构的分区特性（参见TOGAF标准——《应用ADM的更多细节》）

        ■ 要涵盖的具体架构领域（业务、数据、应用、技术）

        ■ 所针对的时间范围以及任何中间时间段的数量和范围

        ■ 将从企业架构库中利用或考虑使用的架构资产：
                — 企业在ADM周期先前迭代中创建的资产
                — 行业中其他地方可用的资产（其他框架、系统模型、垂直行业模型等）

3.3.7 确认并详细阐述架构原则，包括业务原则

审查架构开发所遵循的原则。架构原则通常基于预备阶段制定的原则。这些原则在 TOGAF 标准的 ADM 技术中有所说明，并提供了示例集。确保现有定义是最新的，并澄清任何模糊之处。如有必要，可返回架构治理负责部门，与他们合作首次定义这些关键要素，并确保获得公司管理层的认可。

3.3.8 制定架构愿景

理解所需的构件将使利益相关者能够开始界定他们的决策范围，这将为后续阶段提供指导。这些决策需要在利益相关者图中得到体现。

本阶段需要捕捉政策制定和战略决策，以便为后续工作提供量化依据；例如，合理化决策和指标、收入产生以及符合业务战略的目标。此外，还有其他需要解决的领域；例如，数字化转型和IT战略，其中关于架构愿景的决策将为组织在后续阶段提供领导力和方向。

对于架构愿景，建议先确定一个总体架构，展示所有不同架构领域可交付成果将如何整合在一起（基于所选的行动方案）。

根据利益相关者的关注点、业务能力需求、范围、限制和原则，创建基线架构和目标架构的高层次视图。架构愿景通常在高层次上涵盖项目所确定的范围广度。通常使用非正式技术，一种常见做法是绘制简单的解决方案概念图，简洁地展示解决方案的主要组件以及如何为企业带来收益。

业务场景是发现和记录业务需求以及阐述响应这些需求的架构愿景的适当且有效的技术。业务场景还可以在更详细的架构工作中使用（例如在第 B 阶段），其详细描述可见于 TOGAF® 系列指南：业务场景。

此步骤从业务、信息系统和技术角度生成基线和目标环境的初步定义，详见第 3.4 节。

这些架构的初始版本应存储在架构库中，并根据架构框架中的标准和指南进行组织。

3.3.9  定义目标架构价值主张和关键绩效指标（KPIs）

        ■ 为所需架构和变更制定商业案例
        ■ 为每个利益相关者群体制定价值主张
        ■ 评估和确定采购需求
        ■ 与相关赞助者和利益相关者审查并确认价值主张
        ■ 定义将融入企业架构中的性能指标和衡量标准，以满足业务需求
        ■ 评估业务风险（参见TOGAF标准——ADM技术）

此活动的输出应纳入《架构工作说明书》中，以便据此跟踪绩效。

3.3.10  识别业务转型风险及缓解措施

识别与架构愿景相关的风险，并评估风险的初始级别（如灾难性、关键性、边缘性或可忽略）及其潜在发生频率。

为每个风险分配缓解策略。TOGAF标准——ADM技术中描述了风险管理框架。

应考虑两个层次的风险，即：
        ■ 初始风险级别：在确定和实施缓解措施之前的风险分类
        ■ 剩余风险级别：实施缓解措施（如果有的话）后的风险分类

应考虑将风险缓解活动纳入《架构工作说明书》中。

3.3.11  制定架构工作说明书；确保获得批准

根据一系列业务性能要求，评估需要制作的工作产品（及其截止日期）。这将涉及确保：

        ■ 工作产品中融入了性能指标
        ■ 有具体的性能相关工作产品可用

然后，活动将包括：

        ■ 确定需要变更的新工作产品
        ■ 指导需更改的现有工作产品（包括构建块），并确保协调所有相关活动和依赖项
        ■ 确定变更对其他工作产品及其活动依赖的影响
        ■ 根据目的、重点、范围和约束条件，确定应开发哪些架构领域、详细程度如何以及应构建哪些架构视图
        ■ 评估在所需时间范围内完成工作所需的资源及可用性；这将包括遵循组织的规划方法和工作产品，以制定执行ADM周期的计划
        ■ 估算所需资源，为拟议的开发制定路线图和时间表，并在架构工作说明书中记录所有内容
        ■ 定义企业架构团队在本轮ADM周期中需达到的性能指标
        ■ 制定具体的企业架构沟通计划，并说明企业架构师将在何时、何地、如何与利益相关者（包括亲和群体和社区）沟通企业架构开发的进展
        ■ 与赞助者审查并商定计划，并根据适当的治理程序确保架构工作说明书获得正式批准
        ■ 获得赞助者的签字批准以继续执行

3.4 输出

阶段 A 的输出可能包括但不限于：

■ 已批准的架构工作说明书（参见TOGAF标准——架构内容），特别包括：
        — 架构项目描述与范围
        — 架构愿景概述
        — 架构项目计划与时间表
■ 经过完善的业务原则、业务目标和业务驱动因素说明书（参见TOGAF标准——架构内容）        ■ 架构原则（参见TOGAF标准——ADM技术）
■ 能力评估（参见TOGAF标准——架构内容）
■ 定制架构框架（参见TOGAF标准——架构内容）（针对本项目），包括：
        — 定制架构方法
        — 定制架构内容（可交付成果和工件）
        — 配置和部署的工具
■ 架构愿景（参见TOGAF标准——架构内容），包括：
        — 问题描述
        — 架构工作说明书的目标
        — 概括性观点
        — 业务场景（可选）
        — 完善的关键高层利益相关者需求
■ 架构定义文档草案，可能包括任何架构域的基线架构和/或目标架构
■ 沟通计划（参见TOGAF标准——架构内容）
■ 填充架构仓库的其他内容（参见TOGAF标准——架构内容）

3.5 方法

3.5.1 概述

A 阶段从发起组织向架构组织提交架构工作请求开始。确保获得公司管理层的认可与支持，以及部门管理层的支持和承诺的相关问题，详见 TOGAF 标准——企业架构能力与治理。

 A 阶段还定义了架构工作中包含和不包含的范围，以及必须应对的约束条件。范围界定决策需要基于资源和能力可用性的实际评估，以及在所选架构工作范围内企业能够切实获得的价值。相关问题在第 1.5 节中讨论。架构愿景阶段涉及的范围问题将仅限于本次 ADM 循环的具体目标，并在初步阶段确定的架构活动总体范围定义内，并在架构框架中体现。

当现有架构框架不适合实现期望的架构愿景时，应重新审视预备阶段并扩展企业的整体架构框架。

这些约束通常是根据业务原则和架构原则来制定的，这些原则是预备阶段的一部分（见第2章）。

通常，企业的业务原则、业务目标和战略驱动力已在其他地方定义。如果是这样，A阶段的活动就涉及确保现有定义是最新的，并澄清任何模糊之处。如果不是，则首次定义这些关键要素。

同样，作为对架构工作构成约束一部分的架构原则，通常也已在预备阶段定义（见第2章）。A阶段的活动涉及确保现有原则定义是最新的，并澄清任何模糊之处。否则，就需要按照TOGAF标准——ADM技术中所述，首次定义这些架构原则。

3.5.2 创建架构愿景

架构愿景为发起人提供了一个关键工具，用于向企业内的利益相关者和决策者推销拟议能力的益处。架构愿景描述了新能力在实现后将如何满足业务目标和战略意图，并解决利益相关者的关切。

架构愿景的核心在于理解新兴技术及其对行业和企业的潜在影响，否则可能会错失许多商业机会。

明确并认同架构工作的目的是这项活动的关键部分之一，且这一目的需要在所创建的愿景中得到清晰体现。架构项目往往带着特定的目的进行——即一组特定的业务驱动力，这些驱动力代表着架构开发对利益相关者的投资回报。明确这一目的，并展示拟议的架构开发将如何实现它，正是架构愿景的全部要点。

通常，架构愿景的关键要素（如企业使命、愿景、战略和目标）已被记录为更广泛商业战略或企业规划活动的一部分，这些活动在企业内部有其自身的生命周期。在这种情况下，A阶段的活动关注的是验证和理解已记录的商业战略和目标，并可能在企业战略和目标与当前架构现实中的隐含战略和目标之间建立桥梁。

商业模式是关键的战略成果，可以通过展示组织如何为客户和利益相关者创造价值来提供这种视角。第3.3.4节介绍了将商业模式应用于架构愿景开发的一个步骤。

在其他情况下，可能至今尚未进行多少或根本没有进行业务架构工作。在这种情况下，架构团队需要研究、验证并获得对架构所要支持的关键业务目标和流程的认可。这可以作为一项独立的工作进行，要么在架构开发之前，要么作为ADM启动阶段（预备阶段）的一部分。

此项工作应审查并查找关于基本业务架构概念的现有资料，例如：

■ 业务能力，代表企业为实现特定目的或结果而可能拥有或交换的特定能力或容量。
在这一阶段，架构师应确定组织中是否存在表示业务能力的框架。如果不存在，架构师应考虑开发框架是否属于项目范围。有关业务能力的介绍，请参阅TOGAF®系列指南：业务能力。

■ 价值流，代表为客户、利益相关者或最终用户创造整体结果的端到端增值活动集合。
有关价值流的介绍，请参阅TOGAF®系列指南：价值流。

■ 组织地图，描绘构成企业、其合作伙伴和利益相关者的主要实体之间的关系。
由于传统的组织结构图往往缺乏反映企业活动全貌的必要细节，架构师可以帮助识别和理解业务实体之间复杂的关系网，以及业务能力的使用情况和与价值流阶段的联系。这些将在后续阶段得到完善和扩展。有关组织地图的介绍，请参阅TOGAF®系列指南：组织映射。

此外，架构愿景还探讨了其他适用于当前企业架构的领域。这些领域可能包含基本领域的要素，但为利益相关者提供了额外的目的。示例领域可能包括：
■ 信息
■ 安全
■ 数字化
■ 网络管理
■ 知识
■ 行业特定
■ 服务
■ 合作伙伴关系
■ 网络安全
这些领域可以独立存在，也可以与其他领域相关联，以提供对整个企业愿景和结构的全面视图。

架构愿景阶段包括进行业务评估（例如，使用业务场景），其中记录关键因素并评估各种行动方案。记录高级别的优缺点，包括风险和机会，并选择最佳行动方案作为架构愿景的基础。

架构愿景提供了对基线架构和目标架构的初步、高级别描述，涵盖业务、数据、应用和技术领域。这些概要描述将在后续阶段中进一步开发。

一旦架构愿景在《架构工作说明书》中定义并记录下来，按照《TOGAF标准 —— 企业架构能力与治理》的描述，利用该愿景建立共识至关重要。没有这个共识，最终的架构很难被整个组织接受。通过发起组织签署《架构工作说明书》来达成共识。

第四章：B阶段：业务架构

本章描述了开发业务架构以支持已达成一致的架构愿景的过程。

图 4-1 B阶段：业务架构

4.1 目标 

B阶段的目标有：

■ 开发目标业务架构，描述企业如何运作以实现业务目标，并响应架构愿景中设定的战略驱动因素，以满足《架构工作说明书》和利益相关者的关注点。

■ 根据基线业务架构与目标业务架构之间的差距，确定候选架构路线图组件

4.2 输入

本节定义了B阶段的输入。

4.2.1 企业外部参考资料

■ 架构参考资料（参见TOGAF标准——架构内容）

4.2.2 非架构输入

■ 架构工作请求（参见TOGAF标准——架构内容）
■ 业务原则、业务目标和业务驱动力（参见TOGAF标准——架构内容）
■ 能力评估（参见TOGAF标准——架构内容）
■ 沟通计划（参见TOGAF标准——架构内容）

4.2.3 架构输入

■ 企业架构组织模型（参见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距及解决方案
— 架构团队的角色与职责
— 架构工作的限制条件
— 预算要求
— 治理和支持策略

■ 定制架构框架（参见TOGAF标准——架构内容），包括：
— 定制架构方法
— 定制架构内容（可交付成果和工件）
— 配置和部署的工具

■ 已批准的架构工作说明书（参见TOGAF标准——架构内容）

■ 架构原则（参见TOGAF标准——架构内容），包括（如果已存在）业务原则

■ 企业连续体（参见TOGAF标准——架构内容）

■ 架构库（参见TOGAF标准——架构内容），包括：
        — 可重用的构建块
        — 公开可用的参考模型
        — 组织特定的参考模型
        — 组织标准

■ 架构愿景（参见TOGAF标准——架构内容），包括：
        — 问题描述
        — 架构工作说明书的目标
        — 摘要观点
        — 业务场景（可选）
        — 提炼后的关键高层利益相关者需求

■ 架构定义文档草案，可能包括任何架构域的基线架构和/或目标架构

4.3 步骤

B阶段所处理的细节程度将取决于整体架构工作的范围和目标。

在B阶段，需要详细定义新的能够体现业务需求特征的模型。在目标环境中要保留和支持的现有业务工件可能已经在之前的架构工作中得到了充分定义；但如果没有，它们也需要在B阶段进行定义。

B阶段中各个步骤的顺序以及它们正式开始和完成的时间应根据既定的架构治理机制，适应当前情况。特别是，要根据TOGAF标准——应用ADM（Architecture Development Method，架构开发方法）中所述，确定在当前情况下是先进行基线架构开发还是目标架构开发更为合适。

在这些步骤中启动的所有活动都应在“完善业务架构”步骤（见第4.3.8节）中结束。从这些步骤中生成的文档必须在“创建/更新架构定义文档”步骤（见第4.3.9节）中正式发布。

B阶段 的步骤如下：

• 选择参考模型、视角和工具（见4.3.1节）
• 开发基线业务架构描述（见4.3.2节）
• 开发目标业务架构描述（见4.3.3节）
• 执行差距分析（见4.3.4节）
• 定义候选路线图组件（见4.3.5节）
• 解决架构景观中的影响（见4.3.6节）
• 进行正式的利益相关者审查（见4.3.7节）
• 最终完成业务架构（见4.3.8节）
• 创建/更新架构定义文档（见4.3.9节）

4.3.1  选择参考模型、视角和工具

根据业务驱动因素和利益相关者的关注点，从架构仓库中选择相关的业务架构资源（参考模型、模式等）。

选择相关的业务架构视角（例如，运营、管理、财务）；即那些能够使架构师展示业务架构中如何解决利益相关者关注点的视角。

结合所选视角，确定用于捕获、建模和分析的适当工具和技术。根据所需的复杂程度，这些可能包括简单的文档或电子表格，或者更复杂的建模工具和技术，如活动模型、业务流程模型、用例模型等。

4.3.1.1 确定整体建模流程

业务建模和战略评估是构建组织业务架构目标状态的有效技术（见第3.3.4节）。这些活动的输出随后被用来阐述为实现当前状态与目标状态之间差距所需的业务能力、组织结构和价值流。如第3.5节所述，这些映射的框架可能已经存在，并且应该加以利用，现在利用它们来表征差距，并更好地将业务价值映射到目标业务架构的实现上。

针对每个视角，选择支持所需特定视图的模型，并使用所选的工具或方法。

确保涵盖所有利益相关者的关注点。如果没有涵盖，则创建新的模型来解决未涵盖的关注点，或增强现有模型（见第4.5.7节）。业务场景是发现和记录业务需求的有用技术，并且可以在业务架构的层次分解中的不同详细程度上迭代使用。业务场景在《TOGAF®系列指南：业务场景》中有详细描述。

第4.5节中描述的技术可用于逐步分解业务：

■ 业务能力映射：识别、分类和分解业务为实现向一个或多个利益相关者提供价值所需的能力

■ 信息映射：收集对业务而言最重要的信息概念及其关系

■ 组织映射：表示业务的组织结构（包括第三方领域），描绘业务单元、这些单元分解为更低层次的功能以及组织关系（单位与单位之间以及映射到业务能力、地点和其他属性）

■ 流程建模：阐明企业的业务流程，以便进行分析和改进。

■ 结构化分析：识别架构范围内的关键业务能力，并将这些能力映射到企业内的业务功能和组织单位上

■ 用例分析：从用户角度识别系统或任务的需求

■ 价值流映射：对组织执行的活动进行端到端分解，以创造与利益相关者交换的价值。

价值流图展示了组织如何交付价值，其针对特定的利益相关者群体，并利用业务能力来创造利益相关者价值，并与目标业务架构的其他方面保持一致。

所需分解的层次和严谨程度因企业而异，并且企业内部也各不相同。架构师应考虑企业的目标、宗旨、范围和企业架构工作的目的，以确定分解的层次。

4.3.1.2 确定业务构建模块所需的目录

目录记录了企业核心资产的库存。目录本质上具有层次结构，能够捕获构建块的分解情况，以及相关联的构建块（例如，组织/参与者）之间的分解情况。

目录是开发矩阵和视图的基础材料，也是管理和信息技术能力的重要资源。

TOGAF标准——架构内容中包含对目录的详细描述，这些目录应在业务架构开发过程中予以考虑。该描述详细阐述了这些目录，并将它们与TOGAF企业元模型中的实体、属性和关系相关联。

4.3.1.3 确定所需矩阵

矩阵展示了相关模型实体之间的核心关系。

矩阵是开发视图的原始材料，也是进行影响评估（作为差距分析的一部分）的关键资源。

《TOGAF标准——架构内容》中包含了对矩阵的详细描述，这些矩阵应在业务架构开发过程中予以考虑。该描述详细阐述了这些矩阵，并将它们与TOGAF企业元模型中的实体、属性和关系相关联。

4.3.1.4 确定所需图表

图表根据利益相关者的需求，从一组不同的角度（视角）展示业务架构信息。

《TOGAF标准 — 架构内容》中详细描述了在业务架构中应该开发的图表，深入说明了这些图表的内容，并将其与TOGAF企业元模型中的实体、属性和关系相关联。

4.3.1.5  确定需要收集的需求类型

在开发了业务架构的目录、矩阵和图表后，通过形式化地定义业务需求来完成架构建模，以实现目标架构的实施。

这些需求可能：
■ 与业务领域相关
■ 为数据、应用和技术架构提供需求输入
■ 提供在设计和实施过程中需要体现的详细指导，以确保解决方案满足最初的架构需求

在这一步骤中，架构师应识别架构应满足的需求（见第13.5.2节）。

在许多情况下，架构定义的目的并不是为解决方案提供详细或全面的需求（因为这些需求可以通过一般的需求管理学科来更好地处理）。需求内容的预期范围应在架构愿景阶段确定，并在经批准的架构工作说明书中记录。

任何超出架构工作说明书定义范围的需求或需求变更，都必须提交给需求库，通过受管控的需求管理过程进行管理。

4.3.2 开发基线业务架构描述

开发现有业务架构的基线描述，必要时支持目标业务架构。需要定义的范围和细节水平取决于现有业务元素在多大程度上可能被纳入目标业务架构，以及是否已有架构描述（参见第4.5节）。

尽可能识别相关的业务架构构建模块，借助架构库（参见《TOGAF标准 — 架构内容》）。

如果需要开发新的架构模型来满足利益相关者的需求，请使用第1步中确定的模型作为创建新架构内容的指南，以描述基线架构。

4.3.3 开发目标业务架构描述

为目标业务架构开发一个目标描述，必要时支持架构愿景。需要定义的范围和细节水平将取决于业务元素与实现目标架构愿景的相关性，以及是否存在架构描述。

尽可能识别相关的业务架构构建模块，借助架构仓库（参见《TOGAF标准 — 架构内容》）。

如果需要开发新的架构模型以满足利益相关者的关注点，可以参照步骤1中确定的模型，作为创建新架构内容以描述目标架构的指导。

如果适用，可探讨不同的目标架构替代方案，并使用架构替代和权衡技术（参见《TOGAF标准 — ADM 技术》）与利益相关者讨论这些方案。

4.3.4 执行差距分析

验证架构模型的内部一致性和准确性：

• 进行权衡分析以解决不同视图之间的冲突（如有）
• 验证模型是否支持原则、目标和约束
• 记录从架构仓库中选定模型所代表视点的变化，并加以文档化
• 根据需求测试架构模型的完整性

使用差距分析技术（参见《TOGAF标准 — ADM 应用》）识别基线架构与目标架构之间的差距。

4.3.5 定义候选路线图组件

在创建了基线架构、目标架构以及完成了差距分析结果后，需要制定一个业务路线图来优先安排接下来各阶段的活动。

这份初步的业务架构路线图将作为原始材料，用于在“机会与解决方案”阶段进一步定义综合的跨学科路线图。

4.3.6 解决架构范围内的影响

一旦业务架构最终确定，就有必要了解任何更广泛的影响或含义。

在这一阶段，应该检查架构全景中的其他架构构件，以确定：

■ 此业务架构是否对任何现有的架构产生了影响？
■ 是否有最近的变更影响了业务架构？
■ 在组织的其他领域是否有机会利用此业务架构的工作？
■ 此业务架构是否影响了其他项目（包括计划中的项目以及当前正在进行的项目）？
■ 此业务架构是否会受到其他项目（包括计划中的项目以及当前正在进行的项目）的影响？

4.3.7 进行正式的利益相关者评审

根据架构项目的初始动机和架构工作声明，审查拟议的业务架构，确认其是否适合支持其他架构领域后续工作的目的。仅在必要时对拟议的业务架构进行完善。

4.3.8 最终确定业务架构

■ 为每个构建块选择标准，尽可能重用从架构库中选定的参考模型
■ 全面记录每个构建模块
■ 对整体架构与业务目标进行最终交叉核对；在架构文档中记录构建块决策的依据
■ 记录最终的需求可追溯性报告
■ 记录架构在架构仓库中的最终映射；从选定的构建块中，识别出可能重用的内容（工作方法、角色、业务关系、职位描述等），并通过架构库进行发布
■ 完成所有工作成果，如差距分析结果

4.3.9  创建/更新架构定义文档

■ 在架构定义文档中记录构建模块决策的依据
■ 准备与架构预期范围和用途相关的业务部分

如果适用，使用建模工具生成的报告和/或图形展示架构的关键视图。将文档提交相关利益相关者审阅，并整合他们的反馈意见。 

4.4 输出

B阶段的输出可能包括但不限于：

■ 架构愿景阶段可交付成果的精炼和更新版本（如适用），包括：
— 架构工作说明书（参见TOGAF标准——架构内容），如有必要进行更新
— 验证过的业务原则、业务目标和业务驱动力（参见TOGAF标准——架构内容），如有必要进行更新
— 架构原则（参见TOGAF标准——架构内容）
■ 架构定义文档草案（参见TOGAF标准——架构内容），包括：
— 已批准的基线业务架构（如适用）
— 已批准的目标业务架构，包括：
        — 组织结构——确定业务地点并将其与组织单位相关联
        — 业务目标和宗旨——针对企业和每个组织单位
        — 业务功能——一个详细的递归步骤，涉及将主要功能区逐步分解为子功能
        — 业务能力——企业为实现其目标和宗旨所需拥有或交换的能力
        — 业务服务——通过封装独特的“业务行为要素”来支持业务的服务；企业外部提供的服务                     可能由业务服务支持
        — 产品——企业为客户提供的产出；产品包括材料和/或服务
        — 业务流程，包括衡量指标和可交付成果
        — 业务角色，包括技能要求的开发和修改
        — 业务数据模型
        — 组织/业务功能和业务能力的相关性——以矩阵报告的形式将业务能力与组织单位相关联
— 与选定观点相对应的观点，解决关键利益相关者的关注点
■ 架构需求规范草案（参见TOGAF标准——架构内容），包括业务架构需求，如：
— 差距分析结果
— 技术要求——识别、分类和优先排序对剩余架构领域工作的影响；例如，通过依赖关系/优先级矩阵（例如，指导交易处理速度和安全性之间的权衡）；列出预期产生的具体模型（例如，以Zachman框架的原始要素表示）
— 更新的业务需求
■ 架构路线图中的业务架构组件（参见TOGAF标准——架构内容）
TOGAF标准——架构内容中详细描述了本阶段可能产生的架构构件。

4.5 方法

业务架构是对能力、端到端价值交付、信息以及组织结构的整体、多维业务视图的呈现；它还展示了这些业务视图与战略、产品、政策、举措和利益相关者之间的关系。业务架构将业务要素与业务目标以及其他领域的要素联系起来。

4.5.1 通用概述

对业务架构的了解是开展任何其他领域（数据、应用、技术）架构工作的先决条件，因此，如果尚未在其他组织流程（如企业规划、战略业务规划、业务流程再造等）中予以考虑，业务架构就是首先需要开展的活动。

从实际操作的角度来看，业务架构也往往是向关键利益相关者展示后续架构工作业务价值的一种手段，并向这些利益相关者展示他们支持和参与后续工作所能获得的投资回报。

B阶段的工作范围主要由A阶段提出的架构愿景来确定。业务战略定义了目标、驱动力和成功的衡量标准，但不一定说明如何实现这些目标。这正是B阶段详细定义的业务架构所发挥的作用。

这在很大程度上将取决于企业环境。在某些情况下，业务架构的关键要素可能已在其他活动中完成；例如，企业使命、愿景、战略和目标可能被记录在更广泛的业务战略或企业规划活动中，这些活动在企业内部有自己的生命周期。

在这种情况下，可能需要验证和更新当前记录的业务战略和计划，以及/或者在高层次的业务驱动力、业务战略和目标与本次架构开发工作相关的具体业务需求之间建立联系。

在其他情况下，到目前为止可能几乎没有或根本没有进行过业务架构工作。在这种情况下，架构团队需要研究、验证并获得对架构将要支持的关键业务目标和流程的认可。这可以作为一项独立的工作来进行，要么在架构开发之前，要么作为A阶段的一部分。

在这两种情况下，都可以使用业务场景技术（参见TOGAF®系列指南：业务场景）或任何其他能够阐明关键业务需求并指出隐含的IT架构技术需求的方法。

一个关键目标是尽可能重用现有材料。在架构成熟度更高的环境中，将存在现有的架构定义，这些定义（希望如此）自上一次架构开发周期以来一直被维护着。如果存在架构描述，则可以将其作为起点，并在必要时进行验证和更新；参见TOGAF标准——架构内容。

仅收集和分析与本次架构工作范围相关的信息，以便做出明智的决策。如果本次工作专注于定义（可能是新的）业务流程，则B阶段必然涉及大量详细工作。如果工作重点是支持现有业务架构的其他领域（数据/信息、应用系统、基础设施）的目标架构，则在B阶段中构建完整的架构全貌尤为重要，同时避免不必要的细节处理。

4.5.2 开发基线描述

如果企业已经有现有的架构描述，应将其用作基线描述的基础。这些输入可能已经在 阶段 A 中被用于开发架构愿景，例如业务能力地图或第 3.5.2 节中提到的核心价值流，并且它们本身可能足以作为基线描述的依据。

更新这些材料的原因包括缺失的业务能力，新的价值流，亦或是尚未在企业架构项目范围内评估的变更组织单元。第 4.5.3 节到第 4.5.6 节 讨论了使用核心业务架构方法，基于阶段 A 的战略范围建模业务架构的方法。需要注意的是，将这些方法付诸实践以推动后续架构工作的聚焦和目标状态，并不意味着阶段 A 中的基本框架（例如通用企业业务能力地图）必然会发生改变，而是基于具体企业架构项目的范围和需求来应用这些框架。

如果不存在架构描述，则需要收集信息并开发业务架构模型。

无论具体项目的范围如何，重要的是确定是企业的基本业务视图发生了变化，还是这些视图的使用方式发生了变化，从而确定特定项目相对于企业其他部分的范围、优先级和关系。

4.5.3  应用业务能力

在架构愿景阶段找到或开发的业务能力地图提供了一个独立的业务视图，这一视图独立于当前的组织结构、业务流程、信息系统和应用程序以及产品或服务组合中的其他部分。这些业务能力应映射到企业架构项目范围内的组织单元、价值流、信息系统和战略计划上。这种关系映射能够更深入地了解各领域的对齐和优化情况（参见 TOGAF® 系列指南《业务能力》中关于关系映射的部分）。

另一个常见的分析技术是热图分析，它可以用来展示相同核心业务能力集的多个不同视角。这些视角包括成熟度、有效性、绩效以及每项能力对业务的价值或成本。不同的属性决定了业务能力地图上每种能力的颜色（参见 TOGAF® 系列指南《业务能力》中关于热图分析的部分）。

例如，一个业务能力成熟度热图可以通过颜色表示特定能力的期望成熟度：绿色表示已达期望的成熟度，黄色表示低一个等级，红色表示低两个或更多等级。其他颜色可能表示不同的状态，例如紫色可能表示公司尚不存在但期望获得的能力，或者表示某一能力被过度投资，分配了超出必要的资源。这种差距分析直接与当前的企业架构项目相关联；差距只有在业务需求的背景下才有意义，并为此阶段中的进一步映射或后续架构阶段的优先事项提供了重点。

4.5.4 应用价值流

价值流为利益相关者提供了关于组织为何需要业务能力的宝贵背景信息，而业务能力则说明了组织为了在特定价值阶段取得成功所需的内容。

从架构愿景阶段记录的业务初始价值流模型集开始。在特定的企业架构项目范围内，如果项目范围足够广泛，可能需要创建尚未存储在知识库中的新价值流。

可以通过热图分析（按价值流阶段）或围绕价值流的完整定义开发用例（请参阅TOGAF®系列指南中的《价值流：基线示例》）在项目范围内分析新的或现有的价值流。项目可能侧重于特定的利益相关者、业务价值的一个要素，或强调某些阶段而非其他阶段，以便在后续阶段为解决方案开发更好的需求。

最大的实质性好处来自于将价值流中的各个阶段与业务能力进行映射，然后针对特定利益相关者通过价值流实现业务价值的能力（如热图分析）进行差距分析（请参阅TOGAF®系列指南中的《将价值流映射到业务能力》）。

4.5.5 应用组织图

组织图展示了构成企业生态系统的关键组织单元、合作伙伴和利益相关者群体。该图还应描绘这些实体之间的工作关系，这与仅显示层级汇报关系的组织架构图有所不同。组织图通常被描绘为各种业务实体之间关系和交互的网络或网状图（参见明茨伯格和范德海登于1999年所著的《组织图：描绘公司的真实运作》）。

业务单元是建立组织图的主要概念。根据对企业构成相对宽泛的理解，企业可能是正在进行的项目中的一个业务单元，也可能包括所有业务单元，或者还包括第三方或其他利益相关者群体。具体的解读取决于架构工作的范围。

此图是业务架构的关键要素，因为它为整个企业架构工作提供了组织背景。能力映射揭示了企业所做的事情，价值流映射则揭示了企业如何向特定利益相关者提供价值，而组织图则确定了拥有或使用这些能力的业务单位或第三方，以及哪些单位或第三方参与了价值流。

结合第4.5.3节、第4.5.4节以及相关指南中的方法，组织图有助于理解哪些业务单位应参与架构工作、何时与谁讨论特定需求，以及如何衡量各项决策的影响。

有关组织图的进一步指导，请参阅TOGAF®系列指南：《组织映射》。

4.5.6 应用信息图

在业务架构阶段，信息的表征始于对业务最重要的元素进行识别，例如产品、客户、工厂等。通过列出这些关键元素，跨学科的团队可以列出并绘制出最重要的信息，并以业务术语来描述这些信息。信息领域可以从业务术语所归类的组或类别中推导出来。这些领域是构建信息图的良好起点，因为它们有助于确保信息图的完整性，并能够最大化其价值，之后可以进一步详细讨论数据类型的细节。

接下来，可以在信息图中添加信息领域之间的关系，这将有助于形成一个良好的基准信息图，提供更深入的理解。接下来的最重要的步骤是构建信息与业务能力之间的矩阵。将对业务最重要的信息与描述如何利用这些信息创造价值的业务能力进行关联，是业务架构中的一个关键环节。这些信息图以及与业务能力的关系将在后续的架构阶段中应用，涉及数据表征、应用程序和基础设施等方面。

有关信息图的更多指导，请参阅《TOGAF® 系列指南：信息映射》。

4.5.7 应用建模技术

此处提供的建模和映射技术是扩展手段，旨在将上述B阶段中描述的业务能力、价值流和组织图付诸实践。它们扩展了运营模型，该模型展示了组织如何在多个领域运作以实现其目标（参见《一种识别流程复用机会以增强运营模型的方法》，M. de Vr ies等人）。

除了上述技术（能力图、价值流和组织图）外，如果认为合适，还可以采用多种其他建模技术。例如：

■ 活动模型（也称为业务流程模型）描述了企业的业务活动、活动之间交换的数据和/或信息（内部交换），以及与模型范围外其他活动交换的数据和/或信息（外部交换）。
活动模型具有层次性。它们捕捉业务流程中的活动，以及这些活动的输入、控制、输出和机制/资源（ICOMs）。活动模型可以通过明确的业务规则说明进行注解，这些规则代表了ICOMs之间的关系。例如，一条业务规则可以规定在特定条件下谁可以做什么、需要哪些输入和控制的组合，以及产生的输出。创建活动模型的一种技术是集成计算机辅助制造（ICAM）定义（IDEF）建模技术。对象管理组织（OMG）开发了业务流程建模表示法™（BPMN™），这是一种业务流程建模的标准，包括一种用于指定业务流程、其任务/步骤和产生的文档的语言。

■ 用例模型从用例和与业务流程和组织参与者（人、组织等）相对应的角色角度描述了企业的业务流程。
用例模型在用例图和用例规范中进行描述。

■ 逻辑数据模型（或类模型）
逻辑数据模型描述了实体、它们的属性、这些属性的可接受值以及各个实体之间的关系。对于分析而言，“是”关系特别有用。例如，如果轿车是一种汽车，而汽车又是一种车辆，那么就可以为所有车辆编写一条通用的业务规则，并自动适用于所有类型的汽车和卡车。
类模型通过包含实体（现在称为类）特有的服务（方法）来扩展逻辑数据模型以包含行为。通常，应用程序和信息架构师将使用类图，而业务架构师将使用逻辑数据模型。

 上述三种类型的模型都可以用统一建模语言™（UML®）来表示，并且存在多种用于生成此类模型的工具。某些行业领域拥有针对该领域特定的建模技术。

4.5.8 架构仓库

作为B阶段的一部分，架构团队需要考虑从架构库（参见TOGAF标准——架构内容）中可以获取哪些相关的业务架构资源，特别是：

■ 与组织所在行业相关的行业参考模型
■ 企业特定的业务架构视图（能力地图、价值流地图、组织地图等）
■ 企业特定的构建块（流程组件、业务规则、职位描述等）
■ 适用的标准

第五章：C阶段：信息系统架构

本章介绍一个架构项目的信息系统架构，包括数据和应用架构的开发。

图5-1 C阶段：信息系统架构

5.1 目标

C阶段的目标有：

    ■ 开发目标信息系统架构，描述企业的信息系统架构将如何支持业务架构和架构愿景，以符合           架构工作说明书并解决利益相关者的关注点
     ■ 根据基线信息系统架构与目标信息系统架构（数据和应用）之间的差异，确定候选架构路线            图组件

5.2 方法

C阶段涉及数据架构和应用架构的某种组合，顺序可以是任意的。对于这两种顺序，各有支持者。例如，Steven Spewak的《企业架构规划》（EAP）推荐采用以数据为驱动的方法。

另一方面，主要的应用系统——如企业资源规划（ERP）、客户关系管理（CRM）等——通常同时提供技术基础设施和业务应用逻辑。一些组织采取应用驱动的方法，他们认识到某些关键应用程序构成了关键业务流程的核心支撑，并将这些核心应用的实施与集成作为其架构工作的主要重点（而集成问题往往构成一个主要挑战）。

C阶段的详细描述分别在每个架构领域中给出：
■ 阶段C：信息系统架构——数据架构（见第6章）
■ 阶段C：信息系统架构——应用架构（见第7章）

第六章：C阶段：信息系统架构--数据架构

本章描述C阶段的数据架构。

6.1 目标

        C阶段的数据架构的目标有：

        ■ 开发目标数据架构，支持业务架构和架构愿景，以解决架构工作声明和利益相关者的关注点。
       ■ 根据基线数据架构与目标数据架构之间的差距，确定候选架构路线图组件

6.2  输入

          本节定义C阶段（数据架构）的输入

6.2.1 企业外部的参考资料

         ■ 架构参考资料（参见TOGAF标准——架构内容）
         ■ TOGAF® 系列指南：信息架构——客户主数据管理
         ■ 开放群组指南：信息架构：商业智能与分析以及元数据管理参考模型

6.2.2 非架构输入

        ■ 架构工作请求（参见TOGAF标准——架构内容）

        ■ 能力评估（参见TOGAF标准——架构内容）

        ■ 沟通计划（参见TOGAF标准——架构内容）

6.2.3 架构输入

        ■ 企业架构组织模型（参见TOGAF标准——架构内容），包括：
                — 受影响组织的范围
                — 成熟度评估、差距及解决方案
                — 架构团队的角色与职责
                — 架构工作的限制
                — 预算要求
                — 治理和支持策略
        ■ 定制架构框架（参见TOGAF标准——架构内容），包括：
                — 定制架构方法
                — 定制架构内容（交付物和制品）
                — 配置和部署的工具
        ■ 数据原则（参见TOGAF标准——ADM技术），如已存在                                                                  ■ 架构工作说明书（参见TOGAF标准——架构内容）
        ■ 架构愿景（参见TOGAF标准——架构内容）
        ■ 架构仓库（参见TOGAF标准——架构内容），包括：
                — 可重用的构建块（特别是当前数据的定义）
                — 公开可用的参考模型
                — 组织特定的参考模型
                — 组织标准
        ■ 架构定义文档草案，可能包括任何架构域的基线架构和/或目标架构
        ■ 架构需求规范草案（参见TOGAF标准——架构内容），包括：
                — 差距分析结果（来自业务架构）
                — 将应用于本阶段的相关技术要求
        ■ 架构路线图中的业务架构组件（参见TOGAF标准——架构内容）

6.3 步骤

C阶段的详细程度将取决于整体架构工作的范围和目标。作为此工作一部分引入的新数据构建模块需要在C阶段详细定义。那些将在目标环境中延续和支持的现有数据构建模块，可能已经在之前的架构工作中得到了充分定义；但如果没有，它们也需要在C阶段进行定义。

本阶段步骤的顺序，以及正式开始和完成的时间，应根据当前情况并遵循已建立的架构治理进行调整。特别是，需确定在当前情况下，是否应首先进行基准描述或目标架构的开发，如TOGAF标准中所述——应用ADM（架构开发方法）。

在这些步骤中启动的所有活动应在“最终确定数据架构”步骤中完成（参见第6.3.8节）。这些步骤生成的文档必须在“创建/更新架构定义文档”步骤中正式发布（参见第6.3.9节）。

C阶段（数据架构）的步骤如下：
■ 选择参考模型、视角和工具（见第6.3.1节）
■ 开发基线数据架构描述（见第6.3.2节）
■ 开发目标数据架构描述（见第6.3.3节）
■ 执行差距分析（见第6.3.4节）
■ 定义候选路线图组件（见第6.3.5节）
■ 解决架构景观中的影响（见第6.3.6节）
■ 进行正式利益相关者审查（见第6.3.7节）
■ 完成数据架构（见第6.3.8节）
■ 创建/更新架构定义文档（见第6.3.9节）

6.3.1 选择参考模型、视角、工具

回顾并验证（如有必要则生成）一系列数据原则。这些原则通常将构成一套总体架构原则的一部分。关于如何制定和应用这些原则，以及一组数据原则的示例，请参阅TOGAF标准——架构开发方法（Architecture Development Method，简称ADM）技术。

根据业务驱动因素、利益相关者、关注点以及业务架构，选择相关的数据架构资源（参考模型、模式等）。

选择相关的数据架构视角（例如，数据的利益相关者——监管机构、用户、生成者、主题专家、审计员等；各种时间维度——实时、报告周期、事件驱动等；位置；业务流程）；即那些能够让架构师展示如何在数据架构中解决利益相关者关注点的视角。

确定与所选视角相关的用于数据捕获、建模和分析的适当工具和技术（包括表单）。根据所需的复杂程度，这些可能包括简单的文档或电子表格，或者更复杂的建模工具和技术，如数据管理模型、数据模型等。

数据建模技术的示例包括：
■ 实体关系图
■ 类图

关于信息架构参考模型的进一步指导，可参阅以下文档：
■ TOGAF®系列指南：信息架构——客户主数据管理
■ The Open Group指南：信息架构：商业智能与分析及元数据管理参考模型

6.3.1.1确定整体建模过程

对于每个视角，使用所选的工具或方法，选择支持所需特定视角所需的模型。

确保涵盖所有利益相关者的关注点。如果没有涵盖，则创建新的模型来解决未涵盖的问题，或扩展现有模型（见上文）。

开发数据架构的推荐过程如下：

        ■ 从现有的业务架构和应用架构材料中收集与数据相关的模型

        ■ 合理化数据需求，并与任何现有的企业数据目录和模型对齐；这有助于开发数据清单和实                体关系图

        ■ 通过将数据与业务服务、业务能力、业务功能、访问权限和应用程序相关联，更新和开发                架构中的矩阵

        ■ 通过研究数据的创建、分发、迁移、保护和归档方式，详细阐述数据架构视图

6.3.1.2 确定所需的数据构建块目录

数据描述可以作为目录进行捕获，展示相关模型实体之间的分解（例如，数据实体 -> 逻辑数据组件 -> 物理数据组件）。

在业务架构阶段，创建了业务服务/信息图，展示了主要业务服务所需的关键数据实体。这是成功进行数据架构活动的前提条件。

通过使用从业务功能/业务能力到应用程序和数据实体的可追溯性，可以创建支持架构愿景所需的数据清单。

一旦将所有数据需求整合到一个位置，就可以对数据清单进行细化，以实现语义一致性，并消除差距和重叠。

TOGAF标准——架构内容中包含了应在数据架构开发中考虑的目录的详细描述，详细描述了这些目录，并将其与TOGAF企业元模型中的实体、属性和关系相关联。

6.3.1.3 确定所需的矩阵

在这个阶段，可以生成一个实体与应用程序的矩阵，以验证这种映射。此时，数据是如何被创建、维护、转换，并传递给其他应用程序，或被其他应用程序使用的情况，应该开始得到理解。需要注意一些明显的差距，比如某些实体似乎永远不会被某个应用程序创建，或者是创建了但从未使用的数据，这些都需要在后续的差距分析中加以关注。

经过合理化的数据清单可以用于更新和完善数据与其他架构方面相关联的架构图

一旦这些更新完成，可能需要进入应用架构的一个短期迭代，以解决所识别的变更。

TOGAF 标准 — 架构内容包含了有关应在数据架构中开发的矩阵的详细描述，详细说明这些矩阵，并将其与 TOGAF 企业元模型中的实体、属性和关系相关联。

6.3.1.4 确定所需图表

图表根据利益相关者的需求，从不同视角（观点）呈现数据架构信息。
一旦数据实体得到细化，就可以绘制出实体及其属性之间的关系图。
在此阶段，重要的是要注意，信息可能是企业级数据（来自系统服务提供商和软件供应商信息）和个人数据库及电子表格中保存的本地级数据的混合体。
需要对建模的详细程度进行仔细评估。一些物理系统数据模型会详细到非常具体的层面；而其他模型则只建模核心实体。并非所有数据模型都会随着应用程序的修改和扩展而保持最新状态。所提供的详细程度应达到平衡（例如，再现现有的详细系统物理数据模式或展示高级流程图和数据需求，这两者体现了两种极端观点）。
《TOGAF标准——架构内容》中包含对数据架构开发中应考虑的图表的详细描述，详细阐述了这些图表，并将它们与TOGAF企业元模型中的实体、属性和关系相关联。

6.3.1.5 确定需收集的需求类型

一旦数据架构的目录、矩阵和图表开发完成，就通过规范实施目标架构所需的数据导向型需求来完成架构建模。

这些需求可能：

■ 与数据域相关
■ 为应用架构和技术架构提供需求输入
■ 为设计和实施过程提供详细指导，以确保解决方案满足最初的架构需求

在这一步骤中，架构师应确定架构应满足的需求

6.3.2 开发基线数据架构描述

制定现有数据架构的基准描述，必要时支持目标数据架构的实施。所需定义的范围和详细程度将取决于现有数据元素在多大程度上会被纳入目标数据架构，以及是否存在架构描述，具体参见第6.5节。尽可能识别相关的数据架构构建块，参考架构库（参见 TOGAF 标准 — 架构内容）。

当需要开发新的架构模型以满足利益相关者的关注点时，使用第1步中识别的模型作为创建新架构内容的指南，以描述基准架构。

6.3.3 开发目标架构描述

制定目标数据架构的描述，必要时支持架构愿景和目标业务架构的实现。所需定义的范围和详细程度将取决于数据元素对实现目标架构的相关性，以及是否存在架构描述。尽可能识别相关的数据架构构建块，参考架构库（参见 TOGAF 标准 — 架构内容）。

当需要开发新的架构模型以满足利益相关者的关注点时，使用第1步中识别的模型作为创建新架构内容的指南，以描述目标架构。

如有必要，调查不同的目标架构替代方案，并使用架构替代方案与权衡技术与利益相关者进行讨论（参见 TOGAF 标准 — ADM 技术）。

6.3.4 执行差距分析

验证架构模型的内部一致性和准确性：
■ 进行权衡分析以解决（如果存在）不同视图之间的冲突
■ 验证模型是否支持原则、目标和约束条件
■ 记录从架构仓库中选择的模型中表示的观点所发生的变更，并文档化
■ 测试架构模型的完整性，确保其满足需求

使用TOGAF标准中的ADM技术所述的差距分析技术，识别基线与目标之间的差距。

6.3.5 定义候选路线图组件

在创建基准架构、目标架构和差距分析之后，需要制定数据路线图，针对未来各阶段的活动确定优先级。

6.3.6 解决架构环境中的影响

一旦数据架构最终确定，就需要理解其可能带来的更广泛的影响或后果。

在这个阶段，应该检查架构环境中的其他架构成果，以确定：

■ 这个数据架构是否对任何现有的架构产生了影响？
■ 是否有最近的变更对数据架构产生了影响？
■ 是否有机会在组织的其他领域利用这个数据架构的工作？
■ 这个数据架构是否影响了其他项目（包括计划中的项目和正在进行中的项目）？
■ 这个数据架构是否会被其他项目（包括计划中的项目和正在进行中的项目）所影响？

6.3.7 进行正式的利益相关者审查

核对架构项目的初衷和架构工作说明书与所提议的数据架构是否一致。进行影响分析，以确定业务架构和应用架构（例如，业务实践）可能需要做出哪些调整，以适应数据架构的变化（例如，表单或程序、应用程序或数据库系统的变化）。

如果影响显著，则可能需要重新审视业务架构和应用架构。

确定应用架构（如果在此阶段已生成）可能需要做出哪些调整，以适应数据架构的变化（或确定即将设计的应用架构所面临的约束）。

如果影响显著，则在此阶段可能适合对应用架构进行短暂的迭代。

确定即将设计的技术架构所面临的任何约束，并仅在必要时完善所提议的数据架构。

6.3.8 最终确定数据架构

■ 为每个构建块选择标准，尽可能多地重用来自架构库的参考模型
■ 对每个构建块进行全面记录
■ 对整体架构与业务需求进行最终交叉核对；在架构文档中记录构建块决策的理由
■ 记录最终的需求可追溯性报告
■ 记录架构仓库内架构的最终映射；从所选构建块中识别出可能重用的部分，并通过架构仓库进行发布
■ 完成所有工作产品，如差距分析

6.3.9 创建/更新架构定义文档

在架构定义文档中记录构建块决策的依据。

准备架构定义文档中关于数据架构的部分，包含以下内容中的部分或全部：

■ 业务数据模型
■ 逻辑数据模型
■ 数据管理过程模型
■ 数据实体/业务功能矩阵
■ 数据互操作性要求（例如，XML架构、安全策略）

如果适当，使用建模工具生成的报告和/或图形来展示架构的关键视图；将文档提交给相关利益相关者进行审查，并整合反馈意见。

6.4 输出

C阶段（数据架构）的输出包括，但不限于：

■ 架构愿景阶段可交付成果的修订和更新版本，视情况而定：
        — 架构工作说明书（参见TOGAF标准——架构内容），如有必要则进行更新
        — 验证后的数据原则（参见TOGAF标准——ADM技术），或新生成的数据原则（如在此阶段生成）
■ 架构定义文档草案（参见TOGAF标准——架构内容），包括：
        — （如适用）已批准的基线数据架构
        — 已批准的目标数据架构，包括：
        — 业务数据模型
        — 逻辑数据模型
        — 数据管理过程模型
        — 数据实体/业务功能矩阵
        — 对应于选定观点、解决关键利益相关者关注点的视图
■ 架构需求规范草案（参见TOGAF标准——架构内容），包括数据架构需求，如：
        — 差距分析结果
        — 数据互操作性要求
        — 将适用于本架构开发周期演进的相关技术要求
        — 对即将设计的技术架构的约束
        — （如适用）更新的业务需求
        — （如适用）更新的应用需求
■ 架构路线图中的数据架构组件（参见TOGAF标准——架构内容）
TOGAF标准——架构内容中详细描述了本阶段可能产生的架构制品。

6.5 方法

6.5.1 数据结构

数据架构应能够处理：
        ■ 静态数据——存储中的数据
        ■ 动态数据——交易或服务/API中的数据
        ■ 使用中的数据——应用程序边界处的数据（例如，图形用户界面）
        ■ 开放数据——组织为公众使用而提供的数据，以及组织自愿或依法必须提供的数据
将增加处理这些类型数据架构的不同替代方法。

数据架构是通过使用三个元模型实体创建的：数据实体、逻辑数据组件和物理数据组件。

数据实体可用于创建概念数据模型，以帮助IT开发人员理解他们将处理的概念。通常，实体关系模型还包含对关系的一些要求（例如，一个客户只能有一个地址）。

逻辑数据组件可用于创建逻辑数据模型。对于IT领域而言，清晰地了解IT环境中使用的所有数据通常很重要。逻辑数据模型通常被用作对应用程序中存储的数据（静态数据）、应用程序之间流转的数据（动态数据）或应用程序用户界面处的数据（使用中的数据）的要求。

物理数据组件是之前某个项目已实现（链接到例如XML消息、数据库模式）的逻辑数据组件的集群，或是对新实施项目的要求。

所有这三个数据实体都可以用于在IS服务、逻辑应用程序组件或物理应用程序组件之间/传进/传出时传递数据的数据交换模型。
所有数据实体都可以针对特定情况具有质量属性。

6.5.2 数据架构的关键考量因素

6.5.2.1 数据管理

当企业决定进行大规模架构转型时，了解并解决数据管理问题至关重要。采用结构化和全面的数据管理方法，能够有效利用数据，从而发挥竞争优势。

需要考虑的因素包括：

■ 清晰定义在企业架构中哪些应用组件将作为企业主数据的记录系统或参考系统
■ 是否会有一个企业范围的标准，要求所有应用组件，包括软件包，都必须采用？
（通常，软件包对数据模型的要求可能较为严格，且可能不具备灵活性。）
■ 清晰理解数据实体如何被业务能力、业务功能、流程以及业务和应用服务所利用
■ 清晰理解企业数据实体如何以及在哪里被创建、存储、传输和报告
■ 支持应用间信息交换所需的数据转换的级别和复杂性是什么？
■ 支持与企业客户和供应商的数据集成的软件需求是什么？（例如，在数据迁移过程中使用提取、转换、加载（ETL）工具、使用数据分析工具评估数据质量等）

关于数据管理的更多指导，请参见《TOGAF®系列指南：信息架构——客户主数据管理》。

6.5.2.1 数据迁移

当现有应用程序被替换时，数据（主数据、事务数据和参考数据）的迁移将成为一个关键需求。数据架构应识别数据迁移的需求，并提供有关所需数据转换、筛选和清洗水平的指标，以便将数据以符合目标应用程序要求和约束的格式呈现。目标是确保目标应用程序在填充数据时具有高质量的数据。

另一个关键考虑因素是确保建立企业范围内的通用数据定义，以支持转型过程。

6.5.2.3 数据治理

数据治理考虑以下因素，确保企业具备必要的条件来支持转型：

■ 结构：此维度涉及企业是否拥有必要的组织结构和标准机构来管理数据实体在转型中的相关方面。

■ 管理系统：在此方面，企业应拥有必要的管理系统和数据相关程序，以在整个生命周期内管理数据实体的治理方面。

■ 人员：这一维度解决了企业为实现转型所需的数据相关技能和角色

如果企业缺乏这些资源和技能，那么企业应考虑要么获取这些关键技能，要么通过明确的学习计划培训现有的内部资源以满足要求。

6.5.3 架构仓库

在这一阶段，架构团队需要考虑组织架构库（参见TOGAF标准——架构内容）中有哪些相关的数据架构资源可用；特别是与组织所在行业“垂直”领域相关的通用数据模型。

第七章：C阶段：信息系统架构--应用架构

本章描述了C阶段中的应用程序架构部分。

7.1 目标

C阶段中应用程序架构部分的目标是：

        ■ 开发目标应用程序架构，该架构能够以满足《架构工作说明书》和利益相关方关注点的                    方式，使业务架构和架构愿景得以实现

        ■ 根据基线应用程序架构与目标应用程序架构之间的差距，确定候选架构路线图组件

7.2 输入

        本节定义了C阶段（应用架构）的输入

7.2.1 企业外部参考资料

■ 架构参考资料（参见TOGAF标准——架构内容）

7.2.2 非架构输入

        ■ 架构工作请求（参见TOGAF标准——架构内容）
        ■ 能力评估（参见TOGAF标准——架构内容）
        ■ 沟通计划（参见TOGAF标准——架构内容）

7.2.3 架构输入

■ 企业架构组织模型（参见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距及解决方案
— 架构团队的角色与职责
— 架构工作的限制
— 预算要求
— 治理与支持策略

■ 定制架构框架（参见TOGAF标准——架构内容），包括：
— 定制架构方法
— 定制架构内容（交付成果和制品）
— 配置并部署的工具

■ 应用原则（参见TOGAF标准——ADM技术），如存在

■ 架构工作说明书（参见TOGAF标准——架构内容）

■ 架构愿景（参见TOGAF标准——架构内容）

■ 架构知识库（参见TOGAF标准——架构内容），包括：
— 可重用的构建块
— 公开可用的参考模型
— 组织特定的参考模型
— 组织标准

■ 架构定义文档草案，可能包含任何架构域的基线架构和/或目标架构

■ 架构需求规范草案（参见TOGAF标准——架构内容），包括：
— 差距分析结果（如可用，来自业务架构和数据架构）
— 将适用于本阶段的相关技术要求

■ 如有可用，架构路线图中的业务架构和数据架构组件（参见TOGAF标准——架构内容），

7.3 步骤

C阶段的细节程度将取决于整体架构工作范围和目标。

在这一阶段，作为此项工作一部分引入的新应用构建块需要进行详细定义。对于那些将在目标环境中继续使用并支持的现有应用构建块，可能已经在之前的架构工作中得到了充分定义；但如果没有，它们也需要在C阶段进行定义。

本阶段各步骤的顺序，以及正式启动和完成的时间，应该根据实际情况进行调整，并遵循已建立的架构治理。在此过程中，特别需要确定是否应根据TOGAF标准 — 应用ADM，首先进行基线描述或目标架构开发。

在本阶段中启动的所有活动，应在“最终确定应用架构”步骤（见第7.3.8节）中完成。由这些步骤生成的文档必须在“创建/更新架构定义文档”步骤（见第7.3.9节）中正式发布。

C阶段（应用架构）的步骤如下：
        ■ 选择参考模型、视角和工具（见第7.3.1节）
        ■ 开发基线应用架构描述（见第7.3.2节）
        ■ 开发目标应用架构描述（见第7.3.3节）
        ■ 执行差距分析（见第7.3.4节）
        ■ 定义候选路线图组件（见第7.3.5节）
        ■ 解决架构全景中的影响（见第7.3.6节）
        ■ 进行正式的利益相关者评审（见第7.3.7节）
         确定应用架构（见第7.3.8节）
        ■ 创建/更新架构定义文档（见第7.3.9节）

7.3.1 选择参考模型，视角和工具

审查和验证（如有必要则生成）一系列应用原则。这些原则通常将构成一套总体架构原则的一部分。关于开发和应用原则的指导原则，以及一套应用原则的示例，请参见TOGAF标准——架构开发方法（ADM）技术。

根据业务驱动力、利益相关者及其关注点，从架构仓库中选择相关的应用架构资源（如参考模型、模式等）。

选择相关的应用架构视角（例如，应用程序的利益相关者——与应用程序的功能性和单个用户相关的视角等）；即，选择能够使架构师展示如何在应用架构中解决利益相关者关注点的视角。

确定适当的工具和技术，以配合所选视角进行捕捉、建模和分析。根据所需的复杂度，这些工具和技术可以是简单的文档或电子表格，也可以是更复杂的建模工具和技术。

考虑使用与平台无关的业务逻辑描述。例如，OMG的模型驱动架构®（MDA®）提供了一种建模应用架构的方法，它能够在底层平台和实现技术发生变化时，保持业务逻辑的独立性。

7.3.1.1 确定整体建模流程

对于每个视角，使用所选工具或方法选择支持特定视图所需的模型。

确保覆盖所有利益相关者的关注点。如果未覆盖，需创建新模型来解决未涉及的关注点，或者对现有模型进行增强（如上所述）。

开发应用架构的推荐过程如下：

■ 基于基线应用组合、需求和业务架构范围，了解所需的应用或应用组件列表。
■ 通过将复杂的应用拆解为两个或更多应用来简化复杂的应用。
■ 确保应用定义集内部一致，通过尽可能消除重复功能并将相似的应用合并为一个来实现。
■ 确定逻辑应用和最合适的物理应用。
■ 通过将应用与业务服务、业务能力、数据、流程等关联，开发架构矩阵。
■ 通过检查应用如何运作，捕捉集成、迁移、开发和运营方面的关注点，进一步阐述一组应用架构视图。

所需的拆解级别和严格性因企业而异，也会因企业内部不同部门而有所不同，架构师应根据企业的目标、任务、范围和企业架构工作目标来确定拆解的层次。拆解的粒度应足够细致，以便能够识别差距并界定候选工作包的范围。

7.3.1.2 确定所需的应用构建块目录

组织的应用组合在架构仓库中记录为一个目录。目录是层次结构的，捕获了元模型实体的分解，以及相关模型实体之间的分解（例如，逻辑应用组件 → 物理应用组件 → 应用服务）。

目录构成了开发矩阵和图表的原始材料，同时也是管理业务和IT能力的关键资源。

目录的结构基于元模型实体的属性，这些属性在TOGAF标准 — 架构内容中已有定义。

TOGAF标准 — 架构内容包含了有关目录的详细描述，这些目录应在应用架构中考虑开发，详细描述它们并将其与TOGAF企业元模型中的实体、属性和关系相关联。

7.3.1.3 确定所需的矩阵

矩阵显示了相关模型实体之间的核心关系。
矩阵构成了开发图表的原始材料，并且是影响评估的关键资源。

一旦基线应用组合已组建完成，就需要将应用程序与其在支持业务方面的作用进行映射。初步的映射应聚焦于业务架构中的业务服务，因为这是架构决策最可能需要进行的粒度层级。

一旦应用程序与业务服务映射完成，也可以通过在业务架构阶段开发的业务信息图表，将应用程序与数据进行关联。

如果基线应用数据模型容易获取，则可以用来验证业务架构，并识别哪些数据是本地存储的，哪些是远程访问的。数据架构阶段将重点关注这些问题，因此，如果认为对架构工作的范围有价值，此时可能适合进入数据架构的短期迭代。

通过利用基线应用目录中的现有信息，应用架构应识别用户和组织对应用程序的依赖。此活动将支持未来状态规划，通过确定受影响的用户群体，并促进根据用户类型或用户位置对应用程序进行分组。

需要特别考虑的一个关键用户群体是运营支持组织。此活动应检查应用程序对共享运营能力的依赖，并生成一个图表，展示每个应用程序是如何有效地进行操作和管理的。

特别考虑运营社区的需求，可能会识别出对新的或扩展的治理能力和应用程序的需求。

TOGAF标准 — 架构内容中包含了关于矩阵的详细描述，这些矩阵应在应用架构中考虑开发，并将其详细描述并与TOGAF企业元模型中的实体、属性和关系相关联。

7.3.1.4  确定所需图表

图表根据利益相关者的需求，从不同视角（观点）展示应用架构信息。一旦明确了应用所需的功能，就必须对如何最佳地构建应用以满足这些需求进行内部评估。

在打包应用的情况下，应用很可能支持多种配置选项、附加模块或应用服务，这些都可以应用于解决方案中。对于定制开发的应用，需要确定应用的高级结构，即模块或子系统的结构，以此作为组织设计活动的基础。

《TOGAF标准——架构内容》中详细描述了应用架构开发时应考虑的图表，对这些图表进行了详细描述，并将其与TOGAF企业元模型中的实体、属性和关系相关联。

7.3.1.5 确定需收集的需求类型

一旦应用程序架构的目录、矩阵和图表制定完成，便可通过规范以应用为中心的需求来实施目标架构，从而完成架构建模。

这些需求可能：
■ 与应用领域相关
■ 为数据和技术架构提供需求输入
■ 提供详细指导，这些指导将在设计和实施过程中得到体现，以确保解决方案满足原始架构需求

在这一步骤中，架构师应确定架构应满足的需求（参见第13.5.2节）。

7.3.2 开发基线应用架构描述

开发现有应用架构的基线描述，其详细程度需足以支持目标应用架构。要定义的范围和详细程度将取决于现有应用可能多大程度上被纳入目标应用架构，以及是否存在如第7.5节所述的架构描述。在可能的情况下，参考架构仓库（见TOGAF标准——架构内容）来确定相关的应用架构构建块。如果架构仓库中尚未存在这些构建块，则根据应用组合目录（见TOGAF标准——架构内容）为每个应用进行定义。

当需要开发新的架构模型来满足利益相关者的关切时，可使用第1步中确定的模型作为创建新架构内容的指南，以描述基线架构。

7.3.3  开发目标应用架构描述

开发目标应用架构的描述，其详细程度需足以支持架构愿景、目标业务架构和目标数据架构。要定义的范围和详细程度将取决于应用元素对于实现目标架构愿景的相关性，以及是否存在架构描述。在可能的情况下，结合架构库（参见TOGAF标准——架构内容）来确定相关的应用架构构建块。

当需要开发新的架构模型以满足利益相关者的关切时，应使用第一步中确定的模型作为创建新架构内容的指南，以描述目标架构。

如果合适，应研究不同的目标架构备选方案，并使用架构备选方案和权衡技术（参见TOGAF标准——ADM技术）与利益相关者讨论这些方案。

7.3.4  执行差距分析

验证架构模型的内部一致性和准确性：
        ■ 执行权衡分析以解决（如果存在）不同视图之间的冲突
        ■ 验证模型是否支持原则、目标和约束条件
        ■ 记录从架构库中选定的模型所代表的观点的变化，并进行文档记录
        ■ 针对需求测试架构模型的完整性
使用TOGAF标准中描述的差距分析技术（ADM技术），识别基线与目标之间的差距。

7.3.5  定义候选路线图组件

在创建基线架构、目标架构和执行差距分析之后，需要制定一个应用路线图来优先安排未来各阶段的活动。

这个初步的应用架构路线图将作为原始材料，用于在机会与解决方案阶段内支持更详细地定义一个综合的、跨学科的路线图。

7.3.6 解决架构全景中的影响

一旦应用架构最终确定，就有必要了解任何更广泛的影响或含义。

在这一阶段，应该检查架构全景中的其他架构制品，以确定：
        ■ 这个应用架构是否对任何已有的架构产生了影响？
        ■ 最近是否有变更影响了应用架构？
        ■ 在组织的其他领域是否有机会利用这个应用架构的工作？
        ■ 这个应用架构是否影响了其他项目（包括计划中的项目和正在进行中的项目）？
        ■ 这个应用架构是否会受到其他项目（包括计划中的项目和正在进行中的项目）的影响？

7.3.7 进行正式的利益相关者评审

对照拟议的应用架构，检查架构项目的初衷和架构工作说明书。进行影响分析，以确定业务和数据架构（例如，业务实践）可能需要做出哪些改变以适应应用架构的变化（例如，表单或程序、应用程序或数据库系统的变化）。如果影响显著，可能需要重新审视业务和数据架构。

识别即将设计的技术架构（尤其是基础设施）上的任何约束条件。

7.3.8 确定应用架构

■ 为每个构建块选择标准，尽可能重用从架构库中选择的参考模型中的内容
■ 对每个构建块进行充分记录
■ 对整体架构与业务需求进行最终交叉核对；在架构文档中记录构建块决策的理由
■ 记录最终的需求可追溯性报告
■ 记录架构在架构库中的最终映射；从所选的构建块中，识别出可能重用的部分，并通过架构库进行发布
■ 完成所有工作产品，如差距分析

7.3.9 创建/更新架构定义文档

■ 在架构定义文档中记录构建块决策的理由
■ 准备架构定义文档中的应用架构部分；如果合适，使用建模工具生成的报告和/或图形来展示架构的关键视图；将文档提交给相关利益相关者进行审阅，并整合反馈意见

7.4 输出

C阶段（应用架构）的输出可能包括但不限于以下内容：

        ■ 在适用情况下，对架构愿景阶段交付成果的精炼和更新版本：
                — 架构工作说明书（参见TOGAF标准——架构内容），如有必要则进行更新
                — 经过验证的应用原则，或新生成的应用原则（如在此阶段产生）

        ■ 架构定义文档草案（参见TOGAF标准——架构内容），包括：
                —已批准的基线应用架构，
                —已批准的目标应用架构
                —与所选视角相对应的观点，解决关键利益相关者的关注点

        ■ 架构需求规范草案（参见TOGAF标准——架构内容），包括如下应用架构需求：
                —差距分析结果
                —应用互操作性要求
                —将适用于本轮架构开发周期演进的相关技术要求
                —即将设计的技术架构上的约束条件
                —（如适用）更新后的业务需求
                —（如适用）更新后的数据需求

        ■ 架构路线图中的应用架构组件（参见TOGAF标准——架构内容）

TOGAF标准——架构内容中详细描述了可能在本阶段产生的架构工件。

7.5 方法

7.5.1 架构仓库

作为这一阶段的一部分，架构团队需要考虑在架构库（参见TOGAF标准——架构内容）中有哪些与应用架构相关的资源可供使用。

特别是：

■ 与组织所在行业相关的通用业务模型及相关应用模型
■ 与常见高级业务功能相关的应用模型，如电子商务、供应链管理等。

The Open Group有一个综合信息基础设施参考模型（III-RM）（参见TOGAF®系列指南：TOGAF综合信息基础设施参考模型（III-RM）），该模型专注于提供综合信息基础设施所需的应用级组件和服务。

第八章：D阶段：技术架构

本章描述了架构项目的技术架构的开发。

图 8-1 D阶段：技术架构

8.1 目标

D阶段的目标有：

        ■ 开发目标技术架构，该架构能够通过技术组件和技术服务来实现架构愿景，交付目标业                    务、数据和应用构建块，同时解决架构工作说明书和利益相关者的关注点
        ■ 根据基线技术架构与目标技术架构之间的差距，确定候选架构路线图组件

8.2 输入

本节定义了D阶段的输入。

8.2.1 企业外部参考资料

■ 架构参考资料（参见TOGAF标准——架构内容）
■ 候选产品信息

8.2.2 非架构输入

        ■ 架构工作请求（参见TOGAF标准——架构内容）
        ■ 能力评估（参见TOGAF标准——架构内容）
        ■ 沟通计划（参见TOGAF标准——架构内容）

8.2.3 架构输入

        ■ 企业架构组织模型（参见TOGAF标准——架构内容），包括：
                — 受影响组织的范围
                — 成熟度评估、差距及解决方案方法
                — 架构团队的角色与职责
                — 架构工作的限制条件
                — 预算要求
                — 治理和支持策略

        ■ 定制架构框架（参见TOGAF标准——架构内容），包括：
                — 定制架构方法
                — 定制架构内容（交付物和制品）
                — 配置和部署的工具

        ■ 技术原则（如存在，参见TOGAF标准——ADM技术）

        ■ 架构工作说明书（参见TOGAF标准——架构内容）

        ■ 架构愿景（参见TOGAF标准——架构内容）

        ■ 架构仓库（参见TOGAF标准——架构内容），包括：
                — 可重用的构建块
                — 公开发布的参考模型
                — 组织特定的参考模型
                — 组织标准

        ■ 架构定义文档草案，可能包括任何架构域的基线架构和/或目标架构

        ■ 架构需求规范草案（参见TOGAF标准——架构内容），包括：
                — 差距分析结果（来自业务、数据和应用架构）
                — 前一阶段的相关技术要求

        ■ 架构路线图中的业务、数据和应用架构组件（参见TOGAF标准——架构内容）

8.3 步骤

D阶段所处理的详细程度将取决于总体架构工作的范围和目标。
作为这项工作的一部分而引入的新技术构建块需要在D阶段进行详细定义。在目标环境中需要支持的现有技术构建块可能需要在D阶段进行重新定义，以确保它们能在这一特定的技术架构内实现互操作性和适用性。
D阶段中步骤的顺序以及它们正式开始和完成的时间，应根据既定的架构治理机制，适应当前情况而进行调整。特别是，要根据TOGAF标准——《应用ADM（Architecture Development Method，架构开发方法）》中的描述，确定在当前情况下是先进行基线描述还是目标架构开发更为合适。
在这些步骤中启动的所有活动都应在“完成技术架构”步骤（见第8.3.8节）中结束。这些步骤生成的文档必须在“创建/更新架构定义文档”步骤（见第8.3.9节）中正式发布。

D阶段的步骤如下：

■ 选择参考模型、视角和工具（见第8.3.1节）
■ 开发基线技术架构描述（见第8.3.2节）
■ 开发目标技术架构描述（见第8.3.3节）
■ 执行差距分析（见第8.3.4节）
■ 定义候选路线图组件（见第8.3.5节）
■ 解决架构全景中的影响（见第8.3.6节）
■ 进行正式的利益相关者评审（见第8.3.7节）
■ 完成技术架构（见第8.3.8节）
■ 创建/更新架构定义文档（见第8.3.9节）

8.3.1 选择参考模型、视角和工具

审查和验证技术原则集合。这些原则通常会是总体架构原则集合的一部分。关于如何制定和应用原则，以及技术原则的一个示例集合，请参阅TOGAF标准中的《ADM技术》。

根据业务驱动力、利益相关者及其关注点，从架构知识库中（见TOGAF标准中的《架构内容》）选择相关的技术架构资源（如参考模型、模式等）。

选择相关的技术架构视角，以便架构师能够展示技术架构是如何解决利益相关者所关注的问题的。

结合所选视角，确定用于捕获、建模和分析的适当工具和技术。根据所需复杂程度的不同，这些工具和技术可能包括简单的文档和电子表格，或者更复杂的建模工具和技术。

8.3.1.1 确定整体建模流程

针对每个视角，使用所选的工具或方法，选择支持所需特定视角所需的模型。确保涵盖所有利益相关者的关注点。如果未涵盖，则创建新的模型来解决这些问题，或对现有模型进行扩展（见上文）。

技术架构的开发流程包括以下步骤：

        ■ 定义技术服务分类和逻辑技术组件（包括标准）
        ■ 确定技术部署的相关位置
        ■ 对已部署的技术进行实物盘点，并抽象化以适应分类体系
        ■ 审视技术对应用和业务需求的影响
        ■ 现有技术是否适合满足新的要求（即，它是否满足功能性和非功能性要求）？                                       — 完善分类体系
                 — 产品选择（包括依赖产品）
        ■ 确定所选技术的配置
        ■ 确定影响：
                  — 规模与成本
                  — 容量规划
                  — 安装/治理/迁移影响

在ADM（应用开发与管理）的早期阶段，关于服务粒度和服务边界的某些决策将对技术组件和技术服务产生影响。技术架构可能受到影响的领域将包括以下几点：

■ 性能：服务的粒度将影响技术服务要求
粗粒度服务包含多个功能单元，可能具有不同的非功能性要求，因此应考虑平台性能。此外，粗粒度服务有时可能包含请求系统实际所需之外的信息。

■ 可维护性：如果服务粒度太粗，那么对该服务进行更改将变得困难，并影响服务的维护以及承载该服务的平台

■ 位置和延迟：服务可能通过远程链路相互交互，服务间通信将具有内置延迟
绘制服务边界和设置服务粒度时，应考虑这些服务间通信对平台/位置的影响。

■ 可用性：服务调用可能会受到网络或/和服务故障的影响

在服务分解和定义服务粒度时，高通信可用性是一个重要考虑因素。

产品选择过程可能发生在技术架构阶段，此时可能涉及现有产品的重用、增加增量容量，或在项目启动期间产品选择决策成为约束条件。

如果产品选择偏离现有标准、涉及大量工作或有广泛影响，则应将此活动标记为机会，并通过“机会与解决方案”阶段进行处理。

8.3.1.2 确定所需的技术构建块目录

目录是业务核心资产的清单。目录具有层次性，能够捕捉元模型实体的分解以及相关模型实体之间的分解（例如，技术服务→逻辑技术组件→物理技术组件）。

目录是开发矩阵和图表的基础材料，也是管理和信息技术能力的重要资源。

技术架构应创建如下技术目录：

■ 基于现有的技术目录以及在应用架构阶段进行的应用分析，收集正在使用的产品列表

■ 如果在应用架构中确定的需求无法通过现有产品满足，则通过审查市场上提供所需功能且符合标准的产品来扩展产品列表

■ 如果适用，根据所选的分类法对产品进行分类，并根据需要扩展模型以适应正在使用的技术产品的分类

■ 如果当前已有技术标准，则将其应用于技术组件目录，以获得技术标准合规性的基线视图

《TOGAF标准——架构内容》中详细描述了应在技术架构开发中考虑的技术目录，详细描述了这些目录，并将其与TOGAF企业元模型中的实体、属性和关系相关联。

8.3.1.3 识别所需矩阵

矩阵展示了相关模型实体之间的核心关系。

矩阵是开发图表的基础材料，同时也是进行影响评估的关键资源。

《TOGAF标准——架构内容》中详细描述了应在技术架构开发中考虑的矩阵，详细阐述了这些矩阵，并将它们与TOGAF企业元模型中的实体、属性和关系相关联。

8.3.1.4  确定所需图表

图表根据利益相关者的要求，从一系列不同的视角（观点）呈现技术架构信息。

此活动为平台需求和托管需求之间建立了联系，因为单个应用程序可能需要物理上位于多个环境中，以支持本地访问、开发生命周期和托管需求。

对于主要基线应用程序或应用程序平台（即在相同的基础设施栈上托管多个应用程序的情况），应制作一个堆栈图表，展示硬件、操作系统、软件基础设施和打包应用程序是如何组合的。

如果合适，扩展软件分发的应用程序架构图表，以显示应用程序如何映射到技术平台上。

针对每个环境，制作一张展示环境内容和组件间逻辑通信的硬件与软件基础设施逻辑图。在可能的情况下，收集已部署基础设施的容量信息。

针对每个环境，制作一张通信基础设施的物理图，包括路由器、交换机、防火墙和网络链路等。在可能的情况下，收集通信基础设施的容量信息。

《TOGAF标准——架构内容》中详细描述了应在技术架构开发中考虑的图表，详细阐述了这些图表，并将它们与TOGAF企业元模型中的实体、属性和关系相关联。 

8.3.1.5 确定需收集的需求类型

一旦技术架构目录、矩阵和图表得以开发，就可通过规范化针对实施目标架构的技术需求来完成架构建模。

这些需求可能：
■ 与技术领域相关
■ 为设计和实施过程提供详细指导，以确保解决方案满足原始架构需求

在这一步骤中，架构师应确定架构应满足的需求（参见第13.5.2节）。

8.3.1.6 选择服务

服务组合是从已定义分类的服务类别中选取的不相互冲突的基本服务的集合。这些服务的组合会再次经过测试，以确保能够支持应用程序。这是后续步骤中全面定义架构的先决条件。

之前确定的需求可以提供更详细的信息，关于：
■ 组织特定元素或已有决策（如适用）的需求
■ 已有且不变的组织元素（如适用）
■ 继承的外部环境约束

如果需求要求定义在TOGAF标准中未识别的专业服务，那么应考虑如果未来有标准化服务可用，这些专业服务应如何替换。

对于每个构建块，构建一个服务描述组合，作为一组不相互冲突的服务。这组服务必须经过测试，以确保所提供的功能满足应用程序的需求。

8.3.2 开发基线技术架构描述

开发现有技术架构的基线描述，以支持目标技术架构。要定义的范围和详细程度将取决于现有技术组件在多大程度上可能被纳入目标技术架构，以及是否存在如第8.5节所述的架构描述。

利用架构仓库中持有的任何构件，确定相关的技术架构构建块。如果架构仓库中没有任何内容，则根据技术组合目录（参见《TOGAF标准——架构内容》）定义每个应用程序。

首先，将现有环境的描述转换为组织技术服务和技术组件分类法（例如，《TOGAF技术参考模型》（TRM））的术语。这将使开发架构的团队能够获得对分类法的经验和理解。团队可能会利用以前的架构定义，但假设需要进行一些调整，以匹配本过程中描述作为一部分的架构定义技术。另一项重要任务是制定一系列关键问题清单，这些问题可在后续的开发过程中用于衡量新架构的有效性。

如果需要开发新的架构模型来满足利益相关者的关注点，请使用第1步中确定的模型作为指导，创建新的架构内容来描述基线架构。

8.3.3 开发目标技术架构描述

制定技术架构的目标描述，其详细程度需足以支持架构愿景、目标业务架构和目标信息系统架构。要定义的范围和详细程度将取决于技术元素对于实现目标架构的相关性，以及是否存在架构描述。尽可能利用架构仓库（参见《TOGAF标准——架构内容》）来确定相关的技术架构构建块。

在创建目标系统的广泛架构模型时，一个关键过程是构建块的概念化。应用构建块（Application Building Blocks，ABBs）描述了功能以及如何在不引入配置或详细设计的细节的情况下实现这些功能。《TOGAF标准——架构内容》中描述了定义构建块的方法，以及在使用它们创建架构模型时的一些一般指导原则。

如果需要开发新的架构模型来满足利益相关者的关注点，请使用第1步中确定的模型作为指导，创建新的架构内容来描述目标架构。

如果合适，研究不同的目标架构备选方案，并使用架构备选方案和权衡技术（参见《TOGAF标准——ADM技术》）与利益相关者讨论这些方案。

8.3.4 进行差距分析

验证架构模型的内部一致性和准确性：
■ 进行权衡分析以解决不同视图之间的冲突（如有）
■ 验证模型是否支持原则、目标和约束条件
■ 记录从架构仓库中选定的模型所代表的观点的变化，并编写文档
■ 测试架构模型是否完全符合需求

使用TOGAF标准中描述的差距分析技术（ADM技术），识别基线与目标之间的差距。

8.3.5 定义候选路线图组件

在创建了基线架构、目标架构并进行差距分析之后，需要制定一份技术路线图来优先安排接下来各阶段的活动。

这份初步的技术架构路线图将作为原始材料，用于在“机会与解决方案”阶段支持更详细地定义一个综合的、跨学科的路线图。

8.3.6 解决架构全景中的影响

一旦技术架构最终确定，就有必要了解任何更广泛的影响或含义。

在此阶段，应检查架构全景中的其他架构工件，以确定：
■ 这项技术架构是否对任何既存架构产生影响？
■ 是否有最近的变更影响了这项技术架构？
■ 在组织的其他领域是否存在利用这项技术架构工作成果的机会？
■ 这项技术架构是否影响了其他项目（包括计划中的项目和正在进行中的项目）？
■ 这项技术架构是否会受到其他项目（包括计划中的项目和正在进行中的项目）的影响

8.3.7  进行正式的利益相关者评审

核对架构项目的初衷、架构工作声明与拟议的技术架构，判断其是否适合支持其他架构领域中的后续工作。仅在必要时对拟议的技术架构进行完善。

8.3.8 最终确定技术架构

■ 为每个构建块选择标准，尽可能重用从架构仓库中选定的参考模型
■ 为每个构建块提供完整的文档
■ 对整体架构与业务目标进行最终交叉检查；在架构文档中记录构建块决策的理由
■ 记录最终的需求可追溯性报告
■ 在架构仓库中记录架构的最终映射；从选定的构建块中，识别出那些可能被重用的内容（工作方法、角色、业务关系、职位描述等），并通过架构仓库进行发布
■ 完成所有工作产品，如差距分析

8.3.9 创建/更新架构定义文档

在架构定义文档中记录构建块决策的理由。准备架构定义文档的技术部分，包括以下部分或全部内容：

■ 基本功能和属性——语义清晰、无歧义，包括安全能力和管理能力
■ 具有所需功能和命名接口的依赖构建块
■ 接口——选定的一组接口，提供的（应用程序编程接口、数据格式、协议、硬件接口、标准）
■ 与业务/组织实体和政策的映射

如果适当，可以使用建模工具生成的报告和/或图形来展示架构的关键视图。将文档提交给相关利益相关者进行审查，并整合反馈意见。

8.4 输出

D阶段的输出可能包括但不限于以下内容：
        ■ 架构愿景阶段可交付成果的精炼和更新版本（如适用）：
                — 架构工作说明书（参见TOGAF标准——架构内容），如有必要进行更新
                — 验证过的技术原则，或新生成的技术原则（如在此阶段生成）

        ■ 架构定义文档草案（参见TOGAF标准——架构内容），包括：
                — 基线技术架构（如适用，已批准）— 目标技术架构（已批准），其中包括：
                        — 技术组件及其与信息系统的关系
                        — 技术平台及其分解，展示实现特定技术“堆栈”所需的技术组合
                        — 环境和位置—将所需技术分组到计算环境（如开发、生产）中
                        — 预期的处理负载以及负载在技术组件间的分布
                        — 物理（网络）通信—硬件和网络规格
                — 与选定观点相对应的视图，解决关键利益相关者的关注点

        ■ 架构需求规范草案（参见TOGAF标准——架构内容），包括技术架构要求，如：
                — 差距分析结果
                — B阶段和C阶段的需求输出—更新后的技术要求

        ■ 架构路线图中的技术架构组件（参见TOGAF标准——架构内容）

TOGAF标准——架构内容中详细描述了可能在此阶段产生的架构工件。

8.5 方法

8.5.1 新兴技术

新技术的演进是推动寻求新型创新运营方式和改进业务的企业变革的主要驱动力。技术架构需要把握企业采用新技术所能获得的转型机遇。

虽然企业架构以业务关注点为导向，但变革的驱动力往往源自技术能力的不断发展。随着更多数字创新产品进入市场，利益相关者需要既预见又接纳技术驱动的变革。数字转型的部分原因在于电信和计算机能力的融合，这为实施基础设施开辟了新的途径。

解决方案开发方法也在不断演进，以挑战传统的开发方法，并对传统企业架构方法中共享服务和共同使用效益造成压力。如果没有强大的企业架构方法，快速采用不断变化的技术将导致企业内部的不连续性。

TOGAF架构开发方法（ADM）的灵活性使技术变革成为变革的驱动力和战略资源，而不是变革请求的接受者。因此，技术架构可以同时驱动业务能力和响应信息系统需求。

8.5.2 架构库

作为 D 阶段的一部分，架构团队需要考虑架构仓库中有哪些相关的技术架构资源可用（请参阅 TOGAF 标准 - 架构内容）。尤其要关注以下内容：

• IT 仓库或 IT 服务目录中记录的现有 IT 服务；
• 适用的已采用的技术参考模型；
• 与组织所在行业部门相关的通用技术模型；
• 与通用系统架构相关的技术模型。

The Open Group有一个集成信息基础设施参考模型（III-RM），详见《TOGAF 系列指南：TOGAF 集成信息基础设施参考模型（III-RM）》，该模型侧重于提供集成信息基础设施所需的应用程序级组件和底层服务。

第 9 章：E 阶段：机遇与解决方案

本章描述了识别有效交付前阶段确定的目标架构的交付工具（项目、程序或 投资组合）的过程。

图9-1 E阶段： 机遇与解决方案

9.1 目标

E阶段的目标是：

• 根据 B、C、D 阶段的差距分析和候选架构路线图组件，生成架构路线图的初始完整版本。
• 判断是否需要采用渐进式方法，如果需要，则确定能够持续带来业务价值的过渡架构。
• 定义整体的解决方案构建模块（SBBs），以便在架构构建模块（ABBs）的基础上确定最终的目标架构。

9.2 输入

       本节定义阶段E的输入

9.2.1 企业外部参考资料

• 架构参考资料（见《TOGAF 标准 —— 架构内容》）
• 产品信息

9.2.2  非架构输入

• 架构工作请求（见《TOGAF 标准 —— 架构内容》）
• 能力评估（见《TOGAF 标准 —— 架构内容》）
• 沟通计划（见《TOGAF 标准 —— 架构内容》）
• 规划方法论

9.2.3 架构输入

• 企业架构组织模型（见《TOGAF 标准 —— 架构内容》），包括：

         — 受影响的组织范围

         — 成熟度评估、差距及解决方法

         — 架构团队的角色和职责

         — 架构工作的限制条件

         — 预算需求

         — 治理和支持策略

• 以下方面的治理模型和框架：

        — 企业商业规划

        — 企业架构

        — 项目组合、项目集、项目管理

        — 系统开发 / 工程

        — 运营（服务）

• 定制的架构框架（见《TOGAF 标准 —— 架构内容》），包括：

        — 定制的架构方法

        — 定制的架构内容（可交付成果和工件）

        — 配置并部署的工具

• 架构工作说明（见《TOGAF标准——架构内容》）
• 架构愿景（见《TOGAF 标准 —— 架构内容》）
• 架构库（见《TOGAF 标准 —— 架构内容》），包括：

        — 可重复使用的构建模块

        — 公开可用的参考模型

        — 特定于组织的参考模型

        — 组织标准

• 架构定义文档草案，其中可能包含任何架构领域的基线架构和/或目标架构
• 架构需求规范草案（见《TOGAF标准——架构内容》），包括：

        — 架构要求

        — 差距分析结果（来自业务架构、数据架构、应用架构和技术架构）

        — 信息技术服务管理要求

• 针对现有业务项目和计划的变更请求（见《TOGAF标准——架构内容》）
• 来自B、C和D阶段的候选架构路线图组件

9.3 步骤

        E阶段所涉及的详细程度将取决于整个架构工作的范围和目标。

        E阶段中各步骤的顺序，以及这些步骤正式启动和完成的时间，都应根据既定的架构治理原则，因地制宜地进行调整以适应手头的实际情况。

        在这些步骤中已启动的所有活动，都必须在“制定架构路线图及实施与迁移计划”步骤中（见9.3.11节）完成收尾工作。

E阶段的步骤如下：

￭确定/确认关键的企业变革属性（见9.3.1节）

￭确定实施过程中的业务限制因素（见9.3.2节）

￭审查并整合从B阶段到D阶段的差距分析结果（见9.3.3节）

￭审查相关业务职能部门的综合需求（见9.3.4节）

￭整合并协调互操作性要求（见9.3.5节）

￭细化并验证各项依赖关系（见9.3.6节）

￭确认业务转型的就绪程度和风险（见9.3.7节）

￭制定实施与迁移策略（见9.3.8节）

￭识别主要工作包并对其进行分组（见9.3.9节）

￭确定过渡架构（见9.3.10节）

￭制定架构路线图以及实施与迁移计划（见9.3.11节）

9.3.1 确定 / 确认关键的企业变革属性

此步骤旨在确定如何以最佳方式实施企业架构，从而充分利用组织的商业文化优势。这应包括创建一个“实施因素目录”（请参阅《TOGAF标准——架构开发方法（ADM）技术》），将其作为架构实施和迁移决策的仓库。该步骤还包括对所涉及的组织单位的过渡能力（包括文化和能力方面）进行评估，以及对企业整体（包括文化和技能组合）进行评估。

评估得出的结果因素应记录在实施因素目录中。对于那些企业架构已完善建立的组织来说，这一步可能很简单，但仍必须建立相应的矩阵，以便它能用作所做决策的档案和记录。

9.3.2 确定实施的业务约束

确定任何可能会限制实施顺序的业务驱动因素。这应当包括对公司层面和业务部门层面的业务及战略规划进行审查，以及对企业架构成熟度评估进行审查。

9.3.3 审查和巩固 B 至 D 阶段的差距分析结果

        整合并综合来自业务架构、信息系统架构和技术架构（在B到D阶段创建的）的差距分析结果，并就潜在的解决方案以及相互依赖关系评估这些结果所产生的影响。这应通过创建一个“综合差距、解决方案及依赖关系矩阵”来完成，如《TOGAF标准——架构开发方法（ADM）技术》中所示。该矩阵将有助于识别那些有可能解决一个或多个差距的标准构建模块（SBB）以及与之相关联的架构构建模块（ABB）。

        标准构建模块（SBBs）是基于B、C和D阶段的候选路线图组件创建的。

        如果合适的话，研究不同的目标架构备选方案，并运用“架构备选方案与权衡”技术（详见《TOGAF标准——架构开发方法（ADM）技术》）与利益相关者讨论这些方案。

        审查B、C和D阶段的差距分析结果，并将它们整合到一个单独的列表中。这些差距应连同针对差距的潜在解决方案以及依赖关系一并进行整合。一种推荐的确定依赖关系的技术是使用一系列视图，例如业务交互矩阵、数据实体/业务功能矩阵以及应用程序/功能矩阵，以便全面关联来自不同架构领域的元素。

        对综合差距、解决方案及依赖关系矩阵进行合理优化。一旦所有差距都已记录在案，重新整理差距列表，并将类似的项目归在一起。在对差距进行分组时，参考实施因素目录并审查其中的实施因素。任何额外的因素都应添加到实施因素目录中。

9.3.4 审查相关业务职能的综合需求

        评估各项需求、差距、解决方案和因素，以确定出一组最少的需求，将这些需求整合到工作包中，能够使参与架构的各个业务职能部门更高效且有效地实施目标架构。这种从职能角度出发的方式，可通过提供共享的解决方案和服务来满足多项需求。就架构组件而言，整合这些需求对于资源的提供可能会产生重大影响。例如，多个业务部门提出的若干需求，可以通过在一个工作包或项目中提供一组共享的业务服务和应用服务来得到解决。

9.3.5 整合并协调互操作性要求

整合在之前阶段确定的互操作性要求。应整合并审查架构愿景、目标架构，以及实施因素目录和综合差距、解决方案及依赖关系矩阵，以识别潜在解决方案集合对互操作性所提出的任何限制条件。

一个关键成果是将互操作性冲突降至最低，或者确保在架构中能够解决此类冲突。可重复使用的标准构建模块（SBB）、商用现货（COTS）产品以及第三方服务提供商通常会提出相互冲突的互操作性要求。任何此类冲突都必须在架构中得到解决，并且必须从所有架构领域（业务、数据、应用、技术）来考虑这些冲突。
对于互操作性冲突，有两种基本的处理方法：要么创建一个构建模块，用于在相互冲突的构建模块之间进行转换或转译；要么对相互冲突的构建模块的规格进行修改。

9.3.6  细化并验证依赖关系

        细化初始的依赖关系，确保识别出对实施与迁移计划的任何限制条件。有几个关键的依赖关系需要考虑，例如对现有业务服务和应用服务的实现方式的依赖，或者对这些服务进行变更所产生的依赖。依赖关系应用于确定实施顺序，并明确所需的协调工作。对依赖关系进行研究时，应将各项活动进行分组，为将要建立的项目奠定基础。审查相关项目，查看是否能确定可交付成果的合理增量。这些依赖关系还有助于确定已确定的增量在何时能够交付。完成后，应对这些依赖关系进行评估并记录下来，作为架构路线图以及任何必要的过渡架构的一部分。

9.3.7  确认业务转型的准备情况和风险

        回顾之前在A阶段进行的业务转型准备情况评估的结果，并确定这些结果对架构路线图以及实施与迁移策略的影响。识别、分类并降低与转型工作相关的风险至关重要。风险应记录在综合差距、解决方案及依赖关系矩阵中。  

9.3.8 制定实施与迁移策略

制定一个全面的实施与迁移策略，用以指导目标架构的实施，并构建任何过渡架构。首要任务是确定一种用于实施解决方案和/或利用相关机会的总体战略方针。主要有以下三种基本方法：

        ￭ 全新建设（绿地开发）：一种全新的实施方式

        ￭ 革命性变革：一种彻底的改变（即，直接启用新的，停用旧的）

        ￭ 渐进式：一种渐进融合的策略，比如并行运行，或者采用分阶段的方式来引入新的功能。

接下来，确定一个整体战略方向的方法，该方法要能够应对并降低在综合差距、解决方案及依赖关系矩阵中所识别出的风险。最常见的实施方法如下：

        ￭ 速赢（快速见效的举措/短期成果）

        ￭ 可实现的目标

        ￭ 价值链方法

这些方法以及已确定的依赖关系应成为创建工作包的基础。这项工作以就企业的实施与迁移策略达成一致意见而告终。

9.3.9 识别并归类主要工作包

关键利益相关者、规划人员以及企业架构师应该评估在架构愿景和目标架构中所识别出的缺失的业务能力。

结合使用综合差距、解决方案及依赖关系矩阵与实施因素目录，从逻辑上将各类活动归为不同的工作包。

在“综合差距、解决方案及依赖关系矩阵”的“解决方案”一栏中填写内容，以推荐所提议的解决方案机制。针对每一项差距/活动，指明该解决方案应面向全新开发，还是基于现有产品，以及/或者采用可购买的解决方案。现有系统或许只需进行一些小的改进就能满足需求。对于全新开发项目而言，此时正是确定该工作应在内部开展还是通过签订合同外包的好时机。

将正在考虑中的每一个现有系统分类为：

￭ 主流系统：属于未来信息系统的一部分

￭ 限制使用类：预计在规划期内（未来三年）将被替换或修改

￭ 替换类：在规划期内将被替换

然后，支持性的顶级工作包应依次分解为多个增量，以实现能力的逐步提升。从业务转型问题和战略实施方法的角度对这些工作包或增量进行分析和优化。最后，考虑到各工作包之间的依赖关系以及战略实施方法，将这些工作包归为不同的项目组合，并确定各项目组合内的具体项目。

9.3.10 确定过渡架构

        当实施目标架构所需的变更范围要求采用渐进式方法时，可能就需要一个或多个过渡架构。这些过渡架构能够在实现目标架构的路线图上确定清晰的目标。过渡架构应能带来可衡量的业务价值。连续的过渡架构之间的时间跨度不必保持一致。

       过渡架构的开发必须基于首选的实施方法、综合差距、解决方案及依赖关系矩阵、项目和项目组合清单，以及企业创造和适应变革的能力。

        确定哪些活动难度较大，并且，除非有令人信服的理由，否则应在完成那些最容易实现缺失能力的其他活动之后，再开展这些难度较大的活动。

9.3.11 制定架构路线图以及实施与迁移计划

        将工作包和过渡架构整合到架构路线图草案中，该草案描述了从基线架构到目标架构的演进时间安排。这一时间安排为实施与迁移计划提供信息。架构路线图为F阶段的迁移规划奠定基础。已确定的过渡架构和工作包应具备一系列明确的成果。架构路线图必须展示出过渡架构和工作包的选择以及时间安排是如何实现目标架构的。

        架构路线图草案的细节详细程度，应与在B、C和D阶段所制定的架构定义文档的详细程度相当。若在实施之前还需要补充大量额外细节，那么该架构很可能会过渡到不同的层级。有关管理迭代和处理不同详细程度的技术，请参阅《TOGAF标准——应用架构开发方法（ADM）》。

        实施与迁移计划必须展示出为实现架构路线图所必需开展的活动。实施与迁移计划构成了F阶段迁移规划的基础。实施与迁移计划草案的细节必须与架构路线图的细节保持一致，并且要足以明确实现该路线图所需的项目以及资源需求。

        在制定实施与迁移计划时，有许多方法可供考虑，例如一种数据驱动的顺序，即先实施创建数据的应用系统，然后再实施处理数据的应用系统。要制定出有效的实施与迁移计划，就需要清晰地了解已部署的可复用业务构件（SBB）之间的依赖关系及其生命周期。

        最后，用本阶段产生的任何其他相关成果，对架构愿景、架构定义文档以及架构需求规范进行更新。
 

9.4 输出

E阶段的输出可能包括但不限于：

￭ 经完善和更新后的架构愿景阶段可交付成果版本（如适用），包括：

        — 架构愿景，包括互操作性的类型和程度的定义

        — 架构工作说明（参见《TOGAF标准——架构内容》），如有必要需进行更新

￭  架构定义文档草案（参见《TOGAF 标准 —— 架构内容》），包括：

        — 已获批的基线业务架构，必要时进行了更新

        — 已获批的目标业务架构，如有必要进行更新

        — 已获批的基线数据架构，必要时需进行更新

        — 已批准的目标数据架构，如有必要需进行更新

        — 已批准的基线应用架构，如有必要需进行更新

        — 已批准的目标应用架构，如有必要需进行更新

        — 已批准的基线技术架构，如有必要需进行更新

        — 已批准的目标技术架构，如有必要需进行更新

        — 过渡架构，根据需要确定其数量和范围

        — 与所选视角相对应的视图，这些视图需解决关键利益相关者所关注的问题

￭  架构需求规格说明书草案（请参阅《开放组架构框架（TOGAF）标准——架构内容》），包括：

        — 综合的差距、解决方案及依赖关系评估

￭  能力评估，包括：

        — 业务能力评估

        — 信息技术能力评估

￭ 架构路线图（见《开放组架构框架（TOGAF）标准——架构内容》），包括：

        — 工作包描述（名称、描述、目标）

                — 工作包描述（名称、说明、目标）

                — 功能需求

                — 依赖关系

                — 与机遇的关系

                — 与《架构定义文档》及《架构需求规格说明书》的关系

                — 与任何能力提升（增量）的关系

                — 商业价值

                — 实施因素目录

                — 影响

        — 确定过渡架构（如果存在的话），包括：

                — 与架构定义文档的关系
        — 实施建议：

                — 有效性的评判标准（衡量标准）

                — 风险与问题

                — 解决方案构建模块（SBBs）

￭ 实施与迁移计划（草案），包括：

        — 实施与迁移策略

《开放组架构框架（TOGAF）标准——架构内容》包含了对在此阶段可能产生的架构制品的详细描述，对这些制品进行了详尽说明，并将它们与 TOGAF 企业元模型中的实体、属性以及关系关联起来。

9.5 方法

阶段 E 专注于如何交付架构。它考虑到了所有架构领域中目标架构与基线架构之间的一整套差距，并从逻辑上将这些变更分组到企业投资组合内的工作包中。这是为了构建一个最适配的路线图，该路线图基于利益相关者的需求、企业的业务转型准备情况、已识别的机遇和解决方案，以及已确定的实施限制。关键在于在实现渐进式业务价值的同时，聚焦于最终目标。

阶段 E 是制定实施与迁移计划的初始步骤，该计划在阶段 F 完成。它为一份经过深思熟虑的实施与迁移计划奠定了基础，而这份计划会在阶段 F 中整合到企业的投资组合当中。

以下四个概念对于从开发目标架构到交付目标架构的过渡来说至关重要：

        ￭架构路线图

        ￭工作包

        ￭过渡架构

        ￭实施与迁移计划

架构路线图会在一个时间轴上列出各个工作包，这些工作包将实现目标架构。

每个工作包都确定了为实现目标架构所必需的一组逻辑上的变更。

过渡架构描述了处于基线架构和目标架构之间具有重要架构意义状态的企业情况。过渡架构提供了阶段性的目标架构，组织可以朝着这些阶段性目标架构逐步推进。

实施与迁移计划提供了一系列项目的时间表，这些项目将实现目标架构。

第10章： F阶段：迁移规划

本章阐述迁移规划，即如何通过敲定一份详细的实施与迁移计划，从基线架构过渡到目标架构。
 

图10-1 F阶段：迁移规划
 

10.1 目标

F阶段的目标有：

        ■ 敲定架构路线图以及配套的实施与迁移计划

        ■ 确保实施与迁移计划与企业在管理和实施企业整体变更组合中变更的方法相协调。

        ■ 确保关键利益相关者了解工作包和过渡架构所带来的商业价值以及所需成本。

10.2 输入

本节定义了阶段F的输入内容。

10.2.1 企业外部的参考资料

        ￭ 架构参考资料（参见《TOGAF标准——架构内容》）

10.2.2 非架构输入

        ￭ 架构工作请求（参见《TOGAF标准——架构内容》）

        ￭ 能力评估（参见《TOGAF标准——架构内容》）

        ￭ 沟通计划（见《TOGAF标准——架构内容》）
 

10.2.3 架构输入

        ￭ 企业架构组织模型（见《TOGAF标准——架构内容》），包括：

                — 受影响组织的范围

                — 成熟度评估、差距及解决方法

                — 架构团队的角色和职责

                — 架构工作的限制条件

                — 预算要求

                — 治理与支持策略

          ￭ 以下方面的治理模型和框架：

                — 企业业务规划

                 — 企业架构

                — 投资组合、项目集、项目管理

                — 系统开发/工程

                — 运营（服务）                

          ￭ 定制的架构框架（见《TOGAF标准——架构内容》），包括：

                — 定制的架构方法

                — 定制的架构内容（可交付成果和工件）

                — 配置并部署的工具

        ￭ 架构工作说明（见《TOGAF标准——架构内容》）

                — 可复用的构建模块

                — 公开可用的参考模型

                — 特定于组织的参考模型

                — 组织标准               

        ￭ 架构定义文档草案，其中可能包括任何架构领域的基线架构和/或目标架构，以及/或者过渡架构。  

        ￭ 架构需求规范草案（见《TOGAF标准——架构内容》），包括：

                — 架构需求

                — 差距分析结果（来自业务架构、数据架构、应用架构和技术架构）

                — 信息技术服务管理要求

         ￭ 针对现有业务项目集和项目的变更请求（见《TOGAF标准——架构内容》）
         ￭ 架构路线图草案（见《TOGAF标准——架构内容》），包括：

                — 工作包的识别

                — 过渡架构的识别

                — 实施因素目录        

        ￭ 能力评估（见《TOGAF标准——架构内容》），包括：

                — 业务能力评估

                — 信息技术能力评估

       ￭ 实施与迁移计划草案（见《TOGAF标准——架构内容》），包括高层级的实施与迁移策略。

10.3 步骤

        F阶段所涉及的细节程度将取决于整个架构工作的范围和目标。

        F阶段中各个步骤的顺序，以及这些步骤正式启动和完成的时间，都应根据既定的架构治理原则，针对实际情况进行调整。

        在这些步骤中已启动的所有活动，都必须在“完成架构开发周期并记录经验教训”步骤中收尾（见10.3.7节）。F阶段的步骤如下：

                ￭ 确认实施与迁移计划的管理框架交互情况（见10.3.1节）

                ￭ 为每个工作包赋予一个业务价值（见10.3.2节）

                ￭ 估算资源需求、项目时间安排以及可用情况/交付工具（见10.3.3节）

                ￭ 通过进行成本效益评估和风险验证，对迁移项目进行优先级排序（见10.3.4节）

                ￭ 确认架构路线图并更新架构定义文档（见10.3.5节）

                ￭完成实施与迁移计划（见10.3.6节）

                ￭完成架构开发周期并记录所汲取的经验教训（见10.3.7节）

10.3.1 确认实施与迁移计划的管理框架交互情况

        这一步骤旨在协调实施与迁移计划和组织内部的管理框架。通常有四个管理框架需要紧密协作，才能确保实施与迁移计划取得成功：

        ■ 业务规划负责构思、指导并为实现具体业务目标/成果所需的所有活动提供资源。

        ■ 企业架构对所有企业活动进行架构规划并提供背景，这些活动主要（但不限于）在信息技术领域实现具体的业务成果。

        ■ 项目/组合管理负责协调、设计和构建能够实现具体业务成果的业务系统。

        ■ 运营管理负责整合、运营和维护可交付成果，以实现具体的业务成果。

        实施与迁移计划会影响这些框架各自的输出结果，因此必须在其中得到体现。在这一步骤中，要深入了解组织内部的各个框架，确保这些计划相互协调，并以摘要形式融入到每个框架的计划当中。

        这一步骤的结果很可能是，实施与迁移计划会成为由企业架构参与的其他框架所制定的不同计划的一部分。

10.3.2 为每个工作包赋予业务价值

        为每个工作包确定并赋予业务价值。其目的是首先确定在组织内什么构成业务价值、如何衡量价值，然后将其应用于每个项目及项目增量。

        在这项活动中有几个问题需要解决：

        ■ 绩效评估标准被投资组合和能力经理用于批准和监控架构转型的进展情况。

        ■ 投资回报率标准必须详细制定，并需得到各执行利益相关者的签署认可

        ■ 必须对业务价值以及诸如价值链之类的技术进行定义，这些技术将用于说明在实现切实的业务成果中所起的作用。

        业务价值将被投资组合经理和能力经理用于分配资源，在出现预算削减的情况下，业务价值与投资回报率相结合，可用于确定一项工作是继续推进、延期还是取消。

        ■ 应确定关键成功因素（CSFs），以定义项目和 / 或项目增量的成功标准。

        这些将为管理者和实施者提供一个衡量标准，用以判断怎样才算是成功的实施。

        ■ 效能度量（MOE）通常属于绩效标准，许多公司将其纳入关键成功因素（CSF）之中。

        如果这些标准是分开处理的，那么就应该明确这些标准将如何进行归类。

        ■ 基于整体企业架构（所有层级）的战略适配性，将成为批准任何新项目或新举措，以及确定任何可交付成果价值的关键因素。

以工作包为基础，来确定将纳入实施与迁移计划的项目。所确定的项目将在阶段F的其他步骤中得到全面完善。这些项目以及项目增量可能需要对架构路线图和架构定义文档进行调整。

然后，应通过汇总在（来自E阶段的）“综合差距、解决方案及依赖关系矩阵” 中识别出的风险，将风险分配到各个项目及项目增量中。

使用业务价值评估技术（见《TOGAF标准—— 架构开发方法（ADM）技术》）来估算每个项目的业务价值。

10.3.3 估算资源需求、项目时间安排以及可用资源/交付途径

        这一步骤确定每个项目及其增量所需的资源和时间，并给出初步的成本估算。成本应细分为资本成本（用于创建能力）以及运营和维护成本（用于运行和维持该能力）。应当找出这样的机会，即通过淘汰现有系统来抵消与交付新的和/或更优能力相关的成本。为每项活动分配所需资源，并在项目增量和项目层面进行资源汇总。

10.3.4 通过开展成本/效益评估和风险验证，对迁移项目进行优先级排序

        通过对照项目交付成本来确定其业务价值，从而对项目进行优先级排序。具体方法是，首先尽可能清晰地确定这些项目所交付的所有可共享业务构件（SBB）的净收益，然后核实风险已得到有效缓解并已考虑在内。在此之后，目的是达成必要的共识，以创建一份项目优先级清单，该清单将为资源分配提供依据。

        发现所有成本并确保决策者了解随着时间推移所带来的净收益，这一点至关重要。    

        审查各项风险，以确保项目可交付成果所面临的风险已尽可能得到缓解。然后，用与风险相关的意见对项目清单进行更新。  

        让各利益相关方就项目的优先次序达成一致。确定优先次序的标准将采用在E阶段创建架构路线图草案时所确定的要素，以及与各个利益相关方议程相关的要素。需注意的是，即便某个项目本身的直接效益较小，但如果它在实现重大效益的过程中提供了关键的可交付成果，那么该项目仍有可能获得较高的优先级。

        正式审查风险评估，并在必要时对其进行修订，确保对与项目优先级排序以及预计资金状况相关的残余风险有全面、深入的理解。

10.3.5 确认架构路线图并更新架构定义文档

        更新架构路线图，包括任何过渡架构。回顾到目前为止所做的工作，以评估各过渡架构之间的时间跨度应该是多长，同时要考虑业务价值和能力的增量以及其他因素，比如风险。一旦能力增量确定下来，就按项目整合可交付成果。这将形成一份经过修订的架构路线图。

        为了协调各种架构的多个并行实例的开发，这一点是必要的。可以使用过渡架构状态演变表（见《TOGAF标准——架构开发方法（ADM）技术》）来展示领域架构在不同详细程度下的拟定状态。         

        如果由于确认了实施增量而导致实施方法发生了变化，那么就需要更新架构定义文档。这可能包括指定项目目标，以及使项目及其可交付成果与过渡架构保持一致，从而创建一个架构定义增量表（见《TOGAF标准——架构开发方法（ADM）技术》）。

10.3.6 完成实施与迁移计划

        生成完整的实施与迁移计划。该计划的大部分细节信息已经收集完成，而此步骤则是运用公认的规划和管理技术将这些信息整合在一起。这应包括将所有项目和活动，以及各项依赖关系和变更影响纳入到一个项目计划中。任何过渡架构都将充当项目组合的里程碑。    

        所有外部依赖关系都应被梳理并纳入其中，同时还需对资源的整体可用性进行评估。项目计划可以包含在实施与迁移计划之内。

10.3.7 完成架构开发周期并记录所吸取的经验教训

        此步骤将架构治理从架构开发阶段过渡到架构实现阶段。如果架构能力的成熟度达到要求，可能需要制定一个实施治理模型（请参阅《TOGAF标准——架构内容》）。

        在架构开发过程中所汲取的经验教训应记录下来，并由H阶段的相应治理流程收集，作为管理架构能力的输入内容。

        架构路线图以及实施与迁移计划的详细程度，应与在B、C和D阶段所制定的架构定义文档的详细程度相当。如果下一阶段需要大量额外的细节内容，那么该架构很可能会过渡到不同的层级。根据目标架构以及实施与迁移计划的层级，可能有必要在更细的层级上再迭代一次架构开发方法（ADM）周期。有关管理迭代和不同详细层级的技术，请参阅《TOGAF标准——应用架构开发方法》。

10.4 输出

        F阶段的输出可能包含但不限于：

        ■ 已批准的实施与迁移计划（见《TOGAF标准——架构内容》），包括：

                ——实施与迁移策略

                ——实施过程中的项目及项目组合分解情况：

                        ——工作包在项目和项目组合中的分配情况

                        ——各项目所实现的能力

                        ——与目标架构以及任何过渡架构之间的关系

                        ——里程碑及时间安排

                        ——工作分解结构

                ——项目章程（可选）：

                        ——项目章程（可选）：

                        ——商业价值

                        ——风险、问题、假设条件、依存关系

                        ——资源需求及成本

                        ——迁移所带来的益处

                        ——各种迁移方案的预估成本

        ■ 最终确定的架构定义文档（见《TOGAF标准——架构内容》），包括：

                ——最终确定的过渡架构（如果有的话）

        ■ 最终确定的架构需求规范（见《开放群组架构框架（TOGAF）标准——架构内容》）

        ■ 最终确定的架构路线图（见《TOGAF标准——架构内容》）

        ■ 可重复使用的架构构建块（见《TOGAF标准——架构内容》）  

        ■ 针对架构开发方法（ADM）循环新迭代（如果存在的话）的架构工作请求（见《TOGAF标准——架构内容》）

        ■ 实施治理模型（如果有的话）（见《开放群组架构框架（TOGAF）标准——架构内容》）

        ■ 因从经验教训中所获启示而提出的针对架构能力的变更请求

10.5 方法

F阶段的重点是与项目和项目组合经理合作制定一份实施与迁移计划。

E阶段会提供一份不完整的架构路线图以及实施与迁移计划，这些内容是针对架构工作说明书而制定的。在F阶段，这份路线图以及实施与迁移计划将与企业的其他变革活动相结合。

各项活动包括在企业的其他活动背景下，评估各种迁移项目的依存关系、成本和收益。来自E阶段的架构路线图草案以及实施与迁移计划草案，将构成最终实施与迁移计划的基础，该最终计划将涵盖项目组合和项目层面的详细信息。

然后，架构开发周期应完成，并且要记录所汲取的经验教训，以便实现持续的流程改进。

第11章：G阶段：实施治理

本章对实施过程提供了架构层面的监督指导方面的内容。

图11-1 G阶段：实施治理

11.1 目标

G阶段目标：

        ￭ 确保实施项目与目标架构保持一致。

        ￭ 针对解决方案以及任何由实施驱动的架构变更请求，执行适当的架构治理职能。

11.2 输入

        本节定义了G阶段的输入内容。

11.2.1 企业外部参考资料

        ￭ 架构参考资料（见《TOGAF标准——架构内容》）
 

11.2.2 非架构输入

        ￭ 架构工作请求（见《TOGAF标准——架构内容》）

        ￭ 能力评估（见《TOGAF标准——架构内容》）

11.2.3 架构输入

        ￭ 企业架构组织模型（见《TOGAF标准——架构内容》），包括：

                — 受影响的组织范围

                — 成熟度评估、差距分析及解决措施

                — 架构团队的角色和职责

                — 架构工作的限制条件

                — 预算要求

                — 治理与支持策略        

        ￭ 定制化架构框架（见《TOGAF标准——架构内容》），包括：

                — 定制架构方法

                — 定制的架构内容（可交付成果和工件）

                — 配置和部署的工具

        ￭ 架构工作说明（见《TOGAF标准——架构内容》）

        ￭ 架构愿景（见《TOGAF标准——架构内容》）

        ￭ 架构仓库（见《TOGAF标准——架构内容》），包括：

                — 可复用的构建模块

                — 公开可用的参考模型

                — 特定于组织的参考模型

                — 组织标准

        ￭ 架构定义文档（见《TOGAF标准——架构内容》）

        ￭ 架构需求规范（见《TOGAF标准——架构内容》），包括：

                — 架构需求

                — 差距分析结果（来自业务架构、数据架构、应用架构和技术架构）

        ￭ 架构路线图（见《TOGAF标准——架构内容》）

        ￭ 架构治理框架（见《TOGAF标准——企业架构能力与治理》）

        ￭ 实施治理模型（见《TOGAF标准——架构内容》）

        ￭ 架构合同（标准）（见《TOGAF标准——企业架构能力与治理》）

        ￭ 在E阶段和F阶段中识别出的架构工作请求（见《TOGAF标准——架构内容》） 

        ￭ 实施与迁移计划（见《TOGAF标准——架构内容》）

11.3 步骤

        G阶段所涉及的细节程度将取决于整体架构工作的范围和目标。

        G阶段各步骤的顺序以及正式开始和完成的时间，应依据既定的架构治理规则，根据实际情况进行调整。

        G阶段步骤如下：

        ■ 与开发管理部门确认部署的范围和优先级（见11.3.1节）

        ■ 识别部署所需的资源和技能（见11.3.2节）

        ■ 指导解决方案部署的开发（见11.3.3节）

        ■ 执行企业架构合规性审查（见11.3.4节）

        ■ 实施业务和IT运营（见11.3.5节）

        ■ 进行实施后审查并结束实施（见11.3.6节）。在这一步骤中，需要对实施的成果进行全面审查，评估其是否达到预期目标、是否符合相关标准和要求等。通过审查，总结经验教训，为后续的项目实施提供参考。结束实施意味着相关的部署项目正式完成，各项工作进入收尾阶段，包括项目的验收、资源的清理、文档的整理等工作 。

        

11.3.1 与开发管理部门确认部署的范围和优先级

        ■ 审查迁移规划的输出内容，并就部署工作提出建议。

        ■ 为开发团队确定企业架构的优先级。

        ■ 识别部署问题并提出建议。

        ■ 识别需要替换、更新等的构建模块。

        ■ 对企业架构和解决方案框架进行差距分析。

                需要识别现有企业解决方案框架中的差距，解决方案架构师将确定填补这些差距所需的           特定解决方案构建模块（SBB）。这些SBB与项目可能存在一对一或多对一的关系。解决方             案架构师需要确切定义如何完成这项工作。可能有其他项目也在致力于这些相同的能力建                设，解决方案架构师需要确保能够从这些投资中获得最大价值。

        ■ 编制差距分析报告

11.3.2 确定部署资源和技能

                项目资源将包括开发资源，这些开发资源需要了解企业架构的整体可交付成果，以及特          定开发和实施项目的预期要求。

        在这一步中应考虑以下几点：

        ■ 确定解决方案开发所需的系统开发方法

        注意：项目团队可以使用一系列的系统开发方法和工具。理想情况下，所采用的方法应能够与架构输出成果实现互操作；例如，根据迄今为止交付的架构工件生成代码。这可以通过使用用于企业架构开发的建模语言来实现，这些建模语言可以作为系统开发工具的输入，从而降低解决方案开发的成本。

        ■ 确保所采用的系统开发方法能够就设计方面向架构团队提供反馈。

11.3.3 指导解决方案部署的开发工作

        ■ 制定项目建议书

        对于每个独立的实施和部署项目，请执行以下操作：

        ——在影响分析中记录单个项目的范围。

        ——在影响分析中记录（从架构角度出发的）战略要求。

        ——在影响分析中记录变更请求（比如对标准接口的支持方面的请求） 。

        ——在影响分析中记录合规性规则。

        ——在影响分析中记录路线图中的时间安排要求。

        ■ 记录架构合同

        ——获取所有开发机构以及发起机构的签字。

        ■ 更新企业连续体目录以及解决方案的仓库。

        ■ 指导针对各项服务的业务及信息技术运营模式的开发工作。

        ■ 提供源自企业架构的服务需求。

        ■ 指导业务及IT运营要求的定义工作。

        ■ 对解决方案架构和运营之间进行差距分析。

        ■ 制定实施计划

11.3.4 开展企业架构合规性审查

        ■ 对每个构建模块正在进行的实施治理和架构合规性进行审查。

        ■ 开展开发后的审查工作。

        ■ 结束部署项目中的开发部分工作。

11.3.5 实施业务和信息技术运营

        ■ 开展部署项目，包括：IT服务交付实施；业务服务交付实施；技能开发与培训实施；沟通文件的发布。

        ■ 将新的基线架构发布到架构仓库，并更新其他受影响的仓库，例如运营配置管理仓库。

11.3.6 进行实施后审查并结束实施工作

        ￭开展实施后的审查工作。

        ￭发布审查结果并结束项目。

        当解决方案一次性全部部署完成时，G阶段即告结束。

11.4 输出

        G阶段的输出可能包括但不限于：

        ￭ 按照符合架构要求的已实施架构中的建议，提供（已签署的）架构合同（见《TOGAF标准——企业架构能力与治理》） 。

        ￭ 合规性评估（见《TOGAF标准——架构内容》）

        ￭ 变更请求（见《开放组架构框架（TOGAF）标准》——架构内容）

        ￭ 已部署的符合架构要求的解决方案，包括：

                — 已实施的符合架构要求的系统

                注意：已实施的系统实际上是开发过程的一个成果。然而，鉴于这一成果的重要性，在此将其列为架构开发方法（ADM）的一项输出。架构人员对实施工作的直接参与程度会因企业架构能力和治理情况而有所不同，这一点正如《TOGAF标准——企业架构能力与治理》中所描述的，具体会依据组织政策而定。

                — 已填充内容的架构仓库

                — 架构合规性建议以及（合规性）豁免情况

                — 关于服务交付要求的建议

                —  关于性能指标的建议

                —  服务水平协议（Service-Level Agreements，简称SLAs）

                — 实施后经更新的架构愿景

                —实施后经更新的架构定义文档

                — 已实施解决方案的业务及信息技术（IT）运营模式

                — 架构构建模块（ABBs）

11.5 方法

        正是在此处，成功管理各类实施项目所需的所有信息都汇集到了一起。请注意，在开展G阶段工作的同时，会执行一个特定于组织的开发流程，而实际的开发工作就在这个流程中进行。

        为了能够尽早实现业务价值和效益，并将转型和迁移计划中的风险降至最低，比较可取的方法是将目标架构作为一系列的过渡阶段来进行部署。每一个过渡阶段都代表着朝着目标迈出的渐进式一步，并且每个阶段本身都能带来业务效益。因此，G阶段的总体方法是：

        ￭建立一个实施计划，该计划应能够实现迁移规划阶段所商定要实施的过渡架构的交付工作。

        ￭采用分阶段的部署时间表，该时间表应反映出架构路线图中所体现的业务优先事项。

        ￭遵循组织在企业治理、信息技术（IT）治理以及架构治理方面的标准。

        ￭若组织已建立投资组合/项目群管理方法，则采用该方法。

        ￭定义一个运营框架，以确保所部署的解决方案能够长期有效地运行。

G阶段通过架构合同，在架构设计方与实施方之间建立起联系。

项目细节得以完善，其中包括：

        ￭名称、描述及目标

        ￭范围、可交付成果以及限制条件

        ￭有效性衡量标准

        ￭验收标准

        ￭风险与问题

        实施治理与整体架构治理紧密相关，而整体架构治理在《TOGAF标准——企业架构能力与治理》中有相关论述。

        G阶段的一个关键方面是确保不仅各实施项目，而且企业内其他正在进行的项目也都符合已定义的架构。与这方面相关的架构能力和治理方面的考量，在《TOGAF标准——企业架构能力与治理》中有详细阐释。

第12章： H阶段：架构变更管理

  本章着眼于建立用于管理新架构变更的相关程序。

图 12-1 H 阶段：架构变更管理

12.1 目标

H阶段的目标如下：

        ￭ 确保架构开发周期得以维持。

        ￭确保架构治理框架得以执行。

        ￭确保企业架构能力满足当前的各项要求。

12.2 输入

        本节定义了H阶段的各项输入内容。

12.2.1 企业外部的参考资料

        ￭ 架构参考资料（见《TOGAF标准——架构内容》）

12.2.2 非架构方面的输入内容

        ￭ 架构工作请求（参见《TOGAF标准——架构内容》）

12.2.3 架构输入

        ■ 企业架构的组织模型（见《TOGAF标准——架构内容》），包括：

        —— 受影响组织的范围

        —— 成熟度评估、差距分析以及解决方法

        —— 架构团队的角色与职责

        —— 对架构工作的限制条件

        —— 预算要求

        —— 预算要求

        ■ 经过定制的架构框架（见《TOGAF标准——架构内容》），包括：

        —— 定制的架构方法

        —— 定制的架构内容（可交付成果和工件）

        —— 已配置并部署的工具

        ￭ 架构工作说明（见《TOGAF标准——架构内容》）

        ￭ 架构愿景（见《TOGAF标准——架构内容》）

        ￭架构仓库（见《TOGAF标准——架构内容》），包括：

         —— 可复用的构建模块

        —— 可供公开获取的参考模型

        —— 特定组织的参考模型

        —— 组织标准

        ￭ 架构定义文档（见《TOGAF标准——架构内容》）

        ￭ 架构需求规范（见《TOGAF标准——架构内容》），包括：         

        —— 差距分析结果（来自业务架构、数据架构、应用架构和技术架构）

        —— 架构要求

        ￭ 架构路线图（见《TOGAF标准——架构内容》）

        ￭ 变更请求（见《TOGAF标准——架构内容》）——技术变更：

        —— 新技术报告

        —— 节约资产管理成本计划

        —— 技术撤出报告

        —— 标准制定举措

        ￭ 变更请求（见《TOGAF标准——架构内容》）——业务变更：

        —— 业务发展情况

        —— 业务例外情况

        —— 业务创新

        —— 业务技术创新

        —— 战略变革发展情况

        ￭ 变更请求（见《TOGAF标准——架构内容》）——源自经验教训

        ￭ 实施治理模型（见《TOGAF标准——架构内容》）

        ￭ 架构合同（已签署）（见《TOGAF标准——企业架构能力与治理》）

        ￭ 合规性评估（见《TOGAF标准——架构内容》）

        ￭ 实施与迁移计划（见《TOGAF标准——架构内容》）

12.3 步骤

        H阶段所涉及的细节程度将取决于整个架构工作的范围和目标。

        H阶段中各个步骤的顺序，以及这些步骤正式启动和完成的时间，都应根据既定的架构治理原则，因地制宜地做出调整以适应实际情况。

        H阶段的步骤如下：

        ￭ 建立价值实现流程（见12.3.1节）

        ￭ 部署监控工具（见12.3.2节）

        ￭ 管理风险（见12.3.3节）

        ￭ 为架构变更管理提供分析（见12.3.4节）

        ￭ 制定变更要求以满足性能目标（见 12.3.5 节）

        ￭ 管理治理流程（见 12.3.6 节）

        ￭ 启动实施变更的流程（见12.3.7节）

12.3.1 建立价值实现流程

        影响商业项目，使其借助企业架构来实现价值（取得成果）。

12.3.2 部署监控工具

        确保监控工具已部署并应用，以实现以下目标：

        ￭ 监控可能会对基线架构产生影响的技术变更

        ￭ 监控可能会对基线架构产生影响的业务变更  

        ￭ 业务价值追踪；例如，采用投资评估方法来确定实现业务目标的价值指标

        ￭ 监控企业架构能力的成熟度

        ￭ 跟踪并评估资产管理项目

        ￭ 跟踪服务质量（QoS）的性能表现和使用情况

        ￭ 确定并跟踪业务连续性要求

12.3.3 风险管理

        管理企业架构风险，并为信息技术战略提供建议

12.3.4 对架构变更管理进行分析    

        为架构变更管理提供分析：

• 分析性能。
• 与服务管理部门一起进行企业架构性能评审。
• 评估变更请求并进行报告，确保满足客户预期的价值实现和服务水平协议（SLA）期望。
• 对企业架构的性能进行差距分析。
• 确保变更管理请求符合企业架构治理和框架要求。

12.3.5制定变更需求以满足性能目标  

        针对变更需求提出建议，以满足性能目标并制定行动立场。

12.3.6 管理治理流程 

        管理架构的治理流程和框架：

        ■ 安排架构委员会（或其他管理委员会）会议

        ■ 召开架构委员会会议，旨在就处理变更（技术、业务变更以及特许事项）做出决策。

12.3.7 启动实施变更的流程

        启动架构流程以实施变更：

        ■ 生成新的架构工作请求和投资请求

        ■ 确保在本阶段实施的任何变更都能被记录并在架构仓库中存档。

12.4 输出

        H阶段输出可能包括但不限于：

        ■ 架构更新（用于维护性变更）

        ■ 架构框架和原则的变更（用于维护性变更）

        ■ 架构工作新需求（见TOGAF标准 - 架构内容），用于进入另一个周期（针对重大变更）

        ■ 架构工作说明（见TOGAF标准——架构内容），如有必要进行更新

        ■ 架构合同（见TOGAF标准——企业架构能力与治理），如有必要进行更新

        ■ 合规评估（见TOGAF标准 - 架构内容），如有必要进行更新

12.5 方法

        架构变更管理流程的目标是确保架构能够实现其最初设定的目标业务价值。这包括以一种连贯且符合架构设计的方式来管理对架构所做的变更。

        这一流程通常会对诸如治理要求、技术方面的新发展以及业务环境的变化等事项进行持续监控。当发现变更时，变更管理将决定是否正式启动一个新的架构演进周期。

        此外，架构变更管理流程旨在将已实施的企业架构确立为一种动态架构并为其提供支持；也就是说，这种架构具备灵活应变能力，能够迅速演进以应对技术和业务环境的变化。

        在这个阶段，监控业务的增长和下滑是至关重要的一个方面。企业架构的应用是架构开发周期中最重要的部分。情况常常是，企业所拥有的企业架构只适用于过去的组织模式，但可能无法提供足够的能力来满足企业当下和未来的需求。

         在许多情况下，架构仍然适用，但支撑架构的解决方案可能不再适用，因而需要做出一些改变。企业架构师需要了解这些变更需求，并将其视为架构持续更新的重要组成部分。

        在这个阶段，容量测量以及用于规划的相关建议是一个关键方面。虽然在这个企业架构的生命周期内，构建该架构是为了实现具有商定容量的稳定状态业务架构，但仍需要持续评估使用量的增长或下降情况，以确保实现最大的业务价值。

        例如，一些解决方案架构可能不太适合进行大幅度（比如说扩大至10倍）的扩展，或者当进行扩展时，其他替代解决方案可能会更具经济性。虽然架构规范可能不会改变，但解决方案或其运行环境可能会发生变化。

        如果在之前的各个阶段中，绩效管理和报告功能已被融入到工作产品当中，那么本阶段的重点就是确保这些功能的有效性。如果还需要额外的监控或报告，那么本阶段将负责处理这些变更。

价值与变更管理流程一旦确立，将决定：

        ■ 在哪些情况下，企业架构或其部分内容在部署后将被允许进行变更，以及进行变更所遵循的流程

        ■ 在何种情况下将再次启动架构开发周期，以开发新的架构

        架构变更管理流程与企业的架构治理流程密切相关，同时也与架构职能部门和企业业务用户之间的架构合同管理密切相关（详见《TOGAF标准——企业架构能力与治理》）。

        在H阶段，治理机构制定评判标准至关重要，以此来判断一项变更请求是否仅需进行架构更新，还是需要启动架构开发方法（ADM）的一个新周期。尤其要避免出现“渐进式完美主义（过度优化）”的情况，并且治理机构必须持续关注那些与业务价值直接相关的变更。

        架构合规性报告应说明所做的变更是否符合当前架构。如果不合规，在有合理理由的情况下，可批准给予豁免。如果该变更对架构有重大影响，那么就应制定一项策略来管理其影响。

        要规定出建立这些标准的指导方针并非易事，因为许多公司对风险的接受程度各不相同。但随着架构开发方法（ADM）的实施运用，治理机构的成熟度将会提高，针对特定需求的标准也会逐渐明晰。

12.5.1 变革驱动因素

        到目前为止，开发企业架构的主要目的在于明确战略方向，通过自上而下的架构设计和项目生成来实现企业的各项能力。然而，企业架构并非在真空中运行。通常情况下，企业会有已有的基础设施和业务，并且这些基础设施和业务已经在创造价值了。

        此外，很可能还存在一些变革驱动因素，这些因素往往是自下而上的，基于对现有基础设施进行修改以增强功能。企业架构在一定程度上通过一种战略性的自上而下的方法改变了这种模式，尽管逐步交付架构使得情况变得更加复杂。

有三种改变现有基础设施的方法，而这些方法必须加以整合：

        ■ 从战略层面、自上而下引导的变革，旨在增强或创造新的能力（资本）

        ■ 对处于运营管理之下的基础设施进行自下而上的变革，以修正或增强其能力（运维方面）

        ■ 在运营管理过程中，从先前已交付的项目增量中获取的经验教训，同时这些项目增量仍在由正在进行的项目持续交付

        治理机构将不得不处理这些变更请求的协调工作，此外，还需要建立一个经验教训总结流程，以便解决近期交付的项目增量中出现的问题，并对正在设计和规划的目标架构做出相应变更。

        经验教训总结流程可确保错误只犯一次而不会重蹈覆辙。这些经验教训可能来自任何地方、任何人，并且涵盖企业架构任何层面（战略层面、企业架构定义、过渡阶段或项目层面）的任何方面。通常，与企业架构相关的经验教训可能是从组织内其他地方总结出的经验教训所产生的间接成果。

        架构委员会（详见《TOGAF标准——企业架构能力与治理》）负责评估并批准变更请求（RFC）。变更请求通常是针对已知问题提出的，但也可能包含改进措施。架构委员会在处理变更请求时面临的一个挑战是，要确定是否应该批准该请求，或者是否通过过渡架构中的一个项目就能解决相关问题。

        在评估项目或解决方案是否符合架构时，也可能会出现这样的情况：一个创新性的解决方案或变更请求（RFC）推动了架构的变更。

        此外，还有许多与技术相关的因素会引发架构变更请求。例如：

        ■ 新技术报告

        ■ 降低资产管理成本

        ■ 技术淘汰

        ■ 制定标准

        这类变更请求通常主要可通过企业的变更管理和架构治理流程来进行管理。        

        此外，还有一些推动架构变更的业务驱动因素，包括：

        ■ 日常业务发展  

        ■ 业务例外情况

        ■ 业务创新

        ■ 业务技术创新

        ■ 战略变革  

这类变更请求往往会导致对架构进行全面的重新开发，或者至少会引发架构开发周期中某一部分的迭代，具体如下所述。

12.5.2 企业架构变更管理流程

        企业架构变更管理流程需要确定如何管理变更、应用哪些技术以及采用何种方法。该流程还需要具备筛选功能，以判定架构开发流程的哪些阶段会受到各项需求的影响。例如，仅影响迁移的变更在架构开发阶段可能并不值得关注。

        变更管理有许多有效的方法，同时也有各种各样可用于管理变更的管理技术和方法论。例如，诸如PRINCE2之类的项目管理方法、诸如ITIL之类的服务管理方法、诸如Catalyst之类的管理咨询方法，以及其他众多方法。

        一家企业如果在架构以外的某个领域（例如，系统开发或项目管理领域）已经有了一套现成的变更管理流程，那么很有可能能够对其进行调整，以便应用于架构相关的管理中。

        以下介绍一种变更管理方法，该方法特别针对为动态的企业架构提供支持。如果当前不存在类似流程，可考虑采用此方法。

        该方法基于将所需的架构变更划分为以下三类中的一类：

        ■ 简化变更：简化变更通常可以通过变更管理技术来处理。

        ■ 渐进式变更：渐进式变更或许能够通过变更管理技术来处理，也可能需要进行部分架构重构，这取决于变更的性质（有关指导原则，请参阅第12.5.3节）

        ■  架构重构变更：架构重构变更要求将整个架构再次纳入架构开发周期进行处理。

        看待这三种选择的另一种方式是，可以说对架构的简化变更通常是由减少投资的需求所驱动的；渐进式变更则是由从现有投资中获取额外价值的需求所驱动的；而架构重构变更则是由增加投资的需求所驱动的，目的是为了创造可供利用的新价值。

        为了确定一项变更属于简化变更、渐进式变更还是架构重构变更，需进行以下活动：

        1. 对所有可能影响架构的事件进行登记注册

        2. 针对架构任务的资源分配与管理

        3. 负责架构资源的流程或人员必须对应当采取的措施进行评估。

        4. 影响评估

12.5.3 维护与架构重新设计的指导原则

一条不错的指导原则是：

        ■ 如果该变更影响到两个或更多的利益相关方，那么很可能需要对架构进行重新设计，并重新进入架构开发方法（ADM）流程。

        ■ 如果变更仅影响一个利益相关者，那么它更有可能成为变更管理的对象。

        ■ 如果变更在特许豁免范围内可以被允许，那么它更有可能适用于变更管理流程。

        例如：

       ■  如果变更对业务战略产生重大影响，那么可能需要重新设计整个企业架构，即采用架构重构的方法。

        ■ 如果出现了新技术或新的标准，那么可能需要对技术架构进行更新，但无需对整个企业架构进行调整，这属于渐进式变更。

        ■ 如果变更发生在基础设施层面，例如，将十个系统减少或变更为一个系统，这可能不会改变物理层以上的架构，但会改变技术架构的基线描述；这种变更属于简化变更，可以通过变更管理技术来处理。

        特别是在以下情况下，可能需要进行更新周期（部分或完全重新架构）：

        ■ 基础架构需要重新与业务战略保持一致。

        ■ 在架构部署中，组件和使用指南需要进行重大变更。

        ■ 产品架构中使用的重要标准发生了变化，这对终端用户产生了重大影响；例如，监管方面的变化。

        如果需要一个更新周期，那么必须发出新的架构工作请求（以进入另一个周期）。

第13章：ADM架构需求管理

本章探讨了在整个架构开发方法（ADM）中管理架构需求的流程。

图13-1 ADM架构需求管理 

13.1 目标

需求管理的目标是：

        ■ 确保需求管理流程持续进行，并在所有相关的ADM阶段都能发挥作用。

        ■ 管理在架构开发方法（ADM）循环的任何执行过程中或某个阶段所识别出的架构需求。

        ■ 确保在每个阶段执行时，该阶段都能获取并使用相关的架构需求。
 

13.2 输入

需求管理阶段的输入内容如下：

        ■ 已填充内容的架构仓库（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

        ■ 企业架构的组织模型（请参阅《开放组架构框架（TOGAF）标准——架构内容》），包括：

                —— 受影响组织的范围

                —— 成熟度评估、差距分析以及解决方法

                —— 架构团队的角色与职责

                —— 对架构工作的限制条件

                —— 预算要求

                —— 治理与支持策略

        ■ 定制的架构框架（请参阅《开放组架构框架（TOGAF）标准——架构内容》），包括：

                —— 定制的架构方法

                —— 定制的架构内容（可交付成果和工件）

                —— 已配置并部署的工具

        ■  架构工作说明书（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

        ■  架构愿景（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

        ■  架构需求，用于填充架构需求规范（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

        ■ 需求影响评估（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

13.3 步骤

        需求管理阶段的步骤如下表所述：

	需求管理步骤	架构开发方法（ADM）阶段步骤
步骤 1		识别需求（通常通过分析如何通过价值流设计、业务场景、用户体验或管理信息的提供来实现业务目标 / 指标），并将其记录在架构需求规范和需求仓库中。
步骤 2	建立基线需求：确定优先级，确认利益相关者对优先级的认可，并将其记录在架构需求规范和需求仓库中。
步骤 3	监控基线需求。
步骤 4		识别新的和已变更的需求： a. 移除或重新评估优先级 b. 添加需求并重新评估优先级 c. 修改现有需求
步骤 5	识别已变更的需求并记录优先级： a. 识别已变更的需求，并确保由负责当前阶段的架构师以及相关利益相关者对这些需求进行优先级排序 b. 记录新的优先级 c. 确保识别出所有冲突，并在各个阶段对其进行管理，直至成功解决并确定优先级 d. 生成需求影响声明（请参阅《开放组架构框架（TOGAF）标准 —— 架构内容》），以便指导架构团队 备注： 已变更的需求可能通过任何途径产生。 为确保对需求进行妥善评估和优先级排序，这一过程需要指导架构开发方法（ADM）的各个阶段，并记录与需求相关的决策。 需求管理阶段需要确定利益相关者对所做决策的满意度。 如果存在不满意的情况，该阶段仍需承担责任，以确保问题得到解决，并确定接下来的步骤。
步骤 6		a. 评估已变更需求对当前（正在进行的）阶段的影响 b. 评估已变更需求对先前阶段的影响 c. 确定是实施变更，还是推迟到下一个架构开发方法（ADM）周期；如果决定实施变更，则评估变更管理实施的时间安排 d. 发布需求影响声明，版本 n + 1
步骤 7		实施来自 H 阶段的需求。架构在其生命周期内可通过架构变更管理阶段（H 阶段）进行变更。需求管理流程确保对源自 H 阶段的新需求或变更后的需求进行相应管理。
步骤 8	使用与所请求变更相关的信息更新架构需求仓库，包括受影响的利益相关方的观点
步骤 9		在当前阶段实施变更。
步骤 10		评估并修订过往阶段的差距分析。 架构开发方法（ADM）中从 B 阶段到 D 阶段的差距分析，能够识别出基线架构与目标架构之间的差距。某些类型的差距可能会产生差距需求。 架构开发方法（ADM）描述了两种类型的差距：         ￭ 基线中存在但目标架构中不存在的内容（即，因意外或设计原因而被去除的部分）         ■ 基线架构中不存在，但目标架构中存在的内容（即，新增的内容） “差距需求”指的是任何因意外而被去除的内容，因此需要对目标架构进行更改。 如果差距分析产生了差距需求，那么这一步骤将确保这些需求得到处理、记录并录入架构需求仓库中，并且目标架构也会相应地进行修订。

13.4 输出

        需求管理流程的输出可能包括但不限于：

        ￭ 需求影响评估（请参阅《开放组架构框架（TOGAF）标准——架构内容》）

        ￭ 如有必要，更新后的架构需求规范（见《开放组架构框架（TOGAF）标准——架构内容：架构需求规范》）

        《开放组架构框架（TOGAF）标准——架构内容》对在本阶段可能产生的架构工件进行了详细描述，不仅对这些工件展开了细致阐述，还将它们与TOGAF企业元模型中的实体、属性以及关系建立了联系。

        作为需求管理阶段的一部分，架构需求仓库将得到更新，并且它应包含所有的需求信息。

        当出现新的需求，或者现有需求发生变更时，就会生成一份需求影响声明。该声明会确定架构开发方法（ADM）中那些需要重新审视以应对这些变更的阶段。这份声明会经历多次迭代，直至形成最终版本，其中涵盖了这些需求（例如成本、时间安排以及业务指标等方面）对架构开发的全面影响。一旦当前架构开发方法（ADM）周期的需求最终确定下来，架构需求规范就应当进行更新。         

13.5 方法

13.5.1 概述

        正如架构开发方法（ADM）图示中心的“需求管理”所表明的那样，架构开发方法（ADM）持续受到需求管理流程的推动。

        需要着重注意的是，需求管理这个环节所代表的并非是一组静态的需求，而是一个动态的过程。在这个过程中，企业架构的各项需求以及对这些需求的后续变更得以识别、存储，并在相关的架构开发方法（ADM）阶段中输入和输出，同时也会在架构开发方法（ADM）的不同周期之间进行交互。

        应对需求变化的能力至关重要。架构设计从本质上讲是一项处理不确定性和变化的活动——也就是利益相关者所期望的内容，与能够被明确界定并设计成解决方案的内容之间的“灰色地带”。因此，在实际中，架构需求总是会发生变化。此外，架构设计常常要处理各种驱动因素和限制条件，其中许多因素从本质上来说是企业无法掌控的（比如不断变化的市场状况、新的法规等等），而且这些因素可能会以意想不到的方式引发需求的变化。

        

13.5.2 需求开发

        作为架构愿景的一部分，首批高层次需求得以明确阐述，这些需求是通过业务场景或类似的方法生成的。

        架构开发方法（ADM）的每个阶段，从预备阶段到 H 阶段，都必须从架构需求仓库和架构需求规范中选取该阶段已获批的需求。在阶段结束时，所有这些需求的状态都需要更新。在阶段执行过程中，在当前架构工作说明范围内为未来架构工作产生的新需求，需要记录在架构需求规范中；而那些超出当前架构工作说明范围的新需求，必须输入到架构需求仓库中，以便通过需求管理流程进行管理。

        在架构开发方法（ADM）的每个相关阶段，架构师都应确定架构必须满足的需求类型，包括适用的：

        ￭ 功能需求

        ￭ 非功能需求

在定义需求时，架构师应该考虑到：

        ￭ 需求的假设条件

        ￭ 需求的限制条件

        ￭ 驱动需求的特定领域原则

        ￭ 影响需求的各项政策

        ￭ 需求必须满足的各项标准

        ￭ 关于需求的组织指导方针

        ￭ 需求规范

架构开发方法（ADM）后续阶段的可交付成果同样包含与设计需求的映射关系，并且可能还会产生新的需求类型（例如，合规性需求、实施的时间窗口等）。

13.5.3 资源

        需求工程领域涌现出了丰富多样的关于需求管理的建议和流程。《开放组架构框架（TOGAF）标准》既不强制规定也不推荐任何特定的流程或工具；它只是阐明了一个有效的需求管理流程应该达成的目标（也就是说，如果你愿意的话，可以称之为“针对需求的需求”）。

13.5.3.1 业务场景

        一种用于分析如何通过一个流程或价值流来实现业务目标的技术。分析该流程中的活动由人类参与者和计算机参与者在哪些环节执行，是识别和阐明架构需求的一种非常有效的方法。这项技术在《开放组架构框架（TOGAF®）系列指南：业务场景》中有详细介绍。

13.5.3.2 需求工具

        市面上有大量且数量不断增加的现成商用（COTS）工具可用于支持需求管理，尽管这些工具不一定是为架构需求而设计的。