TOGAF9中文口袋书

1TOGAFTMVersion9-APocketGuide第1章TOGAF概述本章对TOGAF9进行了简介，涉及的主题包括：◎TOGAF简介◎TOGAF的结构和内容◎TOGAF涉及的各类架构1.1.TOGAF9简介TOGAF是一个架构框架，即开放群组架构框架（TheOpenGroupArchitectureFramework）。简言之，它是一种工具，用来帮助架构的接受、创建、使用和维护。它基于一个迭代的过程模型，由一些最佳实践和一套可重用的已有架构资产支持。TOGAF是由TheOpenGroup架构论坛来开发和维护的。TOGAF第一版于1995年开发，当时是基于美国国防部的信息管理技术架构框架（TechnicalArchitectureFrameworkforInformationManagement，TAFIM）。从这个坚实的基础开始，TheOpenGroup架构论坛就一直在定期开发TOGAF的各个后续版本，并将每个版本都发布在TheOpenGroup的网站上。本文覆盖了TOGAF第9版，在本文中简称“TOGAF9”。TOGAF9于2009年1月正式发布，它是从TOGAF8.1.1演进过来的，附录A对变化进行了描述。TOGAF9可用于开发各类不同的企业架构。TOGAF对其他框架进行了补充，并可与这些框架共同使用，这些框架一般更关注特定垂直行业的具体交付物，如政府、电信、制造、国防和金融等行业。TOGAF的关键是其开发企业架构的方法，即TOGAF架构开发方付莱TOGA口袋书2.indd12011-8-519:06:292TOGAFTMVersion9-APocketGuide法（ArchitectureDevelopmentMethod，ADM），以开发出能处理各类业务需求的企业架构。1.2.TOGAF文档的结构TOGAF第9版包括7个部分，如表1—1所示。1.3.什么是TOGAF上下文中的架构ISO/IEC42010:20072把“架构（Architecture）”定义为：“一个系统基本的组织，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及治理其 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 和演进的原则上。”TOGAF接受并扩展了这个定义。在TOGAF中，“架构（Architecture）”根据上下文有两种含义：表1—1：TOGAF文档的结构2ISO/IEC42010:2007，系统和软件工程-软件密集系统的架构描述的推荐做法，第一版（技术上等同于ANSI/IEEEStd1471-2000）。付莱TOGA口袋书2.indd22011-8-519:06:293TOGAFTMVersion9-APocketGuide3数据架构在某些组织被叫做信息架构。（1）一个系统的形式化描述，或指导系统实现的构件级的详细计划。（2）一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。1.4.TOGAF涉及哪些类型的架构TOGAF9涵盖了相互关联的四种类型的架构的开发。一般都把这四类架构看作是一个完整企业架构的子集，TOGAF支持所有这些架构。这些架构如表1—2所示。表1—2：TOGAF支持的各类架构1.5.TOGAF包括哪些内容TOGAF描述了企业内一套架构能力的结构和内容，如图1—1所示。付莱TOGA口袋书2.indd32011-8-519:06:294TOGAFTMVersion9-APocketGuide图1—1：TOGAF内容概览TOGAF的核心是架构开发方法（ADM）（TOGAF9第二部分介绍）。架构能力（TOGAF9第七部分）按照该方法操作。ADM方法由多种指导策略和技术（TOGAF9第三部分介绍）支持。ADM方法产生的内容被存放到存储库中（TOGAF9第四部分介绍），这些内容根据企业连续系列进行分类（TOGAF9第五部分介绍）。存储库最初填充的内容由TOGAF参考模型（TOGAF9第六部分介绍）组成。1.5.1架构开发方法（ADM）ADM描述了如何得到一个特定组织的企业架构，以用来应对业务需求。ADM是TOGAF的重要组成部分，它在以下各个层面上为架构师提供了指导：付莱TOGA口袋书2.indd42011-8-519:06:305TOGAFTMVersion9-APocketGuide◎它介绍了处于一个周期中的多个架构开发阶段（业务架构阶段、信息系统架构阶段、技术架构阶段），可作为架构开发活动的完整过程模板。◎它描述了每个架构阶段，包括对目的、路径、输入、步骤和输出各个方面的描述。其中输入和输出部分对架构内容的结构和各类交付物进行了定义（阶段输入输出的详细描述在架构内容框架中给出）。◎对需求管理进行了跨阶段的总结。ADM将在第2章进一步描述。1.5.2ADM指引和相关技术ADM指引和相关技术介绍了用来支持ADM应用的多种指导策略和相关技术。指导策略解决的问题是如何调整ADM以处理各类使用场景，这些指导策略包括不同的过程风格（如迭代的使用）以及特定的专业架构（如安全）。相关技术用来支持ADM中的具体任务（如原则的定义、业务场景、差距分析、迁移规划、风险管理等）。ADM指引将在第4章进一步描述。ADM相关技术以及关键交付物将在第3章详细描述。1.5.3架构内容框架TOGAF内容框架提供了架构工作产品的详细模型，包括交付物、交付物中的制品以及交付物代表的架构构建块。架构内容框架将在第5章进一步描述。1.5.4企业连续系列企业连续系列介绍了一个对虚拟的存储库进行结构化的模型，并介绍了对架构和解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 制品进行归类的方法，展示了这些不同付莱TOGA口袋书2.indd52011-8-519:06:346TOGAFTMVersion9-APocketGuide类型的制品如何演变、如何被利用和重用。企业连续系列基于广泛存在于企业内和业界的各种架构和解决方案（模型、模式、架构描述等），这些架构和解决方案企业都可以汇集以用于其自身架构的开发。企业连续系列将在第6章进一步描述。1.5.5TOGAF参考模型TOGAF介绍了两种参考模型，这两种模型企业都可将其纳入自身的企业连续系列。这两种参考模型分别是TOGAF技术参考模型（TechnicalReferenceModel,TRM）和集成信息基础设施模型（IntegratedInformationInfrastructureModel,III-RM）。TOGAF参考模型将在第7章进一步描述。1.5.6架构能力框架（ArchitectureCapabilityFramework）架构能力框架（ArchitectureCapabilityFramework）是一套资源、指引、模板、背景信息等，用以帮助架构师在组织中建立起一套架构实践。架构能力框架将在第8章进一步描述。付莱TOGA口袋书2.indd62011-8-519:06:347TOGAFTMVersion9-APocketGuide第2章架构开发方法本章描述了架构开发方法（ADM）、它与TOGAF其他部分之间的关系，以及使用ADM时的一些要点。本章也包括了ADM各阶段的简要介绍。本章涉及的主题包括：◎ADM的介绍◎ADM的各个阶段◎ADM各阶段的目的、步骤、输入和输出◎ADM整个周期中的需求管理◎界定架构活动的范围2.1什么是ADMADM来自于众多架构师的贡献，它构成了TOGAF的核心。ADM是一种用来获得特定组织企业架构的方法，特别为应对业务需求而设计。ADM描述了：◎一种可靠的、经过验证的开发和使用企业架构的方式◎一种在不同层次4（业务、应用、数据、技术）上开发架构的方法，使架构师能够确保各种复杂的需求都能被充分考虑到◎对架构开发工具的一些指导策略2.2ADM有哪些阶段ADM包含了若干阶段，这些阶段在一系列架构域内进行循环，使架构师能够确保各种复杂的需求都能被充分地考虑到。ADM的基4在TOGAF中这被称为一系列架构域付莱TOGA口袋书2.indd72011-8-519:06:348TOGAFTMVersion9-APocketGuide图2-1：架构开发方法（ADM）周期ADM方法在整个架构开发的过程中、过程的某些阶段之间，以及在某些阶段的内部以迭代的方式被应用。在ADM的整个周期内，应当频繁地对原始需求的当前结果进行验证，这里的原始需求包括整个ADM周期的原始需求，也包括流程中特定阶段的原始需求。在验证时应重新考虑范围、细节、进度表和里程碑。每个阶段应考虑利用ADM过程的前序迭代产生的资产和来源于市场的外部资产，如其他框架或模型等。ADM在如下三个级别上支持了迭代的概念：◎ADM整体循环：ADM以一个循环的方式表示，即一个阶段的架构工作完成后的成果直接输入到架构工作的后续阶段中去。◎阶段之间的循环：TOGAF描述了跨阶段迭代的概念（例本结构如图2—1所示。付莱TOGA口袋书2.indd82011-8-519:06:349TOGAFTMVersion9-APocketGuide如，在技术架构完成之后再返回到业务架构阶段去）。◎单个阶段的循环：作为一种细化架构内容的技术，TOGAF支持单个ADM阶段内活动的重复执行。有关迭代的更多信息在TOGAF9第三部分：ADM指引和技术中给出（参见第4章）。表2—1列出了对架构开发方法各阶段活动的描述。表2—1：架构开发方法各阶段的活动付莱TOGA口袋书2.indd92011-8-519:06:3610TOGAFTMVersion9-APocketGuide2.3ADM详细介绍下面各小结中的 表格 关于规范使用各类表格的通知入职表格免费下载关于主播时间做一个表格详细英语字母大小写表格下载简历表格模板下载 对ADM周期中各个阶段的目的、步骤，以及输入和输出进行了总结5。2.3.1预备阶段预备阶段为组织成功实施企业架构项目做好了准备。本阶段的概述如表2-2所示：表2—2：预备架构阶段的简要描述5在本口袋书中具体交付物的版本号被忽略了，因为TOGAF强调ADM编号方案只是范例，它应当根据需要进行调整。付莱TOGA口袋书2.indd102011-8-519:06:3611TOGAFTMVersion9-APocketGuide2.3.2阶段A：架构愿景阶段A主要涉及架构项目的建立，它启动了架构开发周期的新一轮迭代，设定了本次迭代的范围、约束和预期结果。为了能够验证业务背景、创建架构工作说明书并获得批准，这个阶段是必不可少的。本阶段的概述如表2-3所示：表2—3：架构愿景阶段的简要描述付莱TOGA口袋书2.indd112011-8-519:06:3812TOGAFTMVersion9-APocketGuide2.3.3阶段B：业务架构阶段B主要是建立业务架构，以支持已达成共识的架构愿景，如表2-4所示。表2—4：业务架构阶段的简要描述付莱TOGA口袋书2.indd122011-8-519:06:3813TOGAFTMVersion9-APocketGuide2.3.4阶段C：信息系统架构阶段C主要是描述一个组织的IT系统的基本组织，体现在各种主要的信息类型以及处理这些信息的应用系统上。这个阶段包括如下两个步骤，这两个步骤可以以顺序或并行的方式进行：数据架构应用架构2.3.4.1数据架构数据架构的概述如表2-5所示。表2—5：数据架构阶段的简要描述付莱TOGA口袋书2.indd132011-8-519:06:3914TOGAFTMVersion9-APocketGuide2.3.4.2应用架构应用架构的概述如表2-6所示。表2—6：应用架构阶段的简要描述付莱TOGA口袋书2.indd142011-8-519:06:3915TOGAFTMVersion9-APocketGuide2.3.5阶段D：技术架构阶段D主要是描述IT系统的基本组织，体现在硬件，软件和通信技术上，如表2—7所示。表2—7：技术架构阶段的简要描述付莱TOGA口袋书2.indd152011-8-519:06:4016TOGAFTMVersion9-APocketGuide2.3.6阶段E：机会和解决方案阶段E是第一个直接关注实施的阶段。它描述了识别交付载体（包括项目、项目群组或项目组合）的过程，这些交付载体将交付前序阶段定义的目标架构，如表2—8所示。表2—8：机会和解决方案阶段的简要描述付莱TOGA口袋书2.indd162011-8-519:06:4017TOGAFTMVersion9-APocketGuide2.3.7阶段F：迁移规划阶段F关注的是迁移的规划：即，如何通过制定一份正式而详细的实施和迁移计划，从基线架构转换到目标架构，如表2-9所示。表2—9：迁移规划阶段的简要描述付莱TOGA口袋书2.indd172011-8-519:06:4118TOGAFTMVersion9-APocketGuide2.3.8阶段G：实施治理阶段G定义了如何通过架构来约束各个实施项目，在创建项目的同时对其进行监控，并产生一份被签署的架构契约，如表2-10所示。表2—10：实施治理阶段的简要描述付莱TOGA口袋书2.indd182011-8-519:06:4119TOGAFTMVersion9-APocketGuide2.3.9阶段H：架构变更管理阶段H确保了对架构的变更以可控的方式被管理，如表2-11所示。表2—11：架构变更管理阶段的简要描述付莱TOGA口袋书2.indd192011-8-519:06:4120TOGAFTMVersion9-APocketGuide2.3.10需求管理管理架构需求的流程适用于ADM周期的所有阶段。需求管理流程是一个动态的过程，它关注的是如何对企业的需求进行识别、存储，以及将这些需求输入到相应的ADM阶段并输出。正如图2—1所示，这个流程是驱动整个ADM过程的核心。处理需求中的变化的能力对于整个ADM过程来说是非常关键的，因为架构本身处理的就是不确定性和变化，在利益相关者的愿望和实际方案交付成果的差距间建立桥梁。本阶段的概述如表2-12所示：表2—12：需求管理阶段的简要描述付莱TOGA口袋书2.indd202011-8-519:06:4221TOGAFTMVersion9-APocketGuide2.4界定架构活动的范围ADM定义了在开发一个组织范围内的企业架构时，对各个阶段的推荐顺序和步骤，但是ADM不能决定范围：范围必须由组织自身来确定。约束（或限制）架构活动范围的原因有很多，主要的原因与下面的限制有关：◎创建架构的团队的组织权威性◎希望通过架构解决的目标和利益相关者的关注问题◎人力、财力和其他资源的可获得性理想情况下，架构活动选择的范围应当确保企业内所有架构师的工作都能被有效地治理和集成。这就需要有一系列相协调一致的“架构分区”，来确保架构师们的工作不会重复或存在冲突。同时，这也需要定义各架构分区之间的重用和一致性关系。企业及其架构相关活动的划分将在TOGAF9第三部分：ADM指引和相关技术（见第4章）进一步讨论。表2—13说明了可定义并限制架构范围的四个维度。表2—13：限定架构活动范围的各个维度付莱TOGA口袋书2.indd212011-8-519:06:4222TOGAFTMVersion9-APocketGuide第3章ADM周期的关键技术和交付物本章将帮助你理解ADM周期的各类关键技术和交付物。表3-1给出了本章的路线图，按ADM周期的阶段给出了阶段中用到的一些技术和交付物。对于每类技术和交付物，本章随后描述了其要点。付莱TOGA口袋书2.indd222011-8-519:06:4323TOGAFTMVersion9-APocketGuide表3—1：第3章的路线图付莱TOGA口袋书2.indd232011-8-519:06:4324TOGAFTMVersion9-APocketGuide3.1裁剪过的架构框架选择并裁剪框架是一个架构项目的实际起始点。比起从零开始创建框架，基于TOGAF建立框架有如下一些优点：◎当任务规模变得清晰时，它避免了最初的恐慌。◎确保对TOGAF的使用是系统性的，即“条理化的常识”。◎TOGAF总结了其他人在实际中发现的那些有用的办法。◎TOGAF已有了一套可重用的基准资源。◎TOGAF已在企业连续系列中定义了两个参考架构。但是，在TOGAF可以被有效地用于架构项目之前，在若干层次上对其进行裁剪是有必要的，而且应在预备阶段进行。首先，裁剪TOGAF模型并将其集成到企业中是非常有必要的。这种裁剪包括与项目和流程管理框架的集成、术语的定制、展现风格的确立、架构工具的选择、配置和部署等。所采用的任何框架的形式和细节也应该与企业其他的环境因素相协调，如文化、利益相关者、企业架构的商业模式以及架构能力的现有水平等。一旦框架已经根据企业的情况进行了裁剪，对其进行进一步的裁剪以适应特定的架构项目就变得很有必要了。这个级别的裁剪将选定适合的交付物和制品，来满足该项目及其利益相关者的需要。以下是一个裁剪过的架构框架中的典型内容：◎裁剪过的架构方法◎裁剪过的架构内容（交付物和制品）◎已配置并被部署的工具◎治理模型和其他框架的接口☆企业架构管理框架☆能力管理框架☆项目组合管理框架☆项目管理框架付莱TOGA口袋书2.indd242011-8-519:06:4325TOGAFTMVersion9-APocketGuide☆运营管理框架3.2企业架构的组织模型预备阶段产生的一个重要交付物是企业架构的组织模型。为了能成功地使用架构框架，必须得到企业内部合适的组织、角色和职责的支持。其中特别重要的是，要划定不同的企业架构从业者之间的界限、并明确跨越这些界限的治理关系。企业架构的组织模型的典型内容包括：◎被影响的组织的范围◎成熟度评估的结果、差距和解决方法◎架构团队的角色和职责◎对架构工作的约束◎预算要求◎治理和支持策略3.3架构原则本节的文档是预备阶段的初始输出。它们是对正在被开发的架构的一套通用规则要求和指导策略。关于指导策略和一组具体的通用架构原则，参见TOGAF9第三部分中的“架构原则”。本节文档推荐的内容分别是业务原则、数据原则、应用原则和技术原则。3.3.1确立架构原则一般由首席架构师与企业的CIO、架构委员会和其他关键的业务利益相关者一起，共同确立架构原则。如下的一些因素一般会影响架构原则的确立：◎企业的使命和计划：企业的使命、计划和组织结构基础设施。◎企业战略倡议：企业的特征—包括它的优势、弱点、机会和付莱TOGA口袋书2.indd252011-8-519:06:4326TOGAFTMVersion9-APocketGuide威胁——以及现有企业范围内的一些业务倡议（例如流程改进和质量管理等）。◎外部约束：市场因素（上市时间的紧迫性、客户期望等）；现有和潜在的立法。◎现有的系统和技术：企业内已部署的一套信息资源，包括系统文档、设备库存、网络配置图、策略和流程等。◎计算机行业的趋势：来自于可靠信息源以及当前在用最佳实践的，关于计算机和通信技术的使用、可用性和成本的预测。3.3.2定义架构原则根据组织的不同情况，可以在如下任一或所有三个级别上建立原则：◎企业原则：这类原则提供了决策的基础并 规定 关于下班后关闭电源的规定党章中关于入党时间的规定公务员考核规定下载规定办法文件下载宁波关于闷顶的规定 了组织该如何完成其使命。这些原则常见于政府和非营利组织，但也会作为一种协调决策制定的手段出现在商业组织中。它们是成功的架构治理战略中的关键要素。◎IT原则：这类原则对于整个企业如何使用和部署IT资源和资产提供了指导原则。确立这些原则是为了尽可能地提高信息环境的生产效率，降低生产成本。◎架构原则：这类原则是IT原则中与架构工作相关的一个子集。它们反映了整个企业的共识，体现了企业架构的精神。架构原则可以进一步划分为如下原则：☆对架构流程进行治理的原则，它们会影响到企业架构的开发、维护和使用☆对架构实施进行的治理原则TOGAF定义了描述原则的一种标准方式。除了定义的声明，每个原则还应有相关的依据和相关影响的声明，这两类声明都是为了促进对原则本身的理解和接受，并通过解释和论述为什么要作出某付莱TOGA口袋书2.indd262011-8-519:06:4327TOGAFTMVersion9-APocketGuide个具体的决定来支持对原则的使用。表3—2给出了TOGAF定义原则的模板：表3—2：TOGAF定义原则的模板3.3.3原则的质量辨识出一套好的原则有五个标准，如表3—3所示。表3—3：优质原则的推荐标准付莱TOGA口袋书2.indd272011-8-519:06:4428TOGAFTMVersion9-APocketGuide3.3.4使用架构原则架构原则是用来总结关于企业如何使用和部署IT资源和资产的基本事实的。这些原则可以以如下的不同方式被使用：1.提供一个框架，根据这个框架企业可以开始对IT进行自觉的决策2.作为建立相关评价准则的指导原则，在管理IT架构合规的一些后续阶段，对选择产品或产品架构施加强有力的影响3.作为定义架构功能性需求的驱动力4.作为一项输入，用以评估现有的IS/IT系统和未来战略性的项目组合这两者是否与已定义的架构相一致；这些评估将为识别出实施架构所需的过渡活动提供有价值的参考，以支持业务目标和优先事项的达成5.原则依据的声明强调了架构对于企业的价值，从而提供了证明架构活动正确性的基础6.原则相关影响的声明提供了一份企业遵循原则所需的关键任务、资源和潜在成本的概要计划；它们对于未来的过渡性倡议和规划活动也提供了有价值的输入7.在如下方面为架构治理活动提供了支持：☆对于标准的架构合规评估中、允许或需要解释的地方，提供了修改的余地☆当修正某个特定架构带来的相关影响无法通过局部操作流程解决时，支持发起一个特许请求原则之间是相互联系的，并且必须成套地使用。有时原则间会存在一定的冲突，例如，“可访问性”原则和“安全”原则。各个原则必须在“所有其他条件都相同”的条件下被考虑。有时需要在某一特定问题上决定优先考虑哪个原则。所有这些决定的依据必须被记录。原则看上去是不言自明的事实，但并不意味着在组织中原付莱TOGA口袋书2.indd282011-8-519:06:4429TOGAFTMVersion9-APocketGuide则能被实际地遵守，即使是对原则有着口头上的确认。虽然在原则的声明中没有规定具体的处罚措施，但对原则的违反一般都会引起运营问题，并会制约组织完成其使命的能力。3.4业务原则、业务目标和业务驱动力一份关于业务原则、业务目标和业务驱动力的声明通常先于架构活动在企业的其他地方被定义。作为预备阶段的输出，它们将被重新声明，并作为阶段A：架构愿景的一部分被再次审查。阶段A的审查活动是为了确保当前的定义正确且清晰。TOGAF9第三部分：ADM指引和相关技术中包含了一个含有八项业务原则的集合的例子，可以作为一个有用的起点。TOGAF对于这一交付物的内容没有定义，因为其内容和结构可能会随不同组织发生相当大的变化。3.5架构存储库架构存储库在企业中充当了与架构相关的所有项目的保存区域的作用。存储库使项目能够管理其交付物、定位可重用的资产，并向利益相关者和其他利益方发布输出物。对于架构存储库内容的描述，参见6.2节。架构存储库中的一般内容包括：◎架构框架◎标准信息库◎架构景观◎参考架构◎治理日志付莱TOGA口袋书2.indd292011-8-519:06:4430TOGAFTMVersion9-APocketGuide3.6架构工具作为预备阶段的一部分，架构师应选择并实施能支持架构活动的工具。TOGAF并不要求或推荐任何特定的工具。对于选择架构工具来开发各种所需的架构模型和视图，TOGAF提供了一套建议的评估标准。这些标准在TOGAF9第五部分，第42章进行描述。3.7架构工作请求书这是一份由赞助组织发给架构组织的文档，由它触发架构开发周期的开始。它是在架构组织的协助下、作为预备阶段的一项输出而被创建的。架构工作请求书也可作为被批准的架构变更请求的结果而被创建，或是根据来源于迁移规划的架构工作的参考条目而被创建。总的来说，这份文档中的所有信息都应该是比较概要的。这份文档的建议内容如下：1.赞助组织2.组织使命的声明3.业务目标（包括变化）4.业务的战略计划5.时间限制6.业务环境的变化7.组织的约束8.预算信息和财务约束9.外部约束和业务约束10.对现有的业务系统的描述11.对现有的架构/IT系统的描述12.对开发组织的描述13.对开发组织可用资源的描述付莱TOGA口袋书2.indd302011-8-519:06:4431TOGAFTMVersion9-APocketGuide3.8架构工作说明书架构工作说明书作为阶段A的一份交付物被创建，实际上它是架构组织和架构项目赞助者之间的一份契约。这份文档是对输入架构工作请求书后的响应（参见3.6节）。它应当描述一份全面的计划，说明对架构工作有什么样的请求，并建议对已识别出问题的解决方案，将如何通过架构流程来进行开发。这份文档的建议内容如下：1.工作名称的说明2.对项目的请求和背景3.项目的描述和范围4.架构愿景的概要或总体介绍5.管理的方法6.范围变更的流程7.各类职责和交付物8.架构被接受的标准和流程9.项目的计划和时间表10.来自企业连续系列的支持（重用性）11.签署的正式批准3.9架构愿景架构愿景在阶段A应被创建，它提供了一份最终的架构输出的高层的、愿景性的视图。建立愿景的目的是从一开始就对架构应该有什么样的预期结果达成共识，从而使架构师能够聚焦在关键的领域来验证其可行性。架构愿景也通过给出一个完整架构定义的总体汇总版本，来支持和利益相关者之间的沟通。业务场景是一种对于本阶段适合而且重要的技术，可在创建架构愿景文档的过程中被使用。付莱TOGA口袋书2.indd312011-8-519:06:4432TOGAFTMVersion9-APocketGuide架构愿景文档的建议内容如下：1.问题描述：◎各利益相关者和他们的关注◎需要解决问题/场景的列表2.具体的目标3.环境和流程模型◎对过程的描述◎流程步骤与环境的映射◎流程步骤与人员的映射◎信息流4.施动者及其角色和职责◎人员施动者和角色◎计算机施动者和角色◎需求5.结果架构模型：◎约束◎IT原则◎支持流程的架构◎需求与架构的映射3.10利益相关者管理利益相关者管理是一门重要的学问，成功的架构师可以使用它来赢得他人的支持。成功地管理利益相关者帮助了架构师确保他们的项目能取得成功，否则的话就会失败。这项技术应当在阶段A中被使用，用来识别出架构项目的关键参与者，这些参与者在后续的各个阶段中会被不断地更新。这个过程的输出形成了沟通计划的起点（参见3.11节）。付莱TOGA口袋书2.indd322011-8-519:06:4433TOGAFTMVersion9-APocketGuide成功地管理利益相关者有益于以下的几个方面：1.可以在项目早期就识别出最有权力的利益相关者，并用他们的输入来确定架构的概貌；这就确保了他们的支持并提高了架构模型的质量2.来自于最有权力利益相关者的支持将帮助架构项目获取到更多的资源；从而使架构项目更有可能成功3.通过在早期就与利益相关者进行频繁的沟通，架构团队可以确保他们能充分地理解架构开发的整个过程，以及企业架构的好处，这将意味着他们会在必要的时候更积极地支持架构团队4.架构工作团队更有可能获得对架构模型和 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 的有效反应，并将必要的行动编入计划，以充分利用积极的反应，同时避免或处理掉任何消极的反应3.10.1利益相关者管理过程的步骤步骤1：识别利益相关者第一项任务是，确定哪些人是企业架构的主要利益相关者。一般可识别出5大类的利益相关者，如图3—1所示。付莱TOGA口袋书2.indd332011-8-519:06:4434TOGAFTMVersion9-APocketGuide图3—1：利益相关者的类别步骤2：对利益相关者进行定位和分类对最重要的那些利益相关者进行深入的分析，并记录下分析结果（如表3—4中的例子所示），以供在项目过程中参考和并对其进行更新。表3—4：利益相关者分析的范例付莱TOGA口袋书2.indd342011-8-519:06:4535TOGAFTMVersion9-APocketGuide步骤3：确定管理利益相关者的策略这一步骤将使架构团队可以轻松看出哪些利益相关者将可能是阻碍者或批评者，而哪些利益相关者很可能是倡议的拥护者和支持者。确认出利益相关者的权力、影响力和利益所在，可以使企业架构的工作聚焦在某些关键的人身上。这些动作可以通过一个权力/利益矩阵来描述，这个矩阵也指明了你需要采用什么样的策略和他们打交道，如图3—2所示。图3—2：权力网格步骤4：裁剪工作的交付物确定架构工作需要产生的视点、矩阵和视图，并与每一组利益相关者组进行确认，以便能交付一个有效的架构模型。通过定义企业架构模型的特定的视点、矩阵和视图，来对利益相关者的利益予以特别的关注，这一点非常重要。这样可以确保能够同所有的利益相关者沟通架构，使其理解架构，并使他们能够确信企业架构的倡议将解决他们所关注的问题。3.11沟通计划企业架构含有大量复杂并相互关联的信息。在合适的时间、向合适的利益相关者有效地沟通有针对性的信息，是企业架构成功的付莱TOGA口袋书2.indd352011-8-519:06:4536TOGAFTMVersion9-APocketGuide一个关键因素。在阶段A制定架构沟通计划，对于能在一个有计划、被管理的过程中进行沟通提供了保障。沟通计划的内容一般包括如下的一些方面：1.识别出的利益相关者，并通过沟通需求对其的分组2.确认的沟通的需要、与架构愿景相关的关键信息、沟通的风险和关键成功因素（CriticalSuccessFactors，CSFs)3.确认的沟通机制，用于与利益相关者间的沟通、并允许其访问架构信息，如通过会议、新闻通讯、存储库等4.确认沟通时间表，用于展示将在什么时候、什么地方、与哪组利益相关者进行什么样的沟通3.12业务转换的准备就绪评估业务转换的准备就绪评估这项技术在阶段A使用，用来评估并量化一个组织对接受变更准备就绪的情况。了解组织对接受变更准备就绪的情况、发现问题并解决这些问题，是成功地进行架构转换的一个关键步骤。建议这项评估由企业员工、业务线和IT规划人员来共同完成。推荐的活动包括：1.决定将会影响组织的准备就绪因素2.使用成熟度模型来展现这些准备就绪因素3.评估每个准备就绪因素的风险，并确定缓减风险的改善行动将发现记录到能力评估的结果（参见3.13节）中，并在后续将风险缓减行动纳入到实施和迁移计划中去。3.13能力评估在着手进行详细的架构定义之前，很有必要了解一下企业的基线和目标能力水平。这些对能力的评估将首先在阶段A进行，并在阶付莱TOGA口袋书2.indd362011-8-519:06:4537TOGAFTMVersion9-APocketGuide段E进行更新。可以从以下几个方面去评估企业的能力：◎企业的整体能力水平是怎样的？企业希望在哪些方面增强或优化其能力？架构聚焦的哪些领域将支持企业所期望的能力建设？◎企业内部IT职能的能力或成熟度水平是怎样的？开展架构项目就设计的治理、运营的治理、技能和组织结构这些方面来说，可能会产生什么样的影响？架构项目要与IT组织的文化和能力相匹配，需要采用什么样适当的风格，形式化的程度和细节程度应该是怎样的？◎企业内部架构职能的能力和成熟度是怎样的？目前已存在哪些架构资产？这些资产在被维护并且信息准确吗？需要考虑哪些标准和参考模型？在架构项目中有机会创建可重用的资产吗？◎在存在能力差距的地方，为了达到目标能力，企业对于转换准备到何种程度了？除了基本的能力差距，转换的风险、文化上的障碍以及要解决的其他问题分别是什么？以下是一个能力评估交付物中的典型内容：1.业务能力的评估结果，包括：◎业务的能力◎每种能力的绩效水平的基线状态评估结果◎每种能力的绩效水平的未来期望状态◎每种能力如何被实现的基线状态评估结果◎每种能力应当如何去实现的未来期望状态2.IT能力的评估结果，包括：◎变更流程的基线和目标成熟度水平◎运营流程的基线和目标成熟度水平◎基线能力和能力大小的评估结果◎因执行架构项目对IT组织可能产生的影响的评估结果3.架构成熟度的评估结果，包括：付莱TOGA口袋书2.indd372011-8-519:06:4538TOGAFTMVersion9-APocketGuide◎架构治理的流程、组织、角色和职责◎架构技能的评估结果◎架构存储库中景观定义的广度、深度和质量◎架构存储库中标准定义的广度、深度和质量◎架构存储库中参考模型定义的广度、深度和质量◎对于重用性潜力的评估4.业务转换的准备就绪评估结果，包括：◎准备就绪因素◎每一个准备就绪因素的愿景◎当前和目标的准备就绪水平◎准备就绪的相关风险3.14风险管理业务转换风险及缓减活动的识别首先在阶段A被确定。风险管理在TOGAF9第三部分、第31章描述，它是一种在实施架构项目时用于缓减风险的技术。它包括一个由以下活动组成的风险管理过程：1.风险分类2.风险识别3.初始风险评估4.风险缓减和残留风险评估5.风险监控建议将风险缓减活动纳入到架构工作说明书中。3.15架构定义文件架构定义文件是项目过程中创建的核心架构制品的可交付物容器，这份文档跨越了所有的架构领域（业务、数据、应用和技付莱TOGA口袋书2.indd382011-8-519:06:4539TOGAFTMVersion9-APocketGuide术），并检查了架构的所有相关状态（基线状态、各过渡状态和目标状态）。它首先在阶段B被创建，最初只包含与业务架构相关的制品，接下来在阶段C被更新加入信息系统架构的制品，接着在阶段D被加入技术架构的制品。架构定义文件是架构需求规格的伴随物，它们互为补充：◎架构定义文件提供了解决方案的定性视图，其目的在于表达架构师的意图。◎架构需求规格提供了解决方案的定量视图，说明了在架构实施过程中必须满足的度量标准。以下是架构定义文件中的典型内容：1.范围2.目标、目的和约束3.架构原则4.基线架构5.架构模型（建模的每种状态）◎业务架构模型◎数据架构模型◎应用架构模型◎技术架构模型6.架构方法的依据和论证7.与架构存储库的映射：◎与架构景观的映射：◎与参考模型的映射◎与标准的映射◎可重用性的评估结果8.差距分析的结果9.影响分析的结果以下各节将详细描述每类架构。付莱TOGA口袋书2.indd392011-8-519:06:4540TOGAFTMVersion9-APocketGuide3.15.1业务架构业务架构在阶段B被开发。在架构定义文件中应阐明的与业务架构相关的主题如下：1.基线业务架构，如果适当的话—这是对现有业务架构的描述2.目标业务架构，包括：◎组织结构：识别出各个业务场所并将其关联到相应的组织单元上◎业务目标和目的：为企业和每个组织单元描述其业务目标和目的◎业务职能：将大的职能区域逐步地、递归地连续分解为各子职能◎业务服务：企业及其各业务单元向其客户提供的服务，包括内部的和外部的◎业务流程，包括其测度和交付物◎业务角色，包括对技能需求的开发和修订◎业务数据模型◎组织和职能间的相互关系：以矩阵报告的形式，将业务功能与组织单元进行关联3.选定视点的相应视图，用来处理关键利益相关者关注问题3.15.2信息系统架构信息系统架构在阶段C被开发。在架构定义文件中应阐明的与信息系统架构相关的主题如下：1.基线数据架构，如果适当的话2.目标数据架构，包括：◎业务数据模型◎逻辑数据模型◎数据管理流程模型◎数据实体/业务职能矩阵付莱TOGA口袋书2.indd402011-8-519:06:4541TOGAFTMVersion9-APocketGuide3.选定视点相应的数据架构视图，用来处理关键利益相关者关注的问题4.基线应用架构，如果适当的话5.目标应用架构，包括：◎流程系统模型◎地点系统模型◎时间系统模型◎人员系统模型6.选定视点相应的应用架构视图，用来处理关键利益相关者关注的问题3.15.3技术架构技术架构的开发是阶段D的一部分。在架构定义文件中应阐明的与技术架构相关主题如下：1.基线技术架构，如果适当的话2.目标技术架构，包括：◎技术构件及它们与信息系统之间的关系技术平台及其分解，用来展示实现一个特定技术体系（“stack”）所需的技术的组合环境和位置：一组计算环境（如开发环境，生产环境）中所需的技术预计的处理负载量以及跨技术构件的负载分布◎物理（网络）通信◎硬件和网络规格3.选定视点的相应视图，用来处理关键利益相关者关注的问题3.16架构需求规格架构需求规格提供了一套量化的声明，概要地说明了为了符合架构，实施项目必须做到什么样的程度。架构需求规格一般会成为一份实施契约或更详细的架构定义契约的主要组成部分。如上所述，架构需求规格是架构定义文件的伴随物，它对架构定义文件进行了补充，提供了定量的视图。架构需求规格通常包括以下内容：付莱TOGA口袋书2.indd412011-8-519:06:4542TOGAFTMVersion9-APocketGuide1.可进行有效度量的测度（Successmeasures）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.应用可互操作性需求付莱TOGA口袋书2.indd422011-8-519:06:4543TOGAFTMVersion9-APocketGuide4.业务架构中可能需要变更的区域，以符合数据架构和/或应用架构中的变化5.对将被设计的技术架构的约束6.更新的业务需求，如果适当的话7.更新的应用需求，如果适当的话8.更新的数据需求，如果适当的话3.16.3技术架构需求技术架构需求在阶段D填入到架构需求规格中，包括如下内容：◎差距分析结果◎更新的技术需求3.16.4互操作性需求可互操作性的意图体现在整个ADM的周期中。TOGAF9第三部分、第29章给出了定义和建立可互操作性需求的一套指导策略。3.17架构路线图架构路线图列出了变迁的各个增量，并把它们放在一条时间轴上，展示了从基线架构向目标架构的演进过程。架构路线图是过渡架构的关键构件，并在ADM从阶段B到阶段F的过程中，以增量的方式被开发。以下是架构路线图中包含的典型内容：1.项目列表：◎每个项目的名称、描述和目的◎实现目标架构的项目的优先顺序列表2.面向时间的迁移计划：◎确认的迁移的效益（包括与业务需求的映射）◎各个候选迁移方案的预估成本3.实施建议付莱TOGA口袋书2.indd432011-8-519:06:4544TOGAFTMVersion9-APocketGuide◎项目有效性的标准/测度◎风险和相关问题◎解决方案构建块，对其的描述和模型3.18业务场景对于识别和阐明隐含在新的业务功能中、满足关键业务驱动力的业务需求，以及隐含的架构需求，ADM有其自己的方法（“方法中的方法”）。这个过程方法被叫做“业务场景”。业务场景是对业务问题的一种描述方式，使需求能够在整个问题的上下文中，在彼此的关系中被看待。如果缺乏对于背景的描述，解决问题带来的业务价值就会不清晰，潜在解决方案是否适合也会不明确，而且很可能会基于一套不充分的需求来建立解决方案，而这样做是很危险的。任何大型项目成功的一个关键因素就是它与业务需求紧密联系、并且能明确支持和确保企业实现其业务目标的程度。业务场景就是一种帮助识别和理解企业业务需求的重要技术。这项技术可以应用在业务架构层次分解的不同细节层次上，并通过迭代的方式被使用。一般来说，业务场景流程包括如下步骤：1.对驱动项目的问题进行识别、记录，并排定其等级2.通过概要的架构模型来记录发生问题情形的业务和技术环境3.识别并记录期望的目标；成功处理问题后的预期结果4.识别人员施动者及其在业务模型中的位置、人员参与者及其角色5.识别计算机施动者及其在技术模型中的位置、计算元素及其角色6.对于每一个施动者，确定并记录其角色、职责和测量成功的测度、每个施动者需要的场景，以及正确处理该场景的预期结果7.检查上述场景对于开展后续架构工作是否适合，仅在必要时付莱TOGA口袋书2.indd442011-8-519:06:4545TOGAFTMVersion9-APocketGuide进行完善3.19差距分析差距分析技术在ADM周期中被广泛地应用，用来验证正在被开发的架构。它通常是一个阶段的最后一个步骤。其基本的出发点是强调基线架构和目标架构之间的差异，即被故意忽略、意外遗漏或尚未定义的条目。其步骤如下：1.绘制一个矩阵，将所有基线架构的架构构建块（ArchitectureBuildingBlocks，ABBs）放在垂直轴，所有目标架构的架构构建块（ABBs）放在水平轴。2.在基线架构轴的最后一行增加一行，标示为“新增的架构构建块（ABBs）”，在目标架构轴的最后一列增加一列，标示为“除去的架构构建块（ABBs）”。3.如果一个架构构建块（ABB）同时存在于基线架构和目标架构中，在交叉单元格将其标记为“已包括”。4.如果基线架构中的架构构建块（ABB）在目标架构中出现缺失，检查每一个缺失的架构构建块（ABB）。如果确实应该将其除去，在“除去的架构构建块”列合适的单元格中对其进行相应记录。如果不该将其除去，这样就发现了在目标架构中意外遗漏的架构构建块（ABB），在“除去的架构构建块”列合适的单元格中对其进行相应记录，这些被遗漏的架构构建块（ABB）必须在架构设计的下一轮迭代中被恢复并进行处理。5.当某个目标架构中的架构构建块（ABB）没有出现在基线架构中时，在该构建块所在列和“新增的架构构建块（ABBs）”行的交叉单元格上将其作为差距进行标记，这种差距需要通过开发或外购该构建块的方式进行填补。付莱TOGA口袋书2.indd452011-8-519:06:4646TOGAFTMVersion9-APocketGuide当完成上述步骤后，所有出现在“除去的”列或“新增的”行中的都是差距，这些差距要么解释为应该被除去，要么被标记出来，以便进行恢复或开发/采购其功能。表3—5展示了一个基线架构和目标架构之间存在若干差距的例子；在这个例子中在目标架构中消失的元素是“广播服务”和“共享屏幕服务”。差距分析技术应当在ADM的B、C、D、E阶段中使用。3.20架构视点架构师在ADM周期从阶段A到阶段D的各个阶段中，使用视图和视点来开发每个架构领域（业务、数据、应用、技术）的架构。视图（View）是你看到的东西。而视点（Viewpoint）是你从哪儿看；即决定你看到什么的有利位置或角度（一个视点也可以被认为是一种范式）。视点是通用的，可以储存在视点库中供重用。视图对于它为之被创建的架构来说总是具体的。每个视图有描述它的相关联的视点，哪怕该视点是隐含的。ISO/IEC42010:2007鼓励架构师明确地定义视点。在视图的内容和范式之间做出这样的区分，乍看起来似乎是一个不必要的负担，但它确实为在不同的架构之间重用视点提供了一种机制。为了能清楚地说明视图和视点的概念，考虑例1中的场景。这是一个非常简单的机场系统，只有两个利益相关者：飞行员和空中交通管理员。例1：简单机场系统的视图和视点表3—5：差距分析范例付莱TOGA口袋书2.indd462011-8-519:06:4647TOGAFTMVersion9-APocketGuide简单机场系统的视图和视点飞行员看待系统有一个视图，而空中交通控制员有另一个视图。这两个视图都不能表现出整个系统，因为各个利益相关者的视角限制（并减化）了其看待整个系统的方式。飞行员视图包含的某些元素不会被控制员所关注，例如乘客和油料，同时控制员视图包含的某些元素也不会被飞行员所关注，例如其他的飞机。也有一些元素同时出现在两个视图中，例如飞行员和控制员之间的通信模型，以及关于飞机本身的一些重要信息。视点是视图中包含信息的一种模型（或描述）。在这个例子中，一种视点是描述飞行员如何看待系统的，而另外一种视点是描述控制员如何看待这个系统的。飞行员从他们的角度来描述系统，使用的模型包括他们的位置和飞向或离开跑道的向量。所有的飞行员都会使用这个模型，这个模型通过一种特定的语言来记录信息并将其填充入该模型中。控制员则使用另一种方式来描述系统，使用的模型包括空域和空域内飞行器的位置和向量。与飞行员一样，所有控制员也使用源自于同一模型的共同语言，以便记录与他们的视点相关的信息并进行沟通。幸运的是，当控制员与飞行员交谈时，他们使用了一种共同的沟通语言。（换句话说，使用了代表其各自视点、并部分相交的不同模型。）这种共同语言的一部分是关于飞行器的位置和向量的，这对于两者间能进行沟通来说是必不可少的。所以，在本质上每一个视点都是某个特定类型的所有利益相关者，如所有的飞行员、或所有控制员，如何看待机场系统的一种抽象模型。工具的人员用户接口通常非常接近于与视点相关的模型和语言。飞行员特有的工具包括燃料指示器、高度指示器、速度指示器和位置指示器。控制员的主要工具则是雷达。两者共同的工具是无线电通信设备。总结例1，我们可以看到，视图可以通过不同利益相关者的角付莱TOGA口袋书2.indd472011-8-519:06:4648TOGAFTMVersion9-APocketGuide度，如飞行员与控制员的角度，来划分出系统的子集。这种子集可以通过一种被叫作视点的抽象模型来描述，如空中飞行模型与飞行空间模型。视图的这种描述可以通过一种半专门的语言来记录，如“飞行员语言”与“控制员语言”。工具是用来帮助利益相关者的，它们之间通过源于视点的语言进行交互。当利益相关者使用共同的工具时，如飞行员和控制员之间的无线电通信联系，一种共同的语言是必不可少的。3.21架构视图架构视图表现了整体架构，对系统中的一个或多个利益相关者来说具有意义。架构师在ADM周期从阶段A至阶段D的过程中，选择并建立了一套视图，以便可以同所有的利益相关者沟通架构，使其理解架构，并使他们能够验证系统将解决他们关注的问题。5.3节中的概念是在TOGAF中使用架构视图的核心。3.21.1在ADM中建立视图架构师必须做出的关键决定之一，就是决定开发哪些特定的架构视图。架构师有责任确保架构的完整性（适合使用），即能充分解决其所有利益相关者的关注问题；以及架构的一致性，即能将各个不同的视图联系起来