TOGAF架构开发方法

wend huo 知乎专栏

一、预备阶段（Preliminary）

1、目标

预备阶段的目标是：

对组织的背景和环境进行审查（调研）。
明确企业架构的架构赞助者（出资人）、主要干系人，确定他们的需求和优先级，他们与组织的关系等。
确保所有干系人致力于架构过程的成功。
促使架构赞助者为将要受到影响的业务领域的工作制定需求。
明确受影响的各个企业组织元素，界定其范围。还要为这些元素定义各种约束和假设。
定义组织的“架构足迹”，包括负责执行架构工作的人员及他们的职责。
定义进行企业架构建设的框架和详细方法。
确定一个治理和支持框架，用来在整个ADM过程中为架构治理提供业务流程和资源方面的支持。此种框架将会确保目标架构的适用性（fitness-for-purpose），并对过程中的效能进行评测。
选择和落实用于支持架构活动的各种工具和基础设施。
定义架构原则，这些原则将会成为约束架构工作的一个部分。

2、方法

预备阶段为企业定义在哪里、为什么、谁负责、如何创建架构，以及架构的大体内容，具体包括如下几个主要方面：

确定企业的范围，并借此明确将要从企业架构中获益的各个干系人。
明确采用何种框架（包括如何对框架进行裁剪，从而适合组织的需要），明确组织背景和环境，需要从以下几个方面进行考虑：

①企业架构的商业模型和预算计划。
②与架构相关的干系人以及他们的关注点。
③组织的意向和文化。
④支持变更执行和IT运营的流程。
⑤基线架构景观，包括企业当前的状态以及其景观如何通过文档的形式来表现。
⑥将要使用架构框架的组织的技能和能力。

架构工作需求：业务需求驱动了架构工作的需求和性能指标的制定。这些需求应足够清晰，使得业务输出和资源需求得以被界定，同时简要的业务信息需求及与之相关的企业架构工作策略也将被定义出来。
制定原则：此阶段制定的架构原则会成为日后约束架构工作的各项内容的重要组成部分。
明确组织的管理框架：企业架构开发方法是一种通用的方法，它既可以适用于各种行业，也可以与企业中已经存在的各种管理框架相融合。一般来讲，能够与TOGAF相互协调的管理框架包括业务能力管理、项目组合/项目管理、运营管理和解决方案开发方法。这些框架并不是相互隔绝的，而是相互交叠并组合在一起来为组织提供价值。因而TOGAF也不能仅着眼于IT实现，而应扩展视野，将关注点放到其对整个组织的影响上。这种与组织中其他框架的融合也为组织在引入TOGAF时提出了要求，即组织应根据自身特点对其进行适当的改造。
将各种管理框架进行关联：由于组织中存在着各种作用不同的管理框架和方法，他们与企业架构之间的合作关系应该得到明确的定义。TOGAF规范给出了一张管理框架关系图：

为企业架构/业务变更的成熟度评估进行规划：成熟度的实际水平为组织的变更能力提供了一个战略上的评测以及一系列用于改善组织能力的步骤。TOGAF建议组织应以某现存并且开放的成熟度模型（例如NASICO、美国联邦企业架构成熟度模型等）为基础来定制符合自身需要的成熟度模型，不要凭空创建。

3、输入与输出

在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

当前阶段要执行的各个步骤归纳如下：

确定将受到影响的企业组织的范围。
确定治理和支持框架。
定义并建立企业架构团队和组织结构。
明确并制定架构原则。
选择架构框架，并对其进行定制。
落实相关架构工具。

二、架构愿景（Architecture Vision）阶段

1、目标

确保架构开发循环的进展被管理层认知和支持，并取得管理线的支持。
定义和组织架构开发循环。
验证业务原则、业务目标、组织的战略业务驱动力，以及企业架构的主要性能指标（KPIs）。
定义基线架构的范围，明确组件以及组件的优先级。
定义相关干系人，以及他们的关注点、目标。
定义架构工作所要解决的关键业务需求，以及各项约束。
阐明架构愿景，并定制价值主张。这些价值主张被用来阐述对于业务需求和约束的回应。
创建一个综合性计划，阐明规划进度、资源、财务、沟通、风险、约束、假设和依赖关系，并与企业中的项目管理框架相适合（PRINCE2或PMBOK等）。
确保得到正式批准和执行。
理解与其他并行的企业架构开发循环之间的相互影响。

2、方法

架构愿景阶段是从收到架构工作要求书开始的。组织基于对当前资源及其可用性的评估来界定架构工作范围，以及各种约束。这些约束通常来源于在准备阶段中制定的各项业务原则和架构原则。在架构愿景阶段，组织需要确定这些原则是清晰的，否则需在此阶段对这些原则进行明确的定义。此外，在此阶段所涉及到的方法还包括：

创建架构愿景

架构愿景是架构赞助者向干系人、决策者推广其所提出的能力的绝佳工具。它描述了新的能力如何满足组织的战略和业务目标，及当这些能力实现时，相关干系人所关注的问题是如何得到解决的。架构愿景的创建实际上就是对架构的目标进行明确，并阐明如何通过架构开发来达成这些目标。架构愿景在一个很高的层面上为基线和目标架构做了概要性描述，这一描述应涵盖业务、数据、应用和技术这四个层面（这些层面的具体内容将在后续的相应阶段被逐步细化）。

架构愿景被定义并被记录到架构工作说明书中后，各个干系人对这份架构愿景形成共识会成为重中之重。因为如果没有这份共识，最终的架构是否能够被组织所接受就无从谈起了。共识的获得是通过赞助组织签署架构工作说明书来实现。

业务情景

业务情景方法用于识别和阐明隐含的架构需求和隐藏在新业务能力（用于满足关键业务驱动力的需求）中的业务需求。此技术通过一种循环迭代的方式进行，针对业务架构的各层次化分解部件采用不同级别的详细度进行描述。

3、输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物如下：

4、步骤

在当前阶段中所要执行的各个步骤归纳如下：

建立架构项目
识别干系人、关注点和业务需求
确认并阐述业务目标、驱动力和约束
评估业务能力
评估业务转型准备情况
定义范围
确认并阐述架构原则，包括业务原则
开发架构愿景
定义目标架构价值主张和主要性能指标
明确业务转型风险和缓解措施
开发企业架构计划和架构工作说明书，并确保被批准

三、业务架构（Business Architecture）阶段

1、目标

描述基线业务架构。
开发基于原则、业务目标和策略驱动力的目标业务架构，描述产品、服务策略，以及业务环境在组织、功能、过程、信息和地理这些方面的内容。
分析基线和目标业务架构之间的差距。
选择和开发相关的架构视角，通过这些视角解答干系人的关注点。
选择视角相关的工具和技术。

2、方法

业务架构是其他（数据、应用和技术）架构工作的前提条件。业务架构是用来向干系人阐述业务价值和投资回报的必不可少的工具。

在实践过程中，业务架构的关键元素也许已在其他工作中被明确。在这种情况下，组织就需要验证和更新当前已经文档化的业务战略和规划，并/或在已经明确的业务驱动力、业务战略、目标与架构开发工作相关的特定业务需求之间建立关联。在另外一种情况下，业务架构工作也许并没有或者很少被执行，这就需要架构团队研究、验证架构将要支持的各个关键业务目标和流程，并获得相关干系人的认同。

不论处在以上哪种情况，TOGAF ADM的业务情景技术，或者是其他用来阐明关键业务需求以及为IT架构指明其技术需求的方法，都需要被纳入到架构师的工具箱之中。

需要注意的是，在架构活动中应尽量重用各种已经存在的材料，并且针对信息的收集和分析也应该依据架构工作的范围而采用那些能够促成明智决策的信息。如果架构活动关注业务流程的定义，组织需要在流程方面进行很多细致的工作。而如果关注点更着重于其他领域（数据/信息、应用系统和基础设施）中的目标架构，那么组织就需要构建一幅无需包含众多非必要细节的全景图。

此外，在此阶段所涉及到的方法还包括：

开发基线描述

企业中已有的架构描述可以作为基线描述的基础。这些输入可能在架构愿景阶段已被用来开发架构愿景，但对于基线描述应该也是够用的。如果这些描述并不存在，组织就需要从各种渠道收集这些信息进。通常是采用自上而下的方法开发目标架构，而对基线描述来说，对当前状态的分析经常是自下而上的，特别是当只有很少或没有架构资产存在时。在这种情况下，架构师需要记录关于高层次框架的工作假设，并逐步收集能够将这些工作假设转变为现实的证据。

业务建模

业务模型是架构愿景中各业务情景的逻辑扩展，可将高层次的业务需求细化为更详细的需求。在实践中存在着一系列建模工具和技术可以供组织选择使用，例如：

活动模型（Activity Models）：活动模型也称为业务流程模型（Business Process Model），它描述了与组织的业务活动相关的功能、活动之间进行交换的数据和/或信息（内部交换），以及与模型范围之外的其他活动进行交换的数据和/或信息（外部交换）。活动模型在本质上是具有层次型结构的，它涵盖了在业务流程中所进行的各种活动，以及这些活动的输入、控制、输出和所使用的机制或资源（ICOMs：inputs，controls，outputs，and mechanism/resources），各种用于描述ICOMs之间关系的业务规则也可标注在业务模型之中。
用例模型（Use-Case Model）：该模型既可以用来描述业务流程也可以描述系统功能，并且它可以从用例、与业务流程相关的角色以及组织参与者的角度来对企业的业务流程进行描述。
类模型（Class Models）：此模型与逻辑数据模型相类似，主要用于描述静态的信息以及这些信息之间的关系。除此之外，类模型还可被用来描述信息的行为。与其他各种模型类似，类模型也是可以在多种粒度层次上进行模型建设的。根据建模意图的不同，类模型既可以用来表达各种业务领域实体，亦可以被用来描述各个用于进行系统实现的类。一个业务领域模型表达了关键的业务信息、他们的性质、行为和关系。类模型的描述通常通过类图进行表现，不过更加详尽的说明和信息将被记录在额外的说明文档之中。

以上三种模型都可以通过统一建模语言（UML：Unified Modeling Language）来进行描述。

使用架构资源库

在这一阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与业务架构相关的资源可供使用，特别是在如下几个方面的资源：

组织所在行业的通用业务模型（存储在架构资源库的参考资料库中）。前面提到过的联邦企业架构业务参考模型就是个很好的例子。
与在IT行业发布的通用高层次业务领域（例如电子商务、供应链管理等）相关的业务模型，例如主要用于财会系统建模的REA（Resource-Event-Agent）业务模型和关注于产品设计和供应链交互方面的STEP（Standard for the Exchange of Product model data）框架。
企业特定的构建块（流程组件、业务规则、工作描述等）。
各种适用的标准。

3、输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

在当前阶段中所要执行的各个步骤归纳如下：

建立架构项目
识别干系人、关注点和业务需求
确认并阐述业务目标、驱动力和约束
评估业务能力
评估业务转型准备情况
定义范围
确认并阐述架构原则，包括业务原则
开发架构愿景
定义目标架构价值主张和主要性能指标
明确业务转型风险和缓解措施
开发企业架构计划和架构工作说明书，并确保被批准

四、信息架构（Information System Architecture）阶段

信息架构的建设着眼于支持企业业务架构的各种数据和应用，因而信息架构的建设可以分为针对数据架构和应用架构的建设。下文将针对数据架构和应用架构的建设进行探讨。

1、信息系统架构——数据架构（Information System Architecture——Data）

1）目标

通过一种干系人容易理解的方法数据的类型与来源进行定义。数据架构并不是针对存储系统在逻辑或物理方面的设计，而是对企业相关的数据实体的定义。

2）方法

在数据架构的建设过程中所涉及到方法包括如下几点：

数据架构的主要考虑因素

①数据管理（Data Management）：当企业将要承接大型的架构改造任务时，理解并解决数据管理方面的问题将会是非常重要的。一个结构化且全面的数据管理方法则可促进数据的有效使用。对于数据管理来说，企业或组织需要在如下几个方面进行思考：

定义清楚用来担当企业主数据记录和引用系统的应用组件。
是否存在需要被应用组件遵循的企业级标准？
对业务功能、流程和服务如何使用数据实体要有清晰的认识。
对企业数据实体在何处以及如何被创建、存储、传输和汇报的有清晰的认识。
用于支持应用之间信息交换需求的数据转换的复杂程度如何？
用于支持企业客户和供应商之间数据集成的软件的需求都有哪些？（例如，针对在数据迁移过程中用到的ETL工具和用来评估数据质量的数据分析工具的使用都有哪些需求？）

②数据迁移（Data Migration）：当现存应用被替代后，新应用的数据迁移将会成为一个非常重要的需求。数据架构应该识别出数据的迁移需求，并且能够提供有关数据转换和清洗等级等方面指标。此外，组织还需要确保有一个用于支持企业级数据转换的通用数据定义。

③数据治理（Data Governance）：数据治理确保企业或组织拥有足够的能力来促成数据转换，这包括如下几个方面的内容：

结构：这一维度是关于到企业是否具有必要的组织结构和标准体系来管理数据实体。
管理系统：企业应该具有必要的管理系统，实现对数据实体的整个生命周期的治理。
人员：这一维度表述了企业对于数据转换所需的各种数据相关的技能和角色的需求。如果企业缺乏这样的资源和技能，则需要考虑对现有资源进行培训，或直接从外部获取。

使用架构资源库

在当前阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与数据架构相关的可利用资源，特别是与组织所在行业相关的通用数据模型，例如：

零售行业技术标准组织（ARTS：Association for Retail Technology Standards）为零售行业定义了一个数据模型。
Energistics也已为石油技术行业定义了一个数据模型。

3）输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4）步骤

在当前阶段中所要执行的各个步骤归纳如下：

选择参考模型、视角和工具
开发基线数据架构模型
开发目标数据架构描述
执行差距分析
定义路线图组件
通观整个架构景观来明确和解决相关影响
进行正式的关系人审查
最终确定数据架构
创建架构定义文档

2、信息系统架构——应用架构（Information System Architecture——Application）

作为信息系统架构的另外一个组成部分，应用架构描述了各种用于支持业务架构并对数据架构所定义的各种数据进行处理的应用系统。

1）目标

应用架构建设的目的是定义处理数据并对企业业务进行支持的应用系统。需要注意的是，应用架构的建设并不关注应用系统的具体设计，而是定义企业相关应用系统的种类，以及在管理数据和向用户展示信息方面的需求。这里所说的应用并不是指计算机系统，而是应用系统能力的逻辑分组。

应用系统能力是指管理数据（在数据架构中定义的数据），并对业务功能（在业务架构中定义的功能）进行支持的能力。这些应用和能力的定义并不依赖于特定的实现技术，因而这些定义是相对稳定的，而其实现技术则不然。

2）方法

在当前阶段的各项活动中，架构团队需要考虑架构资源库中是否存在与应用架构相关的可利用资源，特别是如下几个方面的资源：

与组织所处行业相关的通用应用模型，例如由TMF（The TeleManagement Forum）开发的与电信行业相关的应用模型，以及由OMG中的一些领域小组开发的与特定行业（例如医疗保健、交通运输和金融等行业）相关的软件模型。
与通用的高层次业务功能相关的应用模型，例如电子商务、供应链管理等。

除了上述内容之外，应用架构的建设还可以参考如下的内容：

The Open Group也提供了一个集成信息基础设施参考模型（III-RM：Reference Model for Integrated Information Infrastructure），其中包括了一个集成信息基础设施所必须的各种应用级的组件和服务。
电子商务全球化标准（ebXML: electronic business using eXtensible Markup Language）也是可选的工具之一，它的目标是提供一个开放的基于XML的基础设施，从而使得电子化的商务信息可以通过一种可交互的、安全且统一的方式进行全球化的使用。

3）输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4）步骤

在当前阶段中所要执行的各个步骤归纳如下：

选择参考模型、视角和工具
开发基线应用架构描述
开发目标应用架构描述
执行差别分析
定义路线图组件
通观整个架构景观来明确和解决相关影响
进行正式的关系人审查
最终确定应用架构
创建架构定义文档

四、技术架构（Technology Architecture）阶段

1、目标

技术架构建设阶段的目标是将应用架构中定义的各种应用组件映射为相应的技术组件，这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。由于技术架构定义了架构解决方案的物理实现，因而它与实施和迁移规划有着很强的关联。技术架构定义了技术组合的基线和目标视图，以及从基线架构到目标架构的一份详细的演进路线图，并借此识别出在过渡过程中的关键工作包。技术架构是制定架构信息集合（包括业务架构、信息系统架构、技术架构）的最后一步，因而它支持在特定迁移情景中的成本评估。

2、方法

在当前阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与技术架构相关的可利用资源，特别是如下几个方面的资源：

在IT资源库或IT服务目录中记录的现有IT服务。
TOGAF技术参考模型（TRM）。
组织所处行业的通用技术模型。
与通用系统架构相关的技术模型，例如The Open Group中关于集成信息基础设施的参考模型（III-RM）。

3、输入与输出

在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

在当前阶段中所要执行的各个步骤归纳如下：

选择参考模型、视角和工具
开发基线技术架构描述
开发目标技术架构描述
执行差别分析
定义路线图组件
通观整个架构景观来明确和解决相关影响
进行正式的关系人审查
最终确定技术架构
创建架构定义文档

五、机会及解决方案阶段

1、目标

本阶段的目标是：

重新审查业务目标和能力，合并自业务架构阶段到技术架构阶段之间的差距，并通过对各构建块进行分组来表明这些能力。
重新审查并确定企业当前用于适应变更的各个因素和能力。
获得一系列过渡架构，它们可以通过对各种机会的开发利用，来为各构建块的实现提供持续的业务价值。
产生概要性的实施与迁移策略，并取得共识。

2、方法

此阶段是第一个关注于目标架构的实现结构的阶段。这一阶段从企业的业务和技术角度出发，对各个IT活动进行梳理，并将它们在逻辑上纳入到若干个IT投资组合之中，或其他依赖与IT的投资组合的项目工作包之中。为达成目标，企业中业务和IT方面的关键干系人需要通力合作，评估组织的业务转型准备情况，识别出各种机会和解决方案，以及所有的实施约束。在这个过程之中，关注于业务价值、灵活性、相互协调以及妥协将是成功的关键因素。

此阶段的输入涉及颇广，架构师和规划者必须对这些信息进行综合、集成、分析，制定最好的前进路线。存在于架构资源库中的各种构建块和案例会是很好的帮手。此外，前面阶段产出的架构制品（特别是差距分析结果）也需要被综合起来，并对他们之间的依赖关系进行评估，从而得出一条初始的用于目标达成的关键路径。这一过程的总体意图是通过减少创建的构建块的数量，以及缩减在项目管理中的管理开销，来简化转变流程。同时，需要审查和澄清有关共存和互操作的问题，以提供准确的开发和实施指导。此阶段还识别和接受实施风险。此外，被转移的和/或缓解的残余风险。

经过上面的过程，一份高层次的实施和迁移战略（将会成为实施和迁移规划的一部分）被制定了出来。用于在关键路径的基础上（通过依赖分析概括而来的）阐明总体实施方法，并借此将位于此路径上的各工作包在企业架构的背景之下组织成各个项目组合、项目或举措。此外，通过对企业（特别是现存的IT基础设施）进行影响分析，组织可以对进一步的活动进行评估。

最终，从架构愿景阶段到技术架构阶段过程中所产生的各个架构被用来开发出一系列过渡架构。正是这些过渡架构展示了从基线架构到目标架构的步进过程。对于规模较小的变更来说，过渡架构可能表述了从基线到目标的直接过渡，而对于规模较大的变更，过渡架构中就需要涵盖一系列中间阶段了。过渡架构包含了一组统筹并定义良好的构建块，并且这些构建块被分配到各个工作包之中。过渡架构采用增量的方式对这些构建块进行实现，从而为支持企业业务目标的实现提供持续性的业务价值流。虽然过渡架构在定义的时序上看是顺序进行的，但在很多情况下，针对多个过渡架构在不同详细度层面的工作是平行推进的，当一个过渡架构在建设时，另外一个架构可以在同时被设计或规划。

3、输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

当前阶段中所要执行的各个步骤归纳如下：

确定关键的企业变更属性
确定针对实施的业务限制
审查并确定自业务架构阶段到技术架构阶段的差距分析结果
从功能的角度审查IT需求
确定并调和互操作需求
改善并验证依赖关系
确认业务转型的准备情况和风险
制定高层次的实施和迁移策略
识别主要工作包，并进行分组
明确过渡架构
创建项目投资组合和项目章程，同时对架构进行更新

五、迁移规划（Migration Planning）阶段

1、目标

本阶段的目标是：

确保实施和迁移规划与企业中各种管理框架相协调。
通过对每个进行中的成本/业务分析赋予业务价值，来为所有的工作包、项目和构建块进行优先级评定。
最终确定架构愿景和架构定义文档，使其与批准的实施方法一致。
与相关干系人一起确认在机会和解决方案阶段中定义的过渡架构。
创建、演进和监控详细的实施和迁移规划，该规划为在机会和解决方案阶段中定义的过渡架构的实现提供必要的资源。

2、方法

这一阶段的重点在于通过与各项目组合和项目经理的通力合作，来创建一个可行的实施和迁移规划。这一过程中的活动包括评估各种迁移项目之间的依赖性，以及他们的成本和收益，这些按照其优先级排序的项目也正是一份详尽的实施和迁移规划的基础。实施和迁移规划为架构补足了各个项目级的任务，以及其所需要的资源，而且该规划也是企业管理框架发布的规划家族中的一个重要组成部分。这些规划通过紧密的协调合作，确保了业务价值的交付，以及用于完成必要工作的资源的可得性。此外，这一阶段还需要确保所有关注于企业架构但身处企业架构范围之外的组织机构能够了解实施和迁移规划的范围和重要性，以及企业架构对他们的活动所带来的影响。最后，机构的演进循环过程需要被建立起来，从而保证架构的相关性，并且使得在持续的改善过程中所获得的经验教训也被记录下来。

3、输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

当前阶段中所要执行的各个步骤归纳如下：

确认管理框架与实施和迁移规划之间的相互作用
为每个项目指定业务价值
估算资源需求、项目时间和可用性/交付工具
通过进行成本/收益分析和风险验证对迁移项目进行优先级排序
确认过渡架构的各增量或阶段，并更新架构定义文档
生成架构实现路线图和迁移计划
创建架构演进循环，并对受到的经验教训进行记录

六、实施治理（Implementation Governance）阶段

1、目标

本阶段的目标是：

为每个实施计划给予建议。
对涵盖整个实施和部署过程的架构契约进行治理。
在解决方案正在实施和部署时，执行适当的治理功能。
确保实施项目和其他项目与已定义架构一致。
确保各解决方案被成功部署，如同一个计划好的工作方案一样。
确保被部署的解决方案与目标架构一致。
调动各种支持性行动，确保被部署的解决方案长期有效。

2、方法

这一阶段的核心是确保已经被定义的架构在实施和部署过程中与计划的一致性，这不仅仅包括了各个为实现目标架构而制定的项目，还包括那些在企业当前正在进行的项目。为了达到这个目标，所有与实施项目的成功管理相关的信息都要在这一阶段中被组织起来，并且组织特定的开发流程也应该与这一阶段并列进行，从而使得在架构和实现组织之间的联系得以被建立（通过架构契约）。为了促使业务价值和利益的实现，并在最大程度上避免或减少迁移方案所带来的风险，最好的办法就是将目标架构的部署转换为一系列的过渡活动，且每个过渡活动都代表着一个朝目标演进的步进过程。在此阶段中的方法可以概括如下：

建立一个实施方案，从而促进在迁移规划中指定的过渡架构的实现。
采用一种阶段化的部署规划。该规划反映了包含在架构路线图中各项业务的优先级。
遵循组织的各项标准（包括公司、IT以及架构治理方面）。
使用组织中已经确立的各种项目管理方法。
定义一个运营框架，来确保所部署的解决方案的长期有效性。

1.9.3 输入与输出

在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

当前阶段中所要执行的各个步骤归纳如下：

通过开发管理确认部署的范围和优先级
明确用于部署的资源和技能
指导解决方案部署的开发
执行企业架构合规审查
实施业务和IT运营
执行实施后审查，并结束实施

七、架构变更管理（Architecture Change Management）阶段

1.10.1 目标

本阶段的目标是：

确保基线架构持续符合当前实际。
评估架构性能，并对变更提出建议。
评估在之前阶段制定的框架和原则的变化。
为实施治理阶段建立的新的企业架构基线建立架构变更管理流程。
将架构和运营的业务价值最大化。
运用治理框架。

2、方法

架构变更管里流程的目标是保证架构能够达成其目标业务价值。并且这一过程还着眼于将原本静态的企业架构建设成为一个动态的架构，使其具有足够的灵活性来对技术和业务环境的改变来进行快速地适应性演进。为了达成这些目标，架构变更管理过程往往针对治理请求、技术上的进步以及业务环境的变化进行持续的监督，同时当这些变更被识别出来后，这一过程还需要对是否启动一个新的架构演进循环而做出决定。由此可见，这一阶段的中心思想就是监督并明确企业所处环境的变更，并据此做出适当的架构变更决策。在变更的监督和明确过程中我们需要注意如下几个方面：

监督业务的消长是这一阶段的一个重要方面。针对企业架构的使用也是架构开发循环中的最重要的一环。在企业中，当前架构支持下的业务虽然能够满足当前的需要，但是对于未来的情况却不一定适用。并且在多数情况下，架构即便能够跟得上变化并始终保持适用，但各种用于对其进行实现的解决方案却不一定可以，因而针对他们的变更也是必要的。企业架构师需要了解这些变更需求，并把他们当作架构持续更新的一个重要组成部分来进行考虑。
容量评测和针对规划的建议是这一阶段的另外一个重要方面。虽然企业架构提供了一个稳定的业务架构，且此业务架构在企业架构生命周期中所提供的能力也是大家所共识的，但是对其使用的增加或减少还是需要被持续监督下去，从而保证最大业务价值的获取。例如，在企业当前状态下，当前的架构和解决方案能够满足需要，但是如果企业规模扩大一个量级后，其他的解决方案却可能更加经济有效。

需要注意的是，如果性能管理和汇报已经在之前的几个阶段中被加入到工作产品序列之中，那么在此阶段中，组织就需要保证其有效性，而如果还存在其他需要被监督和汇报的需求，那么这一阶段还需要对这些变化进行处理。

在架构变更管理阶段，治理机构还需要建立各种指标。用于判断变更请求是采用架构更新措施，还是启动一个新的架构开发循环。在这些标准的制定过程中，企业需要注意避免“完美蠕行”（Creeping elegance）病症，并且治理机构也必须持续寻找与业务价值直接相关的各种变更。架构合规评估报告需要表明一个变更是否与当前架构相适应，如不适应则需要表述其理由，而如果这一变更对架构具有很大的影响，则一个用于管理其影响的策略需要被制定出来。就像不同的企业能够接受不同程度的风险一样，为这些评估标准的制定建立统一的实施指南是非常困难的，但随着架构开发方法的不断实践，治理机构的成熟度水平会日渐提高，这些标准也会根据特定的需求而逐渐清晰起来。

变更驱动力

架构开发的主要目标是将企业的战略目标经由企业架构和各实现项目的捏合最终实现企业自身能力的提升。但在这一过程中，起重要作用的企业架构并不是凭空产生的，在它的周围总是存在着一系列正在创造价值（也许效率不是最优）并等待被整合的基础设施和业务，而针对他们的整合变更，以及外界环境对他们的变更需求，都在企业架构的演进过程中充当了驱动力。一般来讲，有三种方式来对这些将要被整合的基础设施进行变更：

来自于战略层面自上而下的变更，用于增强或创建新的能力。
来自于下面的自下而上的变更，用于修正或更新运营管理中各基础设施的能力。
在项目进展过程中产生的经验。

这些变更在企业架构开发过程中一般以架构变更请求的形式进行提交，因而上面这些变更的将会形成一系列错综复杂的架构变更请求。对待这些变更请求，治理行为是必不可少的，并且一个吸取经验教训的过程也是必要的。这一吸取经验教训的过程的目标是避免已经发生错误的重犯，它将对在进展过程中发现的问题进行解决，并对目标架构进行更改，从而使企业架构一直处于正确的方向之上。

架构委员会（Architecture Board）需要对这些架构申请（RFC：Requests for Change）进行评估和批准，而在这一过程中，架构委员会所面临的一大挑战是判断一个变更请求是否需要被批准，并进一步引起针对架构规划的变更，或者这一申请是否可以由过渡架构中的某个实现项目来解决（即这一变更已经处在未来的规划之中）。

除了上面针对来源的区分，架构变更还可以从技术和业务两个角度来进行分类。技术相关的变更驱动力可以是新技术的产生、资产管理成本缩减、技术退出以及新标准的倡议等。业务相关的驱动力则可以是日常业务开发、业务异常、业务革新、业务技术革新和战略变更等。对于技术方面的驱动力，主要通过企业变更管理和架构治理流程来进行管理，而对于业务方面的驱动力，则往往会导致新一轮的架构开发，或者至少是针对架构开发循环某一部分的迭代。

企业架构变更管理过程

企业架构变更管理过程需要确定各个变更如何被管理，以及在此过程中所采用何种技术和方法。除此之外，这一过程还需要具备一个用于明确哪个架构开发阶段受到影响的过滤功能（例如，仅对迁移方面产生影响的变更就不需要影响到架构开发相关的各阶段）。在当前存在着多种管理变更的方法和技术，例如：

项目管理方法，例如PRINCE2。
服务管理方法，例如ITIL。
管理咨询方法，例如Catalyst。

除了这些方法，TOGAF还推荐了一种用于管理变更的方法。该方法对于架构变更按照如下原则进行了分类：

简化变更（Simplification Change）：通常采用变更管理技术进行处理的变更。此种类型的变更通常来源于一个减少投资的需求。
增量变更（Incremental Change）：一个增量变更可以通过变更管理技术来进行处理，也可能需要对架构进行部分重建。此种类型的变更通常来源于在现存投资中获得额外价值的需求。
重新架构变更（Re-architecting Change）：此种变更需要通过架构开发循环对整个架构进行重建。此种类型的变更通常来源于为了创建新的价值而增加投资的需求。

为了分辨出一个变更属于上述哪种类型，组织可以借助于如下的步骤：

对所有可能影响架构的事件进行注册记录。
为各个架构任务进行资源分配和管理。
对架构资源进行负责的角色或流程需要对所做的事情进行评估。
对影响进行评估。

维护vs架构重新设计

如下的原则可以帮助企业来判断针对一个变更所要采用的处理方式是针对架构的维护还是对架构重新设计：

如果变更影响了两个或两个以上的干系人，那么这个变更很可能会需要一个架构的重新设计和新的架构开发循环。
如果变更只影响了一个干系人，那么这个变更很可能会成为变更管理的候选目标。
如果变更在一个特许之下能获得批准，那么这个变更很可能会成为变更管理的候选目标。

例如：

如果变更对业务战略有着很大的影响，那么整个企业架构可能会被重建。
如果一个新的技术或标准出现了，那么技术架构（而不是整个架构）可能会被要求进行刷新。
如果变更出现在一个基础设施层面，那么此物理层之上的架构将不会受到影响，但技术架构的基线描述将会受到影响。此种变更属于需要借助于变更管理技术的简化类型的变更。

除了上述原则，需要特别注意的是，在如下的情况中，组织需要针对部分或全部架构进行一个刷新循环（如果组织确定要进行该刷新循环，那么一个新的架构工作要求书需要被制定出来）：

基础架构需要与业务战略相校准。
在架构的部署过程中所使用的组件和实施指南需要进行重大变更。
在产品架构中使用的重要标准需要进行变更，并且对用户有着很大的影响。

3、输入与输出

当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

4、步骤

当前阶段中所要执行的各个步骤归纳如下：

建立价值实现过程
部署监测工具
管理风险
为架构变更管理提供分析
开发变更需求来迎合性能目标
管理治理过程
激活实施变更的过程

八、需求管理（Requirements Management）阶段

1、目标

本阶段的目标是定义一个过程，使企业架构的需求可以被识别、存储并与其他架构开发方法各阶段交互。

2、方法

需求管理阶段位于整个架构开发方法循环的中心，而整个架构开发方法过程实际上也是由这一构成所驱动的。需求管理的目标并不是针对一系列静态的需求表述，而是一个动态的过程，借助于这一过程企业架构的需求和因此而产生的变更能够被识别、储存，并与企业架构开发方法其他各个阶段的输入与输出产生互动。需要注意的是，需求管理构成本身并不能解决任何需求（这些应该是企业架构开发方法相应阶段的任务），它只是一个用来在整个架构开发方法周期中对需求进行管理的过程。

可借助的资源

在现实生活中存在着多种关于需求管理的建议和过程，TOGAF并不强制企业采用何种方式来进行需求管理，它只是表述了作为一个有效的需求管理过程所应该达到的要求。

业务情景（Business Scenarios）：此技术是描述在TOGAF中的一个非常有效的技术，用于发现并记录业务需求，同时还可以用来描述一份用于实现这些需求的架构愿景。
Volere需求说明模板（Volere Requirements Specification Template）：此需求说明模板是目前比较流行的需求说明模板之一，虽然它本身并不是为了架构需求而设计的，但是这并不妨碍其可用性，并且这一模板可以被自由获取、修改或复制。
需求工具（Requirements Tools）：在当前存在着很多现成的商业性需求工具，并且其数量还在不断增长。虽然这些工具大多不是为架构需求而特制的，但是其可用性并不受阻碍，因为架构需求从本质上讲也没有太多特殊之处。