本章提供了定义和建立互操作性要求的指南。
7.1 概述
互操作性的定义是“共享信息和服务的能力”。定义信息和服务共享的程度是一个非常有用的架
构要求，特别是在复杂的组织和/或扩展的企业中。
互操作性的确定贯穿整个ADM，如下所示：
■ 在架构愿景（阶段A）中，信息和服务交换的性质和安全考虑首先在业务场景中揭示
■ 在业务架构（阶段B）中，信息和服务交换在业务术语中得到了进一步的定义
■ 在数据架构（阶段C）中，使用公司数据和/或信息交换模型详细说明信息交换的内容
■ 在应用程序体系结构（阶段C）中，指定了各种应用程序共享信息和服务的方式
■ 在技术架构（阶段D）中，规定了允许信息和服务交换的适当技术机制
■ 在机会和解决方案（阶段E）中，选择实际的解决方案（例如COTS包）
■ 在迁移规划（阶段F）中，互操作性在逻辑上得到了实现
7.2 定义互操作性
定义互操作性的方法有很多，目的是定义一种在企业和扩展企业中一致应用的方法。企业和扩展
企业最好使用相同的定义。
许多组织发现将互操作性分类如下很有用：
■ 运营或业务互操作性定义了如何共享业务流程
■ 信息互操作性定义了如何共享信息
■ 技术互操作性定义了如何共享或至少相互连接技术服务
 

从IT的角度来看，以与企业应用集成（EAI）类似的方式考虑互操作性也是有用的；明确地：
■ 演示集成/互操作性是指通过一个通用的门户式解决方案，采用一种通用的外观和感觉方法，
引导用户了解系统集的底层功能
■ 信息集成/互操作性是指企业信息在各种企业应用程序之间无缝共享，以实现一组通用的客
户信息
通常，这是基于一个普遍接受的企业本体论和共享服务，用于信息的结构、质量、访问和安
全/隐私。
■ 应用程序集成/互操作性是指公司功能的集成和共享，这样应用程序就不会重复（例如，地
址服务/组件的一次更改；不是每个应用程序都有一个），并通过工作流等功能无缝链接在
一起
这会影响业务和基础设施应用程序，并与企业业务流程统一/互操作性密切相关。
■ 技术集成/互操作性包括主要在应用平台和通信基础设施领域中用于通信、存储、处理和访
问数据的通用方法和共享服务
这种互操作性的前提是基于标准和/或通用IT平台的企业IT基础设施的合理化程度。例如，
多个应用程序共享一个基础设施，或者使用一个集中式内容管理/网络服务器共享10000个企
业网站（而不是遍布全国/全球的数千个服务器和网站管理员）。
许多组织创建了自己的互操作性模型，如加拿大政府的以下示例所示。他们对三类互操作性有一
个高层次的定义，并确定了他们希望共享的信息和服务的性质。互操作性是指电子政务的电子化
工具。它们的互操作性细分如下：
■ 信息互操作性：
— 知识管理
— 商业智能
— 信息管理
— 可信身份
■ 业务互操作性：
— 交付网络
— 电子化民主
— 电子商务
— 企业资源管理

--关系和案件管理
■ 技术互操作性：
— IT基础设施
在某些架构方法中，如系统体系或联邦模型，互操作性是一种强烈推荐的最佳实践，它将决定系
统之间的交互方式。一个关键的考虑因素将是企业的业务运营模式。
7.3 企业运营模式
建立互操作性的关键是确定企业运营模式，其中运营模式是“向客户交付商品和服务所需的业务
流程集成和标准化水平。运营模式描述了公司希望如何蓬勃发展。通过提供比战略更稳定、更可
操作的公司视图，运营模式推动了执行基础的设计。”1
例如，如果业务线或业务部门只需要共享文档，那么ABB和SBB可能比需要共享结构化交易数据更
简单。同样，如果架构愿景包括共享服务环境，那么定义共享服务的级别是有用的。
公司运营模式通常会表明哪种类型的互操作性方法是合适的。如果不是在阶段B（业务架构）中，
那么这个模型应该在阶段A（架构愿景）中确定，当然也应该在阶段E（机会和解决方案）中确定。
复杂企业和/或延伸企业（如供应链）可能有多种运营模式。例如，内部操作模型（和支持互操作
性模型）通常与扩展企业使用的模型不同。
7.4 改进互操作性
实现互操作性需要创建、管理、接受和执行SMART（具体、可衡量、可操作、现实和有时限）的现
实标准。明确的互操作性措施是成功的关键。
架构是确定标准的关键，促进会议将研究潜在的实用方法（适合当前或新兴的商业文化），以实
现必要程度的互操作性。
应改进互操作性，使其以明确的方式满足企业和/或扩展企业的需求。细化的互操作性度量（程度、
类型和高级目标）应作为企业架构战略方向的一部分或参考。
这些措施在转换策略中实例化，该策略应嵌入目标架构定义中，并在过渡架构中实际实施。完成
后，还更新合并的差距分析结果和依赖关系，以确保捕获辅助会话的所有输出。
指定互操作性的一个例子是互操作性程度（在加拿大国防部和北约）。这些组织专注于信息共享，并提出了以下四个互操作性等级：
■ 第1级：非结构化数据交换涉及人类可解释的非结构化数据的交换，例如作战估计、分析和
论文中的自由文本
■ 第二级：结构化数据交换涉及人类可解释的结构化数据的交换，这些数据用于手动和/或自
动处理，但需要手动编译、接收和/或消息发送
■ 第3级：无缝数据共享涉及基于通用交换模型在系统之间自动共享数据
■ 4级：信息无缝共享是3级的延伸，通过基于合作应用程序的数据处理对信息进行普遍解释
这些学位应该进一步完善，并使每个学位在技术上都有意义。以下是一个包含四个子分类的3级改
进示例：
■ 3A：正式消息交换
■ 3B：通用数据交换
■ 3C：完整的数据交换
■ 3D：实时数据交换
其目的是将互操作性的详细程度指定为必要的细节级别，以便它们在技术上具有意义。
这些程度对于指定各种系统之间必须交换信息的方式非常有用，并为实施系统的项目提供关键指
导。
应制定类似的措施来确定服务/业务和技术互操作性。
7.5 确定互操作性要求
新兴系统和现有系统之间的共存，特别是在转型期间，将是一个重大挑战，主持的会议应试图找
出必须采取哪些措施来减轻痛苦。必须让运营管理人员和架构师参与这一步骤，因为他们将负责
运营项目组合交付成果。
例如，可能需要一个“包装器”应用程序（一个充当遗留应用程序和新兴基础设施之间的接口[也
称为解释器]的应用程序）。事实上，从实用的角度来看，在“如果它有效，就不能修复它”的世
界里，“包装器”可能会成为一种永久的解决方案。
无论如何，以差距分析结果和业务场景为基础，讨论IT问题并解决这些问题，以确保所有差距都
得到明确识别和解决，并验证是否满足组织特定的要求。
值得注意的是，随后的开发过程必须包括对功能依赖性和边界的认识，并应考虑市场上可用的产
品。如何表达这一点的一个例子可以在构建块示例（参见TOGAF标准——架构内容）。
如果使用互操作性程度等机制，则显示互操作性要求的矩阵是一个有用的工具，如图7-1和图7-2
所示，并指出系统和/或利益相关者之间的信息共享程度不一定是对称的或双向的。
下面的矩阵可以在企业和/或扩展企业内使用，作为详细说明可以共享信息和/或服务的一种方式。
该矩阵应从业务架构（B阶段）开始，以捕捉利益相关者之间信息共享的性质，并逐步确定哪些系
统在C阶段共享哪些信息。

上图显示，利益相关者A需要与利益相关者/系统B和D进行结构化数据交换（2级），并与利益相
关器/系统C、E、F和G无缝共享数据（3级）。
业务信息互操作性矩阵应在信息系统架构中使用精确的度量方法进行细化，并指定利益相关者使
用的实际系统。示例如图7-2所示。

在上图中，，交换的性质更为详细（例如，3A级与仅3级），共享是在特定系统之间进行的，而不
是在利益相关者之间进行的。例如，系统A根据企业技术标准与其他系统共享信息。
在许多组织中，业务架构描述了利益相关者和/或组织之间共享的信息的性质（例如，在防御中，
术语是“操作节点”），数据架构指定了系统之间共享的数据。
根据提出的互操作性问题更新定义的目标数据和应用程序架构（已批准）。

7.6 将互操作性要求与潜在解决方案相协调
企业架构师必须确保没有互操作性冲突，特别是如果打算重用现有的SBB和/或COTS。
事实上，需要解决的最重要的问题是业务互操作性。大多数SBB或COTS将嵌入自己的业务流程。更
改嵌入式业务流程通常需要大量的工作，以至于重复使用解决方案的优势将丧失。过去有很多这
样的例子。
此外，必须考虑各种系统之间的工作流程方面。企业架构师必须确保对业务互操作性要求的任何
更改都由业务架构师和架构赞助商在修订后的架构工作声明中签字。