简介

　　本文讨论企业计划和开发一个 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） 通常所做的那样。此外，评估时还需要考虑业务功能和技术架构的企业支持。

　　企业架构评估方法

　　有一些可靠的定性和定量方法可用于评估实践中存在的企业架构。定性方法试图通过检查设计周期中的架构决策来帮助评估企业架构处理提出的要求的能力。这种评估的结果派生出关于评价目标的定性结论。定量方法是更具追溯能力的方法，它们基于在实现阶段执行的数量测量。下面详细介绍：

　　定性方法

　　定性评估一个解决方案的架构的方法是借助基于调查问卷和检查表技术来检查系统，这些方法适用于软件开发周期（SDLC）中原型模型构建之前的早期阶段。架构的定性评估方法也可以称为预测性评估方法。它们试图通过检查 SDLC 早期阶段做出的架构设计（决策）来评估架构处理提出的要求的能力。这种评估的结果提供关于评价目标的定性结论。类似的方法也可以应用于现有的企业软件架构，这只需检查基于调查问卷和检查表的方法，无需任何定量测量。

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

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

　　定量方法

　　一个解决方案的架构的定量评估方法是在现有系统上执行一些实验。这些方法更具追溯能力，它们基于在实现阶段执行的数量测量。原型模型在 SDLC 早期阶段构建，在这些模型上执行定量测量，然后根据这些结果对架构进行定量评估。

　　基于指标的方法：这种方法是基于架构组件的测量的定量分析。这种测量的目的是发现总体架构中存在问题的地方，以便引入一些更改来改进设计。

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

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

　　图 1. 评估过程方法

　　CBS 的维度

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

　　业务架构

　　这个维度解决用户、规划人员和业务经理关注的问题，主要从用户角度考察系统功能。它主要关注业务性能、功能和可用性。它拥有以下几个子视图（请参见 “参考资料” 部分获取一个 Open Group 链接，可以从该链接链接到以下子视图）：

　　人员视图 关注系统的人力资源方面，它检查系统中的人类角色。

　　业务流程视图 处理系统中涉及的用户流程。

　　业务功能视图 处理支持流程所需的功能。

　　业务信息视图 处理支持流程所需的信息。

　　可用性视图 考虑系统及其环境的可用性。

　　业务性能视图 考虑系统及其环境的性能方面。