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 中扮演着同样的角色。企业架构师需要填补任何领域架构师需要帮助的地方。无论是开发技术架构、解释其他领域，还是守护价值。许多技术架构师看不到业务架构带来或将带来的影响。或者，他们可能无法以安全架构师能够采取行动的方式清晰地表达需求。.

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