TOGAF-第三章 ADM周期的关键技术和交付物

2023-01-27  本文已影响0人  侯文_ad82

本章将帮助你理解ADM周期的各类关键技术和交付物。


image.png
image.png

3.1 裁剪过的架构框架

选择并裁剪框架是一个架构项目的实际起始点。比起从零开始创建框架，基于TOGAF建立框架有如下一些优点：

但是，在TOGAF可以被有效地用于架构项目之前，在若干层次上对其进行裁剪是有必要的，而且应在预备阶段进行。
首先，裁剪TOGAF模型并将其集成到企业中是非常有必要的。这种裁剪包括与项目和流程管理框架的集成、术语对的定制、展现风格的确立、架构工具的选择、配置和部署等。所采用的任何框架的形式和细节也应该与企业其他的环境因素相协调，如文化、利益相关者、企业架构的商业模式以及架构能力的现有水平等。
一旦框架已经根据企业的情况进行了裁剪，对其进行进一步的裁剪以适应特定的架构项目就变得很有必要了。这个级别的裁剪将选定适合的交付物和制品，来满足该项目及其利益相关者的需要。
以下是一个裁剪过的架构框架中的典型内容：

3.2 企业架构的组织模型

预备阶段产生的一个重要交付物是企业架构的组织模型。
为了能成功地使用架构框架，必须得到企业内部合适的组织、角色和职责的支持。其中特别重要的是，要划定不同的企业架构从业者之间的界限、并明确跨越这些界限的治理关系。
企业架构的组织模型的典型内容包括：

3.3 架构原则

本节的文档是预备阶段的初始输出。它们是对正在被开发的架构的一套通用规则要求和知道策略。关于指导策略和一组具体的通用架构原则，参见TOGAF9第三部分中的“架构原则”。本节文档推荐的内容分别是业务原则、数据原则、应用原则和技术原则。

3.3.1 确立架构原则

一般由首席架构师与企业的CIO、架构委员会和其他关键的业务利益相关者一起，共同确立架构原则。
如下的一些因素一般会影响架构原则的确立：

3.3.2 定义架构原则

根据组织的不同情况，可以在如下任一或所有三个级别上建立原则：

3.3.3 原则的质量

辨识出一套好的原则有五个标准。


image.png

3.3.4 使用架构原则

架构原则是用来总结关于企业如何使用和部署IT资源和资产的基本事实的。这些原则可以以如下的不同方式被使用：

原则之间是相互联系的，并且必须成套地使用。有时原则间会存在一定的冲突，例如，“可访问性”原则和“安全”原则。各个原则必须在“所有其他条件都相同”的条件下被考虑。有时需要在某一特定问题上决定优先考虑哪个原则。所有这些决定的依据必须被记录。原则看上去是不言自明的事实，但并不意味着再组织中原则能被实际地遵守，即使是对原则有着口头上的确认。虽然在原则的声明中没有规定具体的触发措施，但对原则的违反一般都会引起运营问题，并会制约组织完成其使命的能力。

3.4 业务原则、业务目标和业务驱动力

一份关于业务原则、业务目标和业务驱动力的声明通常限于架构活动再企业的其他地方被定义。作为预备阶段的输出，它们将被重新声明，并作为阶段A：架构愿景的一部分被再次审查。阶段A的审查活动是为了确保当前的定义正确且清晰。TOGAF9第三部分：ADM指引和相关技术中包含了一个含有八项业务原则的集合的例子，可以作为一个有用的起点。
TOGAF对于这一交付物的内容没有定义，因为其内容和结构可能会随不同组织发生相当大的变化。

3.5 架构存储库

架构存储库在企业中充当了与架构相关的所有项目的保存区域的作用。存储库使项目能够管理其交付物、定位可重用的资产，并向利益相关者和其他利益方发布输出物。
对于架构存储内容的描述，参见6.2节。架构存储库中的一般内容包括：

3.6 架构工具

作为预备阶段的一部分，架构师应选择并实施能支持架构活动的工具。TOGAF并不要求或推荐任何特定的工具。对于选择架构工具来开发各种所需的架构模型和视图，TOGAF提供了一套建议的评估标准。这些标准在TOGAF9第五部分，第42章进行描述。

3.7 架构工作请求书

这是一份由赞助组织发给架构组织的文档。由它触发架构开发周期的开始。它是在架构组织的协助下、作为预备阶段的一项输出而被创建的。架构工作请求书也可以作为被批准的架构变更请求的结果而被创建，或是根据来源于迁移规划的架构工作的参考条目而被创建。
总的来说，这份文档中的所有信息都应该是比较概要的。这份文档的建议内容如下：

  1. 赞助组织
  2. 组织使命的声明
  3. 业务目标（包括变化）
  4. 业务的战略计划
  5. 时间限制
  6. 业务环境的变化
  7. 组织的约束
  8. 预算信息和财务约束
  9. 外部约束和业务约束
  10. 对现有的业务系统的描述
  11. 对现有的架构/IT系统的描述
  12. 对开发组织的描述
  13. 对开发组织可用资源的描述

3.8 架构工作说明书

架构工作说明书作为阶段A的一份交付物被创建，实际上它是架构组织和架构项目赞助者之间的一份契约。这份文档是对输入架构工作请求书后的响应（参见3.6节）。它应当描述一份全面的计划，说明对架构工作有什么样的请求，并建议对已识别出问题的解决方案，将如何通过架构流程来进行开发。这份文档的建议内容如下：

  1. 工作名称的说明
  2. 对项目的请求和背景
  3. 项目的描述和范围
  4. 架构愿景的概要或总体介绍
  5. 管理的方法
  6. 范围变更的流程
  7. 各类职责和交付物
  8. 架构被接收的标准和流程
  9. 项目计划和时间表
  10. 来自企业连续系列的支持（重用性）
  11. 签署的正式批准

3.9 架构愿景

架构愿景在阶段A被创建，它提供了一份最终的架构输出的高层的、愿景性的视图。建立愿景的目的是从一开始就对架构应该有什么样的预期结果达成共识，从而使架构师能够聚集在关键的领域来验证其可行性。架构愿景也通过给出一个完整架构定义的总体汇总版本，来支持和利益相关者之间的沟通。
业务场景是一种对于本阶段适合而且重要的技术，可在创建架构愿景文档的过程中被使用。
架构愿景文档的建议内容如下：

  1. 问题描述：各利益相关者和他们的关注；需要解决问题/场景的列表。
  2. 具体的目标
  3. 环境和流程模型：对过程的描述；流程步骤与环境的映射；流程步骤与人员的映射；信息流。
  4. 施动者及其角色和职责：人员施动者和角色；计算机施动者和角色；需求
  5. 结果架构模型：约束；IT原则；需求与架构的映射

3.10 利益相关者管理

利益相关者管理是一门重要的学问，成功的架构师可以使用它来赢得他人的支持。成功地管理利益相关者帮助了架构师确保他们的项目能取得成功，否则的话就会失败。这项技术应当在阶段A中被使用，用来识别出架构项目的关键参与者，这些写参与者在后续的各个阶段中会被不断地更新。这个过程的输出形成了沟通计划的起点（参见3.11节）。
成功地管理利益相关者有益于以下的几个方面：

  1. 可以在项目早期就识别出最优权力的利益相关者，并用他们的输入来确定架构的概貌：这就确保了他们的支持并提高了架构模型的质量
  2. 来自于最有权力利益相关者的支持将帮助架构项目获取到更多的资源：从而使架构新项目更有可能成功
  3. 通过在早期就与利益相关者进行频繁的沟通，架构团队可以确保他们能充分地理解架构开发的整个过程，以及企业架构的好处，这将意味着他们会在必要的时候更积极地支持架构团队
  4. 架构工作团队更有可能获得对架构模型和报告的有效反应，并将必要的行动编入计划，以充分利用积极的反应，同时避免或处理掉任何消极的反应

3.10.1 利益相关管理过程的- - 步骤1：识别利益相关者

第一项任务是，确定哪些人是企业架构的主要利益相关者。一般可识别出5大类的利益相关者。


image.png

3.11 沟通计划

企业架构含有大量复杂并相互关联的信息。在合适的时间、向合适的利益相关者有效沟通有针对性的信息，是企业架构成功的一个关键因素。在阶段A制定架构沟通计划，对于能在一个有计划、被管理的过程中进行沟通提供了保障。
沟通计划的内容一般包括如下的一些方面：

  1. 识别出的利益相关者，并通过沟通需求对其的分组
  2. 确认的沟通的需要、与架构愿景相关的关键信息、沟通的风险和关键成功因素
  3. 确认的沟通机制，用于与利益相关者间的沟通、并允许其访问架构信息，如通过会议、新闻通讯、存储库等
  4. 确认沟通时间表，用于展示将在什么时候、什么地方、与哪组利益相关者进行什么样的沟通

3.12 业务转换的准备就绪评估

业务转换的准备就绪评估这项技术在阶段A使用，用来评估并量化一个组织对接收变更准备就绪的情况。了解组织对接收变更准备就绪的情况、发现问题并解决这些问题，是成功地进行架构转换的一个关键步骤。建议这项评估由企业员工、业务线和IT规划人员来共同完成。
推荐的活动包括：

  1. 决定将会影响组织的准备就绪因素
  2. 使用成熟度模型来展现这些准备就绪因素
  3. 评估每个准备就绪因素的风险，并确定缓减风险的改善行动
    将发现记录到能力评估的结果（参见3.13节）中，并在后续将风险缓减行动纳入到实施和迁移计划中去。

3.13 能力评估

在着手进行详细的架构定义之前，很有必要了解一下企业的基线和目标能力水平。这些对能力的评估将首先再阶段A进行，并在阶段E进行更新。可以从以下几个方面去评估企业的能力：

  1. 业务能力的评估结果，包括：业务的能力；每种能力的绩效水平的基线状态评估结果；每种能力的绩效水平的未来期望状态；每种能力如何被实现的基线状态评估结果；每种能力应当如何去实现的未来期望状态
  2. IT能力的评估结果，包括：变更流程的基线和目标成熟度水平；运营流程的基线和目标成熟度水平；基线能力和能力大小的评估结果；因执行架构项目对IT组织可能产生的影响的评估结果。
  3. 架构成熟度的评估结果，包括：架构治理的流程、组织、角色和职责；架构技能的评估结果；架构存储库中景观定义的广度、深度和质量；架构存储库中标准定义的广度、深度和质量；架构存储库中参考模型定义的广度、深度和质量；对于重用性潜力的评估。
  4. 业务转换的准备就绪评估结果，包括：准备就绪因素；每一个准备就绪因素的愿景；当前和目标的准备就绪的水平；准备就绪的相关风险。

3.14 风险管理

业务转换风险及缓减活动的识别首先在阶段A被确定。风险管理在TOGAF9第三部分、第31章描述，它是一种在实施架构项目时用于缓减风险的技术。它包括一个由一下活动组成的风险管理过程：

  1. 风险分类
  2. 风险识别
  3. 初始风险评估
  4. 风险缓减和残留风险评估
  5. 风险监控
    建议将风险缓减活动纳入到架构工作说明书中。

3.15 架构定义文件

架构定义文件是项目过程中创建的核心架构制品的可交付物容器，这份文档跨越了所有的架构领域（业务、数据、应用和技术），并检查了架构的所有相关状态（基线状态、各过渡状态和目标状态）。
它首先在阶段B被创建，最初只包含与业务架构相关的制品，接下来在阶段C被更新加入信息系统架构的制品，接着在阶段D被加入技术架构的制品。
架构定义文件是架构需求规格的伴随物，它们互为补充：

  1. 范围
  2. 目标、目的和约束
  3. 架构原则
  4. 基线架构
  5. 架构模型（建模的每种状态）。包括：业务架构模型、数据架构模型、应用架构模型和技术架构模型
  6. 架构方法的依据和论证
  7. 与架构存储库的映射：与架构景观的映射；与参考模型的映射；与标准的映射；可重用性的评估结果
  8. 差距分析的结果
  9. 影响分析的结果
    以下各节将详细描述没类架构。

3.15.1 业务架构

业务架构在阶段B被开发。在架构定义文件中应阐明的与业务架构相关的主题如下：

  1. 基线业务架构。如果适当的话——这是对现有业务架构的描述
  2. 目标业务架构。组织结构：识别出各个业务场所并将其关联到相应的组织单元上；业务职能：将大的职能区域逐步地、递归地连续分解为各子职能；业务服务：企业及其各业务单元向其客户提供的服务，包括内部的和外部的；业务流程，包括其测度和交付物；业务角色，包括对技能需求的开发和修订；业务数据模型；组织和职能间的相互关系：以矩阵报告的形式，将业务功能与组织单元进行关联。
  3. 选定视点的相应视图，用来处理关键利益相关者关注问题

3.15.2 信息系统架构

信息系统架构在阶段C被开发。在架构定义文件中应阐明的与信息系统架构相关的主题如下：

  1. 基线数据架构，如果适当的话
  2. 目标数据架构，包括：
  1. 选定视点相应的数据架构视图，用来处理关键利益相关者关注的问题
  2. 基线应用架构，如果适当的话
  3. 目标应用架构，包括：
  1. 选定视点相应的应用架构视图，用来处理关键利益相关者关注的问题

3.15.3 技术架构

技术架构的开发是阶段D的一部分。在架构定义文件中应阐明的与技术架构相关主题如下：

  1. 基线技术架构，如果适当的话
  2. 目标技术架构，包括：
  1. 选定视点的响应视图，用来处理关键利益相关者关注的问题

3.16 架构需求规格

架构需求规格提供了一套量化的声明，概要地说明了为了符合架构，实施项目必须做到什么样的程度。架构需求规格一般会成为一份实施契约或更详细的架构定义契约的主要组成部分。
如上所述，架构需求规格是架构定义文件的伴随物，它对架构定义文件进行了补充，提供了定量的视图。
架构需求规格通常包括以下内容：

  1. 可进行有效度量的测度
  2. 架构需求
  3. 业务服务契约
  4. 应用服务契约
  5. 实施指导原则
  6. 实施规格
  7. 实施标准
  8. 可互操作性需求（参见3.16.4节）
  9. 约束
  10. 假定

3.16.1 业务架构需求

业务架构需求在阶段B填入到架构需求规格中，包括如下内容：

  1. 差距分析系的结果
  2. 技术需求
    初始的一套技术需求应该来自阶段B（业务架构）的输出。这些需求会驱动随后的技术架构阶段的工作，技术架构阶段会识别出这些需求对其他架构领域工作的影响，并对其进行分类，确定其优先级；例如，使用一个依赖性/优先级矩阵（比如，该矩阵可指导在事务处理速度与安全性之间的权衡）；列出希望创建的具体模型（比如，一Zachman框架初始模型表达的模型）。
  3. 被更新的一些业务需求
    业务场景技术可用来发现和记录这些业务新需求。

3.16.2 信息系统架构新需求

信息系统架构需求在阶段C填入到架构需求规格中，包括以下内容：

  1. 差距分析的结果
  2. 数据可互操作性需求
  3. 应用可互操作性需求
  4. 业务架构中可能需要变更的区域，以符合数据架构和应用架构中的变化
  5. 对将被设计的技术架构的约束
  6. 更新的业务需求，如果适当的话
  7. 更新的应用需求，如果适当的话
  8. 更新的数据需求，如果适当的话

3.16.3 技术架构需求

技术架构需求在阶段D填入到架构需求规格中，包括如下内容：

3.16.4 互操作性需求

可互操作性的意图体现在整个ADM的周期中。TOGAF9第三部分、第29章给出了定义和建立可互操作性需求的一套指导策略。

3.17 架构路线图

架构路线图列出了变迁的各个增量，并把它们放在一条时间轴上，展示了从基线架构向目标架构的演进过程。架构路线图是过渡架构的关键构件，并在ADM从阶段B到阶段F的过程中，以增量的方式被开发。
以下是架构路线图中包含的典型内容：

  1. 项目列表：每个项目的名称、描述和目的；实现目标架构的项目的优先顺序列表
  2. 面向时间的迁移计划：确认的迁移的效益（包括与业务需求的映射）；各个候选迁移方案的预估成本
  3. 实施建议：项目有效性的标准/测度；风险和相关问题；解决方案构建块，对其的描述和模型

3.18 业务场景

对于识别和阐明隐含在新的业务功能中、满足关键业务驱动力的业务需求，以及隐含的架构修，ADM有其自己的方法。这个过程方法被叫做“业务场景”。
业务场景是对业务问题的一种描述方式，使需求能够在整个问题的上下文中，在彼此的关系中被看待。如果缺乏对于背景的描述，解决问题带来的业务价值就会不清晰，潜在解决方案是否适合也会不明确，而且很可能会基于一套不充分的需求来建立解决方案，而这样做是很危险的。
任何大型项目成功的一个关键因素就是它与业务需求紧密联系，并且能明确支持和确保企业实现其业务目标的程度。业务场景就是一种帮助识别和理解企业业务需求的重要技术。
这项技术可以应用在业务架构层次分解的不同细节层次上，并通过迭代的方式被使用。一般来说，业务场景流程包括如下步骤：

  1. 对驱动项目的问题进行识别、记录，并排定其等级
  2. 通过概要的架构模型来记录发生问题情形的业务和技术环境
  3. 识别并记录期望的目标；成功处理问题后的预期结果
  4. 识别人员实施者及其在业务模型中的位置、人员参与者及其角色
  5. 识别计算机施动者及其在技术模型中的位置、计算元素及其角色
  6. 对于每一个施动者，确定并记录其角色、职责和测量成功的测度、每个施动者需要的场景，以及正确处理该场景的预期结果
  7. 检查上述场景对于开展后续架构工作是否适合，仅在必要时进行完善

3.19 差距分析

差距分析技术在ADM周期中被广泛地应用，用来验证正在被开发的架构。它通常是一个阶段的最后一个步骤。其基本的出发点是强调基线架构和目标架构之间的差异，即被故意忽略、意外遗漏或尚未定义的条目。
其步骤如下：

  1. 绘制一个矩阵，将所有基线架构的架构构建块（ABBs）放在垂直轴，所有目标架构的架构构建块（ABBs）放在水平轴。
  2. 在基线架构轴的最后一行增加一行，标示为“新增的架构构建块”，在目标架构轴的最后一列增加一列，标示为“出去的架构构建块”。
  3. 如果一个架构构建块同时存在于基线架构和目标架构中，在价差单元格将其标记未“已包括”
  4. 如果基线架构中的机构构建块在目标架构中出现缺失，检查每一个缺失的架构构建块。如果确实应该将其除去，在“除去的架构构建块”列合适的单元格中对其进行相应记录。如果不该将其除去，这样就发现了在目标架构中意外遗漏的架构构建块，在“除去的架构构建块”列合适的单元格中对其进行相应记录。如果不该将其除去，这样就发现了再目标架构中意外遗漏的架构构建块，在“除去的架构构建块”列合适的单元格中对其进行相应记录，这些写被一楼的额架构构建块必须在架构设计的下一轮迭代中被恢复并进行处理。

  5. 当某个目标架构中的架构构建块没有出现在基线架构中时，在该构建块所在列和“新增的架构构建块”行的交叉单元格上将其作为差距进行标记，这种差距需要通过开发或外购该构建块的方式进行填补。
    当完成上述步骤后，所有出现在“除去的”列或“新增的”行中都是差距，这些差距要么解释为应该被除去，要么被标记出


    image.png

    差距分析技术应当在ADM的B、C、D、E阶段中使用。

3.20 架构视点

架构师在ADM周期从阶段A到阶段D的各个阶段中，使用视图和视点来开发每个架构领域（业务、数据、应用、技术）的架构。视图是你看到的东西。而视点是从哪儿看；即决定你看到什么的有利位置或角度（一个视点也可以被认为是一种范式）。视点是通用的，可以存储在视点库中供重用。视图对于它为之被创建的架构来说总是具体的。每个视图有描述它的相关联的视点，哪怕该视点是隐含的。
ISO/IEC 42010:2007鼓励架构师明确地定义视点。在视图的内容和范式之间做出这样的区分，乍看起来似乎是一个不必要的负担，但它确实为在不同的架构之间重用视点提供了一种机制。
为了能清楚地说明视图和视点的概念，考虑例1中的场景。这是一个非常简单的机场系统，只有两个利益相关者：飞行员和空中交通管理员。
例1：简单机场系统的视图和视点


image.png

总结例1，我们可以看到，视图可以通过不同利益相关者的角度，如飞行员与控制员的角度，来划分出系统的子集。这种子集可以通过一种被叫做视点的抽象模型来描述，如空中飞行模型与飞行空间模型。视图的这种描述可以通过一种半专门的语言来记录，如“飞行员语言”与“控制员语言”。工具是用来帮助利益相关者的，它们之间通过源于视点的语言进行交互。当利益相关者使用共同的工具是，如飞行员和控制员之间的无线电通信联系，一种共同的语言是必不可少的。

3.21 架构视图

架构视图表现了整体架构，对系统中的一个或多个利益相关者来说具有意义，架构师在ADM周期从阶段A至阶段D的过程中，选择并建立了一套视图，以便可以同所有的利益相关者沟通架构，使其理解架构，并使他们能够验证系统将解决他们关注的问题。5.3节中的概念是在TOGAF中使用架构视图的核心。

3.21.1 在ADM中建立视图

架构师必须做出的关键决定之一，就是决定开发哪些特定的架构视图。
架构师有责任确保架构的完整性（适合使用），即能充分解决其所有利益相关者的关注问题；以及架构的一致性，即能将各个不同的视图联系起来，圆满的协调不同利益相关者之间存在冲突的关注点，并展示在协调过程所做出的权衡（例如在安全性和性能之间）。

3.22 架构构建块

架构构建块是架构的文档描述和模型，来自于按照架构连续系列进行分类的企业架构存储库。它们在ADM的过程中（主要在阶段A、B、C和D）被定义或选择。架构构建块的特点如下：

3.23 解决方案构建块

解决方案构建块（SBBs）与解决方案连续系列有关。它们是企业架构连续系列中被识别出的各个架构的实现，可以被外购或开发。
解决方案构建块首先出现再ADM的阶段E，在第一次考虑特定产品的构建块的时候。解决方案构建块定义了什么样的产品和构件将实现所需的功能，从而定义了实现方式。它们满足了业务需求，与具体的产品或供应商相关。解决方案构建块规格至少应包括以下内容：

3.24 基于能力的规划

在阶段E和F中起到重要作用的是一种根据基于能力规划的原则、确定和规划企业转换的具体方法，这是一种聚焦业务成果的业务规划技术。它是业务驱动和业务导向的，它将各个业务线所必需的力量结合起来，以达到企业期望的能力。它适用于大多数（甚至所有）的企业业务模型，尤其在需要具备快速响应的是潜在能力（例如，应急准备单元），或相同的资源被投入到多种能力中的组织中尤为有用。通常业务场景技术被用于发现和优化对这些能力的需要。
下图基于能力的规划、企业架构和项目组合/项目管理三者之间的关系。


能力、企业结构和项目之间的关系

3.25 迁移规划技术

阶段E和F中介绍了多种支持迁移规划的技术。下面各小节对这些技术进行了描述。

3.25.1 实施因素评估和推论矩阵

创建实施因素评估和推论矩阵的技术在阶段E被使用，用来记录影响架构实施和迁移计划的各种因素。矩阵应包括影响因素的列表、它们的描述和推论（结论），这些推论指出了指定计划时必须考虑的行动或约束。


实施因素评估和推论矩阵

3.25.2 整合差距、解决方案和依赖性矩阵

创建整合差距、解决方案和依赖性矩阵的技术，使架构师能够将各架构领域差距分析结果中所识别出的差距进行分组，评估出可能的解决方案、以及一或多项差距间的依赖关系。在创建工作包时，可将这种矩阵作为一种规划工具。识别出的依赖性关系将驱动E和F中项目和迁移规划的闯将。


整合的差距，解决方案和依赖性矩阵

3.25.3 架构定义增量表

创建架构定义增量表的技术，使架构师能够规划出一系列过渡架构，概要地描述出在特定时间点企业架构的各个状态。


架构定义增量表的范例

3.25.4 企业架构演进状态表

创建企业架构状态演进表的技术，使架构师能够使用技术参考模型（TRM）来展示不同层面架构的建议的状态。
应绘制一份表格，列出企业中用到的所有TRM的服务、各种过渡架构和建议的转换方式。
应当描述所有解决方案构建块（SBBs）的交付和它们对这些服务的影响。并且应对它们进行标识，以展示企业架构进展的过程。在下面的这个例子中，当已经达到目标能力时，将该SBB标记为“新增”或“保留”；当企业能力正过渡到新的解决方案时，将其标记为“过渡”；当能力将被取代时，将其标记为“替换”。


企业架构演进状态示例

3.25.5 业务价值评估技术

这种评估业务价值的技术基于价值指标维度和风险指标维度来绘制一个矩阵。价值指标应当包括如与原则的符合、财务贡献、与战略的一致性，以及竞争地位这样一些标准。风险指标应当包括如规模和复杂性、技术、组织能力，和失败的影响这样一些标准。应对每一个标准分配单独的权重。
指标及其标准和权重应由高级管理人员制定并批准。在选定这些指标前，应首先制定决策的标准，这一点非常重要。


业务价值评估矩阵

3.26 实施和迁移计划

实施和迁移计划再阶段E和F被制定，它提供了实施过渡架构所描述解决方案的进度表。实施和迁移计划包括了时间、成本、资源、效益和实施的各里程碑。
实施和迁移计划的一般内容包括：

  1. 实施和迁移战略
  1. 与其他管理框架间的架构关系
  1. 各项目章程
  1. 实施计划

3.27 过渡架构

阶段E定义了一或多个过渡架构，并将其作为输出。过渡架构展示了企业的递增状态，反映了在基线架构和目标架构之间的各过渡时间段。可使用过渡架构来对各个工作包和项目进行分组，组成一些可被管理的项目组合和项目群组，以清晰说明每个阶段的业务价值。以下是一个过渡架构中的典型内容：

  1. 机会组合
  1. 工作包组合
  1. 里程碑和过渡架构里程碑
  1. 实施因素评估和推论矩阵，包括：
  1. 整合的差距、解决方案和依赖性矩阵，包括：

3.28 实施治理模型

一旦定义了架构，就有必要规划如何在实施过程中对实现了架构的过渡架构进行治理。在已建立了架构智能的组织中，很有可能已经有一个治理框架，但是具体的流程、组织、角色、职责和度量可能需要针对具体的项目进行进一步的定义。
作为阶段F输出而产生的实施治理模型，确保了一个过渡到实施的项目也会平滑地过渡到适当的架构治理中去。实施治理模型的典型内容包括：

  1. 治理的流程
  2. 治理的组织结构
  3. 治理的角色和职责
  4. 治理的检查点和成功/失败标准

3.29 架构契约

架构契约在阶段G：实施治理中被创建。架构契约是在开发团队和赞助者之间，就架构的交付物、质量和目标适用性达成的协议。这些协议的成功实施将通过有效的架构来交付。通过对架构契约的管理实施治理，可以确保：

3.30 变更请求

对架构变更的请求在阶段H：架构变更管理中被考虑。在架构的实施过程汇总，随着越来越多的事实被了解，初始的架构定义和需求有可能不再适合或不足以完成解决方案的实施。在这种情况下，实施项目偏离原有架构方法或请求扩展范围就变得很有必要。此外，外部因素一如市场因素、商业战略的变化和新技术的机会-也会创造扩展和完善架构的机会。
在这种情况下，可提交变更请求以启动新一轮的架构工作周期。
变更请求的典型内容包括：

  1. 被提议的变更描述
  2. 被提议的变更依据
  3. 被提议的变更影响评估。包括：
  1. 引用存储库的号码

3.31 合规评估

一旦定义了架构，就有必要在实施的整个过程中对架构进行治理，以确保最初的架构愿景能被适当地实现，并且确保实施中的所有经验教训都能被反馈到架构流程中去。在阶段G中对实施项目进行定期的、一致性的审查，就提供了这样一种机制，确保了设计和实施的进行能符合战略和架构目的。
合规评估结果的一般内容包括：

  1. 项目的进度和状态的概况
  2. 项目的架构/设计的概况
  3. 已完成架构的检查表:

3.32 需求影响评估

在ADM的整个过程中，有关于架构的新信息在不断的被收集，随着这些信息的收集，新的事实会显露出来，证明架构已有方面的不合理。一份需求影响评估表评估了现有架构的需求和规格，识别除了应该做出的变更以及这些变更的相关影响。
需求影响评估的结果记录了对变更的评估及对架构变更的建议。它的建议内容如下：

  1. 对特定需求的引用
  2. 需求的利益相关者的优先级
  3. 需要被回顾的各个阶段
  4. 确定需求优先级的阶段
  5. 阶段调查的结果和修正的优先级
  6. 对需求管理的建议
  7. 引用存储库的号码
    这些内容通常作为对变更请求的回应而被创建。
上一篇下一篇

猜你喜欢

热点阅读