【IT168 专稿】

    在对SOA进行治理的同时，也不能忘记SOA的目的是让IT为企业实现价值。

    要实现SOA所带来的易管理、可靠性和重用性，必须先有一个有效的治理结构对服务的创建、维护、提供和消费进行调整。

    然而，虽然SOA具有战略性的优势，但是治理往往会在企业的单个业务线上产生负作用，因此许多中小型企业在开始编制服务目录的时候会遇到种种困难。那么应该怎样对服务资源进行编制从而让我们的项目取得成功呢？本文提供的治理结构可以在接受通常工作的战术性、以项目为中心等特点的同时实现服务的战略重要性。

    对治理的需求

    根据定义，服务应该是一种共享资源。如果要在利益相关人群体中共享资源却缺乏一个有效的治理系统通常会导致资源管理与资源利用之间产生矛盾。要保持较高的ROI（比如通过避免重复性劳动）并符合SLA协议（比如通过在提供服务的同时保证合适的计算资源以满足消费者的要求），就必须对服务进行有效地治理。治理还能帮助企业发现新的服务需求并根据变化做出调整。

    对交付的要求

    在对SOA进行治理的同时，也不能忘记SOA的目的是让IT为企业实现价值。不过，企业是通过业务线（LOB）来实现利润（或其它价值）的，因此，完全可以说业务线就是企业的动力之源，而技术项目只是业务用于实现目标的一种手段。有了这种非常直接的关系，那么如何准时地完成业务技术项目就成了关键。

    有些关于SOA的书籍和文章建议对服务重新进行完全编制才能实现面向服务所应有的效率。如果按这种方式来的话，那么所有开发项目就都会在标准的、能够在服务资源增长的同时保证架构质量的SOA治理中顺序进行。

    可惜的是这种方式通常是以缺乏架构治理（不管是正式的还是非正式的）这个假设为默认条件的。所有企业都有各种正式的和非正式的管理型技术项目，其中某些甚至已经变得很有系统性，与其它技术争夺控制权，甚至阻碍项目的交付以至使项目无法实现其所应有的价值。而治理必须在这样的一个环境中寻得一席之地。

    对于中小型企业（SME）来说这更是一个大问题，因为他们可能没有足够的员工在使业务领域及时完成项目的同时处理这样的一个过程。他们可能没有条件组成一个单独的服务团队，也可能没有足够的架构师在不妨碍开发的情况下对所有开发活动进行审查。结果就是业务领域逐渐失去对降低成本和提高生产力的前景的信心，并因此给SOA的实现埋下了问题的种子。他们很自然地会产生疑惑，认为当前的障碍是否是一种在当前条件下无法解决的问题，只能等待下一次技术潮流涌现并取代SOA。他们可能还不知道云计算……（嘘——别让他们听见）。

    如果一个开发团队要帮助某个业务领域实现价值，那么这个团队就会设计一个适用于这个业务领域的软件。但是由于这种软件是一种紧耦合，缺乏扩展性，因此无法将它应用于其它的业务领域开发团队。虽然这对企业来说是一种低效率的工作，可是却无法及时地反映到业务领域上。这些团队并不是在为企业寻找实现价值的机会——他们工作的对象是业务领域。他们认为他们的工作具有很高的价值。要减缓开发项目的速度以解决企业层次的低效率问题在这种业务领域环境下是难以行得通的。

    解决这种进退两难处境的方法通常是从上层开始推动变化并将所有服务开发平行到另外一个单独的团队中。这是种合理的方法，它能够利用常用的方法提高开发能力（布鲁克定律不算在内）。在各种首席官的带动下，人们希望可以组成一个能够随时实现服务以支持主开发团队的工作的具有各种资源或手段的服务团队。但是这个团队的主要任务并不是帮助业务领域，而是帮助企业。要实现这个目标，这个服务团队在创建服务的时候就要从战略性上着手。它必须对业务团队所提供的需求进行分析并决定这些需求是否对其它团队具有通用性。它还必须对服务的扩展性和易管理性进行评估。总之，它必须小心谨慎。而小心谨慎就意味着时间。在小型企业里，项目的交付期限是很短的，通常少于一年，一般只占一个业务周期的四分之一甚至更少。那么服务团队怎么才能在这么短的期限内还做得小心翼翼呢？