我见过许多公司在试图实施SOA治理的时候落入两个不同的陷阱。第一个陷阱是治理模型不够有力;而另一个则是流程过多阻碍进程。要解决这两个问题秘诀在于平衡流程与敏捷度。

    流程不足导致混乱

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

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

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

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

    · 不切实际的最终期限

    · 缺少执行力支持

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

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

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

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

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

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

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

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

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

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

    寻求合适的平衡点

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

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

    让治理随着时间演变

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

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

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。