TOGAF9中文版（二）
TOGAF9.1版本
Part II Architecture Development
Method （ADM）
第二部分 架构开发方法（ADM）
The Open Group
第5章简介 Introduction
本章描述架构开发方法（ADM）周期、ADM的适应性调整、架构范围和架构综合。
5.1ADM概述 ADM Overview
TOGAF ADM是众多架构实践者持续努力贡献的成果，它描述一种开发和管理企业架构生命周期的方法，并构成TOGAF的核心。它综合本文件中描述的TOGAF元素和其他可用的架构资产，以满足组织的业务和IT需要。
5.1.1 ADM、企业的连续统一体和架构库 The ADM, EnterpriseContinuum, and Architecture Repository
企业的连续统一体提供在执行ADM的过程中支持更强有力地发挥相关架构资产作为的框架和背景环境。按照“第五部分：企业的连续统一体和工具”中的解释，这些资产可包括架构描述、模型以及从各种来源中抽取的特征模式。
企业的连续统一体对架构源资料进行分类 这些素材包括组织自身的企业存储库的内容以及行业内一系列相关可用的参考模型和标准。
企业的连续统一体的实际实施通常会采用架构库（见第五部分，第41章）的形式，包括已在企业内部采用的参考架构、模型和特征模式，以及之前在企业内已做的实际架构工作。架构师将寻求尽可能地从架构库中复用与当前项目相关的内容。（除了收集架构源资料，存储库也将包含架构开发过程制品。）
在整个ADM中的相关位置，提示架构师考虑应使用架构存储库中的哪些架构资产（如果有）。在某些情况下，例如在技术架构的开发过程中，这可能是TOGAF基础架构（见第六部分：TOGAF参考模型）。在其他情况下，例如在业务架构的开发过程中，它可能是取自整个行业内的电子商务参考模型。
在组织的架构库中，包含源资料的准则通常会构成企业架构治理流程的一部分。这些治理流程应考虑企业内部和外部的可用资源，以确定通用资源何时可适应于特定企业的需要，并确定可在何处对特定解决方案进行一般化，以支持更大范围的复用。
在使用ADM的同时，架构师在特定时点“显像”企业决策及其内涵的一幅“快照”。每轮ADM迭代都将使用通过流程识别和得以更好利用的所有架构资产充实组织特有的全景，包括最终交付组织特有的架构。
架构开发是一个连续的循环流程，并且在随着时间推移而反复执行ADM的过程中，架构师逐渐向组织架构库中添加越来越多的内容。虽然ADM的主要聚焦点是企业特有架构的开发，但是在这个更广泛的背景环境中，ADM还可以被视为使用取自“左侧”（企业的连续统一体更一般的一侧）的相关可复用构建块来填充企业自身的架构库的流程。
实际上，因为可复用的架构资产相对稀缺，第一次执行ADM往往将是最艰难的。但是，即便是在本开发阶段，也会有来自于外部来源诸如TOGAF以及整个IT行业内的架构资产，可以更好地被利用来支持这项工作。
随着越来越多的架构资产被识别，用来充实组织架构库并因此可用于未来的复用，后续执行将会更容易。
5.1.2 ADM和基础架构 The ADM and theFoundation Architecture
ADM对于充实企业的基础架构也是有用的。企业的业务需求可用于识别基础架构中必需的定义和选择。这可能是一系列可复用的公用模型、方针和治理定义，或者甚至具体到首要技术选择（例如，如果法律规定）。基础架构的充实遵循类似企业架构原则，区别是，整个企业的需求被限定在总体关注点，因此不如特定企业的需求完整。
重要的是认识到，在综合时来自于不同来源的现有模型可能不一定会产生协调一致的企业架构。在5.6节中描述了架构“可综合性”。
5.1.3 ADM和支持指南和技巧 ADM and SupportingGuidelines and Techniques
“第三部分：ADM指南和技巧”是支持TOGAF ADM应用的一系列资源——指南、模板、检查清单和其他详细资料。
在“第三部分：ADM指南和技巧”中分别描述指南和技巧，以便可以根据需要从ADM中相关位置引用这些指南和技巧，而不会因详细的文本干扰对ADM本身的描述。
5.2架构开发周期 Architecture DevelopmentCycle
5.2.1关键点 Key Points
以下内容是关于ADM的关键点：
■ ADM在整个流程中、各个阶段之间以及各个阶段内（见第三部分，第19章）是迭代的。对于ADM的每轮迭代，必须按照以下因素采取新的决策：
— 待定义的企业覆盖范围的广度。
— 待定义的细节层级。
— 目标时间区间范围，包括任何中间时间区间的数量和范围。
— 更大程度利用架构资产，包括：
—企业内以往的ADM周期迭代所创建的资产。
—在行业其他地方可用的资产（其他的框架、系统模型、垂直行业模型等）。
■这些决策均应基于对资源和能力可用性的实际评估以及实际期望从选定的架构工作范围内增加到该企业的价值。
■作为一种一般化的方法，ADM旨在由位于各种不同地理位置的企业来使用并应用于不同的垂直部门/行业类型。如此一来，它也许是按照特定需要进行剪裁，但不一定必须如此。例如，ADM可以与另一个框架的交付物集结合使用，这些交付物已被视为更适合于某个特定组织。（例如，许多美国联邦机构己经开发出了多个独立架构，用于定义其特殊部门需要的特有交付物。）这些问题在5.3节中详细论述。
5.2.2基本结构 Basic Structure
ADM的基本结构如图5-1所示。
在ADM整个周期中，需要根据原始期望对结果进行经常的确认，既包括整体ADM周期，也包括该流程的特定阶段。
图5-1 架构开发周期
ADM周期的各个阶段被进一步划分为以下步骤；例如，架构开发阶段（B、C、D）内的步骤如下：
■选择参考模型、视角和工具
■开发基线架构描述
■开发目标架构描述
■进行差距分析
■定义候选路线图组件
■化解贯穿架构全景的影响
■进行正式的利益攸关者审视
■最终确定架构
■创建架构定义文件
需求管理阶段是一个连续阶段，它确保通过适当的治理流程来处理任何需求变更并反映在所有其他阶段中。
企业可选择记录所有新的需求，包括通过单个需求存储库来记录当前架构工作说明书范围内的那些需求。在第二部分的以下章节中详细描述ADM周期的这些阶段。
注意，在流程中各处均产生输出且早期阶段产生的输出可在以后的阶段中进行修改。通过版本号管理输出的版本。在所有情况下，ADM编号方案作为一个示例提供。ADM编号方案应由架构师进行调整以满足组织的需求，并与组织所采用的架构工具和存储库一同使用。
特别地，在ADM内，版本编号协定被用来阐明基线架构定义和目标架构定义的演进。表5-1描述如何使用本协定。
表5-1 ADM版本编号约定
阶段 |
交付物 |
内容 |
版本 |
描述 |
|
|
业务架构 |
0.1 |
版本0.1表明架构的高层级概要己形成 |
A:架构愿景 |
架构愿景 |
数据架构 |
0.1 |
版本0.1表明架构的高层级概要己形成 |
应用架构 |
0.1 |
版本0.1表明架构的高层级概要己形成 |
||
|
|
技术架构 |
0.1 |
版本0.1表明架构的高层级概要己形成 |
B:业务架构 |
架构定义文件 |
业务架构 |
1.0 |
版本1.0表明经正式审视的详细架构 |
C:信息系统架构 |
架构定义文件 |
数据架构 |
1.0 |
版本1.0表明经正式审视的详细架构 |
应用架构 |
1.0 |
版本1.0表明经正式审视的详细架构 |
||
D:技术架构 |
架构定义文件 |
技术架构 |
1.0 |
版本1.0表明经正式审视的详细架构 |
5.3 ADM的适应性调整 Adapting the ADM
ADM是种一般化的架构开发方法，被设计用于处理大多数系统和组织需求。然而，修改或扩展ADM以适应特定需要常常是必需的。应用ADM前，一个任务足审视各组成部分的适用性，然后按照企业各自的环境适当剪裁。本活动有可能产生一个“企业特有的” ADM。
想要适应调整ADM且重点强调的一个原因是，ADM中各个阶段的顺序在某种程度上依赖于企业内架构规程的成熟度。例如，如果架构开发的业务案例尚未得到充分识别，那么创建一个架构愿景几乎总是必不可少的；并且详细的业务架构通常要随之而来，以便支撑架构愿景，详细说明其余架构工作的业务案例，并确保关键的利益攸关者主动参与到这项工作之中。在其他情况下，对顺序稍做调整可能更为可取；例如，详细的基线环境库目录可在进行业务架构开发之前完成。
阶段的顺序可以根据企业的架构原则和业务原则来定义。例如，业务原则可要求企业做好调整其业务流程的准备，以满足打包解决方案的需要，以便为快速应对市场变化来迅速实施该解决方案。在这种情况下，业务架构（或至少业务架构的完成）也许在信息系统架构或技术架构完成之后会很好形成。
需要适应性调整ADM的另一个原因是，TOGAF是否将与另一个企业框架（在第一部分，2.10节中解释）综合。例如，企业可能希望使用TOGAF及其通用ADM结合著名的Zachman框架，或另一个具有特定于特殊垂直部门（政府、国防部、电子商务、电信等）的一系列确定交付物的企业架构。ADM在进行专门设计时已经意识到有这种综合的可能性。
需要调整ADM的其他可能的原因包括：
■ ADM是组成公司治理模型的众多公司级流程之一。它与其他标准程序管理流程互补并提供支持，例如那些用于授权、风险管理、业务规划和预算、开发规划、系统开发和采购的流程。
■ ADM经委托由主要或总承包商在外包条件下使用，并且需要剪裁，以在承包商现有实践和承包的企业需求之间达成适当的折中。
■ 企业属于中小型企业，并希望使用更加适合中小型企业这类环境下特有的资源水平和系统复杂度均较低的“精简”方法。
■ 企业规模庞大且复杂，包含一个整体协作的业务框架内的众多独立但相互联系的“企业”，并需要对架构方法进行调整以认识到这种情况。在这种情况下，可使用不同的规划和途径，包括以下方法（可结合使用）：
—自顶向下规划和开发——将整体互连的元企业设计为一个单一实体（一种训练实际情况限定的运用）。
—“一般”或“参考”架构的开发，组织内的企业具有代表性，但不代表任何特定企业，然后期望各个企业进行适应性调整，以便产生一个适于所关注的特指企业的架构“实例”。
—复制——为一个企业开发特定架构，将该架构作为方案验证来实施，然后在其他企业中当作“参考架构”进行克隆。
■在供应商或生产环境中，用于相关产品族的一般架构通常被称为“产品线架构”，并且以上列出的相似流程被称为“（基于架构的）产品线工程”。ADM主要面向IT用户企业中的架构师，但是其产品基于IT的供应商组织很有可能希望将ADM调整为产品线架构开发的一种一般方法。
5.4架构治理 Architecture Governance
无论是由组织适应性调整还是按本文所记录的这样使用，ADM都是一个按照与在企业的连续统一体中分类并在架构库中保存的其他架构制品相同的方式管理的关键流程。架构委员会应确信在架构开发迭代的所有阶段中均在正确应用方法。符合ADM是治理架构的基础，以确保进行了周全的考虑并产生所有需要的交付物。
对所有架构制品、治理和相关流程的管理均应由受控环境所支持。典型情况下，这将会基于支持受版本控制的对象和流程控制及状态的一个或多个存储库。
由治理存储库管理的主要信息领域应包含以下类型的信息：
■参考数据（从组织拥有的存储库/企业的连续统一体中收集，包括外部数据，如COBIT、ITIL）:用于项目实施期间的引导和指令。参考数据包括以上列出的信息的详细说明，也包括对治理程序本
身的描述。
■流程状态：与治理流程的状态有关的所有信息均会被管理；流程状态的示例包括重要的合规性要求、特许请求以及合规性评估调查。
■审核信息：审核信息会记录所有完整的治理流程活动并用于支持：
— 经由治理流程正式认可的任何架构项目的关键决策和负责人员。
— 作为未来架构的和支持流程的开发、引导和排序的参考。
治理制品和流程本身是架构库内容的一部分。
5.5界定架构的范围 Scoping the Architecture
有多个原因约束（或限制）待执行架构活动的范围，大部分原因与下面的限制有关：
■架构创建团队的组织权限
■在该架构内所涉及的目的和利益攸关者关注点
■人员、财务和其他资源的可用性
在理想情况下，架构活动选用的范围应允许对所有架构师在该企业范围内的工作进行有效治理和综合。这就需要一系列协调一致的“架构划分”，确保架构师不会从事重复的或冲突的活动。这也需要定义各架构划分之间的复用和合规性关系。
企业及其架构相关活动的划分将在第40章进行更详细的论述。
典型情况下，使用四个维度来定义并界定架构范围：
■广度：企业的完整扩展广度是什么，本架构工作会涉及该扩展广度的哪一部分？
— 许多企业非常庞大，实际上包括一个由若干组织单元构成的联盟，这些组织单元在其自身范围内就可以被视为企业。
— 现代企业日益延伸到传统边界以外，包括一种由传统业务企业与供应商、客户和合作伙伴结合在一起的模糊组合。
■深度：架构工作应该进行到什么样的细节层级？多少个架构是“足够”的？架构工作和其他相关活动（系统设计、系统工程、系统开发）之间的适当界限是什么？
■时间区间：什么是描绘架构愿景所需的时间区间？在详细架构描述中涵盖同一时区间是否有意义（就现实性和资源而言）？如果没有意义，将定义多少个过渡架构？它们各自的时间区间是什么？
■架构域：一个完整的企业架构描述应当包括全部四个架构域（业务、数据、应用、技术），但是资源和时间约束的现实情况往往意味着没有足够的时间、资金或资源来建立一个涵盖所有四个架构域的自顶向下的全面架构描述，即便是选定的企业范围比整个企业的总体范围要小得多。
通常，首先在广度、深度和时间方面表达架构的范围。一旦理解了这些维度，可选定适于正在应对的问题的适当架构域组合。在第20章中论述使用ADM开发多个相关架构的技巧。
下面详细探究架构范围的四个维度。在每种情况下，特别是在必须以一种联合的方式开发架构的大规模环境中，架构师在自身活动范围内而并非在总体企业层级上进行优化，会存在一定风险。通常有必要在特定领域内进行局部优化，以便在企业层级上优化。目标应始终是寻求层级的共用性，并聚焦于可扩展且可复用的模块以便使企业层级的复用最大化。
5.5.1广度 Breadth
依据所涵盖的总体企业活动的广度（特定的业务部门、功能、组织、地理区域等），其中一个关键决策是架构工作的聚焦点。
通常有必要使存在于整个企业中的多个不同的架构聚焦于特定时间区间、业务功能或业务需求。
对于复杂的大型企业，联邦架构是典型架构——在一个集成框架内依次综合的独立开发、维护和管理的多个架构。这样的框架规定互用性、迁移和一致性的原则。这允许特定的业务单元将这些架构作为独立的架构项目进行开发和治理。更多关于规定不同解决方案互用性需求的详细说明和指南可在第三部分的第29章中找到。
针对每个业务功能或目的的单一的整个企业范围的架构的可行性，因过于复杂和不实用可能被拒绝。在这些情形下，建议整个企业中存在多个不同的企业架构。这些企业架构聚焦于特定时间区间、业务区域或功能，以及特定的组织需求。在这种情况下，我们需要将首要的企业架构创建为这些企业架构的一个“联邦”。
管理和开拓这些企业架构的有效途径是采用一个允许架构被纳入治理框架的发布—订阅模型。在这样一个模型中，项目中的架构开发者和架构使用者（架构工作的供方和需方）签订一个互惠互利的治理框架，以确保：
■架构资料是优质的、最新的、适用的和发布的（经审视并同意公开的）。
■通过以下流程，可监控架构资料的使用，并可体现与标准、模型和原则的一致性：
—合规性评估流程，描述用户正在“订阅”什么，并评估其合规性等级。
—特许流程，可根据是否遵守特定情况（通常带有强烈的业务需要）的架构标准和指南来授予特许。
发布和订阅技巧正在作为一般IT治理的一部分进行开发，特别是用于国防领域。
5.5.2深度 Depth
应关切根据企业架构的预期用途和由此做出的决策来判定将要捕获的适当的细节层级。重要的是，应在包含在架构工作中的每个架构域（业务、数据、应用、技术）中完成一致且对等的深度层级。如果省略相关的细节，那么架构可能会不再有用。如果包括不必要的细节，那么架构工作可能超出可用的时间和资源，和/或得到的架构可能是令人迷惑或凌乱的。第20章更详细地论述在企业范围内的不同细节层级上开发架构。
预测架构的未来用途同样重要，以便在资源限制范围内，架构可被结构化以适应未来剪裁、扩展或复用。企业架构的深度和细节只需要足以满足其目的。
ADM的迭代将会建立在前一轮迭代中所创建的制品和能力之上。需要对企业中的所有模型进行文件化，细节层级适合当前ADM周期的需要。关键是理解企业的架构工作的状态，以及通过可用的资源和能力可以在实际上达成什么，然后聚焦于识别和交付可实现的价值。利益攸关者价值是一个关键聚焦点：过度宽泛的范围可能会使某些利益攸关者感到沮丧（无投资回报）。
5.5.3时间区间 Time Period
根据单一架构愿景周期以及使该愿景能够实现的一系列目标架构（业务、数据、应用、技术）来描述ADM。
在这种情况下，可采用更宽广的视野，由此，企业可通过若干不同的架构实例（例如，战略、分部、能力）表达，每个实例代表特定时点的企业。一个架构实例将表示当前的企业状态（“现状”或基线）。另一个架构实例，也许仅部分定义，将表示最终目标的最终状态（“愿景”）。在两者之间可定义中间的或“过渡架构”实例，每个实例包括其拥有的目标架构描述集。在第三部分第20章中给出如何达成这一点的示例。
通过这种途径，目标架构工作分成两个或更多个离散的阶段：
1. 首先，开发总体（大规模）系统的目标架构描述，表明对相对久远的时间区段（例如，六年）内的利益攸关者的目的和关注点的响应。
2. 然后，开发一个或更多个“过渡架构”描述，作为增量或稳定状态，一个“过渡架构”描述都与目标架构保持一致且汇聚焦于目标架构描述，并描述所关注的增量的特性。
在这种实施途径中，目标架构在本质上是演进的，并要求根据演进的业务需求和技术发展定期审视和更新，虽然过渡架构在本质上（按照设计）是递增的，并且在原则上不应在递增的实施阶段演进，以避免存在“移动的目标”的综合症状。当然，这只在实施进度被严格控制并相对较短（通常是小于两年）的情况下是可能的。
目标架构保持相对的通用性，正因如此，相比过渡架构，其不易被淘汰。目标架构仅体现利益攸关者从一开始所拥有的关键战略架构决策，而过渡架构中的详细架构决策则被有意识地尽可能延后（即刚好在实施之前），以便面对新技术和产品时提高响应性。
企业通过依次迁移至每个过渡架构进行演进。当实施每个过渡架构时，企业在通往最终愿景的过程中达成一致的运行状态。然而，愿景本身是定期更新的，以反映业务和技术环境的变化，并在实际上从未按照初始的描述真正实现过。只要企业存在并继续变革，整个流程就持续进行。
当然，这样一种使架构描述成为一系列相关架构产物的分解，要求对该集合及其相互关系进行有效管理。
5.5.4架构域 ArchitectureDomains
一个完整的企业架构应该应对四个架构域（业务、数据、应用、技术），但是资源和时间约束的现实情况，往往意味着没有足够的时间、资金或资源来建立一个涵盖所有四个架构域的自顶向下的详尽架构描述。
通常架构描述的建立都考虑到特定目的——驱动架构开发的一系列特定业务驱动因素并明晰架构描述，旨在帮助探索的特定议题以及期望帮助解答的问题，这是ADM初始阶段的一个重要部分。
例如，如果特定架构工作的目的是定义和审查用于实现特定能力的技术选项，并且基础业务流程并不对修改开放，那么完整业务架构很可能得不到保障。然而，由于数据、应用和技术架构建立在业务架构上，业务架构仍然需要全面地考虑和理解业务架构。
虽然有时一些情况可能指定构建一个不包含全部四个架构域的架构描述，但应该明白的是，根据定义，这样的架构不可能是一个完整的企业架构。其中一个风险是缺乏一致性并因此缺乏综合的能力。综合或需要在之后进行——具有自身的成本和风险——或需要由架构师清楚表达出与未开发出一个完整和综合的架构有关的风险和权衡对象，传达至企业管理部门并被管理部门理解。
5.6架构综合 Architecture Integration
为处理企业内的问题子集而创建的架构需要一致的参照框架，以便这些架构和指定交付物被视为一个群组。通常，用于界定单一架构（例如细节层级、架构域等）范围边界的维度与在考虑综合多个架构时必须涉及的维度相同。图5-2阐明不同类型的架构需要如何共存。
目前，现有技术水平使得架构综合只能够在综合能力谱系的较低端完成。要考虑的关键因素是每个制品的粒度和细节层级，以及用于架构描述互换标准的成熟度。
图5-2 架构制品的综合
当组织应对共用主题[例如面向服务架构（SOA）和集成信息基础设施]并且通用数据模型和标准数据结构出现时，将会促进对谱系高端的综合。然而，总是需要有效的标准治理来减少对人工协调与冲突解决的需要。
5.7概要总结 Summary
TOGAF ADM为开发架构中涉及的不同阶段和步骤定义了一个推荐的顺序，但不能推荐一个范围——这必须由组织自己来确定，需要牢记的是推荐的ADM流程开发顺序是迭代的，且范围的深度、广度和交付物随着每轮迭代而增加。每轮迭代将会向组织架构存储库增添资源。
尽管一个完整的框架对于将其考虑作为最终长期目标是有用的（确实很重要），但实际上，需要依据特定企业架构工作的范围做出关键决策。因此，至关重要的是，必须理解界定范围的决策所依据的基础以及设定适于该工作的目标的期望。
主要指南将聚焦于“什么为企业创造了价值”，并据此选择水平和垂直范围及时间区间。无论这是否是第一轮，要知道这样的训练将会重复进行，并且未来迭代将会建立于当前的工作所创造的内容之上，增加宽度和深度。
第6章预备阶段 Preliminary Phase
本章描述为满足一个新的企业架构业务方针所需的准备和发起活动，包括组织特定架构框架定义和原则定义。
图6-1 预备阶段
6.1目的 Objectives
预备阶段的目的是：
1 .确定组织所期望的架构能力：
■审视开展企业架构的组织背景环境
■识别并确定受架构能力影响的企业组织元素及范围
■识别与架构能力相交叉的已有框架、方法及流程
■建立能力成熟度目标
2.建立架构能力：
■定义并建立企业架构的组织模型
■定义并建立用于架构治理的详细流程和资源
■选择并应用支持架构能力的工具
■定义架构原则
6.2实施途径 Approach
预备阶段是在所关注的企业中定义“何处、何事、为何、何人以及如何进行架构”。主要内容如下：
■定义企业
■识别组织背景环境中的关键驱动因素和元素
■定义架构工作的需求
■定义架构原则以作为任何架构工作的依据
■定义要使用的框架
■定义管理框架间的关系
■评估企业架构成熟度
企业架构为一个组织提供了自顶向下的战略视图，使高层管理者、计划者、架构师和工程师能够连贯地协调、综合和进行他们的活动。企业架构框架为团队提供在其中运行的战略背景环境。
因此，开发企业架构不是一个孤立的活动，企业架构师需要认识到他们的框架和其他业务之间的互用性。
战略的、过渡的和战术的业务目的及渴望需要被满足。同样地，企业架构需要反映上述需求并允许架构规程在组织内不同层级的运行。
依据企业的规模和投入企业架构规程的预算水平，可采用多种途径方法细分或划分架构团队、流程和交付物。第五部分的第40章论述架构划分的方法。预备阶段应该用于确定所期望的划分方法并为即将投入实践的备选方法建立基础。
应从架构愿景阶段（见第三部分，第19章）回顾预备阶段，以确保组织架构能力可以应对特定架构问题。
6.2.1企业Enterprise
企业架构的主要挑战之一就是企业的范围。
企业的范围，无论是否是联邦的，均将确定那些将从企业的架构能力中得到最大利益的利益攸关者。当务之急是在本阶段指定发起人，以确保有资源推进后续的活动并明晰业务管理的支持。企业可包括众多组织，并且发起人的职责是确保所有利益攸关者被包括在定义、建立和使用架构能力的过程中。
6.2.2组织的背景环境 OrganizationalContext
为了对特定企业范围内使用的架构框架做出有效的和有依据的决策，有必要理解架构框架周边的背景环境。考虑的特定领域包括：
■ 企业架构的商业模型和企业架构活动的预算计划。在不存在这样计划的情况下，预备阶段应开发一个预算计划。
■ 企业中的架构利益攸关者；他们的关键议题和关注点。
■在委员会业务方针、业务关键、业务战略、业务原则、业务目标和业务驱动因素范畴内捕获的组织意图和文化。
■支持执行企业变革和运行的当前流程，包括流程的结构以及在该组织内应用的严谨程度和正式程度。聚焦的领域应包括：
— 用于架构描述的当前方法
— 当前项目管理框架和方法
— 当前系统管理框架和方法
— 当前项目谱系管理流程和方法
— 当前应用谱系管理流程和方法
— 当前技术谱系管理流程和方法
— 当前信息谱系管理流程和方法
— 当前系统设计和开发框架和方法
■基线架构全景，包括企业状态及当前如何以文档形式表达该全景。
■正在采用基线框架的企业与特定组织的技能和能力。
组织背景环境的审视应如何依据以下方面剪裁架构框架而提供有价值的需求：
■应用的正式程度和严谨程度。
■所需的精致和开销程度。
■与其他组织、流程、角色和职责的结合点。
■内容覆盖的聚焦点。
6.2.3架构工作的需求 Requirements forArchitecture Work
企业架构工作背后的业务关键驱动着架构工作的需求和性能指标。这些业务关键应足够清晰，以便确定本阶段的业务成果和资源需求的范围，并定义要完成的企业架构工作的概要企业业务信息需求和相关策略。例如，这些业务关键包括：
■业务需求
■文化渴望
■组织意图
■战略意图
■预测的财务需求
需要清楚表达这些业务需要的重要元素，以便于发起人可以识别出涉及定义和建立架构能力的全部关键决策人和利益攸关者。
6.2.4原则 Principles
预备阶段定义架构原则，其会构成企业进行各种架构工作的部分约束。第三部分第23章解释这一方面所涉及的议题。
架构原则的定义是企业架构开发的基础。业务原则以及架构原则为架构工作之依据。架构原则自身也通常部分地基于业务原则，定义业务规则一般在架构功能的范围之外。然而，根据在企业内定义和发布这种原则方式，架构原则集也可能重新申明，或与企业内其他定义的一系列业务原则、业务目标和战略业务驱动因素交叉引用。在架构项目范围内，架构师将通常需要确保这些业务原则、目标和战略驱动因素的定义是现行有效的，并且需要明晰任何含糊不清之处。
架构治理议题与架构原则议题是紧密关联的。负责治理的主体通常也会负责批准架构原则和解决架构议题。第七部分第50章解释治理中涉及的议题。
6.2.5管理框架 ManagementFrameworks
TOGAF架构开发方法（ADM）是一种一般方法，旨在由处于多种行业类型和多个地理位置的企业使用。如果需要（虽然该方法本身就可完美使用，无须调整），该方法也被设计用于与多种其他企业架构框架一同使用。
TOGAF必须与任何正式或非正式组织内存在的其他管理框架的运行能力共存并提高运行能力。除了这些框架，大部分组织还具有一种用于开发解决方案的方法，大部分解决方案都具有IT组件。系统的重要性是集合各种不同领域（亦即人员、流程和资料/技术）来交付业务能力。
建议于TOGAF相协调的主要框架是：
■业务能力管理（业务方向和规划），确定交付业务价值需要什么业务能力，包括投资收益率的定义以及必要的控制/绩效指标。
■项目谱系/项目管理方法，确定一个公司如何管理其变革举措。
■运行管理方法，描述一个公司如何进行其日常运作，包括IT。
■解决方案开发方法，形成根据IT架构中开发的结构化交付业务系统的方式。
如图6-2所示，这些框架不是彼此分离的，并且这些框架与业务能力管理之间存在明显重叠。后者包括用绩效衡量的业务价值的交付。
至关重要的是，架构师在应用TOGAF企业中不能仅关注IT实施，还必须意识到该架构对总体企业的影响。
图6-2 与TOGAF相协调的管理架构
因此，预备阶段涉及为使ADM适于定义一个组织特有的框架而执行的所有必要的工作，并使用TOGAF交付物或另一个框架的交付物。5.3节已论述涉及这一方面的议题。
6.2.6使管理框架相关联 Relating theManagement Frameworks
图6-3阐明各种不同框架和纳入企业战略计划和方向的业务规划活动之间的更详细的依赖关系集合。企业架构用于提供一个针对公司级所有举措的结构，项目谱系管理框架可用于交付该架构的组件，并且运行管理框架支持在公司级基础设施中纳入新的组件。业务计划者在整个流程中随处可见，通过保留对各种不同的规划和开发阶段资源的批准，支持和执行该架构。
在项目谱系管理框架内使用解决方案开发方法论，以计划、创建和交付项目谱系和项目章程特定的架构组件。这些交付物包含但不限于IT，如一个新的建筑、一系列新技能、生产设备、招聘和营销等。企业架构可为所有的企业活动提供背景环境。为了企业的利益，需要管理框架之间相互补充和紧密和谐地工作。
图6-3 管理框架之间的互用性和关系
战略层级的业务规划为企业架构提供初始方向。年度规划层级的更新提供一个更细层级的持续的引导。基于能力的规划是众多流行的业务规划方法之一。
企业架构将业务规划结构化为一个视企业为系统或系统之系统的综合框架。此综合途径会确认业务计划并向公司级计划者提供有价值的反馈。在一些组织中，企业架构师己经被调动到战略指导组，或与战略指导群组开展紧密合作。TOGAF交付企业架构框架。
项目谱系/项目管理是获得结构化和具有细节指导的一种交付框架，使得架构师能够计划和构建所需要的内容，了解每个指派的交付物所处的背景环境（即，架构师交付的这部分框架将会与作为企业架构的公司级框架适配）。通常这种框架基于美国项目管理协会或英国政府商务办公室（PRINCE2）的项目管理方法论。项目架构和详细的脱离背景环境的设计通常基于系统设计方法论。
运行管理获得交付物后，将这些交付物在公司级基础设施内集成和维护IT服务管理服务通常基于IS020000或BS15000 （ITIL）。
6.2.7企业架构/业务变革成熟度评估规划 Planning forEnterprise Architecture/Business Change Maturity Evaluation
能力成熟度模型（在第七部分第51章中详细说明）是评估企业训练不同能力的有效方式。
能力成熟度模型通常识别需要训练一种能力的选定因素。组织执行特定要素的能力提供对成熟度的测量并能够用来建议一系列改进能力的顺序步骤。这个评估使高层管理者深度透视实用改进一种能力。
良好的企业架构成熟度模型涵盖开发和使用企业架构所必要的特征。组织能够确定其特有的因素并得到适当的成熟度模型，但是建议采取现有模型并按用户要求进行定制化。
有许多好的模型，包括NASCIO以及美国商务部架构能力成熟度模型。
在第七章第51节中，详细说明能力成熟度模型的使用。
其他示例包括美国联邦政府企业架构成熟度模型。尽管这些模型最初来源于政府，但是它们同样适用于工业界。
6.3输入 Inputs
本节定义对预备阶段的输入。
6.3.1企业的外部参考资料 Reference MaterialsExternal to the Enterprise
■ TOGAF
■其他架构框架（若需要）
6.3.2非架构输入 Non-ArchitecturalInputs
■委员会战略和委员会业务计划、业务战略、IT战略、业务原则、业务目标和业务驱动因素（当预先存在时）
■业务中运行的主要框架；例如，项目谱系/项目管理
■治理和法律框架，包括架构治理战略（当预先存在时）
■架构能力
■合作和承包协议
6.3.3架构输入 ArchitecturalInputs
预先存在的用于运行企业的架构能力的模型，其可被用作预备阶段的基线。输入将包括：
■ 企业架构的组织模型（见第四部分36.2.16节），包括：
— 受影响的组织的范围
— 成熟度评估、差距和解决途径
— 架构团队的角色和职责
— 预算需求
— 治理和支持战略
■现有的架构框架（如果有），包括：
— 架构方法
— 架构内容
— 经配置和部署的工具
— 架构原则
— 架构存储库
6.4步骤 Steps
TOGAF ADM是一个通用方法，旨在用于各种不同的企业，并与各种其他架构框架结合（如果需要）。因此，预备阶段包括为启动并使ADM的适应性调整于定义一个组织特有的框架而执行的所有必要的工作。该议题涉及按特定的组织背景环境调整ADM，将在5.3节中详细论述。
预备阶段所划分的细节层级将取决于总体架构工作的范围和目标。
预备阶段中的步骤顺序（见下文）和这些步骤正式开始与完成的时间应按己建立的架构治理来适应当前情况。
预备阶段中的步骤如下：
■界定受影响的企业组织的范围（见6.4.1节）
■确认治理和支持框架（见6.4.2节）
■定义并建立企业架构团队和组织（见6_4.3节）
■识别和建立架构原则（见6.4.4节）
■剪裁TOGAF以及其他选定的架构框架（如果有）（见6.4.5节）
■实施架构工具（见6.4.6节）
6.4.1界定受影响的企业组织的范围 Scope theEnterprise Organizations Impacted
■识别核心企业（单元）——那些受该工作影响最大并从该工作得到最大价值的
■识别“软”企业（单元）——那些将会看到对其能力的改变并与核心单元合作但不直接受到影响的
■识别扩展企业（单元）——那些在界定的企业范围外、受其自身企业架构影响的
■识别涉及的团体（企业）——那些会受到影响并属于团体群组成员的利益攸关者
■识别涉及的治理，包括法律框架和地理范围（企业）
6.4.2确认治理和支持框架 Confirm Governanceand Support Frameworks
架构框架会构成需要开发的架构治理组织和指南的特色（集中的或联邦的，轻的或重的等）的“拱心石”。本阶段主要输出的部分是架构治理的框架。我们需要理解架构资料（标准、指南、模型、合规报告等）如何得到治理，即，将需要什么类型的存储库特征，什么关系和状态记录对于确定哪种治理流程（分配、合规、采用、退役等）具有架构制品所有权是十分必要的。
组织的现有治理和支持模型，为支持新采用的架构框架很可能将会需要改变。为采纳新的架构框架而管理所需的组织变革，就需要对当前企业的治理和支持模型进行评估以理解这些模型的总体形态和内容。另外，对于有可能出现的潜在影响需要与架构发起人和利益攸关者商议。
一旦完成成本步骤，相关的利益攸关者应理解和接受架构结合点和可能的影响。
6.4.3定义并建立企业架构团队和组织 Define andEstablish Enterprise Architecture Team and Organization
■确定现有企业和业务能力
■如果需要，进行企业架构/业务变革成熟度评价
■识别现有工作领域中的差距
■为企业的架构能力管理和治理分配关键角色和责任
■定义现有业务项目群和项目的变更要求：
— 向现有企业架构和IT架构工作通告利益攸关者的需求
— 要求对其计划和工作的影响进行评估
— 识别所关注的共用领域
— 识别所关注的所有关键差异和冲突
— 生成利益攸关者活动的变更要求
■确定企业架构工作的约束
■审视并与发起人和委员会达成一致
■评估预算需求
6.4.4识别和建立架构原则 Identify andEstablish Architecture Principles
架构原则（见第三部分，第23章）基于业务原则，且对建立架构治理基础极其关键。一旦理解了组织的背景环境，就可以定义一系列适合企业的架构原则。
6.4.5剪裁TOGAF以及其他选定的架构框架（如果有） Tailor TOGAF and,if Any, Other Selected Architecture Framework(s)
在这一步骤中，确定需要什么样的TOGAF。考虑需要何种剪裁：
■术语剪哉：架构实践者应使用在整个企业内被普遍理解的术语。剪裁应产生一套共同约定的术语集合，用于描述架构内容。
■流程剪裁：TOGAF ADM提供用于实施架构的通用流程。在对删除己经在组织其他地方执行过的任务、增加组织特定任务（如特定检查点）以及使ADM流程与外部流程框架和结合点相一致等方法，流程剪裁均为此提供机会。需要应对的关键结合点将包括：
—与（项目和服务）项目谱系管理流程的联系
—与项目生命周期的联系
—与运行工作交接流程的联系
—与运行管理流程（包括配置管理、变更管理和服务管理）的联系
—与采购流程的联系
■内容剪裁：以TOGAF架构内容框架和企业的连续统一体作为基础，内容结构和分类方法的剪裁允许采纳第三方的内容框架，并允许对该框架进行定制化以支持组织特定的需求。
6.4.6实施架构的工具 ImplementArchitecture Tools
用于定义和管理架构内容的正规程度将高度依赖于组织内部架构功能的规模、复杂性和文化。理解期望的架构实施途径，就可能选择适当的架构工具来支撑架构功能。
工具的使用途径可能以标准办公效率应用的相对非正式使用作为基础，或以专家架构工具的定制化部署作为基础。依靠复杂程度，工具实施范围可从一个细小的任务到一个更复杂的系统实施活动。在第五部分第42章中论述了工具标准化议题。
6.5输出 Outputs
预备阶段的输出可包括但不限于：
■企业架构的组织模型（见第四部分36.2.16节），包括：
—受影响的组织的范围
—成熟度评估、差距和解决途径
—架构团队的角色和职责
—对架构工作的约束
—预算需求
—治理和支持战略
■经剪裁的架构框架（见第四部分36.2.21节），包括：
—经剪裁的架构方法
—经剪裁的架构内容（交付物和制品）
—架构原则（见第四部分362.4节）
—经配置和部署的工具
■用框架内容充实的初始架构存储库（见第四部分36.2.5节）
■对业务原则、业务目标和业务驱动因素（见第四部分36.2.9节）的重新申明或重新引用
■架构工作要求书（可选）（见第四部分36.2.17节）
■架构治理框架（见第七部分50.2节）输出可包括下列内容中的部分或全部内容：
■目录：
— 原则目录
第7章阶段A:架构愿景 Phase A: Architecture Vision
本章描述架构开发方法（ADM）的初始阶段。它包括关于定义范围、识别利益攸关者、创建架构愿景和获得批准的信息。
图7-1 阶段A：架构愿景
7.1目的 Objectives
阶段A的目的是：
■开发待交付的能力和业务价值的高层级强烈渴望的愿景，作为所建议的企业架构的结果。
■获得对定义工作计划的架构工作说明书的批准，以开发和部署在架构愿景中概述的架构。
7.2实施途径 Approach
7.2.1概述 General
阶段A开始于架构组织从发起组织接收到架构工作要求书。
在第七部分50.1.4节中，论述了涉及确保公司级管理层的适当认可和担保，以及各级管理层的支持和承诺的议题。
阶段A还规定了什么是在架构工作的范围内，什么是在架构工作的范围外以及必须应对的约束。需要基于对资源和能力可用性的实际评估以及根据选定的架构工作范围实际期望累积形成企业的价值来做出界定范围的决策。5.5节论述了涉及这一方面的议题。在架构愿景阶段所应对的界定范围议题将被限于本轮ADM周期的特定目的之内，并且限制在建立初始阶段内和体现在架构框架内的架构活动定义的总体范围之内。
在架构框架不适于达成所期望的架构愿景的情况下，重新回顾预备阶段并扩展该企业的总体架构框架。约束通常将以预备阶段（见第6章）部分开发的业务原则和架构原则为其依据。
通常，已在企业中其他地方定义了组织业务原则、业务目标以及战略驱动因素。如此一来，阶段A中的活动涉及确保现有定义现行有效并明晰任何含糊不清的地方。否则，就涉及首次定义这些重要的内容项。
同样地，通常在预备阶段对构成架构工作约束部分的架构原则已经进行了定义（见第6章）。阶段A中的活动关注于确保现有原则定义现行有效并明晰任何含糊不清的地方。否则，按照第三部分第23章的解释，就需要首次定义架构原则。
7.2.2创建架构愿景 Creating theArchitecture Vision
架构愿景为发起人提供一个关键工具，以向企业内的利益攸关者和决策者举荐所提供能力的益处。架构愿景描述新能力将如何满足业务目标和战略目的，以及在实施时如何应对利益攸关者关注点。
明晰和商议架构工作的目的是本活动的关键部分之一，并且需要在创建的愿景中清晰地反映该目的。通常按照考虑的特定目的承担架构项目——一系列表示利益攸关者在架构开发过程中的投资回报的特定业务驱动因素。明晰该目的，并表明如何通过所推荐的架构开发达成这个目的，是架构愿景的重点。
通常，架构愿景的关键元素——诸如企业的使命、愿景、战略和目标——已被记录为企业内具有自身生命周期的一些更广泛的业务战略或企业规划活动的部分。在这种情况下，阶段A中的活动关注验证和理解己文件化的业务战略和目标，并且在另一方面，可能还关注在企业战略和目标与当前架构现实中隐含的战略和目标之间搭建桥梁。
在其他情况下到目前为止，可能几乎没有开展业务架构工作。在这种情况下，架构团队需要对架构要支持的关键业务目的和流程进行研究、验证和使其获得认同。这可能被作为一次独立的训练来执行，或者在架构开发之前或者作为ADM起始阶段（预备阶段）的一部分。
架构愿景提供基线架构和目标架构的初步的高层级描述，涵盖业务域、数据域、应用域和技术域。这些概要描述在后续阶段开发。
业务场景是一种用以发现和记录业务需求并清楚地表述响应那些需求的架构愿景的合适且有用的技巧。业务场景在第三部分第26章中描述。
一旦在架构工作说明书中定义和文件化架构愿景，那么关键的是使用该架构愿景构建共识，如第七部分50.1.4节所述。如果未达成共识，那么总体而言，组织不太可能接受最终架构。由发起组织签订架构工作说明书来表达共识。
7.2.3业务场景 Business Scenarios
ADM具有其自身的、用于识别和清楚表述隐含在涉及关键业务驱动因素的新业务能力中和隐含着架构需求的业务需求的方法（一个“方法中的方法”）驱动因素。这种流程被称为“业务场景”，在第三部分第26章中描述。该技巧可在业务架构层级结构分解中的不同细节层级上迭代使用。
7.3输入 Inputs
本节定义了对阶段A的输入。
7.3.1企业外部的参考资料 Reference MaterialsExternal to the Enterprise
■架构参考资料（见第四部分36.2.5节）
7.3.2非架构输入 Non-ArchitecturalInputs
■架构工作要求书（见第四部分36.2.17节）
■业务原则、业务目标和业务驱动因素（见第四部分36.2.9节）
7.3.3架构输入 ArchitecturalInputs
■企业架构的组织模型（见第四章36.2.16节），包括：
—受影响的组织的范围
—成熟度评估、差距和解决途径
—架构团队的角色和职责
—对架构工作的约束
—复用需求
—预算需求
—变更要求
—治理和支持战略
■经剪裁的架构框架（见第四部分36.2.21节），包括：
—经剪裁的架构方法
—经剪裁的架构内容（交付物和制品）
—架构原则（见第四部分36.2.4节），包括业务原则（当之前存在时）
—经配置和部署的工具
■经充实的架构存储库（见第四部分36.2.5节）——现有架构文档（框架描述、架构说明、基线描述、ABB等）
7.4步骤 Steps
阶段A中所划分的细节层级取决于架构工作要求书的范围和目标，或者与架构开发本轮迭代相关的范围和目标的子集。
阶段A中的步骤顺序（见下文）和这些步骤正式开始和完成的时间应按已建立的架构治理来适应当前情况。
阶段A中的步骤如下：
■建立架构项目（见7.4.1节）
■识别利益攸关者、关注点和业务需求（见7.4.2节）
■确认和详细阐述业务目标、业务驱动因素和约束（见7.4.3节）
■评价业务能力（见7.4.4节）
■评估业务转型准备度情况（见7.4.5节）
■定义范围（见7.4.6节）
■确认和详细阐述架构原则，包括业务原则（见7.4.7节）
■开发架构愿景（见7.4.8节）
■定义目标架构价值主张和KPI （见7.4.9节）
■识别业务转型风险和缓解活动（见7.4.10节）
■开发架构工作说明书；确保批准（见7.4.11节）
7.4.1建立架构项目 Establish theArchitecture Project
ADM周期的执行应在企业的项目管理框架内进行。在某些情况下，架构项目会是独立的存在。在其他情况下，架构活动会是大型项目中活动的子集。不论哪种情况，均应使用已接受的企业实践对架构活动进行计划和管理。
执行必要的程序以确保对项目的认可、公司级管理层赞同和必要的一线管理层的支持和承诺。将使用中的其他管理框架的参考文献包括在企业范围内，解释本项目是如何与那些框架相关联的。
7.4.2识别利益攸关者、关注点和业务需求 Identify Stakeholders, Concerns, and Business Requirements
识别关键利益攸关者及其关注点/目的，并定义将在架构工作中所涉及的关键业务需求。本阶段的利益攸关者介入旨在实现三个目的：
■识别在开发架构愿景时要测试的候选愿景组件和需求
■识别该工作的候选范围边界以限制所需架构研究的广度
■识别将会塑形架构被表达和沟通方式的利益攸关者的关注点、议题和文化因素
由本步骤产生的主要产物是利益攸关者介入的映射，表明哪些利益攸关者参与介入、其参与程度以及其关键关注点（见第三部分24.3节和24.4节）。利益攸关者映射被用于支持架构愿景阶段的各种不同输出，并识别：
■与该项相关的关注点和视角；在架构愿景阶段被捕获（见第四部分36.2.8 节） .
■与该项目有关并由此形成沟通计划起点的利益攸关者（见第四章36.2.12 节）
■项目内的关键角色和责任，应包括在架构工作说明书内（见第七部分36.2.20 节）
另一个关键任务将是考虑需要开发哪些架构视图和视角，用以满足各种利益攸关者需求。如第三部分第24章所述，在本阶段理解需要开发哪些利益攸关者和哪些视图对于设定工作范围是重要的。
在架构愿景阶段期间，需在架构需求规范中记录选定需求范围内的未来架构工作产生的新需求，并且，必须在整个需求管理流程中将不在选定需求范围内的新需求输入到用于管理的需求存储库中。
7.4.3确认和详细阐述业务目标、业务驱动因素和约束 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
识别组织的业务目标和战略驱动因素。
如果己经在企业的其他地方定义了这些业务目的和战略驱动因素，那么确保现有定义是有效的，明晰任何模糊不清的方面。否则，就要追溯到架构工作说明书的发起人并与其合作来定义这些重要项，并确保公司级管理层对这些重要项的赞同。
定义必须处理的约束，包括整个企业范围的约束以及项目特定的约束（时间、进度、资源等）。业务和架构原则在预备阶段开发或在阶段A某一环节中被予以阐明，为整个企业范围的约束提供依据。
7.4.4评价业务能力 Evaluate BusinessCapabilities
理解企业内的能力集合是很有价值的。能力集合的一部分是指企业开发架构和使用架构的能力，另一部分是指企业的基线能力和目标能力水平。
在架构能力中，确定的差距需要在架构愿景和预备阶段之间迭代，以确保架构能力适于要涉及的架构项目的范围（见第三部分第19章）。
在企业执行变革的能力中识别出的差距或限制，会作为架构师目标架构描述以及在阶段E和阶段F中创建的实施和迁移计划的依据（见第四部分 36.2.14 节）。
本步骤试图在适当的抽象层级上理解企业的能力和愿望（见第20章）。考量因素企业基线能力与目标能力之间的差距是至关重要的。
通过创建表明相关能力联系的价值链图，能够支持呈现总体企业的背景环境中的基线和目标能力。
评估的结果记录在能力评估中（见第四部分36.2.10节）。
7.4.5评估业务转型准备度 Assess Readinessfor Business Transformation
业务转型准备度评估可用于评价并量化组织对接受变革的准备度。如第30章所述，本评估基于一系列准备度因素的确定和分析/评级。
准备度评估的结果应增加到能力评估中（见第四部分36.2.10节）。然后，这些结果被用来形成架构的范围，以识别架构项目内所需的活动以及要应对的风险领域。
7.4.6定义范围 Define Scope
定义什么在基线架构和目标架构范围之内以及什么在范围之外，理解基线和目标不必以相同的细节来描述。在许多情况中，在较高的抽象层级上描述基线，因此，更多的时间可以用来足够详细地设定目标。5.5节论述了涉及这一方面的议题。尤其是定义：
■企业覆盖范围的广度
■所需的细节层级
■架构的划分特征（对于更多详细说明，见第五部分第40章）
■待涵盖的特定架构域（业务、数据、应用、技术）
■目标对准的时间区间范围，以及任何中间时间区间的数量和范围
■根据组织的企业的连续统一体充分利用或考虑使用的架构资产：
—企业内以前的ADM周期迭代所创建的资产
—行业中其他可用的资产（其他框架、系统模型、垂直行业模型等）
7.4.7确认和详细阐述架构原则，包括业务原则 Confirm and Elaborate Architecture Principles, including BusinessPrinciples
审视开发的架构所依据的原则。架构原则通常基于作为预备阶段的部分所开发的原则。第三部分第23章解释这些原则并给出示例集。确保现有定义现行有效，并明晰任何模糊不清的方面。否则，就要追溯到负责架构治理的机构并与其合作以首次定义这些重要内容项并获得公司级管理层的赞同。
7.4.8开发架构愿景 DevelopArchitecture Vision
基于利益攸关者的关注、业务能力需求、范围、约束和原则创建一个高层级的基线架构和目标架构的视图。架构愿景通常涵盖已识别的高层级项目的范围的广度，常常采用非正式的技巧。普遍的做法是绘制简单的解决方案概念图，以简要阐明解决方案的主要组件以及该解决方案如何使企业受益。
业务场景是一种以发现和记录业务需求并清楚地表达响应那些需求的架构愿景的恰当且有用的技巧。业务场景也可在更多架构工作（如在阶段B）的细节层级上使用，并在第三部分第26章中描述。
本步骤从业务、信息系统和技术的层面产生第一个非常高层级的基线和目标环境的定义，如7.5节所述。
这些架构的初始版本应保存在架构存储库中，根据架构框架中建立的标准和指南进行组织。
7.4.9定义目标架构价值主张和KPI Define the TargetArchitecture Value Propositions and KPIs
■开发用于所需架构和变革的业务案例
■产生每个利益攸关者群组的价值主张
■评估和定义采购需求
■审视并与有关发起人和利益攸关者商议价值主张
■定义为满足业务需要而被构建到企业架构中的性能衡量标准和测度
■评估业务风险（参见第三部分第31章）
本活动的输出应被纳入到架构工作说明书内，以允许据此跟踪绩效。
7.4.10识别业务转型风险和缓解活动 Identify the Business Transformation Risks and Mitigation Activities
识别与架构愿景有关的风险并评估风险的初始等级（如，灾难性的、关键性的、不重要的或可忽略的）以及与之相关联的潜在频率。为每个风险指派一个缓解策略。在第三部分第31章描述风险管理框架。应考虑两个风险等级，即：
■风险的初始等级：确定和实施缓解行动前的风险等级
■风险的残余等级：实施缓解行动后的风险等级（如果有）
应考虑在架构工作说明书中包含风险缓解活动。
7.4.11开发架构工作说明书；确保批准 Develop Statementof Architecture Work; Secure Approval
评估根据业务绩效需求集产生（以及至何时）的所需的工作产物。这将涉及确保：
■绩效衡量标准被构建到工作产物中。
■与绩效相关的特定工作产物是可用的。那么，活动会包括：
—识别需要变更的新的工作产物
—提供包括构建块在内的现有工作产物将会变化的方向，并确保所有活动及其依赖性是协调的
—识别变更对其他工作产物及其活动的依赖度的影响
—基于目的、聚焦点、范围和约束，确定应开发哪些架构域，开发到什么细节层级并且应构建何种架构视图
—评估在所需时间区间内执行工作的资源需求和可用性，包括遵守组织规划方法和工作产物以产生执行ADM周期的计划
—预估所需的资源，为所建议的开发制定路线图和进度安排，并在架构工作说明书中记录全部的内容
—定义在ADM周期内将由企业架构团队达成的绩效衡量标准
—开发特定企业架构沟通计划并表明企业架构师在何处、用何种方式以及何时与利益攸关者（包括关联组和群体）就企业架构开发的进展进行沟通
—审视并与发起人商议计划，并按照适当的治理程序确保对架构工作说明书的正式批准
—获得发起人的签字以便继续进行
7.5输出 Outputs
阶段A的输出可包括但不限于：
■批准的架构工作说明书（见第四部分36.2.20节），尤其包括：
—架构项目描述和范围
—架构愿景的概述
—架构项目计划和进度安排
■业务原则、业务目标和业务驱动因素的细化说明（见第四部分，36.2.9 节）。
■架构原则（见第四部分第23章）。
■能力评估（见第四部分36.2.10节）。
■经剪裁的架构框架（见第四部分36.2.21节）（用于该工作），包括:
—经剪裁的架构方法
—经剪裁的架构内容（交付物和制品）
—经配置和部署的工具
■架构愿景（见第四部分36.2.8节），包括：
—问题描述
—架构工作说明书的目的
—概要视图
—业务场景（可选）
—细化的关键高层级利益攸关者需求
■草拟的架构定义文件，包括（当在范围中时）：
—基线业务架构，版本0.1
—基线技术架构，版本0.1
—基线数据架构，版本0.1
—基线应用架构，版本0.1
—目标业务架构，版本0.1
—目标技术架构，版本0.1
—目标数据架构，版本0.1
—目标应用架构，版本0.1
■沟通计划（见第四部分36.2.12节）。
■充实架构存储库的增加内容（见第四部分36.2.5节）。
注：多重业务场景可被用于产生一个单一架构愿景。
输出可包括下列的一些或全部内容：
■矩阵：
—利益攸关者映射矩阵
■图：
—价值链图
—解决方案概念图
第8章 阶段B:业务架构 Phase B: Business Architecture
本章描述用以支持商定的架构愿景的业务架构的开发。
图8-1阶段B：业务架构
8.1目的 Objectives
阶段B的目的是：
■开发目标业务架构，该架构描述企业需要如何运行，从而以表达架构工作要求书和利益攸关者关注点的方式达成业务目标，并响应架构愿景中设定的战略驱动因素。
■基于基线业务架构与目标业务架构之间的差距来识别候选架构路线图组件。
8.2实施途径 Approach
概括来说，业务架构描述产品和/或服务战略，以及业务环境的组织、功能、流程、信息和地理方面。
8.2.1概述 General
对业务架构的了解是在任何其他领域（数据、应用、技术）进行架构工作的前提，因此，如果在其他组织流程（企业规划、战略业务规划、业务流程再造等）中不满足需要，业务架构则是需要进行的第一个架构活动。
实际上，作为向关键利益攸关者表明后续架构工作的业务价值，以及向支持和参与后续工作的利益攸关者表明投资收益的一种手段，业务架构通常也很有必要。
阶段B中的工作范围将在很大程度上依赖于企业环境。在一些情况下，业务架构的关键元素可能在其他活动中开展，如企业使命、愿景、战略和目标可能已被文件化，作为在企业内具有其自身生命周期的一些更广泛的业务战略或企业规划活动的部分。
在这种情况下，可能需要验证和更新目前己被文件化的业务战略和计划，和/或在另一方面，需要在高层级业务驱动因素、业务战略和目标与本架构开发工作相关的特定业务需求之间建立桥梁。业务战略通常定义达成什么——目标和驱动因素，以及成功的衡量标准——而不是如何达到，那是业务架构的工作。
在其他情况下，到现阶段为止，可能几乎没有开展任何架构工作。在这种情况下，架构团队需要对架构支持的关键业务目的和流程进行研究、验证和获得认同。这可能被作为一次独立活动来训练，或者在架构开发之前或者作为阶段A的部分来完成。
在这两种情况下，可使用TOGAF ADM的业务场景技巧（见第三部分第26章）或任何阐明关键业务需求并指出隐含的IT架构技术需求的其他方法。
一个关键目的是尽可能复用现有的资料。在架构方面更成熟的环境中，将存在（但愿如此）自最后一个架构开发周期起保留至今的现有架构定义。在存在架构描述的情况下，这些描述可作为起点使用，必要时可进行验证和更新：见第五部分，39.4.1节。
只采集和分析那些能够做出与本架构工作范围相关的有依据的决策信息。如果本工作聚焦于（可能是新的）业务流程的定义，那么阶段B将必然涉及许多细节工作。如果聚焦点更多的是关于其他领域（数据/信息、应用系统、基础设施）中的目标架构以支持一个基本的现有业务架构，那么重要的是在阶段B中构建一个完整图像，而不陷入不必要的细节。
8.2.2开发基线描述 Developing theBaseline Description
如果一个企业具有架构描述，那么这些描述应被用作基线描述的基础。这个输入可能已经用于阶段A中开发架构愿景，甚至可能足以将其本身用于基线描述。如果不存在这样的描述，则应不论格式的采集信息。
开发目标架构的正常途径是自顶向下。然而，在基线描述中，对当前状态的分析通常必须自底向上完成，特别是在几乎不存在架构资产的情况下。在这种情况下，架构师只是必须将关于高层级架构的工作假设文件化，直到边际效用递减规律出现前，该过程是将工作假设转变为事实而收集的证据之一。
未继续执行的业务流程不具有内在价值。然而，在其他架构域中开发基线描述时，未继续执行的架构组件（原则、模型、标准和当前存储清单）可能仍然具有内在价值，并且可能需要存储清单以了解这些组件的剩余价值（如果有）。
无论是什么途径，目标应是尽可能复用现有资料，只采集和分析有助于做出与目标业务架构相关的有依据的决策信息。重点在于构建一个完整图像，而不陷入不必要的细节。
8.2.3业务建模 Business Modeling
业务模型应是根据架构愿景对业务场景进行的逻辑扩展，以便该架构能够从高层级业务需求向下映射至更详细的需求。如果认为适当，记住上述关于不要陷入不必要细节的警告，可采用各种建模工具和技巧。例如：
■活动模型（也称为业务流程模型）描述与企业业务活动相关联的功能、活动之间交换的数据和/或信息（内部交换）以及与模型范围之外的其他活动交换的数据和/或信息（外部交换）。活动模型在本质上是层级化的，它们捕获在业务流程中所进行的活动，以及那些活动的ICOMs （输入、控制、输出和机制/所使用的资源）。活动模型可注释有显性的业务规则说明，以表示ICOMs间的关系。例如，业务规则可规定在指定条件下由谁做什么、所需输入与控制项的组合以及产生输出。一种用于创建活动模型的技巧是IDEF [集成计算机辅助制造（ICAM）定义]的建模技术。
对象管理组（OMG） 已开发了业务流程建模符号（BPMN），是一种用于业务流程建模的标准，包括一种规定业务流程及其任务/步骤以及生成文件的语言。
■用例模型可依据建模的聚焦点描述业务流程或系统功能。用例模型依据于业务流程和组织参与者（人员、组织等）的用例和施动者描述企业的、业务流程。以用例图和用例规范描述用例模型。
■类模型与逻辑数据模型相似。类模型描述静态信息以及信息间的关系，类模型还描述信息的行为。类似于许多其他模型，类模型还可用于各种粒度级的建模。依据模型的意图，类模型可表示业务域实体或系统实施类别。业务域模型表示关键业务信息（域类别）、业务特征（属件）及其行为（方法或运行）和关系（通常被称为多重性，描述典型情况下有多少类参与到该关系之中）以及基数（描述关系中所需或选的参项）。规范进一步详细阐述和详细说明在该类图中不能表示的信息。
图8-2 UML业务类图
上述这三种类型的模型均可使用统一建模语言（UML）表达，并且存在各种用于生成这种模型的工具。
某些行业对所关注的领域有特定的建模技巧。例如，防务领域使用下述模型。这些模型必须谨慎地使用，特别是如果业务流程的位置和执行将会在未来的业务架构中发生改变的情况。
■节点连接图描述业务位置（节点）、位置间的“需求线”以及所交换信息的特征。节点连接性可在三个层级上描述：概念、逻辑和物理层级。每个需求线均表示两个连接节点间信息传输的某类需求。一个节点可表达一个角色（如CIO）、一个组织单元、一个业务位置或设施等。标注出表示信息流方向的箭头，以描述数据或信息的特征——例如，其内容、介质、安保性或分类等级、时间线和对信息系统互用性的需求。
■信息交换矩阵记录使企业架构的信息交换需求文件化。
信息交换需求表达了三个基本实体（活动、业务节点及其元素和信息流）间的关系，并聚焦于信息交换的特征（诸如性能和安保性）识别谁与谁交换了什么信息、为什么该信息是必要的，以及采用的方式。虽然这些模型最初开发用于防务领域，但是，越来越多地被政府的其他部门使用，并且也可能被考虑用于非政府环境。
8.2.4架构存储库 ArchitectureRepository
作为阶段B的部分，架构团队需要考虑从架构存储库（参见第五部分第41章）中可获得哪些相关的业务架构资源，尤其是：
■ 一般业务模型与组织所属行业领域有关。依照企业的连续统一体，这些属于“行业架构”。通用业务模型被保存在架构存储库的参考库中（见第五部分41.3节）。例如：
— 对象管理组（OMG）www.omg.org 拥有很多垂直域任务组来开发与特定垂直域（诸如医疗保健、交通、金融等）有关的业务模型。
— 电信管理论坛（TMF）www.tmforum.org己开发了与电信行业有关的详细业务模型。
— 不同国家的政府部门和机构强制使用的参考模型和框架，旨在促进跨部门的综合和协同工作能力。例如，联邦企业架构业务参考模型，这是一个功能驱动的框架，用于描述独立于业务运行机构的联邦政府所进行的业务运行。
■与常用高层级业务域有关的业务模型。例如：
— 资源—事件—代理人（REA）业务模型最初由密歇根州立大学的WilliamE.McCarthy 创建（参照 www.msu.edu/user/mccarth4），主要用于会计系统的建模。该模型已被证明对于更好地理解业务流程是十分有用的，从而成为传统企业和电子商务系统的主要建模框架之一。
— STEP框架（产品模型数据交换标准）关注于产品设计和供应链交互工作。STEP是一个ISO标准（IS010303）。STEP标准的实施己经由一些大型航空航天制造商所引领，并且也被诸如建筑业等其他需要复杂图形和流程数据的行业所接纳。
— RosettaNet www.rosettanet.org 是由在计算机、电子组件以及半导体制造供应链方面的领先企业所创建的企业联盟。RosettaNet的任务是开发用于这些供应链的一系列完整的标准电子商务流程，并促进和支持这些流程的采纳和使用。
■企业特定构建块（流程组件、业务规则、工作描述等）。
■可用的标准。
8.3输入 Inputs
本节定义了对阶段B的输入。
8.3.1企业外部参考资料 Reference MaterialsExternal to the Enterprise
■架构参考资料（见第四部分36.2.5节）
8.3.2非架构输入 Non-ArchitecturalInputs
■架构工作要求书（见第四部分36.2.17节）
■业务原则、业务目标和业务驱动因素（见第四部分36.2.9节）
■能力评估（见第四部分36.2.10节）
■沟通计划（见第四部分36.2.12节）
8.3.3架构输入 ArchitecturalInputs
■企业架构的组织模型（见第四部分36.2.16节），包括：
— 组织受影响的范围
— 成熟度评估、差距和解决途径
— 架构团队的角色和职责
— 对架构工作的约束
— 预算需求
— 治理和支持战略
■经剪裁的架构框架（见第四部分36.2.21节），包括：
—经剪裁的架构方法
—经剪裁的架构内容（交付物和制品）
—经配置和部署的工具
■经批准的架构工作说明书（见第四部分36.2.20节）
■架构原则（见第四部分36.2.4节），包括业务原则（当预先存在时）
■企业的连续统一体（见第五部分第39章）
■架构存储库（见第四部分36.2.5节），包括：
—可复用的构建块
—公开可用的参考模型
—组织特定参考模型
—组织标准
■架构愿景（见第四部分36.2.8节），包括：
—问题描述
—架构工作说明书的目的
—概要视图
—业务场景（可选）
—细化的关键高层级利益攸关者需求
■ 草拟的架构定义文件，包括（当在范围中时）：
—基线业务架构，0.1版本
—基线技术架构，0.1版本
—基线数据架构，0.1版本
—基线应用架构，0.1版本
—目标业务架构，0.1版本
—目标技术架构，0.1版本
—目标数据架构，0.1版本
—目标应用架构，0.1版本
8.4步骤 Steps
阶段B中所涉及的细节层级取决于总体架构工作的范围和目标。
作为这项工作的部分而被引入的新的业务流程需要在阶段B期间被详细定义。在目标环境中延用并被支持的现有业务流程，可能己经在之前的架构工作中被充分定义；但是如果没有，它们也需要在阶段B中被定义。
阶段B中的步骤顺序（见下文）及其正式开始和完成的时间应适应于当前情况，秉承已经建立的架构治理。尤其是，在这种情况下确定首先实施基线架构开发还是实施目标架构开发更合适，如第三部分第19章所述。
在这些步骤中已经启动的所有活动必须在最终确定业务架构步骤（见8.4.8节）时结束。这些步骤生成的文档必须在创建架构定义文件步骤（见8.4.9节）中正式发布。
阶段B中的步骤如下：
■选择参考模型、视角和工具（见8.4.1节）
■开发基线业务架构描述（见8.4.2节）
■开发目标业务架构描述（见8.4.3节）
■进行差距分析（见8.4.4节）
■定义候选路线图组件（见8.4.5节）
■化解贯穿整个架构全景中的影响（见8.4.6节）
■进行正式的利益攸关者审视（见8.4.7节）
■最终确定业务架构（见8.4.8节）
■创建架构定义文件（见8.4.9节）
8.4.1选择参考模型、视角和工具 Select ReferenceModels, Viewpoints, and Tools
基于业务驱动因素、利益攸关者和关注点从架构存储库中选择相关的业务架构资源（参考模型、特征模式等）。
选择相关的业务架构视角（如运行、管理、财务）；即，使架构师能够展示利益攸关者的关注点在业务架构中如何得到处理的那些视角。
结合选定的视角，识别用于捕获、建模和分析的适当工具和技巧。根据认可的复杂程度，这些工具和技巧可包括简单的文件或电子表格，或更复杂的建模工具和技巧，如活动模型、业务流程模型、用例模型等。
8.4.1.1确定总体建模流程
针对每个视角，使用选定的工具或方法来选择所需模型以支持所要求的特定视角。确保所有利益攸关者的关注点都被涵盖。若没有，就要创建新模型以应对未涵盖的关注点或扩展现有模型（见8.2.3节）。业务场景是一种发现和记录业务需求的有用技巧，并且可在业务架构层级分解中的不同细节层级上迭代使用。业务场景在第三部分第26章中描述。
活动模型、用例模型和类模型之前作为使能组织业务架构定义的技巧被提及。在许多情况下，这三种途径均可按顺序加以利用，以逐步分解一个业务。
■结构化分析：识别架构范围内的关键业务功能，并将这些功能映射到业务内的组织单元。
■用例分析：贯穿一个功能中多个施动者和组织的业务层级功能的分解，允许将其分解成支持/交付多个功能能力的服务。
■流程建模：通过流程建模中一个功能或业务服务的分解能够识别该流程的元素，并允许识别低层级的业务服务或功能。
在不同企业之间以及在企业内，所需分解的层级和严格程度是不同的。架构师应考虑企业架构的目标、目的、范围以及企业努力确定分解层级的目的。
8.4.1.2识别所需的服务粒度层级、边界和契约
TOGAF内容框架在业务功能和业务服务之间是有区别的。业务服务是特定功能，这些功能具有被明确治理的清晰且限定的边界。为有助于架构师在适于业务并可由该业务管理的粒度层级上灵活定义业务服务，这些功能按如下划分：
微观层级的功能将具有明确且限定的边界，但是可能无法被明确治理。与此类似，宏观业务功能可被明确治理，但是可能不具有明确且限定的边界。
因此，业务架构阶段需要识別哪些架构组件是功能，哪些是服务。通过明确定义服务契约，将服务4功能区别开来。开发基线架构时可能不存在明确的契约，因此，在审查目标架构前，应依据架构师的意见来确定开发这样的契约是否值得。
服务契约涵盖业务/功能界面以及技术/数据界面。业务架构在业务/功能层级上定义服务契约，并在应用和技术架构阶段展开。
业务服务的粒度应根据本业务领域的业务驱动因素、目标、目的和测度确定。更细粒度的服务有助于使管理和衡量更紧密（并且可被组合产生粗粒度服务），似是就要求在治理方面付诸更多的努力。识别服务并定义其契约的指南可在第三部分第22章中找到。
8.4.1.3识别所需的业务构建块目录集
目录集捕获业务的核心资产清单。目录集本质上是分层级的，并贯穿单个构建块的分解以及相关构建块（如组织/施动者）之间的分解。
目录集构成用于矩阵和视图开发的原始资料，并充当项目谱系管理业务和IT能力的关键资源。
应考虑在业务架构内开发下列目录集：
■组织/施动者目录集
■驱动因素/目标/目的目录集
■角色目录集
■业务服务/功能目录集
■位置目录集
■流程/事件/控制/产品目录集
■契约/测度目录集
目录集结构基于元模型实体的属性，如第四部分第34章所定义。
8.4.1.4识别所需的矩阵
矩阵表明相关模型实体之间的核心关系。
矩阵形成视图开发的原始资料，并充当作为差距分析的一部分而被实施的影响
评估的关键资源。
应考虑为在业务架构内开发下列矩阵：
■业务交互矩阵（表明组织与施动者之间的依赖性和沟通）。
■施动者/角色矩阵（表明每个施动者承担的角色）。
矩阵结构基于元模型实体的属性，如第四部分第34章所定义。
8.4.1.5识别所需的图
根据利益攸关者的需求，图代表从一系列不同的关注层面（视角）展示的业务架构信息。
为在业务架构内开发，应考虑下列图：
■业务印迹图。
■业务服务/信息图。
■功能分解图。
■目标/目的/服务图。
■用例图。
■组织分解图。
■过程流图。
■事件图。
图结构基于元模型实体的属性，如第四部分第34章所定义。
8.4.1.6识别待收集的需求类型
一旦开发了业务架构目录集、矩阵和图，通过将为了实施目标架构而聚焦于业务的需求进行正规化来完成架构建模。
这些需求可以：
■与业务域相关。
■提供对数据架构、应用架构和技术架构的需求输入。
■提供将在设计和实施期间要被反映的详细引导，以确保解决方案应对最初的架构需求。
在本步骤中，架构师应识别该架构应满足的需求（见17.2.2节）。
在许多情况下，架构定义并非旨在给出对解决方案的详细或全面需求（因为这些需求可通过一般需求管理规程更好地应对）。期望的需求内容范围应在架构愿景阶段建立，并记录在已批准的架构工作说明书中。
在架构工作说明书所定义的范围之外的任何需求或需求变更必须提交至需求存储库，以通过受治理的需求管理流程进行管理。
8.4.2开发基线业务架构描述 Develop BaselineBusiness Architecture Description
开发现有业务架构的一种某线描述，达到支持目标业务架构所必需的程度。待定义的范围和细节层级，将取决于现有的业务元素有可能延用到目标业务架构中的程度，并取决于架构描述是否存在，如8.2节所述。尽可能地利用架构存储库（参见第五部分第41章）识别相关的业务架构构建块。
当需要开发新架构模型以满足利益攸关者的关注点时，使用步骤1中识别的模型作为创建用于描述基线架构的新架构内容的指南。
8.4.3开发目标业务架构描述 Develop TargetBusiness Architecture Description
为业务架构开发一种目标描述，达到支持架构愿景所必需的程度。待定义的范围和细节层级，将取决于业务元素与实现目标架构愿景之间的相关性，并取决于架构描述是否存在。尽可能地利用架构存储库（见第五部分第41章）识别相关的业务架构构建块。
当需要开发新的架构模型以满足利益攸关者的关注点时，使用步骤1中识别的模型作为创建用于描述目标架构的新架构内容的指南。
8.4.4进行差距分析 Perform GapAnalysis
验证架构模型的内部一致性和准确度：
■进行权衡分析，以解决不同视图间的冲突（如果有）。
■确认模型支持的原则、目的和约束。
■对以架构存储库中选定模型中所表达的视角变更进行注释，并文件化。
■按需求测试架构模型的完整性。
使用第三部分第27章中描述的差距分析技巧识别基线与目标之间的差距。
8.4.5定义候选路线图组件 Define CandidateRoadmap Components
创建基线架构、目标架构和差距分析结果之后，需要一个业务路线图，以确定后续阶段中活动的优先顺序。
这个初始业务架构路线图，将用作支持机会和解决方案阶段中合并的、跨学科路线图的更详细定义的原始资料。
8.4.6化解贯穿整个架构全景中的影响 Resolve ImpactsAcross the Architecture Landscape
一旦最终确定了业务架构终结，理解更广泛的影响或含义是很有必要的。
在这个阶段，应审查架构全景中的其他架构制品以期识别：
■这个业务架构是否对之前存在的架构产生影响？
■是否已经做出影响业务架构的最新变革？
■是否有机会更有力地发挥本业务架构中的工作在该组织其他领域中的作用？
■本业务架构是否影响其他项目（包括已计划的和目前正在进行的项目）？
■本业务架构是否受到其他项目（包括已计划的和目前正在进行的项目）的影响？
8.4.7进行正式的利益攸关者审视 Conduct FormalStakeholder Review
根据建议的业务架构检查架构项目和架构工作说明书的原始动机，询问其是否适于支持其他架构域中后续工作的目的。仅在必要时对建议的业务架构进行细化。
8.4.8最终确定业务架构 Finalize theBusiness Architecture
■为每个构建块选择标准，尽可能复用从架构存储库中选择的参考模型。
■完整每个构建块的文件记录。
■根据业务目标对总体架构进行最终交叉检查；在架构文件中记录构建块决策的理由依据。
■文件化最终的需求可追溯性报告。
■文件化架构存储库中架构的最终映射，在选定的构建块中识别可能复用的部分（工作实践、角色、业务关系、职位描述等），并通过架构存储库发布。
■最终确定所有的工作产物，如差距分析结果。
8.4.9创建架构定义文件 Create ArchitectureDefinition Document
■在架构定义文件中记录构建块决策的理由依据
■准备架构定义文件的业务章节，包括部分或全部下列内容：
—业务印迹（对涉及关键业务功能的人员和位置的高层级描述）
—业务功能及其信息需求的详细描述
—管理印迹（表明控制的幅度和可追究的责任）
—表明工作实践、法规和财务测度等的标准、规则和指南
—技能矩阵和一系列职位描述
如适用，使用由建模工具生成的用来展现架构的关键视图的报告和/或图。分发文件以供相关利益攸关者审视，并纳入反馈。
8.5输出 Outputs
阶段B的输出可包括但不限于：
■架构愿景阶段交付物的经过细化和更新的版本，在适用情况下，包括：
—架构工作说明书（见第四部分，36.2.20节），必要时进行更新
—确认的业务原则、业务目标和业务驱动因素（见第四部分36.2.9节），必要时进行更新
—架构原则（见第四部分36.2.4节）
■草拟的架构定义文件（见第四部分36.2.3节），包括：
—基线业务架构，版本1.0 （详细），如适用
—目标业务架构，版本1.0 （详细），包括：
—组织结构——识别业务位置并使其与组织单元相关联
— 业务目标和目的——用于企业和每个组织单元
—业务功能——一个详细的递归步骤，包括将主要功能领域逐步分解为子功能
— 业务服务——企业和每个企业单元向其内部和外部客户提供的服务
—业务流程，包括测度和交付物
—业务角色，包括技能需求的开发和修改
—业务数据模型
—与所选择的视角相对应的涉及关键利益攸关者关注点的视图
■草拟的架构需求规范（见第四部分36.2.6节），包括如下这类业务架构需求：
—差距分析结果
—技术需求——识别、分类和优先排序剩余架构域工作的含义，例如，通过依赖性/优先级矩阵（例如，指导对事务处理速度和安保性之间进行的权衡）；列出期望产生的特定模型（例如，表示为Zachman框架的原始形式）
—经过更新的业务需求
■架构路线图的业务架构组件（见第四部分36.2.7节）。
输出可包括部分或全部下列内容：
■目录集：
—组织/施动者目录集
—驱动因素/目标/目的目录集
—角色目录集
—业务服务/功能目录集
—位置目录集
—流程/事件/控制/产品目录集
—契约/测度目录集
■矩阵：
—业务交互矩阵
—施动者/角色矩阵
■图：
—业务印迹图
—业务服务/信息图
—功能分解图
—产品生命周期图
—目标/目的/服务图
—用例图
—组织分解图
—过程流图
— 事件图
第9章阶段C:信息系统架构 Phase C: Information Systems Architectures
本章描述架构项目的信息系统架构，包括数据架构和应用架构的开发。
图9-1阶段C：信息系统架构
第10章阶段C:信息系统架构——数据架构 Phase C: Information Systems Architectures — Data Architecture
本章描述阶段C的数据架构部分。
第11章阶段C:信息系统架构——应用架构PhaseC: Information Systems Architectures — Application Architecture
本章描述阶段C的应用架构部分。
第12章阶段D:技术架构 Phase D: Technology Architecture
本章描述架构项目中技术架构的开发。
第13章阶段E:机会和解决方案 Phase E: Opportunities & Solutions
本章描述识别各种交付载体（项目、项目群或项目谱系）的流程，以有效地交付此前各阶段识别的目标架构。
第14章阶段F:迁移规划 Phase F: Migration Planning
本章论述迁移规划，即如何通过最终确定一个详细的实施和迁移计划将基线架构迁移至目标架构。
第15章阶段G:实施治理PhaseG: Implementation Governance
本章提供对实施的架构化监督。
第16章阶段H:架构变更管理PhaseH: Architecture Change Management
本章着眼于为管理变更以达到新架构而建立程序。
第17章ADM架构需求管理ADMArchitecture Requirements Management
本章关注于贯穿ADM始终的架构需求管理流程。