SOA 治理：真的需要还是在浪费时间？

作者 Gernot Starke 译者 戴垚 发布于 2008年1月16日

领域

企业架构

主题

SOA ,

治理 ,

业务/IT整合 ,

最佳实践 ,

企业架构 ,

架构 ,

编程 ,

Buzzwords

在IT出版物和大会中，“治理”这个词被不断地提及已经有一段时间了，但从技术范围来讲，这些讨论通常最多算是隔靴搔痒。而这篇文章从IT治理的基本概念开始，到对设计阶段以及随后的运行阶段的治理，对开发者来说是一个很好的指导。

想象一个正在实施SOA项目的组织。每一个人都因为充足的项目预算和新的业务和技术机会而感到兴奋——看起来机会来了，但每个人同时也感受到了一定的压力。这时我们遇到了“SOA治理”女士，她负责保证关于服务的一切事物都正常运转。治理女士需要关注SOA的大方向和整个组织的利益。她不参与日常业务也不关心技术细节，但她将会制订战略，分配任务和全程监管项目。例如，必须保证花销有尽可能好的回报，实施的服务可以尽可能好的服务于业务。尽管治理女士得到了所有人的尊重，但她有时候会非常严厉，甚至不给项目经理和资深架构师的面子。当然，她最终可以直接向最高管理层和股东汇报，……这使她的言论非常有信服力。换句话说，治理女士至少在公司的SOA方面有着几乎至高无上的权利。

但等等，这不是管理层的工作吗？难道管理层不关心SOA的成败？理论上是对的。但实际上（你应该知道理论和实际的差距！），管理者总是有自己的（有时候甚至是秘密的）打算，它通常是和组织的长远目标相违背的。例如，项目经理更关心项目进度，而不是战略目标。因此，治理女士扮演的是某种超级管理者的角色，她只在乎组织本身。她要鼓励并强制“所期望的做法”。她的工作就是控制，就是法律和命令——而不是彬彬有礼。

她的职责可以作为“SOA治理”新准则的蓝本。这个职责不是为了创造更多的工作乐趣，也不是要使用最新的技术——而是关心花了多少钱和由此产生了多少回报。这就是SOA治理在我们开发者和架构师中不太受欢迎的原因，因为一旦设立了这种治理程序，他们的（当然也包括我在内！) 生活乐趣就会减少。但是可以肯定的是：它会使你的组织或企业保持健康的发展——即使有所损失也是值得的。

在我们进入SOA治理的细节之前，我先解释一下在治理女士海量的知识库中她所钟爱的一条座右铭：“企业和组织需要两个看起来相互矛盾的东西。”

首先，他们需要“秩序和控制“：他们需要法律，审判和暴力机构……这就是治理。需要提出警告的是：不管你们软件开发者或架构师喜不喜欢，一定要把你们纳入治理的范畴之内。

再者，他们需要自由，创作的空间和积极的工作环境，尤其是对脑力工作者。这也是整个“敏捷”运动的目标。

尤其是在IT组织，秩序和控制通常被认为是对提高脑力工作者的生产力起着相反的作用。我这里不是在谈论极权：治理想要加入的是适量的控制，目的是要使业务和IT更加的一致（说的多，成功的少)，因为通常IT人员不关心业务，而业务人员也同样忽略我们做IT的。但他们紧密的合作对企业的成功至关重要！

因此，治理是必要的，适量的治理是企业成功的保证。哈佛教授Weill和Ross可以证明成功的IT治理意味着更高的回报！而缺乏治理意味着长期的高失败风险。

背景

在我们进入细节之前，我们应该看一看整个治理家族（见图“治理层级”）：治理女士生活在一个大家庭中。她的大姐姐自称公司治理，外号“监察女士“。她有着仅次于世界和平的目标：保证企业中发生的任何事情都是对企业有益的。简而言之：她关心的是企业的价值和财富。

图 1: 治理层级

下一个要讲的是治理女士的小姐姐，IT治理。她的工作集中在IT和业务的关系。许多在线和传统媒体都对此（IT治理）有详细的描述，例如“IT治理协会”（ITGI）的[ITGovBB] ，或 Peter Weill与Jeanne Ross合著的一本优秀的书“IT治理”[WeillRoss]。她的责任和任务决定了我们刚刚遇到的SOA治理女士的责任和任务。

下图是“IT治理的核心领域”，摘自[ITGovBB]，它描述了IT治理的任务。太抽象了，不是吗？

图 2: IT治理的核心领域

IT 治理

IT治理是SOA治理的基础——在SOA组织里，两种治理必须协同进行。IT治理需要保证所有IT相关的活动都与组织目标一致，对组织的长远发展提供支持。IT治理大师Peter Weill和Jeanne Ross很好地将之定义为“鼓励所期望IT行为的权利决策与义务框架”（摘自[WeillRoss]）。或者说：治理要鼓励所期望的行为。它提供合适的“秩序和控制”框架，它在为业务提供足够自由蓬勃发展的同时，对个人和流程进行了必要的控制，从而避免混乱的行为。

当我刚接触到治理的时候，我觉得把它联系到实际非常困难。因此，让我们通过一个实际的例子看看什么是所期望的行为——摘自于[Ashar+07]：

“在过去的12个月里，为什么有那么多的混合动力的汽车在加利福尼亚州注册呢？是因为给予混合动力车主的超过1500美元的联邦税收优惠？或者是享受一个人在交通高峰期开在专用车道的奢侈？或者是加利福尼亚州开始越来越重视环保了？不管真实的原因是什么，现实是这些政策正在鼓励所期望的行为——购买低能耗的汽车。这就是一个治理的例子：政策正在引导所期望的结果。

很容易，不是吗？现在你会问：那IT治理如何达到这个目标呢？如何在IT领域里引导所期望的行为呢？

答案就在以下四个必须由我们的IT治理女士回答的问题中：

1. 应该采取哪些IT决策？
2. 这些决策应该由哪些角色或人来执行？
3. 如何执行这些决策？
4. 如何监控这些决策的结果？

 

听起来好像很复杂，不是吗？下图“关键治理问题”总结了这些问题：

图 3: 关键治理问题

治理的好处

但你会问，“为什么这么复杂呢？”这些又能带来什么好处呢？我将给出一个非常诱人的好处列表（不要犹豫，赶快转发给你的经理……）

• 高利润：独立研究表明一个IT治理有效的组织有更高的利润——哈佛商学院把它定量为20%的提高。
• 控制资金投资：IT开销是主要的资金投资——其大约占许多企业每年总投资的50%。
• 投资回报率和达成价值：目前虽然组织对IT进行投资，但通常不能监控这些投资产生的价值。治理采取的监控机制能更好的度量投资回报率。
• 有效地决策：参与IT相关决策的人数还在不断上升，这给建立一个有效的决策流程提供了非常好的理由。例如，现在连业务经理都在对IT花费指手画脚。
• 平衡地解决冲突：花费的效率性和灵活性是两个矛盾的业务目标，这需要从整个组织进行平衡，而这正是IT治理乐于提供的。

假如你的组织或企业还没有任何的IT治理，那你的SOA项目就给了你一个绝好的理由，让我们从今天开始IT和SOA治理吧……

SOA治理

既然我们对IT治理有了一个简单的认识，那究竟什么是“SOA治理”呢？我假设你已经对面向服务的架构（SOA）有了一般的了解。一个采用并实施SOA的组织需要关心在整个服务生命周期中出现的一系列问题。我下面只是列举其中几个：

• 业务过程设计：用面向服务的方式创建业务流程，分析功能性和非功能性需求。
• 利用现有投资重用服务，从而提高现有服务的整体价值
• 提供服务（遵从已设定的服务等级协定）给其他组织和/或客户
• 保证服务质量并进行测试，按照功能性和非功能性需求
• 架构，设计和实现服务技术基础设施，能够重用现有的基础服务，如格式转换，加密，压缩，认证和授权。
• 对服务相关的业务和技术进行适当的文档化，根据服务消费者和提供者
• 监控服务执行期的行为：特定服务被调用的次数，使用了那些参数，从哪个消费者？他们使用了高级功能了吗（要付钱的！），或一直在用免费的版本？

这些问题将会涉及到众多的人，以及从覆盖服务实现的业务需求到提供和运营服务这一漫长的过程中产生的大量文档，模型，日志和其他的产出。

文章的一开始就谈到了对控制的需求——我现在再一次回到那里：SOA需要对文档和各种产出进行严格的控制。任何要求和保持服务正常运营的东西都需要得到治理——要避免非我发明症（not-invented-here syndrome）并最大化重用。作为（敏捷）软件开发者或许并不喜欢它——我一开始就说过了……但如果你的组织想要SOA持久成功，这种控制是必要的！如果你不相信我：即使那些来自Gartner Group对技术很友好的人也会预言，SOA项目因缺少治理而失败的可能性要比因技术缺乏而失败的可能性要大([Gartner])。

现在让我们进一步看看必需的行为：对SOA的控制包括两个不同的时期（Lori MacVittie在他那篇优秀的在线文章中称它们为计时器）：第一个是设计或开发时期，另一个是运行或执行时期。因为二者有一些关键的共同点（称为元数据！）并相互影响，所以你必须同时关注。下面让我们依次讨论它们。

设计时期治理

设计时期治理控制软件开发周期内的所有阶段和活动。它从需求管理开始，延伸至架构，实现，测试，质量控制，文档——直到你的服务正式运行。设想一个业务或需求分析师正在获取下一代业务服务的需求。设计时期治理需要保证分析师获得全部已有的相关信息——并确定完成工作需要的时间。然后，你的软件架构师或服务架构师开始设计一个合适的解决架构。同样，治理要保证所有的产出，文档，（UML）模型，甚至服务契约都要准备完毕并可用（能够快速查找并同时方便重用）。

这种形式的设计时期治理有它的开销：对开发周期中所有产生或使用的东西（如文档，模型，演示，缺陷报告，评估，概念，尤其是服务描述，服务接口等）进行控制。许多开发者认为这种控制是一种障碍，而不是对他们工作的支持。一个组织要看得长远——要给予开发者相应教育并提供合适的工具（参见后续部分），这样会减少这种控制所造成的影响。

最后，服务也实现了，服务级别协议（SLA）也确定下来了，任何相关的东西也被文档化和测试了，那么你的服务就可以准备上线了！……也昭示着第二个SOA治理时期的开始。

运行时期治理

运行时期治理包含所有与服务执行和运营相关的事情。你需要了解哪个服务被调用，调用者是谁，以及使用了什么样的参数。你应该预先能侦测到性能瓶颈，关心服务提供者和消费者两端都认同的服务级别，观测日志和异常情况。简单而言之：它应该不间断地监控服务执行的方方面面。与设计时期治理不同，这并不需要太多的人参与。人，特别是SOA治理女士，只需要对综合结果报告进行评估。他们将会得到可用于下一个服务设计和实现迭代的大量反馈（你的工作又回到开始，不是吗？）

治理工具

针对SOA治理，软件业提供了两类不同的工具：注册和仓库。两者都可以用来存储服务元数据，它们是关于服务的所有信息。术语在这里并不重要，你需要关心的是为SOA设计和运行时期治理选择合适的工具。从我（与厂商无关）的观点看，先从一些小项目或原型项目开始建立你自己的SOA过程，然后再开始你的SOA治理工具链的选购进程不失为一个明智的做法。但是：不要忽略了对你的治理应有的支持。你要努力使之平滑的集成到你特有的SOA生命周期——否则无法得到股东的认可——连最和善的治理女士也不会帮你。
SOA治理工具链应该提供什么样的功能呢？正如前面所讲：你需要的是设计和运行两时期的支持。特殊的SOA生命周期也需要一些特殊的功能列表（是的，你会有一个只属于你的列表）。其中，每一个角色和活动都应该有其相应的支持。说起来容易，做起来难！无论如何，我还是强烈建议你评估这些用来支持治理女士工作的工具——否则你的SOA很可能到最后就是一团糟却没有任何回报。

总结

现在你或许会讲：“SOA治理容易。只要找到一个酷酷的工具就万事大吉了”。错，全错。再听听我们经验丰富的治理女士的话吧，她为有效的SOA治理提出了以下建议：

1. 制订并实施适合你组织的SOA过程。通过设计和开发一些服务来获取使用和提供服务的经验。针对你的SOA活动，设定角色并分配责任。
2. 评估适合你的SOA过程的文档类型。并交给SOA治理，你需要控制它们！
3. 评估在服务运行时需要监控的信息类型。你需要跟踪SLA吗？你需要检查调用服务的日志吗？同样，这都是基于你的需求。
4. 协调SOA治理和IT治理。你的IT治理非常有可能从你的SOA治理获益，你的SOA治理同样也会如此。这称之为协同增效——显然是一个值得拥有的好东西。

通过这些不多的步骤，你就可以建立一个非常有效的SOA和IT治理程序。愿治理女士与你同在：）

引用和参考

• Corporate and IT Governance
• [ITGovBB] Board Briefing on IT-Governance. IT Governance Institute, available online: http://www.itgi.org
• CorpGov
• ITGI: Institute for IT-Governance
• [Weill-Ross]: Peter Weill, Jeanne W. Ross: IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press, 2004. The seminal book on IT-Governance. If you want to read only one piece on governance, I strongly suggest this Weill & Ross. They are precise, concrete, understandable and experts. Additionally they have mastered the art of writing well!

SOA Governance

• [MacVittie06]Lori MacVittie: Understanding SOA Governance. Online: www.intelligententerprise.com
• [Afshar+07]: Mohamad Afshar & Benjamin Moreland: Key to successful SOA Governance, August 2007. Online: http://www.ebizq.net/topics/soa/features/7680.html?page=2&pp=1
• [Gartner]: "Lack of working governance mechanisms in SOA projects will be the most common reason for project failure (0.8 probability). (Jess Thompson, Gartner)"
• [Forrester-Jun06]: Forrester Research, June 12, 2006: "The Scope and Focus of SOA Governance" by Randy Heffner and Larry Fulton with Christine E. Atwood

关于作者

Gernot Starke软件架构和敏捷开发实践的独立咨询师和教练。他的客户来自于不同的行业（金融，物流，电信，制造和公共管理），并受益于他在软件架构，开发和管理方面超过20年的实践经验。他参与建立了面向软件架构师的arc42 portal，并撰写了大量关于软件架构的文章和书籍。他是“SOA专家指南”这本（德文）书的编辑之一。Gernot与他的妻子Cheffe Uli和两个孩子生活在德国科隆，练瑜加，有时也玩玩萨克斯。你可在http://ww.gernotstarke.de得到更多的信息。

查看英文原文：http://www.infoq.com/articles/governance-gernot-starke

---

译者简介：戴垚，2000年计算机硕士毕业后一直从事软件开发管理工作，目前在一家大型外企担任开发部门经理。关心软件技术和相关工具的动态，深信技术的使用应以创造价值为根本。目前致力于SOA的研究，希望能对业已复杂的企业环境有所帮助。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。