简介

本文讨论企业计划和开发一个 CBS 支持策略，从传统企业架构过渡到支持 CBS 的参考架构所需的步骤。我们将讨论一些用于分析和评估企业架构是否遵守业务、应用程序、集成和技术、以及它们的相关关键参数的不同维度的方法。这将有利于我们理解企业是否准备好使用 Composite Business Services (CBS) 构建解决方案，发现当前存在的差距，并满足企业落后的每个维度中的要求。

多数组织已经逐渐自动化了它们的业务流程要求，它们的方法是：将业务流程要求分割为应用用例，然后在预算之内基于需求将业务功能实现为 IT 应用程序。大多数这些应用程序在企业内的发展通常没有计划，有时，为了满足新的业务流程要求，这些应用程序需要和其他程序集成。这些应用程序也许是内部应用程序，也可能是伙伴应用程序。这样，对集成产品和技术的需求就越来越强烈。很多供应商都盯着这个市场，致力于成为 Enterprise Application Integration (EAI) 领域的市场领袖。同时，不同的企业架构蓝图，比如 Zachman、TOGAF、TeA 和 IAF（请参见 “参考资料” 部分了解详情），也在寻求消除业务需求和已实现的 IT 解决方案之间的差距。许多这些企业架构方法寄希望于通过这些应用程序的集成来满足业务流程要求，这导致了人们更加关注集成工作，而不是在企业层面上提供一个清晰的业务流程全貌。当这些应用程序本身面临变革以满足新的业务需求时，应用程序集成就变得困难重重。人们对项目提出了额外的需求：以更少的开发成本、更短的交付时间交付解决方案。业务驱动的 SOA 开发以复合应用程序或复合业务服务的形式对这个问题提供了一种可行的解决方案。一个 Composite Business Service 是一个 Business Services 集合，这些业务服务相互协作，与客户的现有应用程序一起提供一个特定的业务解决方案。CBS（基于一些松散耦合的分布式资产的合成）实现一个资产模型，从而提供灵活的可重用解决方案。CBS 可能包含遗留应用程序、打包应用程序和网络交付服务。Composite Business Services 的架构、设计和开发方法学有助于我们构建可重用的业务服务，这些服务处于一个更高的功能级别，开辟了进行无编码业务驱动开发的美好前景。

对于已经采纳了 SOA 的企业来说，可以通过采用可靠的行业内容模型轻松快速地迁移到复合应用程序开发。行业内容模型提供服务定义、可靠的数据模型以及基于行业标准和最佳实践的公共服务。惟一需要完成的额外工作是使用这些可重用模型来重新遵循业务架构，针对适当的分解和粒度水平重新评估业务服务，以及根据调用它们的角色或通道增强或修改不同的功能特性。

如果一个企业还没有采用业务驱动开发和 SOA，且它想要开发复合应用程序，那么该企业需要在实践中研究和评估组织本身的企业架构，以便直接迁移到 CBS 参考架构。应用程序和数据架构以及它们的集成方法本身不足以评估企业的 SOA 成熟度，就像 Service Integration Maturity Models (SIMM) 通常所做的那样。此外，评估时还需要考虑业务功能和技术架构的企业支持。

基于调查问卷的方法：如果软件系统的目标很容易识别并定性，则可以定义一个问题列表，这些问题可以应用到软件系统的总体架构。这些问题构成用于评估架构的调查问卷，可以处理架构定义的各个不同方面。

基于检查表的方法：这种方法类似于基于调查问卷的方法，但是，它通常关注架构将解决的特定特性。与基于调查问卷的方法相比，基于检查表的方法需要一个更成熟的评估实践。

基于概念证明（Proof-of-Concept，PoC）的方法：采用这种方法时，用于实验和模拟的原型是开发过程生成的工件。在这种方法中，我们通过考虑一个表示架构的模型的复杂应用程序用例来实际测试一个实现。在设计和开发在大量用例中发生前，这些原型结果用于回答一些关键的架构问题。

根据可用时间和组织对评估的支持，我们可以遵循定性方法和定量方法中的一种，或者同时使用两种方法来评估企业架构及其开发复合应用程序的可行性。图 1 展示了一个明确定义的联合评估方法。
图 1. 评估过程方法

CBS 的维度

为了适应 IBM 的 CBS 基础参考架构，需要设计一个评估过程来评估企业架构。CBS 有 4 个维度，下面逐一介绍。

人员视图 关注系统的人力资源方面，它检查系统中的人类角色。
   业务流程视图 处理系统中涉及的用户流程。
   业务功能视图 处理支持流程所需的功能。
   业务信息视图 处理支持流程所需的信息。
   可用性视图 考虑系统及其环境的可用性。
   业务性能视图 考虑系统及其环境的性能方面。
   应用程序和数据架构

这个维度描述涉及数据和应用程序系统领域的架构，它包括应用程序软件库存、图表和应用程序之间的接口（这包括事件、消息和数据流）。数据架构包括概念、逻辑和物理数据模型及其元数据模型。

访问/呈现集成视图 处理访问系统功能的不同方法，以及对各种类型的客户端（门户、移动、内联网、电话设备、电子邮件设备、PDAs 等）的支持。
   应用程序集成视图 处理组织内应用程序的集成，或者使用企业应用程序的业务伙伴。这允许应用程序互相连接，以便它们能够在企业层面上更好共享和使用信息。
   信息（数据）集成视图 处理可以跨企业集成的各种形式的业务信息。这种集成在一个统一的信息资产视图上支持一致的搜索、访问、复制、转换和分析，从而满足业务需求。
   流程集成视图 处理企业内外部业务中的变化，以及它如何在跨人员和异构系统的流程建模、自动化和监控过程中操作。

   技术架构
   本质上，技术架构是包含硬件和软件组件的基础设施，它包含企业服务器、数据服务器、防火墙、应用程序基础设施、安全、监控和中间件。技术架构还描述企业中使用的编程语言和操作系统。这个维度还评估已开发的软件组件利用开放技术标准的程度。

   如何评估企业架构的 CBS 就绪程度
   评估企业架构的第一步是完成一个 Request for Information (RFI)，在其中处理前面提到的 4 个维度。这个 RFI 将发送给客户。从客户获得响应之后，准备一个基于检查表的模板，针对这个模板验证响应。这些模板最终结果针对 CBS 参考架构和 CBS 服务的开发对现有架构进行定性评估。如果一个组织在所有 4 个维度的定性评估中均合格，那么将继续进行第二个步骤 —— 定量评估，这需要该组织准备一个基于各种场景开发一个原型模型的说明。这个说明将描述如何根据场景设计、开发这个原型模型并描述将用于评估的指标，“基于场景的 PoC 评估” 小节将详细介绍这个说明。图 2 展示了用于遵循 CBS 的定性和定量方法。

图 2. 定性和定量迭代

组织有良好定义的 Business Process Management System (BPMS) 来定义、维护、测量、分析和持续改进它们的业务流程吗？
企业拥有业务流程建模器、可执行流程建模器、流程执行引擎、业务活动监视器、流程管理门户等工具来支持 BPMS 的完整生命周期管理吗？
组织建立了一个 BPM Center of Excellence (BPM-COE) 中心来实践这样的框架、工具和方法学，以便将业务要求有效地转换为 IT 系统吗？
组织拥有帮助确保公司方向在运营层面上实现的流程治理吗？
RFI 中的 “业务要求” 部分需要将预定义的业务子功能包含到企业从事的业务领域。我们可以将一个客户银行自助服务门户作为一个示例。这个门户可能包含以下子功能：账户开立、账户查看、支票簿和 ATM 复制 PIN 的服务请求、账单支付、资金转账和信用卡服务等。组织需要在这些子功能中或围绕这些子功能提供它们的业务解决方案。根据从企业获取的 RFI 响应，组织业务遵循应该考虑以下几点：

组织当前同时支持多少业务子功能？
   有多少业务子功能需要根据预定义的功能进行修改？
   有多少业务子功能需要从头开发？
   有多少业务子功能当前不受支持，但有明确的路线图以便在一个规定的时间范围内支持那些服务？
  “业务架构评估” 部分还包含一个关于通过业务流程模型和业务服务实现业务子功能的问卷调查。在评估他们的业务服务实现时应该考虑以下几点：

组织采用了一些行业特有的业务流程模型了吗？
   他们使用自己的自定义构建模型吗？如果是，这些自定义构建模型吸收业务要求中的变化的灵活性如何？
   他们的业务服务支持 ACCORD、HiPAA 和 SWIFT 等行业特有的数据模型来在其他服务之间交换数据吗？
   组织遵循任何标准方法或技术来识别 RUP for SOA、SOMA 等业务服务吗？
   已实现的业务服务提供基于业务政策和用户上下文的灵活的可调节行为吗？
   业务服务是通过多个通信通道提供的吗？
   业务服务是从不同的 IT 系统实现的吗？如果是，它来自一个 Silo 格式吗？是集成的吗？或者，它是来自组件化的流程集成的吗？
   上述问卷调查的所有答案将针对遵循 CBS 服务的开发进行研究和分析，并最终针对这个部分准备一个定性评估图表。

通道和呈现层
   业务流程和精编层
   服务或呈现功能
   业务规则
   服务注册层
   数据和数据访问层
   以下小节将详细介绍上述每个主题：

呈现层应该支持 STRUTS、JSF 和 Dot Net U 等开放标准框架，必须可以轻松扩展或修改来构建自定义呈现层框架。
   呈现层还应该足够灵活，以便添加 PDA 客户端、表单和电子邮件等新通道。
   如果组织正在使用某种自主框架，那么应该评估该框架与开源框架之间的关系。
   检查通过 Web 服务接口的无外设（headless）系统功能调用。
   检查呈现层是否与当前系统/应用程序松散耦合。
   系统支持哪些不同类型的物理设备/通道？向现有系统添加一个新的物理设备的灵活性如何？
   业务流程和精编层

应用程序架构的评估要考虑业务流程和精编功能。评估人员应该检查组织，查看他们是否采用任何业务流程层和运行时引擎来编排他们的业务服务/应用程序功能。以下几点用于评估这个架构层。

如果组织使用了任何自主流程流或工作流层，通过将其移植到外部 BPEL 设计工具和运行时引擎来检查它是否遵循 BPEL 标准。识别在开放标准运行是引擎上运行这样的自主工作流需要遵循的步骤和程序。
   组织是否拥有任何自动为部署而生成 BPEL 运行时代码的业务流程建模工具？
   检查遵循 BPEL 的运行时引擎如何实现为一个可伸缩的成熟产品，并拥有补偿、业务和技术异常处理功能以及指标、交易量监控功能。
   检查当前流程流是否支持调用人工任务、选择器、业务规则和 ESB。
   检查 BPEL 流程流和服务交互是如何实现的：它们是紧密耦合还是松散耦合的？BPEL 流程本身可以使用开放标准呈现吗？
服务和呈现功能

现在，我们将从另一个角度检查如何评估系统和应用程序的架构：它如何与作为接口和 API 的服务或呈现功能相关。服务成熟度从以下几点确定：

如何访问服务？是通过 Web 服务或 SCA 接口这样的开放技术标准吗？
   服务如何通过底层系统实现，它们是紧密耦合的还是松散耦合的？
   组织的边界服务遵循 ACCORD、HiPAA 等行业标准进行企业数据共享和访问吗？
   服务使用适当的分解和粒度级别实现吗？
   服务同时支持同步和异步调用吗？
   服务同时支持异常处理和故障恢复吗？
   服务同时支持身份验证和授权码？
   服务在设计时和运行时都有在注册表中发布的条件吗？
   设计时和运行时都支持服务版本控制吗？
   技术服务如何组织，以及应用程序服务或业务服务在实现业务交易时如何与这些技术服务交互？
   业务规则

本小节评估应用程序的架构与业务规则之间的关系。业务规则是如何实现的？它们与系统紧密耦合且不能被外部化吗？尽管有些实现是松散耦合的，但它们仍旧不能被外部化，要修改规则需要代码级别的修改。有些实现被松散耦合和外部化，但使用一个自主规则引擎和自主编程框架。有些业务规则也是松散耦合和外部化的，它们的编程模型遵循 JSR94 等标准，规则可以随业务要求轻松改变。以下几点用于评估解决方案的架构中采用的业务规则的强度。

规则引擎是如何构建的？它是纯 Java 类或 EJBs 吗？它实现为一个可伸缩的成熟产品，具有在线编辑和完整的生命周期管理支持吗？
现有规则引擎支持第三方规则引擎连接，以便添加新的规则或将现有规则传输到第三方引擎吗？
   检查这个规则组件是否可以呈现为一个 Web 服务或 SCA 服务，以便从外部 BPEL 流程流编排（orchestrate）或从第三方客户机调用。
服务注册层

服务注册表提供服务的注册、元数据的管理和自动化服务。这个层根据以下问题的答案进行评估：

是否正在使用一个注册表？如果没有，使用共享服务的各方如何知道服务的可用性和功能？如何维护服务信息以避免不必要的复制？
   有什么政策来确保注册表的正确使用？
   如何在注册表内部和外部定义和管理服务元数据？设计中考虑了未来可能出现的长期需求了吗？
   在 SOA 生命周期（从开始到结束）中的哪个阶段使用这个注册表？
   服务访问控制和更改管理政策是如何治理的？是否有适当的控制来平衡安全、可修改性、以及遵循 IT 和其他标准？
   注册表正用于服务调用的动态路由（比如，故障转移、负载平衡和应用程序分区）吗？如果是，注册表安装是单个故障点吗？它满足性能和故障转移时间要求吗？
   注册表是公开的还是私有的？注册表实现能恰当地处理内部和外部服务之间的区别吗？
   数据和数据访问层

这个小节评估应用程序的架构与数据和数据访问之间的关系。进行这个小节的评估时要考虑以下几点：

数据模型有多健壮和多灵活？它遵循成熟的行业标准吗？可以轻松添加新的数据元素吗？
   数据访问层使用什么实现？它是紧密耦合且使用自主框架吗？它是松散耦合且遵循诸如开源数据对象之类的成熟框架吗？
   组织利用 toplink、hibernate 或 iBatis 等对象关系映射工具吗？
   如果一个数据资源库跨企业分发，它遵循哪种机制来允许对应用程序的访问？
   要支持 “信息即服务”，组织需要利用哪些种类的工具或产品？
   企业数据架构如何通过更少的数据延迟帮助处理从事务型数据到分析型数据的转换？
   企业数据架构如何帮助对数据进行分析性处理，以便根据需要向业务用户交付信息？

需要询问的关于集成层的几个样例评估问题是：

集成层的健壮程度如何？它实现为一个可伸缩的成熟产品吗？或者，它基于一个按需（as-needed）基础，使用一个开源 API 或使用多个连接器和适配器来实现吗？
   受到支持的集成架构模式是什么？它将使用 ESB、hub and spoke、或者 point-to-point 吗？
   集成层支持的功能有哪些，比如消息路由、数据格式转换、针对所有服务的中央安全网关？它将支持发布和订阅消息模型和消息聚合吗？
   集成层与系统或应用程序的其余部分松散耦合或紧密耦合的程度如何？
   组织当前支持哪些不同类型的集成规范/标准/框架？例如，它支持 RPC、RMI、SOAP/JMS 或 SOAP/HTTP 吗？
   集成层支持异常处理、事件管理、审计、日志记录等辅助功能并支持访问控制吗？
   当前遵循的应用程序架构提供了一个条件来将这个集成层引入到拥有具有集成架构的成熟解决方案的层之间吗？
   我们特意通过获取关于下面的问题的信息来采集关于遗留应用程序集成在企业内部发生方式的信息：

为新系统和遗留系统的集成采用了什么机制？我们寻找的机制包括屏幕搜刮器、Web 服务调用、带有用于遗留平台的适配器的 ESB、消息传递系统、直接遗留软件 API 调用、特定于技术的网关和桥接。
   已选择的机制是如何根据复杂性和实现成本进行比较的？
   根据预期的调用数量、理想的响应时间，已选择的机制满足系统性能要求吗？
   访问控制和数据隐私等安全要求在现有和遗留系统中都得到满足了吗？

基础设施服务
   安全架构
   系统管理和支持服务
   开放技术标准
   经营模型和部署架构
   性能
   其他 NFR、可用性和可靠性
   当前遵循的应用程序架构提供了一个条件来将这个集成层引入到拥有具有集成架构的成熟解决方案的层之间吗？
   我们特意通过获取关于下面的问题的信息来采集关于遗留应用程序集成在企业内部发生方式的信息：

为新系统和遗留系统的集成采用了什么机制？我们寻找的机制包括屏幕搜刮器、Web 服务调用、带有用于遗留平台的适配器的 ESB、消息传递系统、直接遗留软件 API 调用、特定于技术的网关和桥接。
   已选择的机制是如何根据复杂性和实现成本进行比较的？
   根据预期的调用数量、理想的响应时间，已选择的机制满足系统性能要求吗？
   访问控制和数据隐私等安全要求在现有和遗留系统中都得到满足了吗？
   基础设施服务

我们检查了应用程序部署的重用或在企业层面的重用所需的各种基础设施组件（请参阅 “参考资料” 部分提供的文章 “SOA Practitioners guide part 2 SOA reference architecture”）。如果这些服务在企业的所有层面上都是可重用的，那么这说明组织是统一的，拥有一个统一的方法来使用含有成熟服务的架构解决方案。通过此前使用这样的服务构建的解决方案提供的历史数据，可以很容易地确定组织能否满足服务水平协议。评估基于组织中可用的各种服务。为确定如何最好地建立基础设施架构，我们将考虑以下几个问题：

组织中有哪些公共组件/服务可用于开发自定义应用程序/打包应用程序？这些服务可能包括数据服务、日志服务、故障处理服务、审计、搜索、通知以及会话管理服务。
组织中有哪些不同类型的门户服务可重用并获得统一的观感？这些服务包括个性化、报告、本地化和 Web 流量监控服务。
组织中有哪些不同类型的企业基础设施服务可用？我们将寻找 LDAP、电子邮件、协作（聊天/IM/白板）和内容管理等服务。
   组织中有哪些不同的主数据管理服务可用？自定义数据集成服务和产品主数据管理服务属于这个类别。

   安全架构
   重要的是要理解当前安全模型、用户角色、权限和应用程序功能。以下几点可以帮助评估安全架构的成熟度：

组织中实现了哪些不同的 IT 安全服务？
   确认 IT 安全是否可以在所有应用程序层实现？
   更改和更新安全架构的难度如何？
   查明安全架构是否通过一个协议防火墙、域防火墙和企业防火墙配置实现。
   应用程序是否支持单点登录（SSO）？SSO 同时处于应用程序和 Web 服务级别吗？
   组织拥有现成的安全政策管理框架吗？
   系统管理和支持服务

在这个小节中，我们将评估应用程序的架构与应用程序管理和支持服务之间的关系。有些应用程序架构完全没有系统管理服务支持，而有些应用程序的架构和设计优良，拥有完整的生命周期服务支持/应用程序管理，比如治理、访问、授权和监控。

检查系统监控和管理服务是否使用 JMX、开源 SNMP APIs 等开放标准和 APIs 实现。
   检查是否所有这些管理服务或使用的开放标准产品正在实现监控业务和 IT 关键性能指标的要求。
   检查监控数据是否正在帮助管理架构师调优基础设施，并帮助业务分析师重新定义优化的业务流程。

   部署架构
   下面我们检查各种中间件服务器，它们用于支持通过指定的应用程序架构实现的解决方案。通常，组织将提供解决方案的一个详细部署模型。

检查组织在冻结他们的拓扑架构时是否遵循了任何标准电子商务部署架构模式？
   检查系统的经营模型和拓扑架构，它们将展示将在一个典型生产环境中运行的硬件节点以及软件组件的各种版本。检查模型是否完整清晰，是否提供了关于区域、硬件、软件以及连接规范或细节的详细信息。
   检查其他方面，比如解决方案是否虚拟化，解决方案网格是否允许您利用集群化和工作负载平衡。

   性能
   通过检查组织针对低、中和复杂用例提供的性能指标结果来评估应用程序的性能。根据用户数量和事务数量，通过支持的硬件配置获取关于系统伸缩性的信息。多数组织都不够成熟，不能提供服务级别的性能基准测试。重点关注这样的服务水平性能指标：能够帮助预测构建复合应用程序时的端到端响应时间和计划服务器容量。另外，检查以下几个方面：

根据事务响应时间和流量，组织拥有任何能够改进解决方案性能的软件架构组件或产品吗？
   组织拥有性能建模和容量计划工具吗？当前解决方案考虑了未来 2 至 3 年的用户工作负载增长计划了吗？
   在解决方案阶段的 Software Development Life Cycle 过程中，我们想查看性能工程生命周期方法学/工具是否已经被遵循或应用。
   其他非功能要求（可用性和可靠性）

在以下关键条件下检查系统可用性：

当系统受到未授权或未格式化的消息的攻击时
   当系统超载时
   在维护期间
   在软件版本更改期间
   为以下项目检查故障和恢复之下的系统可靠性：

事务性流程状态
   恢复之后维护相同的数据
   上述每个维度中提到的问卷调查帮助您使用一些定性属性评估企业架构，比如低度、中度和高度遵循 IBM CBS 参考架构。

为了更好地理解对 CBS 架构的遵循程度的定量评估概念，下面讨论一个基于应用程序架构维度中的 PoC 评估的样例场景。

场景：
   现有应用程序服务和组件可以直接用于开发一个复合应用程序吗？

定量评估基于以下这组预先定义的评估点进行。每个确认点都以以下方式定义：它拥有一个独立的不同于它的理想遵循度的差别水平。查看以降序排列的数据点，它们偏离 CBS 服务遵循度，因此，针对每个点的评估得分逐渐减小。

组织拥有一些服务/组件，它们直接呈现为 Web 服务，正在从 BPEL 流程使用。这些服务在 UDDI 或一些等效注册表中发布（得分：100%）。
   组织拥有一些服务/组件，它们直接呈现为 Web 服务，正在从 BPEL 流程使用。但这些服务没有在 UDDI 或一些等效注册表中发布（得分：75%）。
   组织拥有一些服务/组件，它们通过某个架构框架组件（网关服务）间接呈现为 Web 服务，但能够从 BPEL 流程使用（得分：50%）。
   组织拥有一些服务/组件，它们直接呈现为 Web 服务，但不能从外部客户机调用，原因是：由于不遵守 WSDL，SOAP 地址绑定 URL 规范缺失（得分：25%）。
   组织拥有一个作为 EJB 接口实现和呈现的服务/组件（得分：0%）。
根据这个场景，我们通过将一个 Web 服务导入其组装环境来构建一个小型 PoC，并通过一个已构造的 BPEL 流程、使用针对一个 Web 服务的直接以及间接（通过 UDDI）端点 URL 查询来调用它。如果使用条件 4 中指定的 Web 服务类型，那么这种类型的 WSDL 不允许导入 WID 本身。基于这些 PoC 执行和观察，定量评估针对这个场景进行。类似的 PoC 模型基于集成和技术架构维度中的场景构建，并对它们的架构进行定性评估。