随着各个公司已经从问“什么是SOA”“为什么要SOA”的阶段过度到问“如何实施SOA”的阶段，他们开始寻找某种工具或方法来加速使用面向服务的架构(service-oriented architecture ,SOA)并降低实现风险。为了满足这种需求，提出了几种SOA成熟度模型，旨在帮助公司确认他们在通往SOA的道路上已经走了多远。由于SOA本身仍然是一套最佳实践的集合，所以这些模型的最大挑战在于都从不同角度观察SOA模型，结果在很多情况下给SOA增添了混乱而不是清除混乱。本文中，我们的目的在于排除干扰和混乱，但不是谈我们自己的SOA成熟度模型(尽管可能现在可以满足)，而是对如何理解这些模型之间的区别提出建议。这样，你就能自己评估这些模型是否能帮助你成功实施SOA。

　　什么是成熟度模型?

　　现在，大多数SOA成熟度模型的开发可以追述到被广泛应用的能力成熟度模型(Capability Maturity Model ,CMM)，该模型已经升级到能力成熟度模型集成(Capability Maturity Model Integration ,CMMI)。它们都出自卡耐基梅隆大学的软件工程研究所。CMMI是评估和测算一个组织的软件开发与集成过程的方法。CMMI有五个成熟度级别，分别指出了从低到高的成熟过程的特征。它使组织能够意识到当前自己IT部门处于什么级别以及需要改进的地方。

　　SOA成熟度模型与CMMI关系并不紧密，因为尽管它借用了CMMI模型中的名词，但在其它地方都不相同。CMMI测算了IT过程的成熟度，而SOA成熟度模型则是测算了一个组织架构的成熟度。但毕竟，由于CMMI可应用于所有的软件、集成和IT过程，当然它也可以应用于面向服务的方法。我们或许可以争论CMMI是不是测算这种过程的最佳工具，但这不是本文的主题。

　　而讨论如何测算一个公司架构的成熟度是有意义的。当架构师为此开发或使用一个SOA成熟度模型时，他应该要列出他的架构所具有的特性或功能。这么做是为了确定架构中的缺陷或丢失的元素，然后更好的为架构中剩下的优先级排序。SOA成熟度模型应该和CMMI一样分级(但不一定非要五级)，分级可以把架构的特性和能力进行分组。这样一来，架构师就能和其它公司的架构进行比较，或者为投资或外购提供里程碑，或者指导新软件的购买。

　　然而，用SOA成熟度模型测算架构本身的成熟度而不仅仅是它的实现是极其重要的。ZapThink曾看到过一些所谓的不能测算架构成熟度的SOA成熟度模型，它们只能说明组织的服务有多么先进或者运行时基础设施可能有多么成熟。这些模型根本不能称为“SOA成熟度模型”，Sonic Software, Systinet, AmberPoint和 BearingPoint等就是失败的典型。一个好的模型应该是把组织开发的服务成熟度作为SOA的一部分，而不是测算架构本身的成熟度。这种成熟度模型实际上更应该叫做服务成熟度模型，因为它不能体现架构的成熟度。

　　什么是SOA成熟度模型?

　　所以，如果公司的服务成熟度对SOA成熟度模型不是充分必要条件，那么它到底应该包含什么呢?不同的组织对SOA有不同的理解，从事实上无概念的架构一直到宽泛的多视角的面向服务的企业架构。SOA成熟度模型就应该包括这样一些东西，比方说，公司如何在他们的架构远景中充实各种视图。在更低的级别，他们只有一个SOA的技术架构视图。但是随着上升到更高的成熟度，他们会在企业级SOA中加入数据架构、信息架构、过程架构(或其它的东西)作为相关视图。

　　SOA成熟度的另一个方面在于公司如何利用架构模型，尤其是服务模型。服务模型表示了产品中的服务以及业务对新服务或修改服务的需求。在更低的成熟度级别，公司压根就没有这种服务模型，或者最多只有一个受限的还在设计中的模型草案。而在更高的级别，组织在设计和运行时都利用服务模型来表述他们还要继续改进的服务。

　　SOA成熟度还能测算的就是在SOA成熟度模型中确定SOA应用的范围。在更低的级别，SOA经常只是实验品或部门级别。随着SOA成熟度的提升，SOA应用会超出部门范围。而在最高的成熟度级别，SOA应用是企业范围 (甚至是跨公司的)。

　　SOA成熟度模型还可以测算架构实现的成熟度。很明显，一个纯理论的架构跟一个完全实现的、被测试过的并已做成产品的架构的成熟度是不一样的。但是，也不能只见树木不见森林——因为成熟的实现首先是源于成熟的架构。如果不测算架构的成熟度，那么一个成熟度模型就不是真正的SOA成熟度模型。

　　你应该选择哪个SOA成熟度模型?

　　理解众多公司创建SOA成熟度模型的初衷将能帮助你决定采用什么样的SOA成熟度模型。例如，软件供应商会把SOA成熟度模型当作它们软件的一种销售工具。这种模型关注他们产品中提供的功能，而不谈他们做的不好(或根本没有提供)的功能。而另一方面，咨询公司则用SOA成熟度模型来确定他们客户的需求。当然，这种模型某种程度上也是销售工具，但是它更是咨询师的评估工具，而且要随时关注客户的价值。提供全方位SOA咨询的专业服务公司则会比那些专注于SOA某个方面的专家们使用更全面的SOA成熟度模型。IBM Global Services的“服务集成成熟度模型”(Service Integration Maturity Model)就是这样一个不错的例子。

　　产业界也在寻求SOA成熟度模型。这些模型的优点在于它们不是扮演销售工具的角色，也不像咨询公司使用的模型那样全面和详细。你还能发现分析公司也在制造这种模型，但他们的模型总是让公司在SOA上原地踏步。因此，在购买分析公司的SOA成熟度模型前务必要了解他们整个的SOA业务。

　　最后，你可以创建自己的成熟度模型。ZapThink已发现有企业架构师造出了自己的SOA成熟度模型，而这样的模型有很明显的优势，就是特别适用于自己的公司。但是，这种模型与创造它们的人息息相关。能力强的架构师能设计出强大的SOA成熟度模型，而能力弱的架构师则做不出来。