【eNet硅谷动力专稿】很多企业在部署SOA的过程中，容易陷入两个不同的陷阱中。第一个陷阱是没有足够健壮的SOA治理模型。第二个陷阱是部署了太多的过程。如果你想要在部署SOA的时候不陷入这两个陷阱的话，关键在于要在过程和灵活性二者之间找到一个平衡点。
没有足够多的过程会带来混乱
关于企业没什么没有找到一个足够健壮的SOA治理模式，有许多方面的原因。以下我就简单列举出了几个：
缺乏对于设计时（design time）和运行时（runtime）最佳做法的全面理解。
企业文化不支持SOA的标准和最佳做法
缺乏治理资源和工具的资金
不现实的最后期限
缺乏行政支持
如果没有一个有效的治理模型，你曾将幻想的SOA天堂就有可能变成一个恶梦---系统崩溃、高昂的开发成、难以管理的生产环境和不满意的客户。要实现SOA所承诺的高度重用性、灵活性、敏捷性以及易于集成性，设计时治理必须确保SOA服务是按照统一一致的方式创建的，它们能够提供商业价值并且满足某些性能和安全性的要求，并且最重要的是这些服务必须是平台中立的，不能破坏企业任何已经部署的应用。
由于SOA具有分布性和抽象的本质，运行时治理是至关重要的。单一的企业服务是由一系列的组件构成的，而这些组件位于无数的架构层之内。当某个服务发生错误时，你最好有合适的流程和工具，从而能够快速发现问题并在顾客开始抱怨之前恢复系统。
其次就是如果没有健壮的治理模型，管理服务版本、主动监测性能和安全性、确保一致性和执行管制措施以及其它一些任务就会变得相当复杂。
在没有可靠的治理模式的条件下部署SOA就相当于修建飞机场但却不配备控制塔一样。当然，即便是机场的飞机性能非常好并且飞行员也非常优秀，但是如果没有适当的规划和及时的信息，最终结果将会是灾难性的。因此，一定要修建一个控制塔，并聘请一些空中交通管理员，这样，机场才能正常无误的运转。而SOA治理模型就相当于SOA的控制塔，缺少了它，SOA架构就会非常不稳定和不安全。
过程太多会扼杀创新并损害灵活性
过程太少会产生混乱，古语说得好，物极必反，过程太多也不是什么好事。过分相信过程的作用而在部署SOA时引入太多的过程会扼杀创新并损害灵活性。部署人员由于创建了太多的过程而陷入了文档的汪洋大海之中，忽视了业务驱动因素的作用。这样的服务过程由于粒度太细而只能提供非常少或没有任何商业价值，而不用说服务重用了。通常，“过度治理”或“过程死亡”模式使SOA架构师们思维僵化，像机器人那样思考，只是简单地执行任何文件或清单中所罗列的方法。此外，企业审批过程变得相当漫长，通常只需要一两天时间就能完成的审批过程却需要占用几周的时间甚至更长。造成上述这种状况的原因有以下几个：
将SOA作为一个技术问题不是一个业务驱动因素
对架构师和企业领导层缺乏信任
领导层缺乏技术和业务专业知识
在过程和灵活性之间找到正确的平衡
每个公司的企业文化及其SOA部署项目都是独特的。就SOA治理模型而言，没有一个通用的一刀切模式。堆栈供应商，SOA部署咨询公司以及标准机构都有各自的一套行之有效的SOA治理方法。从中选择一个最适合你企业文化的模式，让它能够满足企业的最终需求。
因此，我们如何才能在实施SOA治理的同时还能保持系统的灵活性呢？一种方法就是放弃原来的那种文字过多的文本型文档资料，而采用生动的可视型文档资料。换句话说，不再编写冗长的Word文件，而开始使用UML模型、业务流程模型、用例图和结构图。这些文物是一样的蓝图建筑的建筑师。举个例子，如果你想盖一座房子，你是愿意给你的施工人员一份写满房屋具体规格的Word文件，还是一份栩栩如生的架构图呢？我的座右铭一直是“把重点放在能够带来价值之上，其余的一切都不重要”。不要让你的工作人员单纯为了完成某个“教条”规定而做无用功。SOA治理策略不应由项管理者确定，而是应该由企业架构师来制定。SOA治理是有关服务生命周期管理的，标准的n层过程法则并不适用。
随着时间的推移逐渐演化SOA治理
即使你在SOA治理的过程中，找到了平衡过程和灵活性的正确途径，你也不要认为只执行一次就能永久收益。与部署SOA类似， SOA治理是永远没有重点的旅程。从小处着手并且只部署必要的服务。
例如，如果你第一次部署工作完成了15至20个服务，那么你可能不会需要有一个强大的SOA卓越中心（COE），尤其是当你的部署团队拥有人手充足的技术人员。随着服务数目的增加以及架构师人数的增加，你要相应地扩大治理模式。有些公司甚至花费了一年多的时间才将所有合适的治理进程安置到位，而这一年多的时间给业务带来的增值为零。我的建议是，在企业部署SOA的过程中，应该把SOA治理过程作为一个重要的组成部分。无论怎么样，评判一个SOA项目的好坏都是以它给企业带来的价值为标准的。因此，请确保你的SOA治理模型能够在SOA的最佳做法以及企业业务灵活性之间找到平衡。
