级别： 中级 Eric M. Nelson (ericnels@us.ibm.com), 认证高级 IT 架构师, IBM
2008 年 6 月 12 日 企业开放体系结构（Open Architecture，OA）是一种非功能需求模式，可以帮助您创建和维护更加开放和灵活的复杂系统以及系统的系统。拥有大型复杂系统的组织正在期望 OA 帮助管理复杂性，提高灵活性和降低系统成本。在系统设计和实现中满足 OA 非功能需求（开放标准、模块性、可互操作性、可扩展性、可重用性、可组合性和可维护性）是企业级 OA 的基本要求。在本文中，了解 OA 背后的企业业务驱动因素，以及 OA 非功能需求。本文还将介绍用于处理这些需求的关联体系结构原则。后续文章将讨论 OA 业务原则、OA 指标和其他 OA 主题。
引言
一些拥有大型复杂系统的组织正在期待开放体系结构帮助管理复杂性，提高灵活性和降低成本。其他组织正在期待某种实现开放性的更广泛方法，从而支持更强的协作、创新和以 OA 的技术方面作为基础的社会策略。
 | | 对于 OA 倡导者来说，原始的 IBM® PC 体系结构和万维网是 OA 所能实现的成果的示例。遗憾的是，PC 和 Web 上的开放性并不直接转换到企业体系结构（enterprise architecture，EA）中。 |
|
长久以来，软件开发和复杂系统开发一直在设法实现“即插即用”的简单性和灵活性。作为快速技术采用和进步的一个促进因素，诸如 IBM PC 和万维网等 OA 经济效果表明了 OA 的价值。人们经常引证 OA 提供了几个有价值的业务成果：
- 快速的技术采用
- 更强的业务流程和技术基础设施灵活性
- 更容易的测试和集成
- 快速的技术功能和性能改进
- 通过以下方面降低系统生命周期成本：
- 提高的竞争力
- 更容易维护和升级
- 更熟练的实践者
- 更强的组件重用
这样的成果让人确信，在系统开发和工程中使用 OA 可以节约资金，更快完成产品和系统，并使得扩展和维护那些产品和系统更加容易。但是，将 OA 扩展到企业还需要支持流程和企业体系结构（enterprise architecture，EA）治理。企业和政府已开始认真地考虑企业级别的 OA。人们还日益重视将开放性作为跨越组织边界和公共与私有机构间实现更强的协作灵活性和大规模创新的基础。这个“开放的生态系统”是从增加的连接性、更容易的协作和更好的高速通信技术可用性发展而来的。政府和企业正在使用更高的透明度，以更加灵活地对更快的事件节奏及其更广的全局影响作出反应。
|
开放的 ICT 生态系统
开放 ICT（信息和通信技术）生态系统路线图
具有来自全世界的政府和企业的例子，这些例子说明了使用开放 ICT 生态系统来实现效率、创新和增长的最佳实践。其中将开放 ICT 生态系统定义为“……能够整合和维持互操作性、协作开发和透明度。[……]开放的生态系统是异构的，并组合了开放和封闭以及专有和非专有的技术”。开放的 ICT 生态系统是可互操作、以用户为中心、协作、可持续和灵活的。
|
|
OA 的目标相对容易定义。但是在企业级别实现 OA 或在复杂系统或系统的系统中创建 OA 却不一定那么容易。本系列文章讨论 OA 的技术方面，以及在企业环境中指定、构建和维护 OA 所必需的业务原则和指导原则。
OA 业务驱动因素
OA 体系结构原则用于指导设计以满足一组特定的业务驱动因素：
- 降低总体拥有成本：
- 增加重用
- 提高灵活性
- 加快上市时间
- 改进互操作性
- 加强竞争
- 降低风险
其目标是实现一个只需极少的时间和成本影响即可修改和扩展的体系结构。系统的组件应该很容易替换和升级，并且应该很容易学习和维护。该体系结构应该可以外包，或者更好的是，应该可以开发任何组件而没有法律、技术和财务约束，并且只需对接收系统做很少的自定义或不需要做任何自定义。
定义 OA 的优点和随后实现这些优点完全是两回事。虽然 PC 和 Web 可能证明了开放性对特定技术的价值，但该价值并不自动适用于企业。对于产品供应商来说，PC 的 OA 可以促进构成部件的商品化、更低的成本和快速的创新。企业通过使工资单和 HR 系统变得开放和可互操作来获得价值要困难得多。在某种意义上，PC 和 Web 是通用的，但是工资单和 HR 会非常特定于某个企业，并且很可能由许多运行在多种平台上的应用程序组成。让这种规模的企业变得开放是一项更加复杂的任务。
定义开放和封闭体系结构
如何识别 OA，以及如何从目前的现状开始到达 OA 的彼岸呢？来自电子硬件和材料工程的“即插即用”概念非常具有有吸引力，但是由于两个重要原因而证明其在软件中非常难于实现：
- 软件互操作性涉及到供应者和使用者之间更多的自由度。数据语义、交互语法和协议是非常开放的。公司可以使用几乎无限种类的数据模型来表示想来应该简单的“客户”概念。
- 与软件组件相比，对硬件组件的属性和功能进行数学建模要容易得多。可以证明，正确的软件一般仍然使我们理解不了。可以论证的是，您使用软件来编码的流程和功能不太可能被证明是正确的，因此在现实系统中应用这样的证据是没有用的。
有了用于确定体系结构开放性的定性标准（无论是某个当前系统还是某个设计），您要寻找什么和您要构建什么呢？在最高级别上，您可以问：第三方是否可以替换某个系统组件，并且仅使用该组件的公开发布和可用的技术和功能规范？如果回答为“是”，则系统的技术体系结构、组件规范和组织的业务实践都无法阻挡第三方开发、销售、集成和维护该组件。回答“是”意味着：
- 不存在技术障碍，例如对封闭组件的依赖、不完善的规范等等。
- 不存在业务障碍，例如专利、许可证、NDA、第三方协议等等。
做肯定回答还意味着组件和系统都是开放 的。
完全封闭 的系统不可扩展，并且无法与其他系统互操作。在具有完全封闭的系统的组织中，数据通常通过人工传递网络 (sneakernet) 或其最新改进形式——即时消息——进行交换。封闭系统具有以下特征：
- 围绕紧密相关的任务进行组织。
- 针对性能做了高度优化，并且使用仅包括与工作效能相关的数据的数据库或文件结构。
- 其组织方式通常最适合于应用程序的结构。
此类系统的一个部分示例是 Seibel CRM 系统。虽然 Seibel CRM 系统提供了用于互操作性的 API，但其数据格式是专有的。您无法在 Seibel 服务器之外重新构造完整的数据模型，因为许多数据元素关联内置在服务器应用程序本身之内。
也许除了 20 世纪 60 年代和 20 世纪 70 年代构建的独立专业系统以外，当今的大多数系统并不是完全封闭的。这些系统提供了一些用于互操作性的 API，但是关键功能仍然保持不可访问（或者使用法律约束来尽量锁定客户使用他们的产品）。在大型系统集成中，例如在国防工业中，这种锁定会非常微妙，并且只有到需要升级和扩展系统时才会认识到这种锁定。例如，可以添加特殊的商业化现成（commercial off-the-shelf，COTS）中间件来“改进”系统，但同时也使得总体系统依赖于专有扩展。
如果没有维护 EA 治理，即使设计良好的开放系统也会缓慢地降级为封闭系统。在时间压力之下，或在不了解系统架构师意图的情况下，更容易以不够开放的方式修复问题或添加功能。随着时间的推移，这样的系统更改往往会导致不够开放的实现。
本文的其余内容将解释创建 OA 所需的条件，并解释企业治理所需的体系结构原则，以了解架构师将系统保持开放的意图。
|
Naval 开放体系结构
一条 2004 年的美国海军指令要求海军的武器以及指挥和控制系统开始采用具有 OA 属性的系统。这些系统需要降低成本，以及加速开发和部署。IBM 和一些小型业务合作伙伴一起与海军签约，以帮助海军在其获取和系统开发工作中引入 OA。海军的部分机构已经引入了 OA 方法，包括一个称为“开放体系结构计算环境”（Open Architecture Computing Environment，OACE）的技术规范和一个称为 ARCI 的基于 COTS 的 OA 反潜声纳计划。IBM 领导的团队与所有海军战区、软件工程协会和约翰霍普金斯高级物理实验室合作定义了如何在整个海军中应用 OA。本文得益于与参与者所进行的讨论，但本文中的陈述和意见并不代表海军部或该项工作中的任何其他参与者的陈述和意见。
|
|
OA 技术需求
技术 OA 是一种帮助您创建、部署和管理 OA 系统的非功能需求 (NFR) 模式。本部分提供从业务驱动因素中产生的核心 OA NFR 的综合概述。其中说明了七个 OA NFR 之间的关系。
在诸如系统工程等部分领域，OA 注意事项同时适用于硬件和软件组件。两种组件类型的 OA 体系结构原则是相同的，虽然软件的 OA 体系结构原则更难进行评估。（对 OA 指标的讨论是恰当的，但是超出了本文的范围。本 系列的后续文章将会对此进行讨论。）
图 1 中的类关系图显示了关键 OA NFR。这些 OA NFR 之间的关系表明，要使设计满足某一个需求，可能需要得益于满足其他某一个需求。需求的满足建立在满足开放标准和模块性需求这个基础之上。
图 1. OA 非功能需求
下面将讨论 NFR 以及 NFR 之间的需求满足依赖性。当然，这个 NFR 模式只是可应用于某个体系结构的 NFR 的一个子集。其他 NFR 包括可用性、可恢复性、可伸缩性、可承受性等等。在已决定需要一个 OA 时，此模式就会产生。
开放标准
|
软件的开放标准要求
“为了符合开放标准要求，开放标准必须满足以下条件：
1. 无秘密：该标准必须包括可互操作的实现所必需的所有详细信息。
2. 可用性：该标准必须在免版税条件下自由和公开可用（例如来自稳定的网站）。
3. 专利：该标准的实现所必需的所有专利必须：
- 在免版税条件下授权无限制使用，或者
- 在由开放源代码软件使用时适用非纠纷承诺
4. 无协议：一定不能存在任何针对许可协议执行、NDA、授权、点击次数的要求，或要求部署该标准的一致性实现的任何其他形式的书面材料。
5. 不存在与 OSR 不兼容的依赖性：标准的实现一定不需要任何其他无法满足本要求的条件的技术。”
|
|
开放标准的一般定义如下：
- 来自 Wikipedia：“……包含可实现的规范的公开可用文档”。
- 来自 DoD：“广泛使用、基于共识、由公认行业标准组织发布和维护的标准”。
虽然这些定义对于奠定基础非常有用，但它们没有阐明是什么构成了有用的 开放标准。存在某个标准并不意味着可以支持某个开放系统的开发——而只是意味着该标准本身是开放的。
可以将谚语“您可以使用任何语言来编写 Fortran”变换到 OA，即您可以使用任何数量的开放标准来创建一个封闭系统。开放源代码协会（Open Source Institute，OSI）提供了更明确的描述，该机构已定义了一个开放标准要求（Open Standard Requirement，OSR），其中规定了开放标准必须满足开放源代码开发需求的要求。如果据称的开放标准妨碍了开发、分发或运行开放源代码项目中的代码的能力，则（从 OSI 的角度看）该标准就不足够开放。OSR 是一个非常清楚 的规范，其中规定了某个开放标准一定不能包括的内容。
当然，并不能预期所有系统功能都具有开放标准规范——尽管无数竞争的标准导致了这一印象。在缺乏相关标准的情况下，希望创建开放体系结构的企业应该在适当的情况下，指定与 OSR 的严格级别相同的组件接口和行为规范。如果企业已与某个系统集成商签约构建一个开放系统，应该在契约中要求该集成商提供不亚于 OSR 标准的接口规范。
有些组织，尤其是美国以外的组织，喜欢诸如 OMG 或 ISO 等国际标准机构的额外批准，因为此批准意味着该工作得到了充分检查。如果组织对问题域不是十分熟悉，这样做尤其非常重要。但是，这是对某个国际开放标准的假定质量，而不是对其技术开放性的陈述。对于正在开放其功能的企业，标准机构的批准就像技术质量一样不必要。
对其他 OA NFR 的依赖性
无。在系统体系结构中满足开放标准要求并不需要满足任何其他 OA NFR，也不会通过满足任何那些要求来得到促进。
模块性
在软件工程中，模块“……一般必须是某个更大系统的组件，并且在该系统中的操作独立于其他组件的操作”(Wikipedia)。
模块性是一组支持操作独立性的系统属性，包括：
- 划分为离散、可伸缩和自包含的功能单元。
- 定义良好的模块接口，旨在便于理解。
在 OA 中，模块性的目标是按照模块的功能规范实现一致性和完备性，以及相对于其他系统模块的最大独立性。这适用于任何有边界的体系结构子系统或组件。规范并不需要基于某个开放标准；使用开放标准接口并不能内在地增强模块性。由于模块性本质上是一种自包含措施，对模块性需求的满足应该不需要满足任何其他 NFR。
对其他 OA NFR 的依赖性
无。模块性是按模块的设计和实现进行评估的。其重点在内部。模块化程度越高，模块就越不需要了解其集成和运行时上下文。此需求仅直接牵涉到定义良好、有边界的接口和行为，对外部接口的依赖性非常小。
互操作性
在 EA 上下文中，互操作性是运行在单独进程空间中的系统和系统元素交换数据和信息或请求和提供功能执行的能力。IEEE 将其定义为“……两个或更多个系统或组件交换信息和使用已交换的信息的能力”。在实践中，互操作性有时还指共享运行时资源，例如磁盘访问、内存或诸如数据库访问等服务。
对其他 OA NFR 的依赖性
互操作性isFacilitatedBy 开放标准（请参见图 1）。开放标准通常旨在支持分布式、异构环境中的互操作性。实现开放标准的系统使得该系统的功能成为已知数。其他系统的架构师能够预期该标准所规定的功能和服务将可供他们的系统使用。系统或其子系统和组件不必基于开放标准即可实现互操作——只是变得更容易了。从原理上讲，原本可以在没有公共开放标准的情况下构建万维网的，但是那样的话，万维网将不会那么丰富、那么普遍或那么廉价，并且不会具有我们所体验到的转化力量。
可扩展性
可扩展的系统设计具有允许将来添加功能的挂钩（例如接口、端口、连接器、抽象类）。要支持可扩展性，系统实现必须具有足够的内部质量和模块性，使得新功能不致对现有的数据和行为引入意外的更改。
组件的可扩展性不同于系统的可扩展性。可扩展的组件可存在于不可扩展的系统中。类似地，可扩展的系统可通过不可扩展的组件创建而来（尽管在所有组件都不可扩展的情况下，在系统级别实现可扩展性将非常困难，虽然也并不是不可能）。可扩展性是向系统组件添加新功能（模块可扩展性）和向现有系统添加组件和子系统（系统可扩展性）的能力。
对其他 OA NFR 的依赖性
可扩展性 isEnabledBy 模块性。其组件之间具有紧密耦合的系统很难扩展，因为依赖性的网络是非常脆弱的。更改的结果很难预测，并且很可能导致故障。没有重视定义良好的业务或技术功能的组件具有“模糊”的边界，扩展这些组件的方式很不明确。定义良好的模块化系统不会遭遇到这些问题。
可扩展性 isFacilitatedBy 互操作性。支持互操作性的系统可容易地包括其他可互操作的元素，因此更容易扩展。系统不一定要可互操作；良好的模块化设计也许足以实现内部可扩展性。
可重用性
可重用性是构件的一个属性，此属性允许在多个运行时和业务流程上下文中使用构件的功能。传统上，在软件工程中，重用一般发生在代码和模块级别。最近，系统设计、开发、培训、实现、配置或维护中的任何生命周期构件都可以是重用的候选者。例如，模型驱动的体系结构 (Model Driven Architecture™) 更明显地表明了设计构件是非常有价值的重用构件。
在 OA 上下文中，可重用性主要是指可重用系统组件，而不是主要指设计和属于获取过程一部分的其他构件。但是，最佳实践认为，与组件的设计、构造和配置相关的所有构件都应该是可交付的可重用构件的一部分。
对其他 OA NFR 的依赖性
可重用性 isEnabledBy 互操作性。可重用组件显然需要能够在具有最少调整的情况下与其他组件互操作。取决于组件不可互操作的程度，其作为可重用组件的价值也相应地降低。
可重用性 isEnabledBy 可扩展性。可重用组件更容易集成到可容易扩展的系统中。可重用资产规范 (Reusable Asset Specification) 将可扩展点确定为资产包的关键组成部分。在某些情况下，可重用资产不应该是可扩展的，因此可扩展性不是必需的特性，但是可重用资产中原则性的可变点使得资产能够适应更多的上下文。对于接收系统，可扩展性使得添加可重用资产变得更加容易。
可重用性 isEnabledBy 模块性（由可扩展性传导而来）。重用取决于构件的可理解性及其无依赖性。紧密耦合的组件将难于移动到不同的运行时上下文中。高度耦合的组件的重用需要将运行时上下文、系统和组件一起移动到另一个平台。这是简单的可移植性，而不是完全的可重用性。良好的模块化设计提供了重用所需要的定义和最少的依赖性。
可组合性
可组合性是一个处理组件相互关系的系统设计原则。高度可组合的系统提供了重组组件，可以通过各种方式选择和组合重组组件以满足特定的用户需求。对于 OA，此基本定义应该包括以下需求，即可组合的组件只需很少或不需要更改即可互操作。
对其他 OA NFR 的依赖性
可组合性 isEnabledBy 可重用性。可组合性是重用的一种变体，并预期不需要对组件或系统做任何修改或调整，即可在新的或更改后的业务流程中使用该组件。可重用性对于实现可组合性非常重要。
可组合性 isEnabledBy 互操作性（通过可重用性传导而来）。可组合的元素必须能够立即与新运行时上下文中的适当组件协作。可组合的元素必须是可互操作的，并且必须部署到包含其他可互操作元素的运行时上下文中。
可组合性 isEnabledBy 可扩展性（通过可重用性传导而来）。系统组件的可组合性要求能够在对现有系统组件或系统配置做最少更改的情况下实现接口更改。还应该能够在不致将组件实例置于不一致状态的情况下，实现对组件交互协议的逻辑更改（组件接口上的方法调用顺序）。
可组合性 isEnabledBy 模块性（通过可重用性和可扩展性传导而来）。具有可组合元素的系统需要定义良好的功能组件，这些组件的功能非常清楚并且绑定良好。组件需要最少数量的依赖项，以便能够成功部署到不同的运行时上下文。良好的模块化设计对于提供这两个属性极为重要。
可维护性
可维护性是“根据规定的要求执行功能单元维护的容易程度”(Wikipedia)。可维护性的设计影响安装后的组件或系统生命周期，包括其生命的终止。生命周期的一个重要部分是更新系统，以引入新的技术、更改后的业务流程等等。
对其他 OA NFR 的依赖性
可维护性 isEnabledBy 模块性。设计良好的模块化组件允许您对现有系统进行更改、扩展和替换其组件。如果没有模块性所提供的分离，要整合更改将更加困难，并且随着时间的推移，将需要越来越长的时间来创建、测试和安装更改。
可维护性 isFacilitatedBy 可组合性。如果系统使用重组组件，将会更容易添加、替换和删除组件而不会导致系统故障。尽管不是必需的，但是使用重组组件有助于实现系统的可维护性。
可维护性 isFacilitatedBy 可重用性。组件可重用性主要集中于使用可重用组件来创建系统，因此可维护性不是直接的关注重点。然而，可重用组件在表现出模块性和互操作性的情况下，很可能更容易维护。
可维护性 isEnabledBy 互操作性（通过可重用性传导而来）。在考虑到互操作性的情况下开发的组件和系统使得通过技术、功能和规模更改来维护系统变得更加容易了。
可维护性 isFacilitatedBy 开放标准（通过互操作性传导而来）。开放标准可能受到多种实现的支持，这些实现应该是可互换的，从而可替换以执行修补、升级和替换。熟悉开放标准系统的技术资源将会更多，有关维护开放标准组件或系统的知识库将会更加广泛。
OA 和 SOA
您可能已经注意到许多 OA 需求同样地适用于面向服务的体系结构 (SOA)。它们之间的区别主要是侧重点不同。SOA 的侧重点跨越了系统，而 OA 的侧重点在某个系统之内。在最高级别上，OASIS SOA 参考模型将 SOA 定义为“……一种用于组织和利用可能受不同所有权域控制的分布式功能 的范型”。表 1 对这两者作了对比。
表 1. SOA 和 OA 的区别
| SOA 关注事项 | OA 关注事项 |
|---|
| 系统之间的句法和语义互操作性。 | 某个系统中的开放和模块化设计。 |
|---|
| 软件体系结构。 | 软件和硬件体系结构。 |
|---|
| 将系统中所有操作的一个子集公开为服务。 | 系统及其所有重要组件都应该是开放的。 |
|---|
这里的区别不是绝对的；两种体系结构方法都与互操作性有关。在边界上，由于不同的重点而存在区别。例如，可以使用一个 Web 服务适配器向网络公开封闭系统的功能，而不使该系统本身变得开放。无论如何也不可能将该系统本身视为开放的。另一方面，没有外部可见的服务的系统仍然可能是非常开放的。事实上，已经开放的系统已满足了创建 SOA 中的良好服务所需要的许多互操作性和可组合性需求。
图 2 显示了（不按比例）SOA 和 OA 如何在所有核心 OA 需求方面具有一些共同的关注事项。在某些情况下，例如对于可维护性，软件可维护性将适用于 SOA，但是硬件可维护性则是不相关的。
图 2. OA 与 SOA 重叠
OA 原则
体系结构原则是对企业系统和系统组件的大致约束。体系结构原则应该：
- 沿着实现特定业务目标的方向指导体系结构、设计、开发和系统管理决策。
- 避免将会限制系统成功的错误。
与指导原则不同，原则是强制性的。为某个企业开发的所有系统和组件都必须遵守适用的原则。例外是可能发生的，但是必须在企业级别对例外进行仔细论证、审核和批准。论证过程必须说明：不能满足原则的原因、该例外对原则意图的影响，以及用作原始动机的用于避免任何问题的缓解措施。
允许例外的门槛必须非常高。由于原则应用于企业，接受审核的任何系统都应该精心设计以优化整个组织中的流程或功能。任何种类的性能优化几乎都决不应该是违背原则的充分理由。
本部分讨论处理 OA 需求的体系结构原则陈述。其中将讨论每个原则的一些重要结果。
存在开放标准时使用开放标准
| 体系结构原则：在 OA 系统中，适用的开放标准是所有系统和组件的强制性规范。这适用于中间件和第三方组件以及正在开发的系统。 |
|---|
在不存在适用的开放标准的情况下，组件和系统（无论是 COTS 还是自定义的组件和系统）应该具有文档记录，并在组织中以与开放标准和 OSR 一致的方式可用。
- 动机
- 此原则的目标是创建在整个生命周期中具有最大数量的标准可替换组件的系统。成本削减和质量改进可容易地整合到不太复杂的升级中。此原则背后的因素包括：
- 专有或未发布的 API 将系统所有者锁定在供应商的产品和升级计划中。由于被锁定，采购竞争技术将非常困难并且成本昂贵，因此系统所有者付出了更高的生命周期代价，并且供应商没有太大的动力去实施创新。
- 使用开放标准降低了新系统和组件的集成和互操作性风险。供应商一般将开放标准遵从性视为客户的需要，因此构建的新系统通常遵从或兼容适当的标准。
- 开放标准通常具有了解标准并且已经将标准应用于广泛的环境和问题的相关社区。
- 结论
- 开放标准 API 也许没有提供系统所需的所有功能。避免自定义或扩展任何符合开放标准的组件。相反，应该在某个显式依赖 OS 兼容组件的扩展组件中实现额外的功能。
如果您的组织才开始使用外部规定的标准，则需要一个学习过程。
如果组织过去曾认为其所有 需求都是独特的，这可能是个严重的摩擦点。主管的支持必须一致、明确并高度可见才能支持此更改。
开放标准可以使更多的熟练专业人员对组织可用。除了非常常见的软件的事实上的标准以外，大多数专有系统都有许多专业人员可用，这些人员通常提出非常高的工资要求。
要维持对此原则的遵从性，将需要作为 EA 治理的一部分进行体系结构审核。您可能需要一个体系结构审核委员会来维护标准的组合，以及确认系统和系统组件遵守该原则。
对组件和系统使用模块化设计
体系结构原则：必须在系统的所有层上对每个系统的所有软件和硬件组件使用模块化的设计原则。
- 动机
- 模块化的设计使得维护、扩展和升级系统变得更加容易，从而降低总体拥有成本。与开放标准遵从性相结合，模块化的设计使得利用供应商的价格竞争和标准化系统及组件的性能变得更加容易。
- 结论
- 如果模块化的设计不是组织中的普遍实践，则设计和开发良好的模块化系统将要花更多的时间。需要额外的时间来开发：
- 清楚的模块化组件和系统设计文档，该文档对于重用组件和随时间推移而维护系统非常关键。
- 数据模型和明确规定的服务质量，以提供组件之间最大的互操作性。
如果模块化系统中的某个模块不是由第三方提供的，则企业必须建立标准所有权和生命周期维护过程。模块化的组件不应该进行特别修改。两种常用方法是自身拥有的管理 (owned management) 和组织开放源代码。
- 对于自身拥有的管理，一个组织拥有该组件、该组件的生命周期管理和部署。当企业没有将 IT 视为战略资产时，这种实践也许是最好的。变更请求将发送到所有者组织，并在其标准 CM 流程（例如 ITIL）中进行处理。
- 对于组织开放源代码，企业使用 OS 社区协作。所有相关各方都可以贡献新功能、修复错误和审核变更。企业在致力于此类方法之前，应该首先研究 OS 社区最佳实践。需要将 OS 协作与主动的 EA 治理流程结合在一起，并且 EA 治理可能必须变得更加主动。
互操作性设计
体系结构原则：OA 系统和组件必须提供并支持系统、流程和数据的互操作性。互操作性适用于某个系统的组件、该系统在任何运行时上下文中对共享资源的使用，以及与可通过网络访问的系统之间的互操作性（当需要分布式互操作时）。
- 动机
- 互操作性是水平集成和面向服务的体系结构的基本要求。互操作性支持适当的系统资源共享，并支持在系统之间提供和使用功能及数据的能力。互操作性使得系统的系统更加可行和可管理。
- 结论
- 至少，一个企业公共数据模型是必要的。如果在企业之外需要互操作性，例如在供应链管理中，则应该使用某个域数据模型（本体）。公共数据模型（其中包括数据结构、数据结构之间的关系和关联的语义）对于有效的互操作性非常关键。
可能还需要处理服务质量。如果客户机系统需要特定的 QoS 才能正常操作，则所需的 QoS 将是确定互操作性的基本要素。
信息保证（Information assurance，IA）是一个基于恰当互操作性的重要假设。如果对影响系统执行的数据（以及元数据）没有信心，则互操作的正确性就值得怀疑。对 IA 的需要不仅适用于运行时期间的数据共享，而且还适用于数据的来源、其未使用时的安全性、其时效性，以及正在处理时的处理安全性和可靠性。
可扩展性设计
体系结构原则：OA 组件的设计必须允许更新当前功能和添加新功能，而不需要改写该组件或任何依赖该组件的组件。修改后的组件和新组件必须能够在对现有组件、功能和过程具有最小影响的情况下与系统集成。系统可扩展性还应该最大限度减少变更对系统管理、维护和培训的影响。
模块化、兼容开放标准的系统能够提供即插即用功能，但是可扩展性不一定如此。基于标准的组件可能仍然难于扩展，特别是在组件经过仔细优化的情况下。
- 动机
- 在 IT 系统中，更改是不可避免的。在现实意义上，IT 系统是已实现的知识。实现用户的知识的基本过程将改变他们对知识的理解并带来新的需求。诸如新技术、新规章和竞争等外力推动了系统的更改。无论是否为扩展做了预期和设计，对系统的扩展都是不可避免的。
- 结论
- 企业架构师应该鼓励关键参与者描述他们的业务方向远景和支持该业务方向的系统。任何体系结构都与某个时间点相关；体系结构处理了当前（也许包括不久的将来）的一组关注事项，但在将来的作用通常未得到处理。参与者可能还没有以这种方式考虑体系结构，架构师应该鼓励他们检查一下可扩展性范围。这可以是支持和论证可扩展点的起点。
可扩展性设计将要花稍长一点的时间。与 OA 的所有设计方面一样，要为项目中的初始需求捕获和设计计划更多的时间。紧密集成的不可扩展系统很容易构建，因为这些系统没有过多考虑当前问题的需求。
可重用性设计和利用
体系结构原则：在系统生命周期的每个阶段，充分使用现有的企业资产是必需的。重用要在扩展之前进行考虑，扩展又要在新的设计和开发之前进行考虑。新组件的设计和开发将考虑到可重用性，并将向审核委员会提交候选的可重用组件。
可重用组件需要对使用这些组件的特定问题域进行某种程度的抽象。可重用组件必须捕获：
-
共同点——跨大多数潜在的组件使用场景所共有的核心行为和信息。
-
可变点——可能需要更改组件以便在不同的问题上下文中工作的地方。
重用几乎是开放标准、模块化设计和可扩展性的一个自然属性。开放标准通常基于相关各方就常用功能或相关功能集的结构和行为达成的一致意见。模块化的设计推动了具有极少依赖项的定义良好的组件的创建，从而使组件可以在不同的上下文中使用。确定和实现可重用组件中的可变点是可扩展性的一个基本方面。满足这些需求的组件可能也是可重用的。
- 动机
- 资产重用可以节省大量的时间和精力，并改进系统质量。
- 结论
- 创建可重用组件需要付出更多的精力来进行设计、开发和测试。
要使重用对企业具有实质性的价值，需要对重用进行管理。如果没有管理和治理，可重用资产存储库就变成了垃圾场。EA 团队必须建立用于提议、验证和提供可重用组件的方法。还需要相关方法来保证新项目充分利用现有的可重用资产。这会给组织带来有关如何划分成本、所有权和跨组织职责的挑战。
可重用组件将需要极其严格的测试。对于典型的开发，将使用指定系统行为的用例来生成测试用例。在此上下文中，不需要使用范围之外的测试。然而，可重用组件预计将在还未预期到的用例中工作——某个组件最终可能在新用例中处于不稳定状态。详尽测试组件方法调用顺序和参数值的所有排列是不切实际甚至是不可能的，但是测试必须努力逼近可预测的情形的边界。至少，测试模块需要演示所能管理的尽可能接近完整的代码覆盖范围。
使用可重用资产规范 (Reusable Asset Specification) 作为可重用资产打包和部署的公司标准。这样将允许您利用重用存储库的当前和将来的工具支持。
可组合性设计
体系结构原则：实现业务级别功能的系统组件的设计必须允许将组件的原子行为编排到不同的操作序列中以实现多个流程，而不必更改组件的实现。
可组合性主要是与“编排不同的操作序列而不更改任何实现或数据元素”这个需求之间的互操作性。与可重用性非常类似，可组合性是一个满足其他 OA NFR 的自然属性。良好的模块化设计对于在许多不同的用例中提供定义良好并得到充分理解的功能是非常有用的。取决于其部署，模块化的设计对其他组件具有极少的依赖性。
互操作性对可组合性非常关键，因为如果要对可组合的组件进行编排以使其无需更改即可一起工作，则这些组件必须使用某个公共数据模型来进行工作。互操作性在基于开放标准时的功能是最强大的，因为它们往往得到了大型相关社区的良好测试和理解。
可组合性主要是一个业务操作级别的需求。虽然可以在系统体系结构中的较低级别应用可组合性，但其目标已经通过其他 OA NFR 得到了满足。
- 动机
- 业务流程通常比 IT 系统中实现的实际业务功能更改得更加频繁。利用已实现的功能并对它们重新排序或重新组织以提供新的功能或流程是可取的。原则上，这就像是程序员在对编程语言的指令重新排序以执行不同类型的功能时所做的工作。可组合性只不过是将业务功能概念化为业务的操作语言指令。
- 结论
- 可组合性需要 IT 基础设施功能的业务操作级别的规范。操作和信息必须以非常良好地映射到业务词汇表的术语来表述。重新组织功能的协同工作方式要求这些功能非常紧密地符合业务流程专家了解业务操作的方式。因此，业务和 IT 必须通过长期紧密协作所建立的交流来进行非常清楚的交流。
如果功能定义得足够好，使其自然地映射到业务的操作概念，那么这些功能的粒度级别非常可能也能容易地支持 SOA 方法的使用。
可维护性设计
体系结构原则：OA 系统、子系统和组件的设计和实现必须最大限度减少在其整个生命周期中修复和管理它们所需要的精力。
可维护性是系统：
- 可维持功能的程度
- 可更改配置的程度
- 可应用修复的程度
- 可安装替换组件的程度
可维护性还完全是个系统属性。在硬件方面，可以使用非常开放的组件，同时仍然将它们放在一起，使其无法分开。在软件方面，所部署的软件系统应该不需要极端措施（例如重新编译）即可修改，并且配置更改应该非常容易。
- 动机
- 开发和获取成本大约仅占生命周期成本的 20%。在其余成本中，基础设施和许可证成本是相对固定的。维护成本是能够通过事先设计来大幅度减少的成本。维护成本影响平均成本回收时间、升级的成本和复杂性等等。对于诸如自动化制造或航空控制系统等使命或安全关键型系统，易维护性特别重要。
- 结论
- 设计可维护的系统需要更多的时间。软件供应商之外的软件架构师应该考虑系统需要如何进行维护，以及如何修改自己的设计以促进可维护性。
确定可维护性需要清楚了解组件和系统的使用条件。诸如服务器安装等受控环境中的可维护性与诸如战场或极端气候等敌意环境中的可维护性区别相当大。
应该对可维护性进行测量。由于可维护性可以包括维护过程中的人工活动，因此测量和分析应该包括经过培训（和可能未经培训）的技术工作人员执行维护的时间、工作量和可行性。测量指标可以包括：
- 测试组件的删除和替换。
- 需要多少时间？
- 一个不熟悉该组件的适当技术人员使用所提供的文档来学会替换该组件要花多长时间？
- 如果环境需要（例如在军事系统中，存在熟练人员阵亡的实际风险），并且该组件是使命或安全关键型组件，一个未经培训的人员替换该组件要花多长时间？
- 需要将多少其他组件或系统删除或置于离线才能执行维护？
- 对于硬件组件，可维护性的所有内容都与易访问性有关。
如果存在某个组件的平均无故障工作时间（mean time between failure，MTBF）数据，可以在总体设计中考虑该数据。对于其 MTBF 很低或未知的组件，设计应该使这些组件高度可访问并且可容易地替换。如果 MTBF 未知，应该在可能考虑任何重新设计的任何场合收集并考虑 MTBF 数据。
持续的组件运行状况指标应该是组件设计的一部分，并且应该收集这些指标以便能够预计替换需求。
总结
OA 可以使系统更廉价、更灵活、更加可互操作和更快。OA 需要一种定义系统属性的方法，当在设计和实现中体现了这些属性时，系统将会变得更加开放。OA 还需要一个 EA 治理流程以建立 OA 原则并维护这些原则。七个 NFR 是支持开放性的核心体系结构属性：
- 遵守开放标准
- 模块性
- 互操作性
- 可扩展性
- 可重用性
- 可组合性
- 可维护性
每个 OA NFR 具有用于解释动机的对应体系结构原则陈述。这些原则研究了一些在采用 OA 并将其应用于设计和实现时可能出现的组织和技术影响。
欢迎阅读下一期文章
在技术方面，OA 只是可统称为开放生态系统的若干活动的一部分，这些活动包括：开放计算、开放创新、开放源代码、开放标准，等等。本系列的后续文章将讨论 OA 范畴，以及它如何与其他范畴相关。将探索的其他主题包括：
| 开放生态系统 | 集中于开放性的活动和技术的范围以及这些活动如何与 OA 相关，包括 OA 和 SOA 如何相关。 |
|---|
| OA 业务原则 | 为什么业务和获取流程需要是开放的，以及这些流程如何支持技术 OA。 |
|---|
| OA 指标 | 确定组件或系统是否需要 是开放的。测量开放性，尤其是在复杂的分层体系结构中。 |
|---|
| OA 指导原则 | 识别支持和阻碍成功 OA 的技术和业务流程。将 OA 原则应用于总体拥有成本的各个成本组成部分。 |
|---|
参考资料 学习
获得产品和技术
- 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
关于作者 | 
| | Eric Nelson 是 IBM Software Group Federal CTO Strategic Architecture 团队的一名认证高级架构师。他是 Naval 开放体系结构活动的 IBM 首席架构师，并且是创建 OMG UPDM 开放标准（UML Profile for DoDAF 和 MODAF）的 IBM 和行业团队的主要成员。 |
对本文的评价
| 
