TOGAF ADM 概述
TOGAF ADM 设置 TOGAF 框架 除了其他 企业架构框架.它是唯一一个包含所有 框架的三个部分 – 如何记录架构， 如何建立企业架构团队， 和 如何开发架构.
TOGAF ADM 开发企业架构
每个 TOGAF ADM 阶段解释发展知识的活动。每个 ADM 阶段都会开发关于部分内容的知识 企业架构.阶段之间的交互是信息流。这些信息流合并成几个关键的可交付成果——一个是 TOGAF ADM 阶段 F 实施计划。
什么是 TOGAF F 期？
TOGAF 阶段 F 为企业架构师提供了步骤和信息输入，以支持规划人员制定实施计划。企业架构师支持规划人员显然是最佳实践。他们的角色是确保架构中利益相关者的决策反映在计划中。如果先前的决策未反映在实施计划中，则必须更新企业架构。只有当您的企业承诺进行更改时，候选企业架构才会最终获得批准。
TOGAF ADM 阶段 F 的目标是什么？
F 阶段的目标是从 架构路线图 开发于 TOGAF ADM E 期 到实施计划。架构路线图已经筛选出糟糕的变更选项。实施计划是您的组织打算如何执行变更并达到过渡状态。
当我们解释企业架构时，我们谈到考虑可能的变化，权衡选项。过去的一切。架构路线图指出了前进的道路，潜在的过渡点。是时候进行最后的选择了。
成功需要：
- 您决定如何执行更改（项目）
- 您知道将被编组以交付更改的资源
- 您知道所需的好处和施加的限制（架构合同）
与 TOGAF 的交互 B阶段, C期 阶段 D， 和 E期
虽然瀑布方法不能提供良好的架构，但架构路线图和制定实施计划之间应该有一个明显的突破。探索和放弃潜在的变化是企业架构中的一个有价值的结果。阶段 F 进入一个艰难而实际的世界。
项目组合规划者、项目经理和项目经理并不生活在一个充满可能性的世界中。他们生活在一个艰难的执行世界中。他们谈到诸如 铁三角.他们希望了解目的地、预期收益和限制。他们打算把每个人都拖过终点线。
虽然 TOGAF 标准规定您要到 F 阶段才能完成目标架构，但您的架构只会在您的组织拒绝继续进行时发生变化。否则，架构开发就完成了。
什么是架构实施计划？
实施计划提供了将实现目标架构的项目时间表。可执行项目将被分组到管理的投资组合和计划中。这 实施策略 说明改变的方法。
让我们解开实施计划定义。首先，实施计划是一个时间表。它及时链接项目。
二是基于项目。我们知道从 PMI 每个项目都是一组具有共同目标的相互依赖的任务。项目特点：
- 明确的开始和结束日期。他们将有一个明确的开始，一个明确的结束，以及两者之间发生的事情的概述
- 他们创造了一些新的东西。它们是一次独特的活动。再也不会以同样的方式重复
- 它有明确的界限。它们在时间、金钱、质量和功能的限制下运作
- 它永远不会像往常一样。它改变了一切照旧
最后，它说明了变革将如何进行。这 实施策略 将需要更改为：
- 进化的
- 革命性的
- 格林菲尔德
为什么实施计划与架构路线图不同？
TOGAF 标准 ADM 将 E 阶段和 F 阶段以及架构路线图与实施和迁移计划分开。分离基于最佳实践计划。架构路线图支持确定您的路径、目的地以及尚未做出决定的地方。它还支持识别旅程中哪些地方存在未解决的分叉。实施和迁移计划仅支持执行。
我们可以保证您当前的路线图看起来更像是实施计划，而不是架构路线图。但是，我们很少看到将工作分解为离散的项目，并将项目链接到 Portfolio 和 Program 进行管理。通常，它是一个单一的广泛项目。实施策略很少是明确的，这导致项目试图在项目内部决定什么是最好的方法。他们总是决定对项目最简单的路径。
与利益相关者、资源所有者和您的企业规划者一起制定真正的实施计划。企业架构师在那里强调预期价值、依赖性和实施策略。我们已经评估了价值。你有过渡架构。这是一个计划交付预期的练习，而不是弄清楚什么是合理的。
TOGAF ADM F 阶段实施计划可交付成果
F 阶段的两个核心成果是实施计划和架构合同。这是企业架构的动作部分。
实施计划最有价值的用途
- 定义变更计划。确定会发生什么变化，以及何时发生变化
- 通过实施战略定义变更类型
- 通过 Portfolio 和 Program 定义控制
实施计划将有助于回答以下问题：
架构合同将帮助回答以下问题：
- 预期有哪些有形和无形的收益—— 架构合约 - 收益
- 当约束限制了实施者的自由时—— 架构合约——架构规范
- 如何应对风险和不确定性—— 架构契约 - 控制
- 预计会有什么变化—— 架构合约——实施策略
- 什么变化是越界的—— 架构合同 - 过渡 ＆ 益处
实施计划是一种企业变更执行工具。它将执行和组织整合在一起。
完成 F 期实施计划
所有 TOGAF ADM 阶段都会引导您开发所需的知识。阶段 F 的结果是实施计划和支持架构合同。
| 产出与成果 | 基本知识 |
| 一组获批的项目[1]，包含目标和任何必要的约束、所需的资源以及开始和结束日期。 | 可用于进行更改的资源。
利益相关者的优先级和偏好如何根据价值、努力和变化风险进行调整。 （利益相关者要求） |
F相裸骨
在阶段 F，变更计划者执行大部分繁重的工作。实施计划需要对工作的承诺。
F阶段的基本框架是：
- 什么时候会发生什么变化—— 实施计划的项目
- 会发生怎样的变化—— 实施策略
- 如何管理变革以取得成果—— 实施计划的组合
- 如何将变革作为工作进行管理—— 实施计划的程序
- 将带来什么好处—— 架构合约
- 哪些限制限制了实施者的自由—— 架构合约
我们总是在 F 阶段感到自由。广泛的架构可能性缩小到单个线程。所有复杂的权衡都已经过去了，我们需要对资源和时间进行艰难的谈判。坦率地说，如果我们的架构路线图没有处理范围和质量的边界，我们还没有为实施规划做好准备。
- 什么时候会发生什么变化
分配给项目的工作包。一个或多个项目达到过渡状态或最终目标。会发生什么变化？什么时候会发生？
您将需要解释过渡状态。实施者是具体的现实主义者。他们将认同目标状态并寻求前往那里。因此，他们会想要超越过渡状态。他们会对利益相关者将价值休息点作为同义词并执行出口匝道的想法感到非常不舒服。
什么工作，什么范围，什么时候。这一切都在 实施计划的项目.
- 会发生怎样的变化
永远不要将变更类型留给项目团队。他们有一个最终目标，并且会切入任何角落以取得胜利。因此，系统是 不是 退役。这就是遗留流程的原因 永远持续.如果您期待更换，那就是 Greenfield。如果您期待增强，它是进化的。清楚，然后在 G阶段实施治理 测试合规性。用你最强大的 实施治理 工具 实施策略.
- 如何管理变革以取得成果
项目管理专业发明了投资组合和计划的概念，以解决管理一组复杂项目的问题。从事这项工作的人很难看出他们是如何结合在一起的。他们着眼于非常直接的回报，并将在项目结束时专注于有形的交付。当您的企业架构具有一个或多个过渡状态时，您需要额外的 实施治理.
按结果对项目进行分组，并由专人负责结果，简化了实施治理。最佳实践架构治理使用自然权限结构。投资组合管理是一种自然结构。帮助您的利益相关者创建他们的 实施计划的组合.
- 如何将变更作为工作进行管理
投资组合用于对结果进行分组。程序用于分组执行。当您按执行对项目进行分组时，您就是在简化 实施治理.像投资组合分组跟随 最佳实践架构治理 并采用自然的权威结构。帮助您的利益相关者创建他们的 实施计划的程序.
- 将带来什么好处
我们开发了架构合同的概念，以将利益或价值与项目描述分开。项目团队期待项目的结束。项目团队关注赞助商的需求。您可以期望实施者放弃与其项目不直接一致的利益。您可以期望下降被认为是降低风险或降低成本。
要提供明确的方向和控制，请使用 架构合约 获得利益或价值。特别是如果你正在建造 能力 或确保未来 企业敏捷性.
- 哪些约束限制了实施者的自由
如果你没有东西，你 必须 控制，你需要远离架构规范。架构规范总是阻碍创新并限制实施团队的创造力和知识。
当您需要某些东西时，请使用架构规范 架构合约.在 导航™，我们使用四种架构规范：
- 原则，适用于如何决定的一般指导
- 模式，其中存在已知的首选方法
- 标准，有已知可接受的方法
- 规则，必须删除所有选择
我们希望我们的企业架构师在制定规则之前始终拥有一个标准。根据模式测试他们的标准。确保模式符合原则。我们这样做是为了确保尽可能少地限制实施者的自由度。编写规则很容易，但需要近乎无所不知。您必须向前看，并了解独特的情况和未来的能力。或者弄错了规则。
阶段F的三个完成要领：
- 首先，完成的定义。我们什么时候会进入过渡状态？
- 第二，变革责任。谁对什么投资组合或计划负责？
- 第三，交通规则。会带来什么好处？施加了什么约束？
有了这三个要素，利益相关者就可以制定实施计划了。他们知道他们想要做什么。他们知道他们不想改变什么。他们知道他们如何限制他们的实施者。
TOGAF ADM 阶段 F——实施计划可交付成果和企业架构目的
开发企业架构有四个核心目的。要么支持战略、投资组合、项目，要么支持解决方案交付。在大多数情况下，除非您支持战略或投资组合，否则您不会制定架构路线图。这些模式在 企业架构师开发架构指南.
不同的可交付成果在每个目的中具有不同的重要性。
支持战略的架构
当您支持战略时，您将提供端到端的目标架构并制定变革路线图。您的架构将确定变更计划以及支持组合和计划。架构路线图将设定职权范围、确定协同效应并管理投资组合和计划的执行。
支持产品组合的架构
当您支持投资组合时，您通常会处理单个投资组合。您的架构将识别项目，并设置他们的职责范围，调整他们的方法，识别协同效应，并管理项目的执行。
| 支持战略的架构 | 支持产品组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| F阶段工作产品：架构实施计划 | 可能没用过 | 关键交付物
在投资组合预算期间 根据需要刷新以支持预算和项目管理 |
关键交付物
项目开始前 |
关键交付物
在订婚和签约之前 |
| F阶段工作产品：架构合同 | 可能没用过 | 限制使用 | 关键交付物
项目启动完成前 |
关键交付物
在订婚和签约之前 |
| F 阶段工作产品：目标企业架构 | 重要的交付物
用于记录保存和未来的架构开发 |
重要的交付物
用于记录保存和未来的架构开发 |
主要是优越的架构
用于记录保存和未来的架构开发 |
高级架构 |
实施计划
无论您是在努力支持战略、投资组合还是项目，您的实施计划的结构都会发生变化。实施计划用于 治理实施.
| 支持战略的架构 | 支持产品组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| 实施计划项目 | 概括 | 关键交付物 | 高级架构 | 高级架构 |
| 实施计划战略 | 适合项目 | 关键交付物 | 关键可交付成果或卓越架构 | 高级架构 |
| 实施计划组合 | 关键交付物 | 关键交付物 | 高级架构 | 高级架构 |
| 实施计划方案 | 关键交付物 | 关键交付物 | 高级架构 | 高级架构 |
架构合约
| 支持战略的架构 | 支持产品组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| 架构合约 - 收益 | 适合项目 | 关键交付物 | 关键交付物 或高级架构 | 高级架构 |
| 架构合约——架构规范 | 原则 | 原理与模式 | 原则、模式和标准 | 原则、模式、标准和规则 |
| 架构契约 - 控制 | 适合项目 | 关键交付物 适合项目 | 关键交付物 或高级架构 | 关键交付物 或高级架构 |
| 架构合同 - 实施计划策略 | 适合项目 | 关键交付物 | 关键交付物 或高级架构 | 高级架构 |
| 架构合同 - 过渡 | 关键交付物 | 关键交付物 或高级架构 | 关键交付物 或高级架构 | 高级架构 |
目标企业架构
完整的 企业架构将包含领域架构模型 以及一组合并的间隙。作为可交付成果，您将更新目标企业架构以在未来架构开发中使用，或作为 G 阶段实施治理中的参考。
构成目标企业架构的模型
企业架构师在 F 阶段的作用是什么？
在 TOGAF 阶段 F，我们希望企业架构师为规划者提供建议。他们将需要解释目标架构和任何转换。最关键的是，它们将确保计划中包含预期的收益和约束。
架构师习惯于规划能够带来意想不到的好处的工作顺序。或者期待约束的需要。企业架构师需要解释过渡状态。
项目规划者的时间范围很短，并且是非常直接的思考者。他们会对以下情况感到不舒服：
- 无形利益
- 延迟实现利益
- 阻碍当前项目的约束
关于利益，我们总是以架桥为例。坡道和支撑是必要的，但不会产生增量价值。此外，在您完成整个道路甲板之前，这座桥不会提供任何可实现的价值。它可以帮助人们理解我们可能正在做大量的工作，只是为了在实现显着收益之前做更多的工作。
我们发现谈论高速公路和立交桥有助于他们了解阻碍当前项目的限制因素。随着交通量的增加，路基和沥青的成本急剧增加。在我们建造这座桥之前，交通量很低，所以在路基上的花费只会推高当前项目的成本。当道路、桥梁和立交桥连接在一起时，您就有了一个可以维持交通量的交通网络。提供价值的一种。一种不需要撕毁正在使用的道路并重新建造的道路。
企业架构师最重要的角色是超前思考和跨越边界。他们会理解为什么当前的项目可能会受到限制，或者成功标准不明显。当项目发起人取消企业利益时，他们将帮助吸引投资组合所有者。
关于 TOGAF F 阶段的两个核心事实——实施计划
采取务实的态度 建立企业架构团队。我们基于一个令人不安的事实采取务实的做法——如果正常思维能带来灵活、高效的组织，我们的职业就不存在了。企业架构需要非正常思维。
我们讲述了两个核心事实 企业架构师 关于 TOGAF 阶段 F - 架构路线图。首先，除了您的利益相关者，参与实施计划的任何人都不会相信您所说的任何话。你的想法总是太大，太延迟，太理论化了。你需要像老鹰看老鼠一样观察每个人。他们将需要与您的利益相关者建立牢固的关系。您将需要使用已经有过的权衡对话来制定架构路线图。事实上，你可以期待与其他人重新争论权衡。其次，如果您没有记录在案的架构合同，您将在实施治理方面遇到困难。没有人会记住预期的收益、实施策略或任何约束。曾经。他们将在项目执行期间重新想象一切（TOGAF ADM 阶段 G) 尽可能轻松地完成项目，以服务于项目发起人的战术利益。
利益相关者需要企业架构师来保护他们想要的价值。通常，大部分的保护来自项目发起人和实施团队。
[1] 不要专注于“项目”一词的定义或项目是什么。这只是为实现可理解的结果而组织的工作。您的组织对项目的内部定义以及使用的标签不太可能与其他任何人的一致。我的助理提到预订航班是一个项目。
实施计划模型、工具和技术
TOGAF ADM 阶段 F 交付实施计划和架构合同。此阶段的存在是为了启用操作。
阶段 F 是将架构路线图和目标架构转化为行动。有五种核心实施计划制定技术可帮助利益相关者了解如何实现目标架构的好处。
- 投资组合分组
- 节目分组
- 利益实现
- 风险缓解
- 架构合约
- 实施策略模型
- 使用架构路线图技术
实施计划技术
总之，这些技术将突出企业架构师必须为制定实施计划做出贡献的所有内容。企业架构师的角色归结为保护变更的价值。
投资组合计划/投资组合分组
项目管理专业使用 Portfolio 和 Program 来管理一组复杂的项目。项目发起人和实施者查看项目的明确可交付成果。
投资组合计划按结果对项目进行分组。作为指定的投资组合，有人可以对结果负责。这增加了成功的可能性并实现了实施治理。
投资组合创建了一个自然的权限结构。组织的其余部分将采用权力结构和基于结果的报告。
项目规划/项目分组
程序将项目分组以供执行。就像 Portfolio 一样，您将联系到负责管理一组相关项目的人员。创建了一个以执行为导向的自然权威结构。组织的其余部分将采用权限结构和基于执行的报告。
利益实现
我们始终将企业架构的优势与启动当前架构开发的缺陷相结合。我们使用架构路线图和企业架构来 治理实施.这需要将预期收益与预期会带来收益的项目分开。
在 导航 我们将福利与工作包挂钩。我们将工作包链接到它正在填补的差距和将交付它的项目。
我们经常发现，在项目启动和项目执行期间，将交付利益的工作被取消范围，而利益继续出现在项目的 PowerPoint 幻灯片上。当项目发起人无法获得福利时尤其如此。
企业架构的存在是为了指导有效的变革。有效的改变实现了好处。
在制定实施计划时，我们会寻找能够明确填补空白并带来收益的工作。没有工作，你有一个未填补的差距和缺失的利益。
风险缓解
我们对这个词有两种用法 风险.首先，它是不确定性对实现目标的影响。这是风险管理专业使用的定义。我们发现它与企业架构产生了最强烈的共鸣。其次，是风险是可能发生的坏事的正常用法。我们发现大多数人认为风险是一种威胁或坏事。如何使用风险并不重要。我们发现不确定性和威胁的处理方式相同。您使用控件来解决它，并且该控件必须通过工作包来实现。
导航 将风险与资产或目标对齐。控制可减轻风险。工作包可实施控制。我们将工作包与负责的项目联系起来。
目标是我们进行变革的原因。缺失意味着更改毫无意义。当您不确定能否实现目标时，您正在采取哪些措施来减少不确定性？解决不确定性是关键 实施计划和 实施治理 活动。
同样，我们将风险和控制与项目分开。我们通过工作链接。这使我们能够计划和监控去范围。
我们经常发现，在项目启动期间，与项目和项目发起人没有直接关联的项目执行目标和资产将被取消范围。当项目发起人不拥有目标时尤其如此。
我们通常期望变革举措来开发能力、减少敏捷性消耗摩擦、降低持续运营成本。然而他们经常失败。他们失败了，因为我们通过专注的项目交付工作。每个重点项目都受到铁三角的约束，并将积极地去范围。我们从未见过将描述视为对企业目标的威胁。他们总是将其作为对项目的改进。
企业架构师必须在实施规划期间解决实现目标的不确定性。没有这个，他们就无法执行 实施治理 活动。
架构合约
TOGAF 的架构合约概念非常强大。它通常表现为 EA 团队和项目之间某种形式的书面协议。虽然记录它是有用的，但合同是在利益相关者和项目之间。这是 绝不 在项目和 EA 团队之间。
当我们制定架构合同时，我们确保它包括：
- 益处
项目将通过哪些工作包提供哪些好处？
这为实施者、治理流程和利益相关者提供了可见性，他们期望谁负责，以及他们正在做什么来实现他们的责任。
- 控制
项目将通过哪些工作包交付哪些控制？这些控制措施减轻了哪些风险？
就像收益一样，这为实施者、治理过程和期望实现目标的利益相关者提供了可见性，谁是负责的，以及他们正在做什么来实现他们的责任。
- 架构规范
哪些约束剥夺了实施者的自由？
这阐明了项目团队必须遵循与其项目逻辑相矛盾的指导。如果他们的项目逻辑会驱使他们遵循约束，我们就不需要架构规范。我们使用架构规范，其中项目的逻辑会导致企业做出糟糕的选择。
- 实施计划战略
如何应对变化
就像架构规范一样，实施者必须如何处理项目？在项目逻辑将引导他们采用另一种方法的情况下尤其如此。
- 过渡
我们什么时候故意停止做空？过渡点之后的每一分钟变革工作都可能是浪费。我们将过渡点设计为价值休息点。利益相关者可以延迟、停止或改变方向的变化点。我们使用过渡 实施治理.当项目逻辑或项目发起人的偏好将推动项目比预期更进一步时，它们会提供帮助。通常带有效率的解释。但是，如果赞助商延迟、停止或改变方向，并且未达到下一个完整的价值休息点，则该项目将建造另一座半桥。
实施策略
无论您是否在架构合同中包含实施策略，实施策略在制定实施计划时都至关重要。三种类型的变化（进化、革命和绿地）将推动项目设计和系统设计。
例如，如果您需要从头开始（Greenfield），您期望组织、流程和系统发生变化。你故意抛弃现有的组织、流程和系统。你的项目最好设计成创造一些新的东西，并通过变革来领导变革管理。
坦率地说，遗留系统、糟糕的流程和僵化的组织是通过对项目的简单路径（进化）进行更改来维持的。
使用 架构路线图技术
制定架构路线图的不同技术用于在制定实施计划时提供不同的指导和约束。
热图将提供来自价值、工作、风险或过渡状态等属性的指导和约束。他们推动项目设计。
生命周期图表提供有关时间的指导和约束。无论生命周期图是关于系统还是关于变更，它都突出了启动和停止的界限。当某个时间需要更改事件时，它们非常强大。令人惊讶的是，延迟更改往往毫无价值。如果你不能及时拥有新系统，那么迟到的新系统就会失去它的价值。
依赖模型提供关于依赖的指导和约束。依赖项是工作、组织、系统还是过渡状态。依赖关系图通常可以帮助您了解生命周期图中的要求日期。
在制定实施计划时，情景路线图很少有用。
工作包、架构选项或过渡状态选项的复杂可视化。辐射图通常表示关注点或属性，例如价值、工作或风险。图上的点通常代表架构选项或过渡状态选项。
了解有关 Conexiam 的更多信息 架构路线图研讨会
过渡架构
过渡架构提供关于停止点的指导和约束。为了提供价值休息点，您可以构建项目以一起达到过渡状态。任何过渡状态中最重要的日期是“要求”或“截止日期”。
差距与解决方案
差距解释了我们需要弥补的缺陷。它们帮助项目定义范围和结果。
解决方案简化了设计。如果有预期的解决方案或解决方案属性，它会简化范围和设计。当您选择了新的或革命性的实施战略时，尤其如此。
符合企业架构目的的实施计划技术
架构团队支持不同的目的。无论您支持投资组合问题还是解决方案交付，都将改变您开发和使用架构路线图的方式。例如，支持解决方案交付的架构不会使用架构路线图类型 1：热图来制定决策。我们将把它用作优越的架构以及对架构开发和任何实现的一组约束。优秀的架构师总是在卓越架构的约束下工作。
| 支持战略的架构 | 支持产品组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| 投资组合规划 | 关键交付物 | 关键交付物 | 高级架构 | 高级架构 |
| 节目策划 | 关键交付物 | 关键交付物 | 高级架构 | 高级架构 |
| 利益实现 | 关键交付物 | 关键交付物 | 重要的可交付成果和卓越的架构 | 高级架构 |
| 风险缓解 | 关键交付物 | 关键交付物 | 重要的可交付成果和卓越的架构 | 高级架构 |
| 架构合约 | 重要的可交付成果 | 关键交付物 | 关键交付物 & 高级架构 | 关键交付物 & 高级架构 |
| 实施策略 | 高级架构 | 高级架构 | 高级架构 | 高级架构 |
| 架构路线图类型 1：热图 | 高级架构 | 高级架构 | 高级架构 | 高级架构 |
| 架构路线图类型 2：生命周期图 | 高级架构 | 高级架构 | 高级架构 | 高级架构 |
| 架构路线图类型 3：依赖关系 | 高级架构 | 高级架构 | 高级架构 | 高级架构 |
| 架构路线图类型 4：场景 | 高级架构 | |||
| 过渡架构 | 高级架构 | 高级架构 | 高级架构 | 高级架构 |
| 差距与解决方案 | 高级架构 | 高级架构 | 高级架构 |
企业架构用例的实施计划技术
实施计划技术为不同的 企业架构用例.根据用例的不同，企业架构师可以更有效地帮助其利益相关者使用不同的技术。
虽然每个企业架构用例都与变化有关，但变化的类型和驱动因素是不同的。
| 战略变革 | 增量变化 | 提高成本 | 提高质量 | 提高企业敏捷性 | 降低技术风险 | IT 现代化 | 数字化转型 | 应用程序组合合理化 | 采集集成 | |
| 投资组合规划 | 批判的 | 有用 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 批判的 | ||
| 节目策划 | 批判的 | 很有用 | 有用 | 有用 | 批判的 | 很有用 | 批判的 | 批判的 | 批判的 | 批判的 |
| 利益实现 | 批判的 | 很有用 | 批判的 | 批判的 | 批判的 | 很有用 | 很有用 | 批判的 | 有用 | 批判的 |
| 风险缓解 | 批判的 | 很有用 | 批判的 | 批判的 | 批判的 | 很有用 | 很有用 | 批判的 | 有用 | 批判的 |
| 架构合约 | 批判的 | 有用 | 有用 | 有用 | 批判的 | 批判的 | 有用 | 批判的 | 批判的 | 批判的 |
| 实施策略 | 批判的 | 有用 | 有用 | 有用 | 批判的 | 批判的 | 批判的 | 批判的 | 有用 | 有用 |
| 架构路线图类型 1：热图 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 |
| 架构路线图类型 2：生命周期图 | 批判的 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 批判的 |
| 架构路线图类型 3：依赖关系 | 批判的 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 批判的 |
| 架构路线图类型 4：场景 | 有限使用 | 有限使用 | 有限使用 | 有用 | ||||||
| 过渡架构 | 批判的 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 有用 | 批判的 | 有用 | 批判的 |
| 差距与解决方案 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 | 有用 |
将企业架构原则应用于实施计划制定
您的架构原则将推动和约束您的实施计划。我们的咨询实践确定 每个企业架构师都应该知道的 7 条架构原则.下表提供了一个简单示例，说明实施计划如何受到高级架构的约束。
任何不符合卓越架构的文字和精神的实施计划都需要被 企业架构治理 并返工。
| 实施计划的含义 | |
| 不要与成功混为一谈 | 所有的变化都需要评估它是否会损害当前的成功。需要限制潜在的改进以确保维持基线。 |
| 专注于卓越 | 变革必须有重点。必须质疑所有与企业价值没有直接关系的变化。使用支持卓越的价值定义来评估变革的潜在价值。
不要害怕将不能提高企业卓越性的变化识别为“无价值。 |
| 为什么不是一个？ | 需要挑战造成重复的变化，减少价值交付。
消除重复的更改需要增加价值交付。 |
| 数据是一种资产 | 确保不会以降低数据资产价值的方式放弃对数据模型的控制。 |
| 系统在我们工作的地方工作 | 工作地点和工作方式是衡量价值的基础。任何不能满足位置和风格需求的变化都会降低价值传递。 |
| 无痛用户体验 | 需要审查变更成本，以确保正确评估用户影响。仔细查看与潜在收益相比的变化影响。您将始终为影响付出代价，而您可能无法获得预期的收益。 |
| 自助服务 | 自助服务是一种企业价值衡量标准。通过基线、过渡和目标状态查看自助服务交付。调整成本和收益评估，以奖励供应自助服务以及惩罚和损害现有自助服务。你总是为损坏付出代价。你可能会得到好处。 |
TOGAF 阶段 F 如何与敏捷开发保持一致？
每个实施计划都将为敏捷开发提供多重约束和指导。我们看 企业架构和敏捷开发 在四个领域相交。有四个区域有交叉点：
- 定义敏捷方法
- 指导 sprint 中的积压工作
- 限制 sprint 中的选择
- 解决交叉产品依赖
实施计划将显着影响敏捷方法的定义。例如，实施战略模型将强制或禁止使用敏捷开发。
过渡状态和预期收益将为产品开发或产品发布提供信息，这将指导积压工作。
TOGAF Phase F 如何实现企业敏捷性？
企业敏捷性 是您的组织应对意外情况的能力。实施计划符合预期。强大的计划能力可帮助您应对意外情况。企业敏捷性模型与收集信息和做出解决决策的能力直接相关。这些是计划技能。
企业敏捷模型
- 警觉性——你能发现机会和威胁吗？
- 可访问性——您能否及时访问相关信息以做出回应？
- 果断——你能决定使用可用的信息吗？
- 敏捷性——你能在可用的时间内实施你的决定吗？
- 灵活性——您正在采取哪些措施来减少行动障碍？
