随着公司日益追求面向服务架构(SOA)的利益，组织想要通过一个客观的标度计量他们的努力变成了有意义的事情。SOA是代表着IT不断满足业务持续的变化的需求同时IT组织的管理和治理方式也在不断地变换的方法。SOA使得公司可以抓住一些切实的东西并能够凝结出实物来计量他们的前进。无论是软件厂商，分析人士，咨询公司还是市场商人，他们都堆积在用他们的方式衡量SOA成熟度上。

　　就像ZapThink公司之前提到的，很多已经存在的成熟SOA模型都是自给服务的、受软件厂商驱动的结果，他们的目的在于将公司购买的产品比他们构架解决方案结合在一起的时候能够更加成熟一些。不过，我们也注意到越来越多的公司在衡量他们的SOA应用的成熟度时开始将多种多样的，试图理解维度效益产生努力结合起来。然而，在过去的十八个月中，我们已经看到了相当多的失望，公司们都在单独的使用着他们创造的SOA程序并对其进行管理，并将其作为衡量成熟度的一种表现。这就意味着，拥有数以千计的服务将远远重要于一个成熟服务。毫无疑问，这绝对是一个错误的结论。

　　关注一个服务Vs. 上千个服务

　　对于服务创建、管理或者消费的数量并不能用来衡量成熟的很简单的一个解释就是，创造服务是一个价值很低的活动。实际上，现在市场上有大量的工具可以通过已有的软件逻辑、数据库、中间件设备甚至是硬件网络设备等，创造出数以千计的服务界面来。为了更进一步强调这一观点，我们甚至可以得出一个极端的观点，展示服务是没有价值的。服务价值是在一些事物对其进行了消费的时候产生的。换句话来说，在一千个服务当中，如果几乎没有甚至没有服务有人对其进行消费的话，那么它的价值根本赶不上一个拥有成千上万的用户的服务。这种SOA价值的观念并不是有多少服务，而是聚焦于服务的消费有多少。

　　不过，这并不意味着在多个流程领域中不得不再使用的一些服务是有价值的。在ZapFlash的文章《所有的服务都应该能够再使用吗?》中，我们讨论了使用服务的很多原因。其中，再使用也位列其中。但是，至少要有一个消费者要去给服务价值。因此，在创建服务是价值很低的以及相关的活动也是低价值的环境下，大家最关心的问题就成了如何使服务更加简单、可靠以及可以更灵活的使用。因此，即使一个公司有一个他们极为关注的服务，而且他还是可靠的，可使用的以及面对不断变化的情况时是灵活的话，那么这个服务以及导向这个服务的架构都具有很高的成熟度。不过，如果一个服务是缺乏质量的，缺少治理的，而且由于是单独的缘故而缺少控制，那么公司只能完全的错失SOA带来的利益了。公司应该成熟化那些对它们而言最重要的服务，而不是关注他们有多少服务。我们来假设数量代表着成熟的程度使得公司建立了潜在的隐患。

　　度量结构的成熟度

　　现在有一个迹象，那就是公司并没有恰当考虑有关成熟度的概念。他们在架构过程中，都太晚考虑有关质量、治理、生命周期以及可靠性的有关事宜。创建服务只是在SOA开发生命周期当中的一步，但是甚至不是第一步。实际上，公司采取开发和执行服务的步骤应该是他们采用成熟的架构过程的最后几步之一。特别是质量因素，应该在任何服务被建立以前就要慎重考虑。如果一个公司没有考虑过这些因素的话：服务是如何被测试的，顾客在使用服务的过程中是如何成功可靠的运行或者是如何失败的，以及他们在服务版本中是如何重申的，那么，所以签约了这些基础服务的客户将在架构他们自身服务时面临同样的风险。

　　同样的，治理也是要在SOA设计阶段的早期需要被考虑的因素之一。公司如何确保服务被按照企业和政府的要求恰当的使用而不是走向毁灭是需要考虑的问题。就像我们已经讨论了多次的说法，没有治理的SOA项目将导致没有人准确的知道服务在企业中是如何被使用或消费的混乱的系统。商业上是极为痛恨混乱的，他们将很快导致一个混乱的SOA结果。在这种情况下，ZapThinks也给那些咨询客户一个建议：建议他们将registry/repository系统和元数据管理系统当作最初的SOA活动进行执行。通过搜集和管理企业的元数据，组织可以消除简单系统随着时间的流逝变得越来越复杂而又笨拙的问题。

　　另一个需要被考虑的组成成熟度的因素就是安全性和可靠性。就是因为公司可能将服务暴露给客户或者合作伙伴并不意味着他的安全性和可靠性比暴露给更多的人的安全性和可靠性低。实际上，如果服务是独立运行于公司与顾客接触的话，那么任何危及到服务提供可靠性和安全访问能力安全的，都会危及到整个系统的价值。虽然这看上去是十分有道理的，但是我们不能为你准确的指出我们实际发现多少次客户在决定先使用在做安全的环境中暴露了他们的服务。正像质量和治理一样，成熟的SOA组织在他们使用第一个服务之前就要考虑可靠性和安全性。

　　所以，一个计量SOA效果成熟度的方法就是通过计量服务中质量、治理、安全性以及生命周期的方法来度量，无论是有多少个服务都是如此，即使只有一个也不例外。同样的，数量和组织效果的成熟度毫不相干。但是，这些SOA技术的方面也仅仅是当今组织整个SOA成熟度的一小部分。用面向服务的方法进行治理、质量管理、可靠性管理以及变化管理改变了IT组织运行中的运行方式。公司如何管理组织采纳的SOA衡量着他们采用架构最好实践的成熟度。

　　衡量组织的成熟度

　　随着公司的注意力从仅关注生产服务向消费服务进行转变，他们开始注意到他们已经存在的组织框架和管理框架已经不再有效。特别是，IT组织也许已经排列入仓指向了那些以紧密连接的，非组件化的，毫无疑问不可能是面向服务的世界的形式存在的具体的系统或流程。至今为止。在持续变化的并且异构的环境中进行再使用也是对不同的组织结构进行质量要求、服务生命周期要求和治理要求的一种不同的方法。

　　随着公司不断成熟化他们的服务和架构，他们将必然的成熟化他们的组织。这意味着他们也许会成立杰出的SOA中心，EA团队，以及集中的或分散的解决方案体验中心。他们的目的是贯穿组织，能够帮助他们指导、技术化SOA最好的方法，管理增长的服务使用(甚至包括了暴露的服务数量)以及用SOA的方法维持企业效率和IT治理。

　　同样的，即使公司只有一个他们关注的服务，增加这个服务质量和可靠性的使用和反复将会必要的要求组织进行变革。变革将会要求自上而下的管理，自下而上的面向服务的方式，以及循环的开发方式和服务生命周期管理，持续建立和改进业务使用的服务案例的能力。就像在这里服务的数量一点都不重要一样，上述的这些要求对于SOA项目来说也都是些小虾米。即使组织将注意力放在为特别的一部分进程或者是个人部门开展的服务中的很小的一部分上，他们也能将他们的组织和结构的方法成熟化，从而获得他们努力的最大的价值，即使在他们并没有传播到公司的其它部门的情况下。也没有仅仅为了达到称为最高级的成熟度就进行“企业范围内的SOA”的必要。将精力集中在问题上，并且通过得到最有价值的面向服务的解决方案的方法使得企业尽可能的成熟是必要的。

　　ZapThink的看法

　　成熟度是和自身相比较，而不是和其他公司比较的。也就是说，没有什么外部的度量方法可以被公司采纳来考虑自身的SOA活动是不是“最成熟的”。正确的方法是，公司需要理解服务的数量或者全企业应用SOA的努力和他们使用的服务给企业带来的重要性和价值几乎不相关。将精力放在多维的方法上用来完备对结构和组织以及技术上的考虑将帮助公司完善他们的SOA，因此将给他们业务的带来最多的收益——这也是唯一的与成熟化有关的方法。

　　当我们满怀希望的看着公司将更深层的在SOA项目中考虑有关结构和组织成熟度的有关事宜时，我们知道简单的诱惑性。如果不恰当的，成熟度的模型将强迫组织寻找他们希望SOA那样的快速的解决方案。不幸的是，SOA对企业而言是一个很少见的可以和混乱的结构挑战斗争的快速解决方案。就像ZapThink建议的，一个可以反复使用的，持续的面向服务的方法将会考虑可以被SOA恰当解决的业务问题。ZapThink也建议一个SOA成熟度的逐步式的方法，它不会考虑服务数量的问题，而会考虑企业选择使用和消费的服务的质量。