TOGAF® ADM D 阶段——开发技术架构

TOGAF ADM D 阶段技术架构可交付成果

D 阶段的一个核心成果是技术架构。这是完整的企业架构的一部分。因此，以迂回的方式，TOGAF ADM 阶段 D 有五个有用的可交付成果：

1. 构成技术架构的模型
2. 当前和目标技术架构之间的差距
3. 填补空白的候选工作包
4. 候选架构规范，可让您管理未来的架构开发和实施
5. 对业务架构、应用架构、数据架构和安全架构的影响

永远记住，您正在寻求改善组织。改进需要改变。这种变化带来了价值。可以衡量改变的价值和成本。不确定性总是会降低潜在价值。当成功不确定时，成本会成倍增加。极少的不确定性将消除预期。

大多数时候，当我们谈论技术架构时，我们指的是模型和架构规范。不同的模型将解释整个基础设施的不同方面。模型和所需的更改共同构成了技术架构。

在查看不同的模型类型时，请记住相同术语的许多用途。我们再怎么强调都不为过，以至于您应该放松对模型的标签。你称之为功能分解模型的东西，别人会称之为服务。我们的企业架构咨询关注的是目的，而不是模型的名称。您可以将其称为功能分解、系统模型或服务模型。我们只关心模型的目的——你想学习什么，你的模型是否有效地解释了实际工作的这方面是如何工作的？

D阶段技术架构完成

所有 TOGAF ADM 阶段都有信息输入和活动来开发您需要的知识。阶段 D 的结果是开发候选技术架构。

TOGAF 10 TOGAF 系列指南中的表格：企业架构师开发架构指南

D相裸骨

在阶段 D，技术架构师的工作是确定需要对技术进行哪些更改以使信息系统能够支持企业。听起来很简单。您需要做的就是了解组织正在努力改进的内容、不足之处以及必须改变的地方。

D阶段的基本框架是：

• 了解基础设施组合如何实现价值获取

组织在做客户愿意支付更多费用的事情时创造价值。当材料发生变化、提供服务或使用信息时，通常会产生价值。铁矿石到钢铁、天气警报交付，或零件、订单和制造能力创建生产订单。

技术通常起辅助作用。它使人和应用程序能够产生价值。作为支持功能，我们优化效率。通过了解所需的最低服务来回答关键问题。

• 了解如何交付基础设施

我们过去需要拥有和运营我们的技术。借助公共云 PaaS 提供商，我们可以运营不拥有任何技术的全球可扩展组织。大多数组织将混合拥有他们拥有和运营的基础设施、他们选择其他人运营的基础设施以及一组基础设施服务。

• 了解成本、复杂性和刚性的来源

每个基础设施组合都存在刚性问题。基础设施很难改变。复杂性和刚性会产生成本和复杂性。您的基础设施看起来像一个复杂的手表。一个由几乎随机的零件组装而成的。改变一件事通常会在整个投资组合中产生级联变化。

技术架构必须降低刚性以实现 企业敏捷性.您必须优化核心基础设施组合，以降低持续成本和复杂性。争夺公共云 PaaS 只是为了购买一些敏捷性。 了解 ITFM 维护数字产品和 IT 服务的成本模型至关重要。

• 了解如何选择基础设施

有四种基础架构模型：PaaS、企业系统、专业系统和定制开发。每个都有不同的成本和优化模型。您需要在正确的地方应用正确的基础设施采购模型。

• 了解基础设施的期望

有时我们需要一个通用的基础设施服务。有时我们需要专业的硬件。大多数时候，我们需要一些没有太多开销的东西。我们利用其中的概念和属性 能力模型 指导有关我们技术架构的选择。我们的业务架构能力评估指南具有一组易于调整的属性。

• 知道如何使用基础设施

选择的接口是什么？您是选择使用行业标准还是进一步使用专业界面？你用抽象来掩盖接口吗？

然后是运营基础设施。运营预期如何？正常运行时间或吸收组件故障的能力如何？能够更改基础架构的要求是什么？

• 为了提供最佳的基础设施组合，必须做出哪些改变？

我们开发技术架构来改善组织。基础设施变化的步伐和现实意味着大多数变化都是不周期的。当前的业务变更必须使用现有的基础架构。作为技术架构师，您经常致力于 企业敏捷模型 - 灵活性。如果没有先发制人的工作来减少行动障碍，您的组织就会受到意想不到的变化的限制。

人们想要做出的大多数改变都只是修修补补。就六西格码而言，它是局部优化。使系统的一小部分变得更好，即使是以整个系统为代价的。作为技术架构师，请使用 TOGAF ADM 阶段 D 中的指南来关注推动有意义的企业敏捷性、成本改进或价值创造的重大变化。

D阶段的三个完成要素：

• 首先，必须改变什么？服务、执行者、界面、操作、外包、内包或自动化的变化。这些都是变化。我们这样做是为了改善组织。寻求改善您的基础设施组合。
• 第二，什么时候必须改变？有依赖关系吗？前置条件如何？您是否正在为以后的更改更改设置阶段？
• 第三，你怎么知道改变是否成功？您对成功的治理测试是什么？你将如何保护价值？

利益相关者自己对所有架构更改的批准。技术架构师负责用他们理解的术语来描述变化。就解决他们的担忧而言。以及提供治理测试，以便利益相关者可以指导变更项目。

TOGAF D 阶段技术架构可交付成果和企业架构目的

开发企业架构有四个核心目的。不同的阶段 D 可交付成果在每个目的中具有不同的重要性。

表来自 TOGAF 框架 TOGAF 系列指南：企业架构师开发架构指南

候选技术架构

开发企业架构有四个核心目的。不同的模型在每个目的中具有不同的重要性。

>>> 跳转到常见的 技术架构模型

候选技术架构路线图组件

最小的变化是什么？如果您正在评估更改基础架构供应商，则不太可能发生重大变化。如果您要从通用企业系统更改为专业基础架构，那么基础架构提供商模型中的组件和规范更改就是路线图候选。永远不要忘记所有的级联变化。切换到专业基础架构将需要对整个业务和应用程序架构进行更改。即使只是操作专业硬件的团队发生变化。

我们经常使用一个 基础设施系统模型 总结变化。系统模型为计划和执行对话提供了足够的抽象。我们建议使用分数和工作包来解释更改。有关使用分数的更多信息，请参阅 业务架构能力评估指南.

我们使用所有架构路线图组件 TOGAF 阶段 E - 架构路线图.

候选技术架构需求规范

解释对基础设施设计者、购买者和实施者的限制。解释你将如何评估改进。

我们经常使用分数和简化语句来描述需求。需求可以是自动化的衡量标准，也可以是该基础设施将是公共云 PaaS 或专业硬件的声明。这些要求用于指导和控制 TOGAF 阶段 G 中的变更项目。

技术架构师在 D 阶段的作用是什么？

我们期望技术架构师领导 TOGAF 阶段 D 并交付域架构。他们必须开发能够显示缺陷根源的模型。他们必须运用他们的模型来展示改变如何克服缺陷。我们希望他们通过权衡分析来领导利益相关者、主题专家和其他领域架构师。

技术架构师必须与业务架构师和应用程序架构师密切合作。技术架构通常会导致其领域的缺陷。同样，消除技术架构中的复杂性和僵化通常需要在那里进行更改。

我们希望技术架构师能够关闭业务架构。他们必须了解 运营模式 以及能力和自动化属性 能力模型.我们也希望他们能理解 应用开发模型，任何的能力和自动化属性 应用系统模型, 和 数码产品模型.

>>> 跳转到常见的 业务架构模型 和常见的 应用架构模型

>>> 跳转到常见 技术架构模型

没有技术架构师，企业架构团队就无法成功。现代数字企业看起来只是在软件上运行。它们在基础设施上运行。没有基础设施，什么都不会发生。薄弱的技术选择将削弱业务敏捷性和价值创造。技术架构师专注于技术领域。如果没有有效地与他们合作，他们就无法完成他们的工作 业务架构师、数据、技术和安全架构师。

企业架构师在阶段 D 中的角色是什么？

企业架构师在 TOGAF 阶段 D 中具有相同的角色。企业架构师需要填写任何领域架构师需要帮助的地方。要么开发技术架构，解释其他领域，要么守护价值。许多技术架构师不会看到来自或去往业务架构的影响。或者他们可能没有用安全架构师可以采取行动的术语来表达要求。

企业架构师最重要的角色是跨越边界。无论它们是领域、技能还是权限边界，企业架构师都需要跨越它们。