个人所见过许多公司在试图实施SOA治理时候落入两个区别陷阱第个陷阱是治理模型不够有力;而另个则是流程过多阻碍进程要解决这两个问题秘诀在于平衡流程和敏捷度 　　流程不足导致混乱

　　公司治理模型不够有力有许多原因以下是我曾经见过原因的:

　　· 缺乏对于设计时间和运行时间最佳实战完整理解

　　· 企业文化不支持标准和最佳实战

　　· 缺少资金购买治理资源和工具

　　· 不切实际最终期限

　　· 缺少执行力支持

　　如果没有个有效治理模型你梦想SOA天堂可能会变成场恶梦:系统故障、高开发成本、难以管理生产环境和不满意客户为了达到SOA所承诺重新利用、灵活性、敏捷度以及易于整合设计时间治理必须确保服务建立和业务价值致满足定性能和安全要求保持平台中立并且不能打破任何已经部署东西

　　由于SOA分布式和抽象性特点运行时间管理是至关重要个单商务服务也许由许多组件构成这些组件存在于架构各个层次而当服务出现故障时候你最好具备恰当流程和工具以迅速识别问题并在客户发现的前将其恢复

　　还有个问题就是管理服务版本、主动监控性能和安全、确保遵守协议和执行调整性控制等等复杂性

　　在没有坚实治理模型情况下实施SOA无异于个没有控制塔机场尽管我们可能拥有很优秀飞行员和先进飞机但没有恰当计划和实时信息结果将会是灾难性因此你应该保证建立个控制塔并雇用些空中交通管制员

　　过多流程抑制创新和敏捷度

　　这个问题另个方面就是那些为了流程而相信流程公司他们创建了过多流程使得团队(Team)陷入了文件深渊而忽略了业务驱动器我曾经见到有人打破那些设计精细但不能提供任何价值或从未得到重复利用服务往往来说“冗余治理”或“流程致死”模型使得架构师们机械研究, 按照文件和清单所说去做然后还需要花上好几个礼拜而不是两天来批准提议造成这样模型原因如下:

　　· 将SOA看作是个技术问题而非业务推动器

　　· 对于架构师和领导力缺乏信任和授权

　　· 冗长流程使用导致长交付期限

　　· 领导力层面缺乏技术和业务专业知识

　　寻求合适平衡点

　　每个企业文化、每个SOA倡议都是独无 2我们没有劳永逸或者放的 4海而皆准治理模型栈(Stack)供应商、SOA实施顾问公司和标准团体都具有充分文件介绍说明SOA治理思路方法论选择款最适合你企业文化并根据公司需求进行个性化

　　那么我们要如何同时得到敏捷度并实施SOA治理呢?其中个思路方法就是从文档文件向视觉文件转换换句话说那就是以UML模型、业务流程模型、应用范例和架构范例代替数百页文件这些配置就象是建筑架构蓝图样如果你要建造你梦想房子你会将房子细节输入Word文档交给你建筑师吗?还是说你会将交给她蓝图呢?我座右铭直是“重视会增值配置并舍弃掉其他无价值东西”千万不要让你员工仅仅为了任务清单去做些毫无价值步骤SOA治理不应该由项目经理(project manager)还建立需要识别和定义治理人是架构师这是服务生命周期管理标准N层流程并不适用

　　让治理随着时间演变

　　即使你达到了流程和敏捷适当平衡也不要次性实施像SOA样SOA治理也是趟没有尽头旅程从小处开始在必要时候按部就班

　　比如如果你第次实施含有15到20项服务你也许就不需要充满活力SOA精英团队(Team)(COE)存在特别是当团队(Team)只有几个技术人员时候随着服务数量增加架构师和开发人员队伍也随的壮大治理模型也是如此我曾经见过个公司花费整年时间来部署恰当治理流程这整年没有为业务带来任何增值我建议是将SOA治理作为关键部分纳入你SOA路线图中最终我们会从SOA创造商业价值来接受判断因此就要确保你SOA治理模型在SOA最佳实战和业务敏捷度的间取得平衡