es_ESjapt_PTzh_CNzh_TW

TOGAF ADM：它是什么，为什么它如此重要？

Table of Contents hide
1 什么是 ADM？
2 预备阶段：
3 A 阶段：架构愿景：
4 B阶段：业务架构：
5 阶段 C：信息系统架构：
6 D阶段：技术架构：
7 E 阶段：机会和解决方案：
8 F 阶段：迁移计划：
9 阶段 G：实施治理：
10 H 阶段：架构变更管理：
11 架构需求管理：

TOGAF 是一个开放的组织框架。该框架本身是一个有据可查的知识体系，包括用于开发企业架构的详细方法和一组支持工具。TOGAF 9.2 是该框架的最新版本。

  • TOGAF 由 The Open Group 的成员开发和维护，他们在一个名为 Architecture Forum 的团队中工作。TOGAF 第 1 版的初步开发是在 1995 年完成的，随后的 TOGAF 版本扩展和改进了这一知识体系。
  • TOGAF 是由代表一些世界领先公司和组织的 300 多名架构论坛成员共同努力开发的——因此它是对一般企业架构实践的极好总结。
  • 开发和维护企业架构是一个复杂的过程，涉及许多利益相关者和决策过程。TOGAF 通过记录企业架构规范、流程和工作产品来提供帮助。
  • 通过使用 TOGAF，组织可以开发一致的企业架构，以反映利益相关者的需求，采用最佳实践，并适当考虑当前需求和未来感知的业务需求。

什么是 ADM？

架构开发方法（通常称为 ADM 的首字母缩写词）是开发或更改企业架构的详细分步过程。

 

TOGAF ADM 迭代周期

ADM 描述了涵盖架构开发周期的 10 个阶段。

这些步骤是：

  • 初步阶段
  • A 阶段：架构愿景
  • B阶段：业务架构
  • 阶段 C：信息系统架构
  • D阶段：技术架构
  • E 阶段：机会和解决方案
  • 阶段 F：迁移计划
  • 阶段 G：实施治理
  • 阶段 H：架构变更管理
  • ADM 架构需求管理

图片

预备阶段：

初步阶段的主要目标是识别和建立组织所需的架构能力。

其中一个关键部分是确定需要做什么以及如何实施。 例如，主要输出是一个架构工作请求 ，它概述了需求并决定需要什么范围、结构、工具或架构框架来支持这项工作。

在这个阶段，TOGAF 是为满足即将到来的 ADM 迭代的需求而量身定制的。我们定义基本原则，评估企业架构和业务进行所需更改的能力，并将 TOGAF 与其他管理框架集成。此阶段有一些步骤来限制受提议变更影响的企业组织，确定正确的治理和支持框架，定义和建立 EA 团队和组织，确定和建立架构原则，定制 TOGAF 和任何其他框架，以及实施工具. 在这个阶段结束时，EA 团队应该准备好遵循 ADM 周期的迭代。这部分是因为初级阶段显示在 ADM 图表的顶部，位于阶段 A 到 H 的主循环之外。

A 阶段：架构愿景：

阶段 A 提供了清晰的架构工作声明，将在 ADM 的迭代中提供。它还提供了提议的企业架构的愿景。这种方向感对于在整个迭代过程中指导 ADM 的工作至关重要。这份 建筑工作声明 定义了开发和部署架构愿景中概述的架构的工作程序。正是这种愿景为提议的企业架构将提供的功能和业务价值提供了高层次的愿望。从建筑工作申请开始，阶段 A 提供了一个工具（此愿景），将提议的能力的好处推销给企业内的利益相关者和决策者。业务场景用于理解业务需求并帮助阐明所需功能所隐含的架构需求。这记录在架构工作声明中，用于建立共识以支持最终架构。当赞助组织签署文件时，就会达成共识。

阶段 A 的步骤都是关于将建设工作请求转化为清晰的架构工作声明，并确保业务能够、准备好、愿意并致力于进行必要的架构更改。这涉及建立架构项目，包括定义其范围，以及识别和详细说明架构和业务原则。阶段 A 识别利益相关者及其关注点和要求，并在初步阶段识别业务目标、驱动因素和约束。为确保成功，它还评估业务能力、评估业务转型准备情况并解决任何转型风险。

B阶段：业务架构：

TOGAF 将企业架构视为提高业务能力的一种方式——这就是为什么第一个架构开发阶段涉及 业务架构的原因 。

ADM 从业务角度出发——初步阶段的 架构工作请求 中确定了强大的业务需求，并进一步细化为  阶段 A的架构工作 和 架构愿景 声明。

业务架构阶段的一个关键目标是开发一个目标业务架构，展示企业如何实现架构愿景并解决架构工作请求。它的第二个目标是首先确定候选架构路线图组件，以弥合基线和目标业务架构之间的差距。TOGAF 将业务架构知识视为在数据、应用程序和技术等其他领域进行架构工作的先决条件。业务架构还向关键利益相关者展示了架构工作的业务价值和投资回报。业务模型，例如活动或流程模型、用例和类模型或节点连接图，

所有三个架构开发阶段（B、C 和 D）都遵循类似的步骤。重用任何可用的参考模型并自定义所有输出以解决利益相关者的观点非常重要。然后架构师开发业务架构的基线和目标描述，并执行差距分析以确定如何从一个过渡到另一个。

阶段 C：信息系统架构：

TOGAF 将阶段 C（信息系统架构）分为两部分，涵盖 数据 和 应用程序  架构的开发。TOGAF 文档有一个简短的介绍性章节，涵盖这两个领域，然后是数据和应用程序的单独章节。与其他架构开发阶段 (B&D) 一样，目标是为数据和应用程序开发目标信息系统架构，并根据基线和目标架构之间的差距确定候选架构路线图组件。

阶段 C 始终涉及数据和应用程序架构的组合。提供两者都包含的顺序无关紧要 – 两种方法都有倡导者。数据和应用程序的步骤非常相似——选择参考模型、观点和工具；制定基线，然后定位架构描述，执行差距分析并定义候选路线图组件；并解决整个架构环境中的任何影响。在正式的利益相关者审查之后，最终确定了架构并创建了架构定义文档。

数据和应用程序之间的主要区别在于主题，这反映在使用不同的参考模型、技术和架构表示上。例如，数据架构可能使用实体关系图或类图，而应用程序架构可能使用应用程序通信图或软件工程图。

 D阶段：技术架构：

D 阶段是 TOGAF 的阶段，为架构项目开发技术架构。技术架构描述了平台服务以及逻辑和物理技术组件的结构和交互。阶段 D 开发支持数据和应用程序组件（在阶段 C 中开发）的目标技术架构，支持业务组件。

在 B、C 和 D 阶段开发的架构结合起来实现架构愿景——解决利益相关者的关注和对建设工作的要求。与其他架构开发阶段一样，阶段 D 确定候选架构路线图组件，以实现从基线到目标的过渡。D 阶段的步骤与 B 和 C 阶段的步骤几乎相同——主要区别在于现在的重点是技术。因此，这包括技术参考模型和技术标准或测量——例如性能、可维护性、位置和延迟或可用性。

确定输出和可交付成果对于帮助构建真正支持信息系统和业务架构的技术架构非常重要。获得正确的范围可以加快回报，而过多的范围会阻碍成功实施。这不是关于部署技术本身，而是关于开发真正解决架构愿景和工作要求的技术架构。

 E 阶段：机会和解决方案：

E 阶段得名——它正在寻找通过实施特定解决方案来交付目标架构的机会。E 阶段通过结合建筑开发阶段（B、C 和 D）的分析和建议，生成第一个完整版本的建筑路线图。

这个阶段的重点是如何提供模式。因此，它着眼于创建架构路线图，在时间线中列出工作包以实现目标架构。当更改如此之大以至于无法直接从基线转到目标架构时，阶段 E 会导致增量方法，包括中间或过渡架构。E 阶段将所需的架构更改映射到具有资金和资源的投资计划和项目，以执行工作包并提供过渡和目标架构。此阶段的输入几乎是早期阶段输出的所有内容。这些步骤采取了这些输出；整合它们，分析依赖关系并协调差异；并重申该组织有能力做出改变。阶段 E 细化和更新需求、架构文档和架构路线图。关键输出是实施和迁移计划的第一步。

F 阶段：迁移计划：

ADM 的早期阶段确定了架构更改的需求，然后开发业务、数据、应用程序和技术架构来支持这一需求。然后，第二阶段制定一个高层次的 实施和迁移计划 ，以利用投资机会并确定具体的解决方案。目标 架构 。F 阶段最终确定了详细的 实施和迁移计划 ，以及最终的架构路线图。

它还确保该计划与企业内使用的变更管理方法以及整个变更组合中的其他计划保持一致。最后，阶段 F 确保关键利益相关者充分了解业务价值、工作包的成本以及过渡和未来架构。虽然 ADM 的早期阶段在很大程度上由企业架构团队指导，但从 E 到 H 的阶段需要与其他变革推动者协作。F 阶段特别要求四个管理框架紧密合作，以使实施和移民计划取得成功。这四个领域是：

  1. 商业计划
  2. 企业架构
  3. 投资组合管理
  4. 项目管理

这四个领域必须协同工作，使用绩效衡量、投资回报、商业价值、关键成功因素、有效性衡量和战略匹配等标准来确定工作的优先级。

阶段 G：实施治理：

实际开发和实施与阶段 G 并行进行。阶段 G 确保实施项目以及其他正在进行的项目符合定义的架构。

通常，目标架构被开发为一系列转换，以尽快实现业务价值和收益并降低转型计划中的风险。每一次转型都代表着向目标公司迈出的一步，实现了自己的商业利益。

当我们到达阶段 G 时，架构已经开发（在阶段 A 到阶段 D），已经确定了交付架构的机会和解决方案（在阶段 E），并且已经完成了详细的实施和迁移计划（在阶段F） ）。因此，阶段 G 架构团队的角色是监督架构的实施。这是通过确认部署的范围和优先级、指导开发和解决方案部署以及执行合规审查来完成的。架构合同文件用于推动架构变更。在阶段 G 开始时生成并由架构功能和负责实施的人员批准，它是评估架构治理合规性的机制。

H 阶段：架构变更管理：

一切都没有完全按计划进行——总会有新的需求和要求来改变架构。阶段 H 描述了变更管理过程，以一种内聚的架构方式来管理架构的变更。通常，这需要持续监控治理请求、新技术或业务环境的变化。

该过程应该支持已实施的企业架构作为一个动态环境，可以灵活地快速发展以响应这些变化。在阶段 H，管理机构设置标准以判断变更请求是否需要简单的架构更新，或者是否需要启动架构开发方法 (ADM) 的新周期，这一点至关重要。避免“爬行优雅”很重要，因此更改必须与业务价值直接相关。如何使用企业架构是架构开发周期中最重要的部分，因此在 H 阶段监控业务增长和下降至关重要。最终，昨天为组织工作的企业架构不再支持当前或未来的功能。H 阶段的变更请求输出可归类为简化——通常由减少投资的要求驱动；增量变化——需要从现有投资中获取额外价值；或重新设计变革，这是由增加投资和创造新价值的需求驱动的。

架构需求管理：

在 ADM 的每个阶段生成、分析和审查需求。需求管理阶段描述了在整个 ADM 中管理这些架构需求的过程。需求管理阶段是 ADM 的核心——这就是为什么它显示在 ADM Clipping Circle 的中心。此阶段描述了需求管理的过程以及该过程如何与 ADM 的其他阶段联系起来。需求不是静态的——它们随着我们完成 ADM 的每个阶段和 ADM 周期之间而动态变化。企业架构的需求和对这些需求的后续更改将被识别、存储以及与 ADM 阶段相关的输入和输出，以及在 ADM 的周期之间。处理需求变化至关重要。架构处理不确定性和变化——利益相关者期望和可能性之间的“灰色地带”！因此，架构要求总是会发生变化。此外，架构涉及许多业务无法控制的驱动因素和约束——例如不断变化的市场条件或新的立法——这可能会以不可预见的方式造成需求变化。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。因此，架构要求总是会发生变化。此外，架构涉及许多业务无法控制的驱动因素和约束——例如不断变化的市场条件或新的立法——这可能会以不可预见的方式产生需求变化。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。因此，架构要求总是会发生变化。此外，架构涉及许多业务无法控制的驱动因素和约束——例如不断变化的市场条件或新的立法——这些都会以不可预见的方式产生需求变化。TOGAF 强调需求管理过程本身并没有解决，解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。需求管理阶段只是在整个 ADM 中管理需求的过程。TOGAF 强调需求管理过程本身并没有解决、解决或优先考虑需求，因为这是在 ADM 的相关阶段完成的。需求管理阶段只是在整个 ADM 中管理需求的过程。

（*来源：TOGAF ADM：它是什么，它为什么如此重要？）

TOGAF

ArchiMate 3

Leave a Reply

您的电子邮箱地址不会被公开。