SOA成熟度模型

    SOA项目往往规模较大，具有很大的风险，而获得回报也可能很大。SOA项目的投资回报(ROI)有时很难量化，需要稳定的流程和方法来确保SOA项目的 成功。直接着手SOA项目并非始终是最好的出发点，组织必须确定在其SOA活动中首先要进行的步骤是什么。为了成功地在组织中实现SOA，首先需要了解您 组织的IT状况和总的体系结构。

    现有的各种成熟度模型基本源自由卡耐基梅隆大学的软件工程研究所所提出的能力成熟度模型(Capability Maturity Model, CMM)，该模型目前已经升级到能力成熟度模型集成(Capability Maturity Model Integration, CMMI)。CMMI是评估和测算一个组织的软件开发与集成过程的方法。CMMI有五个成熟度级别（如表1所示），分别指出了从低到高的成熟过程的特征。

    SOA成熟度模型与CMMI关系并不紧密，CMMI目的是测算企业IT过程的成熟度，而SOA成熟度模型 的目的则是侧重于测算一个组织架构的成熟度。讨论如何测算一个公司架构的成熟度是有意义的。SOA成熟度模型应该和CMMI一样分级（但不一定非要五 级），分级可以把架构的特性和能力进行分组。这样一来，架构师就能和其它公司的架构进行比较，或者为投资或外购提供里程碑，或者指导新软件的购买。

    不同的组织对SOA有不同的理解，从企业的角度来看SOA成熟度模型应该包括如下方面:

    首先，公司如何在他们的架构远景中充实各种视图。在较低的级别，他们只有一个SOA的技术架构视图。但是随着上升到更高的成熟度，他们会在企业级SOA中加入数据架构、信息架构、过程架构(或其它的东西)作为相关视图。

    其次，企业如何利用架构模型，尤其是服务模型。在较低的成熟度级别，企业可能根本没有这种服务模型，或者最多只有一个受限的还在设计中的模型草案。而在较高的级别，组织在设计和运行时都利用服务模型来表述他们还要继续改进的服务。

    再次，企业如何确定SOA应用的范围。在较低的级别，SOA经常只是实验品或部门级别。随着SOA成熟度的提升，SOA应用会超出部门范围。而在最高的成熟度级别，SOA应用是企业范围，甚至是跨公司的。

    最后，企业如何测算架构实现的成熟度。很明显，一个纯理论的架构跟一个完全实现的、被测试过的并已做成产品的架构成熟度是不一样的。

    基本SOA成熟度模型

    SOA成熟度模型可以为IT和业务用户提供一种框架，使其能够正确地评估SOA在企业中的适用性和收益。在过去的10年中，SOA已经成为应用设计、开发和实施领域中意义最为重大的一项变革。与CMMI的模型类似，该模型分为五个层次，如图1所示。

    第一层:初始化服务

    在初始阶段，企业为服务创建定义，并且将SOA集成到项目开发的方法中。在金融服务环境下，第一层项目可能会使用应用服务器或企业服务总线(ESB)适配器，在下达命令的管理系统与接受命令的交易服务之间创建简单对象访问协议(SOAP)和HTTP Web服务调用。

    第二层:架构化服务

    在此阶段中，SOA实施的技术管制标准将被确立下来，通常是在架构组织的领导下完成的。标准的SOA基础设施和组件，如ESB、服务及策略库、例外管理服务、转化服务和单一登录服务都被用于实现更高的重用服务，同时也为整个企业提供更紧密的管理和服务控制。

    第三层:业务服务和协作服务

    第三层的特点是引入了面向业务的服务，如业务流程管理(BPM)。由于将重点放在技术与业务部门之间的伙伴关系上，第三层可以优化商业流程的灵活性，使IT部门能够针对业务需求迅速做出响应。

    第四层:可测量的业务服务

    第四层提供有关性能和对第三层流程业务影响的连续反馈。这一层的着眼点在于收集数据和将数据提供给用户，使他们能够改变对事件做出响应的方式。

    第四层项目可能引入日志功能和一项监视业务活动的服务。这些功能为业务经理提供了汇聚和显示流程的能力，使之能够查看整个交易过程。

    第五层:优化的业务服务

    在最后这一层中添加了业务优化规则，而且SOA也转变成为企业的一种神经系统。针对第四层的测量和显示所做出的自动响应，使企业能够对事件采取实时行动。

    第五层项目可以将请求信息输入ESB，并将这些信息发送至一个事件流处理器。该服务对多个场所的所有交易人员行为进行了关联，并从中识别重要的模式。

    IBM SOA成熟度模型

    IBM提出的SOA成熟度模型旨在帮助企业定义体系结构指南和流程，以便在总体IT体系结构活动中实现较高的成熟度和可预测性级别。该SOA成熟度模型的迭代过程允许IT组织向前发展，从而经济高效地满足快速变化的业务需求。

    第一级:初始化

    第一级的组织通常没有正式的体系结构流程。体系结构没有从项目分离出来。通常，这些组织不具有企业架构(EA)团队;每个项目团队通常根据业务系统(LOB)划分，彼此独立地进行工作。精力主要放在交付单个项目上。

    此级别的结果包括项目计划不可预测、预算超支而且代码质量差（通常不能重用，且难于维护）。各个项目重复相同的任务——这将导致交付和维护成本的增加。在此成熟度级别（相当不成熟），IT通常对业务灵活性具有决定性，而不是别的情况。

    第二级:可重复

    在第二级，进行了一些体系结构方面的工作。

    此级别的结果包括对体系结构组件的一些重用。临时流程和较为混乱的通信路线使体系结构解决方案中具有一定的可重复性，因而降低了软件的交付成本和维护成本。不过，从资金的角度而言，此成本节约不甚明显。

    此级别的成熟度的最大优势在于实现了结构化的流程可以提供的优势。

    第三级:已定义

    第三级的组织在EA活动方面进行了一些投资。配备了EA团队，为其指定了对体系结构元素进行标准化的任务，负责进行创建参考体系结构的活动，就此体系结构 对项目团队进行培训，并定义控制和执行策略。通常，EA团队将创建一组技术组件和框架，然后标准化各个项目团队间对这些框架的使用。

    不过，EA团队活动所带来的开销可能超过其增加的价值。EA团队带来的最大的单项成本是体系结构维护成本。在目前紧张的经济环境中，EA通常不会进行维 护，因为核心体系结构团队将回头进行项目交付。这将降低了EA的价值和适用性。此级别的另一个问题是团队之间的“拔河”问题。项目团队并非真的尊重或喜欢 EA团队的“窥探之眼”。与此类似，EA团队成员可能缺乏给定LOB的具体业务知识，可能无法与执行LOB服务的项目团队有效地进行通信。那么，此级别的 成熟度的吸引力到底何在呢？

    此级别是识别SOA需求的第一步。EA工作似乎没有效果，因为这些工作通常不够灵活，不足以满足跨多个 LOB的需求。缺乏业务领域知识是EA团队的一个大问题。认识到这个不足的EA团队将会取得成功。他们一定不能将自己视为专家:他们需要认识到自己最终是 为业务服务的。认识到这点将最终带来成功，而也正是这一点让组织进入下一个体系结构成熟度级别。

    第四级:已管理

    当EA团队开始定义SOA路线时，就达到了这一级别的成熟度。今天，每个大型组织都有一群架构师在谈论 SOA。最起码的，这些架构师看起来已认识到SOA的价值，并在尝试形成SOA策略。

    如果组织的SOA活动主动参与为LOB服务的项目团队的工作，则此组织可归到第 4 级。项目团队和EA团队需要进行协作，以定义组织的 SOA，包括流程、技术和组件。应该定义控制和“奖励”策略。需要建立支持级别，且要清楚地了解何时联系某人以及进行联系的原因，必须配备分析人员用来定义服务的框架。

    此成熟度级别有很多风险，也有很多好处。尤其需要注意，务必认识到第4级的短期成本优势很小，甚至没有短期成本优势。对于任何组织而言，达到第 4 级和执行该级别的活动开销都非常大。如果做法得当，它将使组织达到SOA成熟度模型中的第5级。如果做法欠佳，组织很有可能降到第2级，因为将解散EA团队或该团队对业务的支持几乎为零。

    第五级:优化中

    第五级是“极乐世界”。体系结构流程和策略都已制度化。对服务价值有了清晰的认识。配备了框架，供每个团队公开和使用服务。在此级别，组织可以真正地充分利用SOA的价值。他们开始了解如何与其业务合作伙伴、供应商和客户交换服务。

    为了实现最大业务灵活性，业务服务级别的重用成为了体系结构的核心。在此级别，组织将看到拥有可以迅速响应业务需求的灵活 IT 组织的成本优势和时间优势。此级别的主要目标是定义体系结构活动的终结点。需要明确地定义高标准和目标，从而加以实现。如果没有此级别，组织通过第四级所带来的开销将不能得到回报。