评估企业是否适合开发复合业务服务
本文介绍如何评估一个企业是否适合采用支持 Composite Business Services (CBS) 和复合应用程序的架构来解决企业业务问题。我们主要关注评估企业的 4 个维度：现有业务架构支持、应用程序架构、集成架构和技术架构。
?
?
?
?
业务架构遵循
一个定性评估可以从以下调查问卷开始。可以根据组织提供解决方案的业务领域和功能区域评估该组织。首先，应检查组织的基础设施方面，以支持业务需求。以下是一些需要考虑的重点问题（请参阅 “参考资料” 部分提到的文章 “Exploring Business Process Management Systems and the impact of BPM on developers”）：
组织有良好定义的 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 服务的开发进行研究和分析，并最终针对这个部分准备一个定性评估图表。
?
应用程序和数据架构遵循
在这个小节中，我们将详细介绍如何评估一个组织的应用程序和数据架构，以便遵循 CBS 参考架构。总体应用程序架构成熟度可以根据以下几个标准进行评估：与 CBS 参考架构的接近程度、IBM 的电子商务模式、企业应用程序架构模式、以及是否使用模型驱动的架构工具进行开发。这个部分将严格评估一些架构原则，比如层与层之间的松散耦合、遵循的 MVC 模式、实践的分层概念以及应用程序的伸缩能力。来自他们的应用程序架构的关键架构层和关键评估点（请参阅 “参考资料” 部分中的文章链接 “Evaluating Service Oriented Architecture”）包括：
通道和呈现层业务流程和精编层 服务或呈现功能业务规则服务注册层数据和数据访问层以下小节将详细介绍上述每个主题：
通道和呈现层
应用程序或系统的架构评估要考虑架构如何与通道和呈现层相关。复合应用程序需要从一个共享的公共托管环境服务多个客户机。通道和呈现层从以下几个点评估。
呈现层应该支持 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 评估的样例场景。
?
基于场景的 PoC 评估方法
我们应该通过构建基于场景的 PoCs 来定量评估此前提到过的架构维度。我们应该通过按照企业定义的功能来生成功能测试案例来评估业务架构。这些测试案例将在已部署的解决方案上运行，并使用提交的功能特性来验证。定量评估基于功能测试期间确定的测试案例的数量进行。类似的定量评估将基于一个评估场景分别针对信息、集成和技术架构部分进行。例如，我们将考虑一个来自应用程序架构维度的典型场景，我们将在一个组织转向 CBS 参考架构的架构转换阶段基于这个场景评估该组织。
场景：
现有应用程序服务和组件可以直接用于开发一个复合应用程序吗？
定量评估基于以下这组预先定义的评估点进行。每个确认点都以以下方式定义：它拥有一个独立的不同于它的理想遵循度的差别水平。查看以降序排列的数据点，它们偏离 CBS 服务遵循度，因此，针对每个点的评估得分逐渐减小。
根据这个场景，我们通过将一个 Web 服务导入其组装环境来构建一个小型 PoC，并通过一个已构造的 BPEL 流程、使用针对一个 Web 服务的直接以及间接（通过 UDDI）端点 URL 查询来调用它。如果使用条件 4 中指定的 Web 服务类型，那么这种类型的 WSDL 不允许导入 WID 本身。基于这些 PoC 执行和观察，定量评估针对这个场景进行。类似的 PoC 模型基于集成和技术架构维度中的场景构建，并对它们的架构进行定性评估。
?
结束语
在本文中，我们通过从一个组织获取的 RFI 响应检查了企业架构。首先，我们参照 CBS 解决方案参考架构，根据前面小节中提到的评估点对他们的业务、应用程序和数据、集成和技术架构遵循度进行初始定性评估。由于评估基于企业提供的信息，因此企业架构的定量评估通过在现场执行一个 PoC 来进行，这样您就能确定企业的状态 —— 企业是否准备好利用企业的现有资产，因为这些资产可能与复合业务服务有关。最终的 PoC 评估报告将解释组织需要弥补的差距，以便继续前进，构建复合业务服务。如果组织还不能完全满足 CBS 解决方案的要求，那么需要准备一个支持策略并提交给组织。
?
参考资料
学习
“Exploring Business Process Management Systems and the impact of BPM on developers”（developerWorks，2006 年 8 月）：讨论业务流程管理系统如何改变开发流程，以及架构师和开发人员的角色。原文：http://www.ibm.com/developerworks/cn/webservices/ws-entevaluation/index.html?ca=drs-
