【IT168 专稿】2006年对面向服务的架构（Service Oriented Architecture，SOA）来说是个转折点，那一年中炒作终于变成了现实。多家公司把SOA部署到了实际的生产环境，不过它们在这过程中也遇到了不少难题。

    这些公司发现，实施SOA原来很难——困难不仅仅来自技术方面，治理是另一大难题。对许多公司来说，治理是最主要的难题。企业管理协会（Enterprise Management Associates，EMA）在2007年7月发表了一项研究报告，报告分析了为什么治理是事关SOA项目成功的一个关键因素的原因。 

    EMA在2006年先后发表了一系列研究报告，记录了SOA在IT实际应用领域的进展。这一系列报告中的最后一篇是《SOA：来自部署一线的观点》，报告深入分析了一个个案例调查：多家公司通过把业务服务部署到SOA上，结果获得了重大回报。当被问及对其他公司有何忠告时，所有公司都提到了规划和治理是一大难题，更有80%的公司提到治理是最主要的难题。 

    这一调查结果让人颇感意外，因为迄今为止媒体针对SOA的报道主要集中在SOA的技术难题上。不过，与这些早期采用SOA的人们进行交流之后，我们发现了一个明显的事实：SOA实施是否能够取得成功，实际上与跨组织及与业务相关的因素有着更大关系，而这两种因素又属于治理的范畴。

 
治理驱动SOA 

    治理在过去的几年里备受关注，而这并非巧合。业界日益认识到治理和非常好的实践的重要性，大多数组织也渐渐熟悉IT基础设施库（IT Infrastructure Library，ITIL）和信息及相关技术的控制目标（Control Objectives for Information and Related Technology，COBIT）等学科。人们之所以开始熟悉这些学科，其深层原因是业界正在寻求解决之道。 

    大多数IT预算中70%到80%的部分用于维护及管理，只剩下20%到30%用于发展及创新，这并不是什么秘密，这样做的主要原因之一就是复杂性。随着行业从大型机和瘦客户端迁移到分层架构、以Web为中心的应用软件，使得普通IT部门管理的应用软件、设备和平台其数量急剧增加。如今，IT部门支持1000种或者更多的业务应用软件的现象并不罕见。 

    但是，这种转变却给IT人员和预算带来了不利影响。在许多情况下，这给IT部门和业务部门之间的关系也带来了不利影响。由于业务部门常常不知道这种技术转变所带来的最终影响，IT部门往往被认为是一个钱坑。结果，IT部门发现自己最终成了必输无疑的一方。公司在不断发展过程中，不断需要新的业务应用软件。开发人员提供这样的应用软件，然后把部署与开发工作交给IT部门去完成。IT部门成了应用软件这条铁路的最后一站——只有进来的路，没有出去的路。 

    正是由于出现这种情况，IT部门在绝望中只好求助于治理。由于IT部门对需要支持的应用软件的数量和复杂性几乎没什么控制可言，而如今它们借助非常好的实践来提高效率。

SOA的治理

    SOA治理运用非常好的实践和专门针对SOA的管理技术来处理同一个问题：需要控制及管理复杂性。良好的治理是消除复杂性的妙方。治理包括：基于非常好的实践的流程、通过良好的配置管理获得了解技术关系的可见性、专门的应用软件管理产品。上述的每个方面都有助于增强了解SOA部署的可见性，有助于把它们从充满未知因素的“黑盒子”变成井然有序的分层体系，这个分层体系可通过一种清楚易懂的管理平台来查看。



    早期，采用SOA的人们讨论的一些具体难题包括如下： 

    •我们如何为可在整个公司重复使用的软件拨款？ 

    对部署了SOA的公司而言，SOA的其中一个重大回报就是可重复使用。大多数公司认为部署到生产环境的SOA服务就是整个组织的“资产”，而随着不断被多个业务服务所使用，这种资产的价值也会越来越大。 

    可是，大多数公司是由各个部门为软件开发项目拨款的。如果某一个部门用自己的预算为开发SOA服务拨款，一旦该服务部署下去，其他部门又该如何来“付费”以便使用服务呢？虽然可重复使用会给公司带来显著的成本效益，但这需要改变软件开发的成本分配及软件资产的使用。 

    •一旦SOA业务服务投入了生产环境，我们该如何控制对它的访问？ 

    SOA服务被设计成了松散耦合（loosely-coupled），这意味着它们发布接口后，就可以供需要相应功能的其他服务使用。在实际环境下，这就意味着一旦SOA服务部署到位，它们就被放在了网络上，可供使用。 

    许多公司反映，由于未授权用户和未授权服务找到SOA服务后拿来与自己的生产服务结合，结果出现了“完全免费”的现象。这给性能带来了不利影响，并且带来了严重的安全问题。譬如说，如果控制机制未落实到位，未授权用户就有可能访问敏感的人事或者工资表数据。专门针对SOA的管理产品能够帮人们了解哪些服务在使用、谁在使用，从而有助于解决这个问题，并且只允许得到批准的用户、服务才有权访问。 

    •我们如何监控、管理及评估服务级别？ 

    这是一个重大问题，因为整个IT行业仍在为如何更好地满足管理异构、分布式和组合式的非SOA应用软件的需求而努力。这样，就为松散耦合的服务管理可用性、评估服务级别更是增添了复杂性。虽然有几家应用软件管理厂商正在开始着手解决这个问题，但大多数厂商在提供能够真正解决问题的产品方面还是处在落后位置。 

    •我们如何确保安全，到底怎样才够安全？ 

    除了上面讨论的访问控制问题外，部署的SOA还面临管理分布式分层应用软件曾经遇到的与安全有关的类似难题，SOA的集成性带来了安全隐患。由于SOA应用软件既在组织内部运行，又在外联网上运行，所以安全问题变得至关重要。即便运行期间生成的错误信息也可能含有敏感信息，这些信息必须被保护起来，以防外界看到。 


    与SOA早期采用者进行沟通之后，看过部署失败的多个案例后，再与利用SOA获得重大业务回报的公司进行交谈，给人一种耳目一新的感觉。在许多情况下，这些公司将新产品投放市场的步伐大大超过竞争对手，从而成为各自所在行业的领导者。 还有一些公司声称加快了集成项目，让自己能够少花时间多完成工作，从而避免了成本。 它们都声称遇到了难题，但看来最成功的公司在利用治理来管理技术、推动SOA成功所需的跨部门变化。