TOGAF制品定义.docx
《TOGAF制品定义.docx》由会员分享，可在线阅读，更多相关《TOGAF制品定义.docx（20页珍藏版）》请在冰豆网上搜索。
TOGAF制品定义
4.2架构制品定义
4.2.1原则目录（Principlescatalog）
原则目标对各项业务原则及架构原则进行列举，用以表明一个好的解决方案或架构看起来应该是什么样子。
原则用于对各架构决策点的输出进行评估和认可。
原则也可在针对变更举措的架构治理中充当辅助工具。
4.2.2干系人映射矩阵（StakeholderMapMatrix）
干系人映射矩阵用于明确参与架构活动的各个干系人、他们的影响、他们的主要问题，以及架构框架所必须解答的关注点。
通过对于干系人的识别，并对他们的需求进行理解，架构师可以将注意力集中在能够满足干系人需求的各个领域之中。
此目录所涉及到的内容元模型实体包括：
∙原则
4.2.3价值链图（ValueChainDiagram）
价值链表提供了一张面向高层的企业视图，用于表示企业如何与外界环境交互。
与在业务架构阶段中开发出来的更加正式的功能解构图相比较，价值链表更着重于表象上的影响。
价值链表的目标是使一个特定的变更主张能够快速地在干系人中获得一致性认识，从而使得所有参与者能够对架构所涉及到的高层次功能性和组织性环境进行理解。
4.2.4解决方案概念图（SolutionConceptDiagram）
解决方案概念图提供了一个解决方案的高层次方向，用于达成架构所涉及的各个目标。
与后续架构开发方法阶段开发出来的、更正式且更详细的架构图相比较，解决方案概念图更像是在一开始阶段关于期望解决方案的一张草图。
这张图体现了关键的目标、需求和约束，并对将采用正式架构模型来进行更详细描述的各个工作区域进行了标明。
解决方案概念图的目标是使一个特定的变更主张能够快速地在干系人中获得一致性认识，从而使所有的参与者能够理解架构所需要的究竟是什么，以及一个特定的解决方案被期望以何种方式来满足企业的需求。
4.2.5组织/执行者目录（Organization/ActorCatalog）
该目录的目标是得到一份明确的包括用户和IT系统所有者在内的所有与IT有互动的参与者列表。
该列表可以在开发需求时作为完备性检测的参考。
例如，针对于一个对客户进行服务支持的应用的需求，我们可以通过如下几个方面对其进行完备性检测：
∙需要对何种类型的客户进行支持。
∙是否某种类型的用户存在特定需求或约束。
此目录所涉及到的内容元模型实体包括：
∙组织单位
∙执行者
∙位置（如果一个单独的位置目录并不存在，则关于位置的信息就需要在这个目录中加以维护）
4.2.6驱动力/目标/阶段目标目录（Driver/Goal/ObjectiveCatalog）
该目录的目标是描述组织如何通过目标、工作目标和评测（可选内容）来满足其驱动力的需要，并为此提供一份跨越组织的参考。
通过针对驱动力、目标和阶段目标的层层分解，各个变更举措可以采用一种跨越组织边界的方式进行协同，并在随后的活动中使得各个干系人得以被明确，此外，相关的变更举措也能够被整合或协调起来。
此目录所涉及到的内容元模型实体包括：
∙组织单元
∙驱动力
∙目标
∙阶段目标
∙评测（可选内容）
4.2.7角色目录（RoleCatalog）
角色目录的目标是为企业中所有的授权级别或区域提供一份列表。
一般情况下，应用的安全或行为应该按照其对授权概念的理解而分别进行定义，但在与用户的计算机相绑定时却造成了复杂且不被期望的后果。
如果角色在整个组织和所有应用中都得到了定义、理解和共识，那么更加安全并能够提供更加无缝的用户体验的应用将会出现，因为管理员无需通过迂回的解决方法来使用户执行他们的工作。
除了对企业的安全定义进行支持，角色目录还可以是明确组织变更管理影响、定义工作职能，以及执行最终用户培训这些方面的关键输入。
由于每个角色都暗含着关于一系列业务功能的访问，如果这些功能被影响到，那么变更管理将必不可少，组织的职责也需要被重新定义，同时新的培训可能也是需要的。
此目录所涉及到的内容元模型实体包括：
∙角色
4.2.8业务服务/功能目录（BusinessService/FunctionCatalog）
业务服务功能目录的目标是提供一份功能性的解构，使得各种功能可以被过滤、汇报和查询，并能够作为功能结构图的一个有力补充。
服务功能目录可以被用来对组织中的各项能力进行明确，并对组织中施加到各种功能上的治理水平加以理解。
通过功能解构，用于支持业务变化所需要的各种新能力能够被识别出来，或者对变更措施、应用以及技术组件的范围进行确定。
此目录所涉及到的内容元模型实体包括：
∙组织单位
∙业务功能
∙业务服务
∙信息系统服务（可选内容）
4.2.9位置目录（LocationCatalog）
位置目录为企业的业务运营或房屋建筑相关的资产（例如数据中心或终端用户计算设备）所处位置提供了一份列表。
针对此位置列表的维护，各个变更举措的位置范围得以被快速地定义出来，并且针对当前情况和建议的目标解决方案进行评估时，完备性测试也得以被执行。
例如，一个用于更新台式计算机操作系统的项目需要识别出这些系统所部署的位置。
与此相似，当实施一个新的系统时，一张关于位置的图形描述对于开发适当的部署策略是非常关键的，该部署策略被用于对用户和应用的位置进行了解，并且各个与位置相关的问题（例如，国际化、本地化、针对可用性的时区影响、延时距离影响、网络带宽影响和访问）也得以被明确。
此目录所涉及到的内容元模型实体包括：
∙位置
4.2.10流程/事件/控制/产品目录（Process/Event/Control/ProductCatalog）
流程/事件/控制/产品目录为流程、触发流程的事件、流程的输出和施加到流程执行之上的控制提供了一份层次结构，并可被用来作为流程图（ProcessFlowdiagram）的一个有力的补充，这些流程图使得企业可以进行跨越组织和流程的过滤、汇报和查询操作，从而对其范围、通用性或影响进行明确。
例如，流程/事件/控制/产品目录使得企业可以查看流程与各子流程之间的关系，从而明确源自于一个高层流程的变更所能带来的影响链。
此目录所涉及到的内容元模型实体包括：
∙流程
∙事件
∙控制
∙产品
4.2.11合同/评测目录（Contract/MeasureCatalog）
此目录提供了一份关于所有经过批准的服务合同以及与此相关的评测的列表，从而形成了在整个企业内获得批准的服务水平的主列表。
此目录所涉及到的内容元模型实体包括：
∙业务服务
∙信息系统服务（可选内容）
∙合同
∙评测
4.2.12业务交互矩阵（BusinessInteractionMatrix）
此矩阵用于描述企业中各组织与业务功能之间的交互关系。
理解企业中的业务交互是很重要的，因为它有助于突出整个组织中的价值链以及相互依赖关系。
此矩阵所涉及到的内容元模型实体包括：
∙组织
∙业务功能
∙业务服务
∙业务服务之间的通信关系
∙业务服务之间的依赖关系
4.2.13执行者/角色矩阵（Actor/RoleMatrix）
此矩阵用于展示哪些执行者扮演何种角色，并支持对安全性和技能需求的定义。
理解执行者与角色之间的关系对定义培训需求、用户安全设置和组织变更管理具有关键性作用。
此矩阵所涉及到的内容元模型实体包括：
∙执行者
∙角色
∙执行者与角色之间的担当关系
4.2.14业务足迹图（BusinessFootprintDiagram）
业务足迹图描述了业务目标、组织单元、业务功能和服务之间的关联，并将这些功能映射到各个提供了所需能力的技术组件之上。
它在从技术组件到业务目标的映射中提供了清晰的可追溯性，同时还对已经明确的服务的所有权进行了阐述。
业务功能图仅对联系组织单元功能与交付服务的关键因素进行描述，并且还可被用来作为与高层次干系人（CIO、CEO等）进行沟通的平台。
4.2.15业务服务/信息图（BusinessService/InformationDiagram）
业务服务/信息图展示了用于对一个或多个业务服务进行支持的信息，包括了由业务服务使用或者产生的数据及其信息源。
服务/信息图对信息在架构中的最初表现形式进行了展现，因此为数据架构阶段的进一步描述打下了基础。
4.2.16功能分解图（FunctionalDecompositionDiagram）
功能分解图的目标是将组织中与架构相关的各项能力展现在一张图纸之上。
通过从功能的视角检视组织的各项能力，企业可以快速针对组织所做的事情进行建模，而不用陷入针对组织如何做所进行的额外讨论之中。
4.2.17产品生命周期图（ProductLifecycleDiagram）
产品生命周期图的目标是对企业中关键实体的理解进行辅助。
就关于产品从生产到撤销过程中所必须遵守的环境的关注、立法和规章来说，理解产品生命周期变得越来越重要。
与此相同，在为了保证在控制、流程和程序的设计严谨而进行的业务架构开发过程中，创建涉及个人或敏感信息产品的组织必须对产品生命周期具有一个详尽的理解，例如信用卡、借记卡、智能卡以及用户身份认证等信息。
4.2.18目标/阶段目标/服务图（Goal/Objective/ServiceDiagram）
此图的目标是为服务对业务愿景或策略的达成而定义方法。
通过将服务与驱动力、目标、阶段目标和相关的评测进行关联，企业可以了解到哪些服务贡献于相似的业务效能方面。
此外，该图还为针对某一特定服务所形成的高效能的认定提供了定性的输入。
4.2.19业务用例图（BusinessUse-CaseDiagram）
业务用例图展示了业务服务的提供者和使用者之间的关系。
业务服务被各个执行者或其他的业务服务所使用，而业务用例图则通过针对业务能力在何时以及如何被使用的描述，为业务能力的描述方面提供了额外的价值。
此图形的目标是对各执行者和他们在各流程和功能中所担当的角色之间的交互关系进行描述和验证。
随着架构过程的演进，这些用例图也将从业务级别发展至包括数据、应用和技术在内的更加详尽的级别。
除此之外，业务用例图也可在系统设计工作中得到复用。
4.2.20组织分解图（OrganizationDecompositionDiagram）
组织分解图描述了执行者、角色以及他们在组织树中所处位置之间的关系。
一份组织分解图应提供了一条组织中决策者和业务拥有者的命令链。
虽然组织分解图并不打算将组织与其目标联系在一起，但是在这张图中为最终目标与干系人之间建立直观的联系也是可以的。
4.2.21流程图（ProcessFlowDiagram）
流程图的目标是对流程元模型实体相关的所有模型和映射进行描述，它展示了位于各个活动之间的顺序化控制流，并可借助于泳道技术来表达各个流程步骤的归属和实现。
例如，用于支持一个流程步骤的应用就可以作为一条泳道来展示。
除此之外，流程图也可以被用来细化赋予在流程之上的控制、触发某流程或产生于流程结束时的事件，以及由于流程执行所产生的各种输出产物。
流程图在为主题专家描述架构时非常有用，它可以为这些专家描述一个特定功能的工作是如何被完成的。
通过这样一个过程，每个流程步骤可以被细化为更小粒度的功能块，而且这些功能块在以后亦可以被当作一个流程来进行进一步的阐述。
4.2.22事件图（EventDiagram）
事件图的目标是描述事件与流程之间的关系。
诸如某些特定信息的到来，或者是某个特定的时间点这样的特定事件会致使业务中特定的工作和行为得以进行，同时也经常会有被称为业务事件（或简称事件）的信息被当作某个流程的触发者。
4.2.23数据实体/数据组件目录（DataEntity/DataComponentCatalog）
数据实体/数据组件目录的目标是明确和维护企业中使用的所有数据的列表，包括数据实体，以及用于存储数据实体的数据组件。
一个经过批准的数据实体/数据组件目录支持对信息管理和数据治理策略的定义和应用，并且鼓励对数据进行有效地共享和重用。
此目录所涉及到的内容元模型实体包括：
∙数据实体
∙逻辑数据组件
∙物理数据组件
4.2.24数据实体/业务功能矩阵（DataEntity/BusinessFunctionMatrix）
此矩阵用来描述企业中数据实体和业务功能之间的关系。
业务功能被具有明显边界的业务服务所支持，并通过业务流程加以实现。
通过数据实体与业务功能之间的映射，企业可以得到：
∙将数据实体的所有权分配给各个组织。
∙理解业务服务的数据和信息交换需求。
∙支持差距分析，并决定是否有需要被创建的数据实体被遗漏。
∙为数据实体定义源系统、记录系统和引用系统。
∙启动企业的数据治理程序的开发（建立数据管家、开发与业务功能相关的数据标准等）。
此矩阵所涉及到的内容元模型实体包括：
∙数据实体
∙业务功能
∙数据实体与其所属组织单位的“从属”关系
4.2.25系统/数据矩阵（System/DataMatrix）
此矩阵用于描述系统与系统所访问和更新的数据实体之间的关系（一张两维表，其中一个纬度对应逻辑应用组件，而另外一个则对应数据实体）。
系统用于创建、读取、更新和删除与他们相关联的特定数据实体。
例如，一个客户关系系统将创建、读取、更新和删除客户实体信息。
处在一个被封包好的服务环境中的数据实体可以被分为主数据、引用数据、事务数据、内容数据和历史数据，而用于操作这些数据实体的应用则包括事务应用、信息管理应用和业务仓库应用。
针对应用组件和数据实体之间映射是一个非常重要的步骤，因为它可以使得：
∙针对数据的访问能力被分配给组织中的具体应用。
∙了解在不同应用中数据重复的程度，以及数据生命周期的规模。
∙了解在何处相同的数据会被不同的应用所更新。
∙支持差距分析，并确定是否本应存在的应用被遗漏了。
4.2.26类图（ClassDiagram）
类图的主要目标是描述企业中重要数据实体（或类）之间的关系。
此图用于清晰地展示数据之间的关系，并帮助干系人理解企业下层数据模型。
4.2.27数据传播图（DataDisseminationDiagram）
数据传播图的目标是展示数据实体、业务服务和应用组件之间关系。
此图展示了各个逻辑实体如何被应用组件所实现。
它使得针对数据大小的调整得以被有效地执行，同时IT足迹也会得以改善。
而且，通过为数据设置业务价值，应用组件的业务重要性的指标也能够在同时被获得。
另外，此图还可以展示针对数据复制和主引用的所有权，即它可以展示数据的两个备份以及数据之间的主-备份关系。
此图还能够包含服务，比如，封装数据并且驻留在应用之内的服务，或者驻留在应用之上并能够访问封装在应用中的数据的服务。
上面所说的ITfootprint中，footprint，即足迹，的本意是由动物遗留下的包含了遗留者本身标识和信息的事物。
在信息技术领域，根据哈佛商学院AndrewMcAfee所述，技术足迹表示了其在地理、逻辑分区和/或功能方面所能延展到范围，是针对一个信息技术所期望的覆盖范围的描述（Atechnology'sfootprintisitsgeographic,divisional,and/orfunctionalreach.It'sadescriptionofhowmuchterritoryapieceofITisintendedtocover）。
在TOGAF中并没有说明数据大小的调整与IT足迹改善之间的关系，也没有说明所谓的IT足迹改善的具体含义。
不过通过互联网上的一个关于IT足迹改善的实例，即将原本有着十几台计算机的教室用一台中心计算机和若干终端来代替，笔者有感而发，粗浅的认为这里IT足迹改善意思是说由于数据尺寸得到了很好的调整，那么不必需的冗余信息被削减，因而数据和应用的“足迹”，即其涉及到的范围，将比冗余剔除前更加清晰有效
4.2.28数据安全图（DataSecurityDiagram）
数据可以看作是企业的一项资产，简单的讲，数据安全可被认为是确保企业数据不被损害，并且针对数据的访问也要在适当的控制之下。
数据安全图的目标是描述何执行者可以访问企业中的哪些数据。
此外，此图也可以被用来阐述与数据隐私法规以及其他应用性法规的符合度。
此图还需要考虑发生在企业合作伙伴或其他团体对企业系统进行访问之处的信任含义，例如在外包的情形下，信息可能会被企业之外的其他人员（甚至身处国门之外）所管理。
4.2.29类层次结构图（ClassHierarchyDiagram）
类层次结构图的目标是为技术方面的干系人展示一个有关类层次的视图。
此图的优点是干系人可以得到一份关于数据实体在技术层面上如何被使用的图形描述，它使得干系人可以了解何人正在针对数据进行使用，以及他是在何时、如何以及为何进行这项活动。
4.2.30数据迁移图（DataMigrationDiagram）
在实现一个以封包服务为基础的解决方案时，数据迁移是非常重要的，特别是将现存的遗留系统替换为一个服务封包时，或者当企业将要迁移到一个更大的封包服务时。
每个服务包都倾向于具有属于他们自己的数据模型，并且在数据迁移过程中，遗留的应用数据可能需要在载入到服务封包之前需要进行某种转化。
数据迁移活动通常包含如下的步骤：
∙从原有应用中抽取出数据。
∙配置源数据
∙执行数据转换，其中包括数据质量相关的各个过程：
∙对数据进行标准化、归一化，并消除数据的重复性（数据清洗）。
∙针对不同来源的数据进行比对、合并和整合。
∙进行自源头至目标的映射
∙将数据加载到目标应用之中。
数据迁移图的目标是展示数据如何从源头应用流入到目标应用之中。
此图为数据从源头到目标过程的进行提供了一个可视化表达，并可在数据审计和追溯中作为辅助工具。
此外，此图所展示的细节程度可以按照需要进行调整。
例如，数据迁移图可以仅仅包含一个关于迁移情况的整体布置，也可以为单独的应用提供元数据元素级别的详细信息。
企业架构研究总结（34）——TOGAF架构内容框架之架构制品（下）
4.2.31数据生命周期图（DataLifecycleDiagram）
数据生命周期图是在业务流程的约束之下对业务数据在其整个生命周期（从概念阶段到最终退出）中对其进行管理的核心部分。
数据从本质上讲是一个实体，并独立于业务流程和活动。
数据状态的每个变化都被表现在这张图中，这也可以包括引起此状态变化事件或规则。
数据与流程的分离使得通用数据需求可以被识别出来，从而使得资源共享得以有效达成。
4.2.32应用组合目录（ApplicationPortfolioCatalog）
此目录的目标是明确和维护企业中所有应用的列表。
一个经过批准的应用组合目录使得一系列应用得以被定义和治理。
此目录为后面的矩阵和图形提供了基础，是应用架构开发阶段的起点。
现有的应用注册表和资源库（比如SAP的解决方案管理和系统情况目录产品）也从基线和目标两个角度为这个目录的制定提供了输入。
此目录所涉及到的内容元模型实体包括：
∙信息系统服务
∙逻辑应用组件
∙物理应用组件
4.2.33接口目录（InterfaceCatalog）
接口目录用来界定应用之间接口的范围，并对这些接口进行文档化记录，从而使得应用间的所有依赖关系得以被尽可地界定。
系统可以用来创建、读取、更新和删除其他系统内的数据。
无论是通过循环载入的批处理文件、对其他系统数据库的直接连接，还是通过某种形式的应用程序接口或Web服务，这些行为都是通过接口来实现。
针对应用组件之间关系的映射是一个非常重要的步骤，它使得如下情形得以实现：
∙了解应用间交互程度的，从而可以站在应用与其他系统之间依赖性的角度识别出各个关键的交互。
∙了解应用之间接口的数量和类型。
∙了解应用之间接口的重复程度。
∙在考虑目标应用组合时明确各接口的简化潜力。
∙支持差距分析，并确定是存在本应建立的应用被遗漏了。
此目录所涉及到的内容元模型实体包括：
∙逻辑应用组件
∙物理应用组件
∙应用之间的通信关系
4.2.34系统/组织矩阵（System/OrganizationMatrix）
此矩阵用于描述企业中系统与组织单元之间的关系。
业务功能由组织单元来执行，而一些由组织单元执行的功能和服务也将会被IT系统所支持。
应用组件与组织单元之间的映射非常重要，它会使得：
∙为执行业务功能的组织单元分配针对应用的使用。
∙理解由组织单元所执行的业务服务和流程对应用支持需求。
∙支持差距分析，并确定是否有需要被建立的应用被遗漏。
∙定义特定组织单元所使用的应用集合。
此矩阵是一张两维表，其中逻辑/物理应用组件在一条坐标轴上，而组织单元在另一条轴上。
这两个实体之间的关系包含了一系列需要被验证的元模型关系：
∙组织单位与服务之间的从属关系。
∙执行者与组织单位之间的从属关系，以及其与服务之间的使用关系。
∙服务与逻辑/物理应用组件之间的实现关系。
4.2.35角色/系统矩阵（Role/SystemMatrix）
此矩阵用来描述企业中系统与业务角色之间的关系。
一个组织中的人们会与各种系统发生交互。
在交互过程中，这些用户被假定成为执行一项任务的特定角色，例如，产品购买者。
应用组件与角色之间的关系映射非常重要，它使得：
∙在组织内为特定的角色分配针对应用的使用。
∙理解支持功能的业务服务和流程的应用安全需求，并检查是否与现有策略相符合。
∙支持差距分析，并确定是否有应该被创建的应用被遗漏。
∙定义被特定业务角色所使用的应用集合。
此矩阵是一个两维表，其中逻辑应用组件在一条坐标轴上，而角色在另一条轴上。
这两个实体之间的关系包含了一系列需要被验证的元模型关系：
∙角色与功能之间的访问关系。
∙功能与服务之间的绑定关系。
∙服务与逻辑/物理应用组件的实现关系。
4.2.36系统/功能矩阵（System/FunctionMatrix）
此矩阵用于阐述企业中系统与业务功能之间的关系。
业务功能由组织单元所执行。
一些业务功能和服务将会被IT系统所支持。
应用组件与功能之间的关系映射是非常重要的，它使得如下方面成为可能：
∙为业务功能分配针对应用的使用
∙理解业务服务和流程的应用支持需求
∙支持差距分析，并确定是否有需要被创建的应用被遗漏
∙定义被特定业务功能所使用的应用集合
此矩阵是一张两维表，其中逻辑应用组件位于一条坐标轴上，而功能处在另一条坐标轴之上。
这两个实体之间的关系包含了一系列需要被验证的元模型关系：
∙功能与服务之间的绑定关系。
∙服务与逻辑/物理应用组件的实现关系。
4.2.37应用交互矩阵（ApplicationInteractionMatrix）
应用交互矩阵的目标是阐述系统之间的沟通关系。
在矩阵中展示的应用交互映射与接口目录或者应用通信图示相类似的，只不过以矩阵的形式来展示。
此矩阵是一张两维表，其中的每一个维度都包含了应用服务、逻辑应用组件和物理应用组件这些概念。
在此矩阵中所描述的关系包括：
∙应用服务之间的使用关系。
∙逻辑应用组件之间的通信关系。
∙物理应用组件的通信关系。
4.2.38应用通信图（ApplicationCommu
升级会员 