业务SOA治理
什么是治理？
要想知道需要怎样的治理，首要问题到底什么是治理。OASIS SOA参考架构基础对治理的概括如下:
治理是有关作出一些和整个组织战略以及企业文化相一致的决策。【Gartner】它明确了决策权利与责任的框架，使期望的活动 【Weill/Ross-MIT Sloan School】向实现战略方向发展，并且定义了达到最终目标的激励措施（奖励或惩罚）。它不太关注公开控制以及严格按规章办事，而更多地关注于提供指导以及高效且合理的利用资源，以确保组织战略目标的持续性。【TOGAF v8.1】
至此，这对了解到底治理是什么并没有必然的帮助。在某种程度上，有关治理是什么的问题可以通过治理不是什么来确定。
治理不是关于需求的 —— 需求是“指定”，它本身需要被治理。
治理不是关于设计的 —— 设计是“行为”，它也需要被治理。
治理不是编码 —— 编码是“行为”，它需要被治理。
治理不是WSDL或者XML —— 这些都是需要被治理的生成物。
治理不是注册库 —— 这是一种工具而不是答案。
关键在于治理不是指那些IT元素的所做作为，而在于那些元素的方向以及确保其连贯性。因此治理是在各个层面上进行决策和执行而不是采取积极的控制。
治理的目标
如果SOA的目标是拥有IT资产，使得该资产看起来像业务，管理起来也像业务，就连发展起来都像业务，那么治理就需要关注在该目标上。这意味着把SOA看作改造方案的一部分并设立你自己的治理，使其关注、驱动并确保该目标的实现而不单单是确保技术使用的连贯性。
改造的挑战在于你需要大家以不同的方式工作，你不会去改变所有的人也不会改变他们的历史观。过去的IT系统将继续沿用，就像IT及业务的那些已知行为将沿袭一样。因此为了成功，治理也需要被改造。
Machiavelli与IT
在其《君王论》一书中谈到了接管一个城市或公国面临的挑战并提出了统治新领域的三种办法：
- 把它们消灭掉
- 亲自驻节在那里
- 允许他们在自己的法律下生活，上供贡品，同时在那个国家里面扶植一个和你保持友好的傀儡政府
类比于IT，这些办法实际上映射到
- 绿色区域替换
- 从头开始布设集中的治理结构，并由业务准许
- 妥善处理杂乱无章的东西并通过让CIO向CFO汇报来降低成本
假设我们现在的目标是实现改造，而绿色区域替换是我们的梦想——一般情况下都是的，那么我们就只能选择从头开始的集中治理结构，它被清晰地视为代表了业务的目标
治理的类型
治理发生在多个层次，不能单纯地认为治理能一劳永逸，可以解决任何问题。治理因生命周期改造的不同位置和需要被治理的事物类型的不同而有所区别。
一个单独的治理框架并不会覆盖所有这些方面，重点在于不同的治理元素应该一致并且和改造的总体目标相契合。然而这显得复杂了，它仅仅只是正式地编撰那些已经存在的治理元素并且把它们按照正确的顺序排列。
如果目标转移到看起来、操作起来、发展起来都像业务的IT资产，并且其花费与其所交付的业务价值相符合时，那么所有的方面都需要变成以服务为导向。
治理时间轴
跨组织的推行治理意味着明白治理的目标到底是什么。若没有从某一业务的角度去清楚陈述SOA改造的目标和愿景，那么任何努力的回报将会会偏离方向，或仅限于IT交付范围之内。
第二个要点是，确保特别是IT执行的转移趋近于愿景。这就为改造提供了坚实的基础并确保改造在契合愿景的操作环境中全面开展。
如果执行没有转变成以服务为导向并且与愿景相契合，那么任何改造终将走向失败。
针对业务SOA的治理
了解了治理不关心什么的概念之后，下一阶段就是要明确在各种不同的业务领域和IT改造中应该承担哪些责任。区别建立规范和执行这些规范间的区别十分重要。这就如同整体愿景，其自身并不是治理行为——仅仅是为了实现愿景所作的治理的工作。要想知道如何治理，就要考虑更宽广的系统并理解其工作原理。
政府联邦模型
美国制度体系中政府分为四个部门。行政、立法、司法以及副总统迪克.切尼。
- 行政部门负责管控军队和“负责”具体事务的其他部门
- 立法部门制定法律
- 司法部门执行法律
- 迪克.切尼负责开展针对恐怖主义的工作
行政部门的工作事实上必须“负责让法律得到忠诚地执行”和“维持、保护及捍卫宪法”。换言之，行政部门自身并不负责制定法律，而是负责确保法律能有效适用。从我们的治理模型看来这很重要，因为我们感兴趣的是法律的实际应用和实施。行政部门就是大家各司其职。
立法部门是制定法规的主体，它有权同意签署行政人事任命和决定并且通常会建立一个能使变更生效的体系。从治理的角度来看这很重要，因为正是这些法规使改造得以巩固并且对跟踪成功与否定义了相应措施。值得指出的是立法部门的工作先于其他工作从而形成体系。
我们再来看司法部门：该部门的同志们都是使用法律并执行法律的人。从治理的角度来看，这些人可以决定是否法律或规章得到正确应用，并且当有违规情况发生时能够更改决议或者甚至是强制实施纪律。
最后我们看看迪克.切尼。有一些人，迪克就是其中之一，他们想当然地认为，就好像那些有组织的犯罪团伙想的一样，认为法律对他们是不适用的。问题在于这样的人真的增加了社会的复杂度，因为他们违反法规，认为自己凌驾于法规之上。从改造治理的角度来看，这些人自认为可以为所欲为并且不需要对任何人负责。确定在你的组织中是否存在这样能搅乱改造的“屌人”是非常重要的。
各州政府
联邦政府体制的另一特点在于最高层指定整体框架结构，而无需关注那些限于某一州政府的条条框框。这里的模型是指对治理的整个结构提供了每个州都应该遵守的法律却也支持他们制定针对自己区域的特色法律，只要其不和最高法律相违背即可。
对于我们的治理模型而言，这相当于让各种不同的子区域制定其自己的政策和治理结构。
流程
建立坚实的治理的过程是机构变革的一种，也就是说对机构的各个方面以及其处理事情的方式都会产生影响。这和一个国家的内部法律体系框架制定人们如何工作和行为是同样的道理，针对机构的治理模型也应当如此。
规划愿景
有了愿景意味着有了清晰的面向服务的业务架构——这提供了：
- IT所必须交付的未来业务组织
- 可用来测量的KPI和度量值
- 各种业务服务的业务所有者
业务服务架构是改造流程的总体目标。它代表了需要被治理的头等重要的产出物。
为了规划愿景从而创建业务服务架构，这需要组织的不同部门（IT与业务部一起）选派一组人去规划愿景。这个小组因此成了一个立法团体。他们的工作不在于传递变更而在于制定可用来测量改造的结构、架构和法规。
业务SOA司法部
业务SOA治理的目标是确保业务架构得以交付。
在改造阶段，SOA司法部作为治理机构，担当着确保正确交付业务服务和功能的角色，即确保：
- 业务服务和功能得以清楚实现
- 确保人员使用正确的业务服务
- 确保恶意的服务无法得逞
- 通过战术决策避免破坏的发生
- 资金的转移符合模型要求
这也正是立法团体将一些低层次的问题升级。改造治理小组的成员们须由立法部门直接授权，但是理想的情况是由那些更加关注正确地使用规则而非自我升职的人员组成。
因此，司法工作关注服务之间的边界问题，不关心服务内部具体做什么。
监督边界
美国的体制有联邦政府与州政府责任的概念之分，而此模型在商业世界中也同样奏效。简单看来，有些事情摆在在企业层面是合理的，但是在那些界限背后真的还是由既定的业务部门来决定其自身业务的正确运营方式。
其中的重点在于澄清区域之间的依赖关系是什么，进而明白它们需要什么才能成功，但是它们如何选择去交付这些功能事实上并不重要。从上面的业务服务模型看来财务为销售提供某种支付客户的方式固然重要的，但销售并不会对如何支付给客户感兴趣。
这意味着端到端的设计并不重要，真正有关的是接口的规范用来描述：
- 服务能提供什么功能
- 每个功能（前置条件、后置条件、顺序，等等）面对什么契约
- 服务能提供什么SLA
因此，司法部门的目标不单单是确保某一既定区域为正确规范提供业务服务——也确保某一区域不干扰另一区域内部的情况。 这点十分重要，因为它杜绝了潜在的依存关系的产生。
构建司法团
改造司法团因而关注于业务架构而非技术标准或基础设施元素。这意味着理解并执行架构以及财务改造将会巩固最后的结果。
业务架构
保证了正确的区域就是交付了正确的职能。致力于对业务面的认知，关注决策的长期生命力和稳定性。业务架构治理确保通过立法制定的结构得到严格地执行。虽然这些人通常与既定的某一业务领域紧密相关，但也被选拔到司法部门以确保一切与原本的战略真正保持一致。
好的业务架构师应该对其业务领域有很深的认识，并且能够清楚的识别特定的领域或其依赖的东西在哪里存在功能性的错误。好的业务架构师必须有很强的沟通技巧，被业务视作有决断力的人，拥有确保决定得以执行的人格魅力。
财务控制
驱动使用单一服务以及确保标准化交付的部分挑战在于财会长期方面的工作往往被忽视。诸如“一个功能由谁资助”之类的简单问题都可能会导致程序的中断，针对消费者所使用的某一服务所进行的长期核算标志着IT从一种传统项目的核算到与业务更为相关的财务结构的转变。
以上这些不是琐碎的任务，而是长期的IT改造不可或缺的部分。然而人们很少关注从IT到资本支出（CapEx）的长期财务转变以及支持模型到真正的运营费用（OpEx）模型。治理必须包括对财务模型转变的管理和执行。
业务SOA治理决定了什么
业务SOA治理对程序和项目的实施是否与整体业务架构保持一致作出判断。之后他们关注由程序和项目正在交付的改造是否会带来某领域的财务模型与业务架构同步改进，或者能更有效地交付其他程序和项目元素。
业务SOA治理小组会作出判断，何时程序将开发某一功能以便能更好的在其他地方实现交付，或者在某处已存在的功能却不能重用来实现交付。因此从业务的角度来看，来该小组有权否决所有项目和程序，如果他们无法得到该小组的首肯，那么很显然地，项目或程序就无法成为整体改造项目的一部分，而只能是纸上谈兵，只会白白增加改造的整个费用。
从业务到可执行SOA
改造的下一个阶段是重整目前的运营方式以满足将来的目标状态。这需要IT人员重组、管理变更以及，通过业务架构的使用，清楚的识别各领域的业务负责人。这样的改造可能需要花费大量时间，这取决于当前的组织结构和具体措施，但最终的目标是能够确保任何未来的运营决定及变更在实施过程中与整体愿景保持一致。
从流程角度看，使用最新的信息技术基础设施库（ITIL）第三版框架说明为组织构建这样的运营转变已经有相当坚实的基础了。有了ITIL作为基础的流程和框架，加之每个个体、宗旨和目标与整体业务服务架构相契合，这有助于确保通过ITIL所做的运营治理能与整体业务架构保持一致。
业务SOA治理决定了什么
在运营中，业务SOA治理团体判断是否新的运营结构满足整体业务架构目标。因此它拥有在人员改组上的否决权以确保各就各位各司其职。业务SOA治理小组也扮演着负责升级更改请求和BAU变更的角色，此类更改作为局部战术决定的结果是对某一既定业务服务域的污染。
交付&技术SOA治理
关于治理的最后一点是，调整新交付件的提交方式以及必须作出的技术决定。这本身就是一个大的领域，它确保在实现业务服务时将会使用正确的技术规范，通过这种方式可以增进单人开发的效率并降低开发责任的整体风险成本。从治理的角度看，该领域主要关注程序结构、交付方法、技术规范以及测试和验证。
程序结构
交付中的一个关键改变是远离应用开发而朝面向服务的开发靠拢。这意味着交付团队应该和开发出来的服务保持一致，而不是与应用筒仓一致。这意味着必须改变编程方式，并且需要制定程序的发布方式及其他相关因素。在此领域中，治理就是要确保面向服务交付的基本原则得到实际应用，同时避免那种以应用为中心的交付方式。
交付方式
交付方法治理旨在建立标准的交付方法，使得服务转移到运营时能够清晰归档、交付、以及轻松识别和管理。在该领域，治理指的是实施规范的交付方法并确保产生正确的交付物。
技术标准
技术标准要求每个人在立法部门提出的方式下工作。这里说的是确保接口在技术方面符合标准要求。这些技术好比XML监管员、模式管理员以及技术监督员（确保人人都使用同一种技术语言，并严格监督任何对此语言进行的更改）。对技术标准的关注在整个生命周期中处于规范和设计阶段。
测试与验证
这里说的不是UAT或系统/集成测试，而是边界。是小组检查服务是否有越界。它验证服务是否交付了应有的功能。在某些技术交付中它们是对服务进行边界之内及之部的验证。
这些是司法部门在边界的监控代理。他们确保了操作性服务不管是在部署开始之前还是在运营之中都履行契约。同时他们确保了任何人试图调用某一服务都要遵守其约定，如清除数据服务，否则将阻止这些人操作服务交互。
测试与验证在一个改造项目中常常会被忽略或仅仅被视为集成测试的一部分。集成测试确保了系统可以进行端到端的协调工作，但是当在细节方面发生问题时往往会面临挑战，而此时真正的错误已经发生。正是测试和验证确定了问题真正的归属方。
业务SOA治理决定了什么
在交付和技术中业务SOA治理团队判断新程序和交付方法是否会满足整体业务目标。同时也正是该小组需要批准并提出技术标准，确保这些标准符合组织的长期目标。运营治理小组也需要批准，确保从交付过渡到运维。
业务SOA治理小组在确定了某一程序对应业务架构是正确地构建之后，接下来，是交付和技术治理小组们的任务，他们要确保程序的实现与这一原始结构保持一致。然后业务SOA治理小组在生命周期和UAT期间担当了一个角色，以便继续确保交付和技术治理与最初的业务架构一致。
“迪克”引发的灾难
最后一个问题是如何对付像“迪克”这样的人。每个组织都有类似的个人或团体，他们违反规则或根据自己对规则的“理解”来自创规则。这些个人通常在组织中享有一定分量的权力，正是在此时，你可以检验你的治理，它是一个强大的治理模型？还是仅仅是金玉其外，或者是充斥着内部混乱、管理不善的治理。
你组织内部的这些“迪克”会建议使用新标准而不会遵从团队的方法。他们会拿“局部”最优当借口，甚至声称自己遵守了规则，但事实上很明显没有遵守。
那些“迪克”有个特点，那就是他们不会真正关心整体的改造，他们只关心他们自己的具体观点并且要确保它们在自己的领域内得到实施，除此之外，对于这么做有何影响他们一点也不关心。
这些“迪克”可能是那些明知你正在使用的WSDL 1.1和WS-I Basic Profile 1.1而他们却在使用WSDL 2.0。 他们也可能是一帮“投机取巧”的家伙，不按企业要求的标准去归档服务。他们甚至可能是一些生意人，他们与供应商一起打高尔夫信誓旦旦地同意要买一大堆根本不适合其组织决策的新软件。
这些“迪克”会带来灾难的原因你可以在《人月神话》中找到这样的解释：架构的一致性比个体优化更重要。业务SOA治理就是要确保一致性并防止迪克这样的“屌人”制造灾难。
总结
业务SOA治理是为了和业务对齐而需要长期进行的IT改造。这就表示构建一个清晰的业务架构来展现业务“将会”呈现的状态，进而创建一个业务SOA治理小组来保证将来的项目及运营与愿景相符。这个小组权力很大，需要像司法部门那样去执行任务。他们的角色并非承担具体工作而是界定边界以及指定规则。
查看英文原文：Business SOA Governance