扫一扫
关注中图网
官方微博
本类五星书更多>
-
>
全国计算机等级考试最新真考题库模拟考场及详解·二级MSOffice高级应用
-
>
决战行测5000题(言语理解与表达)
-
>
软件性能测试.分析与调优实践之路
-
>
第一行代码Android
-
>
C Primer Plus 第6版 中文版
-
>
深度学习
-
>
MATLAB计算机视觉与深度学习实战-赠在线交流卡和本书源码
执行SOA-SOA实战指南 版权信息
- ISBN：711126682
- 条形码：9787111266822 ; 978-7-111-26682-2
- 装帧：简裝本
- 册数：暂无
- 重量：暂无
- 所属分类：>
执行SOA-SOA实战指南 本书特色
在企业中成功实施SOA的专业实践指南
在本书中，四位有经验的SOA实施者针对在*大、*复杂的SOA计划中的
成功交付，分享了真实世界的、经过验证的实战指南。
本书紧承作者们的畅销书《Service-Oriented Architecture Compass》，展
示了如何克服成功实施SOA的关键障碍，并确定了针对所有方面的*佳实践。包
括技术方面、组织机构方面和人员方面。本书关注的问题包括：引入服务原则．
支持协作和信息过程共享；利用已有的技术资产和策略来集成服务；为新的工具
选择正确的角色；文化、治理和架构方面的转变；为整个组织机构的生命周期带
来更大的敏捷性，而不只是针对独立的项目。
本书对于每个力求在复杂环境中通过SOA来实现价值的企业架构师、技术
经理和IT领导人来说，是一项**的资源。
本书内容包括：
实现SOA治理，反映组织机构的战略和业务重点。
成功执行SOA项目：关于服务建模和设计的实践指南和经过验证的方法学。
利用可复用的资产：*大限度地利用SOA库。
架构师能够选择正确的工具和产品，它们包含执行SOA方法进行服务设
计和实现时所需的功能。
定义信息服务。以便让合适的人在合适的时间收到合适的信息。
集成SOA与Web 2．0，以及其他创新的产品和解决方案。
在SOA环境中提供高度可用的人员接口。
“全面而实用的一本书。它深刻地描述了SOA治理，给出了服务的全面视
图，从架构视图直到实际的实现，我觉得这一点对我很有价值。对于准备面对
SOA中艰难部分的企业架构师来说，这本书是很有用的。关于如何实现资产复
用、SOA中人员的方面、描述如何适用工具的那些章节，让这本书很值得一读，
而且很实用。”
执行SOA-SOA实战指南 内容简介
王海鹏等译本书细致全面地描述了SOA，从架构视图直到实际的实现，展示了如何克服成功实施SOA的关键障碍，并确定了针对所有方面的*佳实践。本书关注的问题包括：引入服务原则，支持协作和信息过程共享；利用已有的技术资产和策略来集成服务；为新的工具选择正确的角色；文化、治理和架构方面的转变；为整个组织机构的生命周期带来更大的敏捷性。
本书内容详实，结构清晰，可作为管理与技术人员的参考用书。
执行SOA-SOA实战指南 目录
译者序
序
致谢
作者简介
对本书的评价
第1章 SOA简介
1.1 SOA回顾
1.2 要考虑的新问题
1.3 这本书有何不同
1.4 这本书写给谁
1.5 这本书包含哪些内容
1.6 developerWorks的文章链接
1.7 参考资料
第2章 揭示好处
2.1 为什么业务部门应该关心SOA
2.2 架构
2.3 聚焦业务架构
2.4 业务过程
2.5 业务组件
2.6 揭开面纱
……
序
致谢
作者简介
对本书的评价
第1章 SOA简介
1.1 SOA回顾
1.2 要考虑的新问题
1.3 这本书有何不同
1.4 这本书写给谁
1.5 这本书包含哪些内容
1.6 developerWorks的文章链接
1.7 参考资料
第2章 揭示好处
2.1 为什么业务部门应该关心SOA
2.2 架构
2.3 聚焦业务架构
2.4 业务过程
2.5 业务组件
2.6 揭开面纱
……
展开全部
执行SOA-SOA实战指南 节选
第1章SOA简介第1章SOA简介
“又是一本面向服务的架构（SOA）的书”您可能会这样想。书店里已经有几百本这样的书在卖了。在4年的成功应用之后，SOA已经形成了强大的市场价值，您几乎可以买到任何“基于SOA的某种产品”。市场人员很快发现了这种强烈的趋势，所以将产品重新命名或描述为SOA兼容的、基于SOA的、为SOA而生的，以及一切与SOA有关的。虽然出了大量介绍SOA的书，但有一些问题仍没有涉及。所以，在这本书中，我们将讨论这些“漏掉的问题”。
SOA的原则不是新的，不是和这个缩写同时发明的，很多供应商“觉得很有理由”宣称他们的产品是基于SOA的。当然，如果您检查一下IT解决方案，您会发现SOA的原则在几十年以前就实现了。例如，在一些财务服务公司的IT部门内部开发的基于大主机的解决方案，已经很聪明地考虑到了将来的复用和变更要求，以一种松耦合的方式来构建。在某些情况下，已经采用了我们今天所谓的企业服务总线（ESB）的架构。这些单元虽然没有以这样的方式来标识，但它们确实是按SOA的要求来运行的。架构原则不是*近才发明的，您可以认为它们是SOA的基础。
在我们深入细节之前，让我们进一步了解一下SOA的历史。SOA是如何产生的？这个问题的答案将很快揭示成功执行SOA的关键要素。但是，只了解历史是不够的，早期基于服务的架构要向SOA转变，还必须考虑一些新的问题。
11SOA 回顾
SOA的大量采用可能源自于它在IT和业务之间提供的联系。它承诺在两个阵营之间的断层上架起一座桥梁。企业中的相关各方希望打破围墙，不再是业务部门将需求抛过围墙，然后IT部门在围墙后面试图弄明白业务人员想要什么。
在20世纪五六十年代，当IT还是新事物时，接触它的人是一些专家，他们说着神秘的语言，知道如何操作神奇的业务机器。这些机器（以及它们的**个应用程序）能够更快地计算出利润/税款，并使某些业务过程自动化。一组高薪的专家可以很容易地了解简单的业务需求，然后将它们实现为在这些机器上运行的软件。随着个人计算机的兴起，人们知道了如何进行编程，而不只是在绿屏幕的某个位置输入数据，这形成了一个更精通计算机的用户群体，他们知道如何对IT部门提出更复杂的需求。在20世纪70年代，越来越多的软件供应商在市场上出现，为许多行业提供操作自动化的解决方案。
市场让企业能够比较和评估不同的软件解决方案，通常是针对他们自己内部的IT部门。于是，公司开始寻求IT外包，因为IT变得过于复杂，内部的团队不能够控制那些没能实现的需求，而这些需求需要马上实现，以击败竞争对手。战略外包成为IT行业的一个重要市场。实际上，通常整个IT部门会被IT服务公司收购，由IT服务公司来提供一定水平的服务，并承诺消除原有的所有IT“壁垒”。“关注于核心业务”很快变成了今天的格言。
让“专家”来接管IT，可以确保服务水平、升级过程、条件和要求等多方面需求。除此之外，这些外包的服务*终比内部IT部门所支持的企业日常业务要走得更远。服务提供者在客户的要求和竞争压力下，需要提供尽可能低的费用以获取长期的合同，从而确保稳定的收入。实现这一点的途径之一就是，服务提供者实现标准化，并复用已有的IT架构和解决方案。
在20世纪90年代，兼并和收购的规模越来越大，所以一些不兼容的IT解决方案需要进行集成。例如，这些扩大了的公司必须整合各种资产和要求，运营成为一个问题。标准化的软件包代表了这个问题的一种解决方案，但是，原有的企业资源计划（ERP）系统已经在很大程度上进行了定制，在某些情况下，ERP解决方案提供者已经被他们的竞争对手兼并，需要集成他们自己的包。有时候，软件供应商针对某个行业的特定运营单位的特殊需求，发布不同产品线的软件解决方案，这些解决方案在一开始并没有考虑到集成。这些系统缺少作为广泛接受的标准的行业业务模型，使共享成为困难。
这些所谓的“坑子解决方案”，每一个都针对具体的业务主题和数据集（以及在这些数据上的相应操作功能）。在不同企业单元的独立业务考虑的驱使下，这些“坑子解决方案”成为了在每个企业单元内实现操作优化意识的范例。由于优化业务*有效的方式就是关注于业务单元的内部操作，总体大局观就丧失了。
前面我们曾提到，在企业单元之间进行集成的一种驱动力量是兼并和收购，结果导致企业需要通过复用一些企业单元来实现预想的成本降低，如HR、发票、采购和销售管理。*初的尝试是有重复的部门之间创建集成自动化，这样用户可以对同样的数据只输入一次，就适用于不同的系统。或者，利用一个批处理过程从一处系统向另一个系统传输信息。企业应用集成（EAI）系统似乎为建立重复应用之间的点到点的集成提供了成熟的支持。
为了让集成自动化，人们开发出不同的中间语言和适配器；通常，标准软件提供商提供一些应用编程接口（API），目的是更好地将它们的解决方案与其他不同目的的解决方案进行集成。这些*初的尝试将水平的信息流和贯穿企业的业务过程对应起来，产生了集成软件和服务的市场，但是语言和转换规则仍然必须单独定义，并且它们经过剪裁才能用于特定的业务过程。
A11对于企业IT系统更快速集成的要求，标准软件包仍不能满足的特殊业务单元需求的不断增长，以及基于因特网的新业务之间协作的需求（经常跨越边界实现互操作），这些都驱动了对IT行业标准的需求。在Web服务的旗帜下，世界各地的大型软件供应商和不断成长的小型IT提供商定义并支持了一组标准。
“参考资料”小节列出了两个与SOA和Web服务有关的标准化组织。在这些定义中，提出了首批互操作性术语。大家普遍认为，任何通过互联网提供的服务都可以进行描述（如何发现服务、如何调用服务、什么是标准格式，等等）。但是，这还不是一种IT架构定义，只有提供者-消费者注册表这一基本概念，它的定义在如何公开找到web服务、如何宣传、如何由消费者访问等方面提供了标准。
在大多数EAI系统中占主导地位的“集中-发言”架构引发了迈向SOA的另一步。这些系统提供了一个集中控制单元，确保了对已注册应用的正确功能的调用，并处理其他问题，如访问权限、格式转换、确保交付等。将这一思想进行抽象，让它在企业范围内应用，ESB的概念就诞生了。IBM的SOA参考架构的创建就是为了展示这种方法。在参考文献 Bieberstein et al (2006)中，您可以找到关于ESB的深度讨论，以及它如何支持IBM的SOA参考架构。
这些服务要求人的干预，可以配置成整个系统，并根据客户的需求立即进行操作。SOA参考架构于是变成了一个企业运营的清晰框架。这一框架*终可以为*终用户构建的前端和根据Web 20的服务定义构建的应用程序提供一个基础，如混搭（mashup）等，并快速部署用AJAX或类似的透明开发工具编写的面向用户的应用程序。
SOA曾被视为避免IT部门未能及时交付的手段，因为它是服务于多种业务需求和IT需求的架构。在这个系列的**本书《ServiceOriented Architecture (SOA) Compass， Bieberstein et al (2006)》中，我们讨论了各种SOA的定义，它们在早期曾被使用，即刚过了千年之交的时候。*后，人们给出了一个定义，似乎*符合过去和今天我们对SOA的理解和使用。这个定义是这样的：面向服务的架构是一个框架，目的是集成业务过程和起支撑作用的IT基础设施。这些业务过程和IT基础设施表现为安全的、标准化的组件，即服务，它们可以被复用和组合，以应对不断变化的业务优先级。一些作者采用了这个定义，这个定义也确定了SOA的市场方向，即实现一种方式，通过组合业务和IT要求，以更敏捷的业务运营来获得市场优势。灵活性成为了今天的驱动力。企业认识到响应市场的速度以及为客户提供*好的解决方案就意味着赢得全球市场。
要获得快速IT解决方案的支持（以及其中运营的业务过程），一种方法就是复用资产。复用意味着针对IT和业务的一组通用标准（行业范围内的，或在全球跨国企业内的）。归根到底，这意味着得到一组可操作的组件，它们可以根据实际的要求进行组合和重新组合。
12要考虑的新问题
SOA*初的关注点是架构，以及如何以灵活的方式为企业设计IT系统。变得灵活的压力来自于越来越多的不能及时交付和业务对敏捷的要求，因为业务面对的是日益动态的市场和全球化的竞争。因特网的直接性和现代通信使得创新以前所未有的速度征服全球市场。
对于架构师来说，这种互联性意味着不再是针对具体的业务问题来解决独立的问题。相反，架构师必须能将任何新的解决方案集成到已有的解决方案中，并在企业范围内和企业之间不断编织IT系统。IT架构师成为一个城市规划师，而不仅仅是建造一幢房屋的人。许多出版物都描述了IT架构师、SOA架构师和企业架构师的角色，其中强调的总是在IT和业务之间作为协调人的角色。
基于SOA的IT范围变化影响了企业内部和外部的人员和机构。Web 20提供的技术和企业内外使用的一般协作工具所提供的技术，为企业在全球化市场的运营带来了新的机会和风险。
从人类开始贸易起，各种标准就已建立：货物的度量，用于价值比较的货币系统，支持采用来自不同供应商的部件构建复杂机器和技术装备的技术标准。公制系统越来越成为技术和科学的全球标准。但出于方便，仍有某些例外（例如，标准集装箱仍然是基于英尺的）。
首先想到一个新主意并利用它取得市场成功，就意味着为市场设置了标准。每个行业（包括IT，特别是软件业），一直都是争先的竞赛，目的是将自有的标准变成行业的标准。在IT行业中，这种竞赛从二进制编码和ASCII标准开始，一直持续到今天。对于SOA来说，汇集在Web服务名下的标准已成为软件技术领域广泛接受的标准。
A12但对于许多业务目标来说，这些标准还不够，因为它们只定义了在网络中如何分包、描述、访问和查找服务。对于许多业务用户来说，这些标准缺少上下文/语义的相关性。例如，为了帮助用户，业务术语需要实现标准化，以促进访问和可操作性。针对情境的创新将导致*适合的方式。
*开始，开发者必须确定基本元素，并理解如何控制它们（这样就不会根据很严格的、不灵活的规则盲目地执行）。复用（为它而构建并*有效地实际实现）是一个有关生存的问题，是关于如何能够有效而快速地构建一个解决方案的问题。投放市场的时间（从意识到业务机会到让系统和组织机构做好准备迎接它）比以往任何时候都更能决定在市场上的生存能力。
效率不再只是来自于勤奋研究而开发的优化系统，而是来自于如何快速地扩展已运行的系统，让人们知道如何利用系统提供的服务来解决问题。
人们已经开发了一些工具，用于管理技术方面的问题和业务方面的问题。业务过程管理已不再是“铅笔和纸”的方式。定义良好的过程可以由服务组合来实现，并可以快速变化。企业的雇员、客户和外部的业务伙伴都成为过程的一部分。他们可以根据一组可靠的服务，创建任意的过程，以应对不断变化的情况。
A13在这本书中，我们介绍了技术方面及其影响，但我们没有介绍实现基于SOA的企业的*佳组织机构所需的业务转换和转变管理。一些文章、博客和其他论坛（当然还包括许多业务书籍）在这方面提供了指导。不过，我们在这里以一种务实的方式提供了解决方案和思想，这样您就可以将它们应用于自己的情况。
13这本书有何不同
您可能会问：既然我们说了SOA已经用在许多地方了（甚至在这个缩写出现之前），为什么还应该读一本描述如何执行SOA的书呢？
我们在世界各地有越来越多的同事和合作伙伴，他们参与各种项目，涉及许多行业的客户，目标是实现基于SOA原则的解决方案。许多不同的问题，不仅仅是与IT上线和企业方针有关，都会影响到规则的某些方面。某些情况导致了创新的软件功能和产品，使我们更容易成功，而这些功能和产品也适用于许多其他情况。
A14新的标准出现了，可以让业务将一些来源独立的元素组织起来，创建一个解决方案。新的产品必须满足客户和他们的IT部门的期望，并且由于IT和业务线据说正变得越来越近，所以*终用户比以前处于更重要的地位。
在这本书中，我们强调了这样一些方法，它们由合适的工具所支持，包含了企业内外雇员和管理层之间的组织机构和行为的变更。我们将这里讨论的成功SOA的要素建立在我们成千上万个项目的经验上，建立在世界各地许多行业的客户上，这些客户通常在一个“平的世界”上跨国经营，在不同大陆之间24小时共享产品和开发网络。
14这本书写给谁
这本书不是初学者的SOA指南。有一些书已经提供了构建面向服务的机制的基础内容，并讨论了如何开始与此相关的业务转变。
我们编写这本书所考虑的读者主要是在企业中工作的实践者、业务咨询师和企业架构师，他们负责推动业务转变朝着SOA方向前进。我们不提供银弹或100%管用的解决方案，相反，我们依靠的是自己和同事在真实项目中的经验。这本书中提到的情形是经过抽象的，很容易被高级专业人士所使用。
A15我们的前一本书得到了几千个大学图书馆和研究机构的认可，在那本书中，我们主要针对学术读者，并为研究项目提供输入信息。
A16我们希望本书的绝大多数读者都有IT和业务背景。一般来说，这种所谓的“T型”角色要求具有广泛的业务知识和技术知识，并对特定的主题有详细的理解和经验。对于这一类人，本书将很有帮助，并强化个人的“T型”特征。
15这本书包含哪些内容
在提出企业的IT和业务线之间更密切的融合时，对于IT架构师来说，重要的是要考虑业务上的理由。第2章基于各种调查的数据，提供了对执行官的想法的分析。我们将这些分析与面向服务的架构基础联系起来，形成符合两个方面的模式。在一定的抽象层次上，您可以发现业务组织机构和IT结构之间的并行关系，这种IT结构正是SOA的核心。IT架构，业务架构和企业架构展示了一些共性，每个领域中的人员都能从相互交流中获益。*后，这将导致IT和业务之间预期的、要求的链接。今天，人们已经认识到了一些支持性的指标。
A17在许多已经实现的项目中，有一点是至关重要的：即以怎样的方式进行SOA治理，从而实现对SOA项目和企业的组织。在向基于SOA的企业转变的过程中，某些元素和组织结构已被证明比较容易成功。第3章解释了它们的重要性。
建立并实现SOA治理就为成功奠定了基础，下一个重要的步骤就是实现服务的方法学。第4章提供了成功运作项目的实践指南，基于的理论是从世界各地的不同SOA项目中提取出来的。
我们已经暗示过，重要的是在企业内管理服务，而更重要的是通过利用可复用的资产而获得好处。因此，我们在第5章讨论了引入复用库所引起的问题，语义的问题，以及如何、何时、为何使用复用库来实现*有效的解决方案。
通过利用可复用的资产，一组工具将建立起服务的实现。这些工具构建了一个集成的平台，让团队成员的不同角色能够有效地合作。第6章探讨了针对SOA选择怎样的工具，何时使用工具，如何建立开发环境等问题。
数据对于任何业务都是十分重要的。数据会变成信息（知识），不同的人出于不同的目的对数据进行访问。SOA中的信息服务为用户提供并转换了需要的相关数据。第7章“信息服务”讨论了基于*近研究的创新技术，可能有助于将所有重要的信息送达企业中正确的人。
雇员（包括客户和业务伙伴公司的雇员）通过一起协作来利用面向服务的概念。第8章“在SOA下协作：人的方面”将SOA与Web 20以及其他创新产品和解决方案所提出的方法放在一起进行考虑。另外也讨论了人们利用现代工具进行互动，包括来自于经验的例子。
*后，第9章提供了我们对于*近的发展和出现的趋势的看法（初现端倪，或者现在还处于“谈论”的阶段，但是描绘的美好前景足以让我们认真考虑）。
16developerWorks的文章链接
IBM developerWorks(dw)（由正文中边栏的图标表示）中没有具体的文章与这一章直接相关，但我们建议参考以下的站点。这些有关于SOA的讨论和文章：
A11 dW web服务标准站点。
wwwibmcom/developerworks/webservices/standards/
A12 IBM 红皮书中关于“SOA”的研究。
wwwredbooksibmcom/cgibin/searchsitecgi?Query=%20SOA&SearchMax=250&SearchOrder=1
A13 Web服务和SOA论坛首页。
wwwibmcom/developerworks/forums/dw_wsforumsjspa
A14 由IBM员工和IBM业务伙伴提供了dW webcasts。
wwwibmcom/developerworks/views/global/webcastsjsp
输入关键字SOA查找相关主题，这个URL提供了*新的webcast。A15 dW新闻订阅。
www128ibmcom/developerworks/newsletter/
A 16 developerWorks 上的SOA Compass。
http://www128ibmcom/developerworks/dwbooks/soacompasshtml
A17 IBM SOA新闻(除了dW网站之外，您可能希望将这个新闻订阅加入书签。)
wwwibmcom/soa/newsletter
17参考资料
Bieberstein et alServiceOriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, Pearson Education, 2006
OASIS SOA标准定义。wwwoasisopenorg/committees/tc_catphp?cat=soa
W3C web服务标准定义。 wwww3org/2002/ws/
Endnotes
第2章揭示好处第2章揭示好处
当我思索宇宙时，脑海中浮现的一幅图景就是，它是由简单的有序模式构成的，这种模式可能出现在所有现象中，不论现象有多么复杂。
——Jonas Edward Salk, 19141995, The Anatomy of Reality
当业务执行官被问到是否拥有SOA时，他很有可能会回答“SOA是什么？”事实上世界上许多业务执行官都已听说过SOA，但许多人认为它只是IT部门可能会去实现的东西。虽然这种情况正在改变，但我们相信，除非管理层意识到“面向服务”是一项战略目标，否则SOA就不能实现全部的价值。
21为什么业务部门应该关心SOA
术语SOA，特别是术语中的A（架构），常常对业务经理和IT职业人员之间的沟通造成困难。避免使用技术流行词汇，强调IT部门能够让业务过程、交易和信息流更快更敏捷，几乎总是更容易确保得到执行官的资金支付。我们不需要更多的技术，SOA更多的是面向业务的解决方案，业务部门应该理解它，并不带任何勉强地赞成它。
长久以来，公司的业务一直“容忍”信息技术作为一个黑盒子，公司的金钱投入其中。*初，投资回报是正的。将那些明显可以自动化的过程自动化，是有明显价值的，如打印账单，账户往来，订单和销售等。
但是，业务变了。在某种情况下，公司可能收购了一些增加收入的业务，卖掉了一些不增长的业务。突然，几种不同的IT系统很难单独进行管理。不同的IT部门相互之间都不怎么喜欢对方。一个部门可能使用的是全套IBM的技术，另一个部门可能使用全套微软的技术，第三个部门可能使用混合技术。所以，公司在IT黑盒中投入越来越多的资金和费用，在业务上似乎永远得不到任何真正的好处。不同的小组说他们在与其他人协作，每个人似乎都在尝试，但所有人都陷在技术的繁文缛节之中，对业务没有任何帮助。所以，“我们从IT中得到了什么？”，当年末问这个问题时，只有耸肩并环顾左右而言它。
让业务和IT部门说同一种语言是很重要的。“服务”的概念是思考企业业务的一种很自然的方式。业务由什么组成？业务是一组业务服务，以工作流的方式形成一个业务过程，完成业务上需要完成的事情。这正是SOA关注的内容！它不是技术，它是业务！
另外，业务会改变，并且这种改变正在加速进行。IT必须能够支持这种改变，并且要快速地支持。“*好的公司是*好的合作者，在扁平的世界里，越来越多的业务将通过企业之内和企业之间的协作来完成，原因很简单：今后的价值创造会变得越来越复杂，以至于没有单个公司或部门能够独立掌控它们。”
Friedman, ThomasThe World is Flat, Farrar, Straus, and Giroux, 2005, 352353211行业趋势促进对面向业务方式的需求
A21让我们后退一步，看看全景。组织机构的领袖现在应该思考一定的行业趋势并制定计划。Dave Newbold，IBM杰出工程师和IBM CIO技术团队的主席，编写了2010年CIO远景报告。在2010年，对业务产生*大影响的6种趋势包括：
全球集成——业务需要对全球的机会做出快速响应。这意味着企业雇员需要利用企业内部和外部*好的全球智力资本，并发现以前未知的能力。这样的能力将是关键的差异。这包括创建、发现和复用业务服务能力，能够领先于竞争者进入市场。
参与式因特网——这里的意思是记录并复用客户在因特网上的交互，理解用户的智慧，并利用它来进行生产和将来的交互。例如，这一点支持了Google的页面评分，eBay的销售评分，以及Amazon的产品评论。这种技术提供了强大了信息源，快速积累了价值，并创造了很高的忠诚度。这将要求你对客户有统一的看法，并能够在全企业的范围内组合并分析与用户的交互。
劳动力跨越地域——在发达国家，公司正开始经历**次所谓的大规模退休浪潮，因此将失去主题业务专家。代替这些专家的是透明的、可访问的数据和同事之间流畅的联系。对于这个过程来说，确保企业的数据通过健壮的服务接口来提供是至关重要的。
软件即服务（SaaS）——转换了打包的软件业务。这些托管的应用程序更便宜，更容易维护和改进，非常易于集成和支持，在哪里都能访问到。你现在的应用程序可能不容易维护和改进，也不容易集成。你所使用的供应商提供的软件包的运营和维护相当昂贵，并且难以和企业的其他部分进行集成，与使用SaaS相比，你的公司在竞争中处于劣势。
虚拟的数据和服务——应用程序和数据将通过网络交付并存储，让任何带有Web浏览器的平台都能够访问您提供的数据。风险承担者们对您提供数据的能力很在意，不论它们在哪里，都将使您的公司与众不同。
设计的简单性——随着世界变得越来越复杂，竞争变成了看谁能提供简单的交互方法。这种“简单性”要求设计和纪律，但作为业务具有不断增长的市场价值，因为客户会在他们使用的服务中寻找简单性和信心。
在2010年CIO远景中有两个一致的主题：
很容易交互的业务服务。
容易访问并且包含正确的业务数据。
在这个快速变化的世界里，您的员工需要什么样的技能？在支持这些变化方面，您的组织机构准备得有多好？不幸的是，对于大多数组织机构来说，答案是“我们没有准备”。那么，您正在做这方面的工作吗？应对这种情况，您的计划是什么？您的目标时间只剩下两年了。您需要充电，将提供业务服务、提供业务数据和提升员工能力变成现实而不只是愿望，这需要很长的时间（除非它不是您的目标）。
212可访问的业务服务
哪些业务服务可以让您的业务运营获得成功？这不是一个很难的问题。考虑业务服务是很自然的事情。例如，客户购买的产品包含了一项或多项的增值服务。这些产品是通过一个生产过程创造出来的，这个生产过程包括一些业务服务，如“制定交付时间表”，“监控生产过程”，“收集过程中的样品”和“得到完成的产品”。通过“创建订单”，“进行订单管理”和“挑选、包装并运输订单产品”等服务，产品被订购，并运输到客户手中。
业务和IT部门必须考虑并分析这些业务，将它们分解成一些业务服务以及子组件，弄明白如何通过优化得到新的、更好的业务过程。这是创建业务架构的一部分工作，本章稍后将讨论这一点。本书其余的部分将讨论一些SOA方法和技术，让您的业务架构成为现实。这里的要点在于SOA是关于业务的，它关注的是让您的业务变得敏捷、能够快速响应业务风险承担者需求的方式。
213易于访问且正确的数据
如果您的组织机构像大多数组织机构一样，那么对于您运营业务所需的数据来说，*佳的方式也只不过是存放在一组独立业务线的数据库中，这些数据库包含了不同的信息和重复的信息。您的客户知道这一点，因为他们必须告诉您的客户服务代表有关他们与一个小业务部门的交易信息，客户服务部门对此一无所知。或者来自一个网络的信息没有与来自另一个网络的信息实现集成，因此导致更高的成本。这样的例子很多，我相信您可以自己举出更糟糕的例子。负面的影响包括损失收入、增加成本、丧失机会，这甚至会让*短视的业务人员都心烦意乱。
为什么企业会接受这一点，认为“它就是这样的，总是这样的”？不应该这样！应该对客户有一个单一的视图，包括一个规定的过程，一个销售流水线，一些财务记录和其他所有对业务有重要意义的数据。让我们怀着尊敬的心情来对待您的数据，它是组织机构的救命血液。它值得去净化。它值得结成联盟。在某些情况下，它可能甚至不得不经历一个痛苦的集成过程。我们的底线是，业务完全有责任要求IT提供易于访问的、正确的数据。
第7章将深入介绍使这一切成为可能的SOA方法。
214快速变化的劳动力所需要的技能
在Thomas Friedman经典著作《The World Is Flat》里，他指出：“2000年成为一个巨大的碾平机，因为它向如此众多的业务展示了PC、因特网和光纤已经创造一种全新的协作和水平价值创造模式：外包。任何服务，呼叫中心、技术支持操作或能够数字化的知识工作，都可以在全球范围内外包，寻找*廉价、*聪明、*有效率的提供者。”(Friedman, 2005, 108~109)。
Friedman, Thomas The World is Flat, Farrar, Straus, and Giroux, 2005, 108109.这对于我们的工作和组织方式来说意味着什么？今天，企业倾向于按产品、按地域或按职能来进行组织。这样的组织通常具有垂直化的特征，优化需要在垂直的机构中进行。尽管这在20世纪是有意义的，但世界正在变平，Friedman已经雄辩地指出了这一点，所以这种组织方式已变得过时。水平化的组织机构关注自始至终的一个过程，这个过程可以将其中的一些部分日常工作外包出去，这些工作没有业务优势，同时又提升了内部执行的核心业务过程部分的竞争优势。
这就是为什么业务过程管理（BPM）如此重要的原因。BPM采用了更为正式的方式来管理组织机构的业务过程。BPM驱动的组织机构可以从一个企业的层面来管理过程，而不是从一个功能或一个领域的层面，这创造了相互配合和优化，而在垂直型组织机构中这是不可能的。治理和结构化的方法、策略、测量指标、实践和工具得到实施，以整体的方式持续不断地优化业务过程。
IT中的某些功能已经变成或正在变成日用品。这不是说这些功能会消失，但是*好的公司知道他们需要在内部发展和保持哪些技能，哪些技能可以通过协作和外包获得。例如，在水平化组织的、关注服务的组织机构中，会有较少的“编码”和较多的“组装”，组装已有的、可复用的功能。这些功能可能是内部创建的，也可能是从一组全球服务中得到的，或是在今天的市场中不断涌现的SaaS服务。
BPM的兴起意味着某些面向业务的技能正变得越来越需要。例如，“业务过程设计师”必须能够与业务人员和IT人员协作，能够理解原有的端到端的业务过程，为企业的利益而优化这个过程，设计一组业务服务，这些服务必须通过创建或组装来实现所需的灵活性这一目标。业务过程设计师必须熟练掌握业务目标，并能够很好地与技术人员和IT人员协作。许多公司正在让具备业务技能的人轮换不同的业务岗位和IT岗位。他们可以是爱好技术的业务人员，或是能够掌握商业大局观的技术或IT专家。今天，在这个世界上，有多少人具备这些技能呢？不太多。您的组织机构为培养这些技能正在做些什么？让我们更进一步地讨论这个话题。
22架构
许多业务执行官和专家，虽然高度关注制定策略、管理运营和开展业务，但并不关注“架构”。不管是不是面向服务的，架构都是IT专家要考虑的事情，而不是业务专家的职责范围（这是常见的误解）。
这种情况也正在改变。越来越多的人认为，许多适用于信息系统IT架构的原则同样可以适用于业务系统的“业务架构”，而且理应如此。
注意，这里使用短语“信息系统”是强调在企业中对信息流的关注，人们应用信息技术来实现这些信息系统。而短语“IT系统”没有直接描述这些系统的目的。这种信念在多大程度上揭示了SOA的好处？这里我们将进行一些讨论，展示一些应用架构原则来通向商业价值的有效途径。
23聚焦业务架构
不太久之前，信息系统被看成仅是对业务组织机构和业务目标的支持。引入计算机系统是为了更快、更准确地执行手工任务。今天，这种情况已经得到了发展，信息系统不仅改进了业务效率，而且它们常常在企业战略中扮演着关键的角色，目的是在复杂的市场中实现竞争优势。今天，如果没有清晰地确定信息系统的角色，将它作为公司武器库中的一件利器，那么业务几乎不可能开展。
业务架构的*初焦点是确定一组通用的业务概念和关系，这些概念和关系将*终把部署的业务系统和相关的信息系统结成一个统一体。这些通用的业务概念被用于组织特定商业企业的业务知识。来自于这种知识的业务系统和信息系统需求使用通用的语言进行表达，并由SOA定制开发来满足，或者匹配到已有的资产，如SaaS系统。
架构的定义有许多种，但是如我们接受IEEE 14712000的标准定义，业务架构就应该是“业务系统的基本组织，体现为它的组件、组件之间关系和组件与环境关系，以及管控其设计和演进的原则”。定义这样的架构不是为了指导别人来构建业务系统，而是为了帮助别人来理解业务系统的本质。
IEEE Std 14712000 Systems and Software EngineeringRecommended Practice for Architectural Description of Softwareintensive Systems [20070715]
McDavid, D W“A Standard for Business Architecture Description,”IBM System Journal, 38: 1, 1998通过将同样的系统工程原则应用于业务系统和信息系统，使用一组通用的底层概念和概念间的联系，我们就前进了一大步。但是，这一步并不容易。首先，没有业务执行官会觉得容易准备时间和资源，以建立通用的业务概念，并在组织机构内部使用通用的业务语言。为了实现这一点，必须有一个有机的过程，它能够在一段相当长的时间内，在很强的原则和管控之下不断进化。当不同的部门提到“客户”时，他们必须指的是同一个概念，不论*后是否统一地实现。
其次，定义的概念模型必须能够清晰地表达*初的需求和需求的变更，并在组织机构内清楚地指导如何组织工作。这种方式已经得到了描述，并得到成功实施。在一些国家的许多项目中，人们已经关注构建企业本体论，以便为将来的业务和信息系统架构提供坚实的基础。
在确定了概念模型之后，显然，业务架构是根据会计责任领域来考虑的，工作在这些领域中组织起来，以实现一组定义良好的产物。这种看待业务系统的方式聚焦于取得结果，而且通常是以一个增值交付机制链的方式来表示的。当然，采用这种方式取决于对业务模型和业务策略的清晰定义，这是对结果进行会计责任审计的基础。
24业务过程
在每一个会计责任领域中，工作组织起来，资源得到供应，并定义了相应的监控方式。近些年来，设计工作流来实现特定的结果受到了广泛的关注。工作可以系统地组织起来，并以业务过程的形式显式地进行管理。但不论它多么吸引人，这一观点仍然没有被世界各地的企业一致接受。实际上，许多企业还没有在思想上做出反应，以迎接转向“面向过程”的挑战，为将来制定计划。
揭示SOA的全部潜力的下一个步骤，通常是在企业关注于建模、规范、部署、监控过程，以实现特定的业务结果。许多因素促成了对过程的关注，这一点曾一度隐藏在“组织结构和方法”以及“工作流”的标签之下。
这种标准的“业务过程建模表示法（BPMN）”能够通过图形表示法来表示内部业务过程，并让组织机构能够以标准的方式来沟通这些过程。这种建模确保了对业务的理解，并且业务的参与者能够让组织机构快速进行调整，以适应新的内部环境和业务环境。
参见wwwbpmnorg 网站上的“Object Management Group / Business Process Management Initiative”。
参见“Business Process Execution Language for Web Services”网址是wwwibmcom/developerworks/library/specification/wsbpel/。这种标准表示法已经成为许多基于计算机的工具的基础，人们使用这些工具对业务过程进行建模、模拟和监控。这类工具的出现推动了业务和信息系统背后的面向过程思维的转变。另一个因素人们开发了一些软件工具，以标准的方式来描述业务执行的过程。“业务过程执行语言（BPEL）”是由一个软件供应商协会开发的，现在已经得到许多IT平台的支持。在一个很高的抽象层上，BPEL让业务专家能够描述他们的业务过程，然后将它们翻译、半自动化，成为实际执行的信息系统，支持这些业务过程。
每个业务过程都由一系列必须执行的业务任务或活动组成，它们由人工或机器执行，以实现定义的业务结果。某些过程很简单，包含较少的任务。而有些过程较复杂，包含成百上千个任务，其中夹杂着为得到正确结果而必须做出的一些决定。一些有经验的实践者总结了构建有效业务过程的*佳实践和活动的模式，记录在模型中，以备将来使用。所有这些因素都推动着业务朝着“面向过程”转变。
如果假定在特定的会计责任领域边界中，必须包含交付结果所需的所有业务过程，这是无效率的。当不同的会计责任领域通过共享关键“子过程”而相互协作时，这种“锅炉烟囱”式的无效率就得到很大改善。随着每个业务过程被分解为子过程和业务任务，这种共享就可能实现。因为每个任务都假定需要一些人力技能、资金支出、运营成本、原材料、补给和许多其他“资源”，所以这种信念的剧变意味着为了共享关键子过程而共享责任。这种共享的责任，如果管理得好，将封装对资源的需求，以一种定义良好的方式优化资源的使用，从而降低运营成本。
25业务组件
在特定会计责任领域内，因与合作伙伴的合作而实现或包含的所有业务过程和子过程，可能会根据它们与特定业务功能的关系进行分组。这些子过程的分组通常叫做业务组件，因为它们由原子的功能元素组成，可能是执行官将来进行分析的焦点。
参见“A ComponentBased Approach to Strategic Change”，网址是 www935ibmcom/services/us/igs/cbm/html/bizmodelhtml。图21展示了IBM开发的方法学，用于识别业务组件并进行分析。每个垂直的列都由与特定功能业务能力相关的组件构成。水平的行根据它们在执行官层面（方向）、管理层面（控制）或运营层面（执行）对业务的影响来组织这些组件。例如，销售是图21业务组件模型处在“服务和销售”能力域和运营层面的一个组件。
在业务活动分析确定了一组业务组件之后，就可以确定哪些是核心的业务组件，哪些可以外包，哪些是企业所特有的，哪些是行业内一般的功能。战略中的业务目标就可以对应到一些组件，这些组件需要以某种方式增强，才能实现期望的结果，并实现成本压缩。
在分析中关注业务组件和业务过程，真的是很有效的。业务组件分组则将业务活动、它们的资源，以及它们的方法联系起来，成为企业的“构建块”，业务过程分析理解了活动的线索，这些线索将组件串起来，以实现业务目标。某些业务过程可能全在一个组件之内，而另一些业务过程可能涉及几个组件的功能。在这个层次上对业务架构及其组件的理解让我们朝着揭示SOA的好处更进了一步。但如何做到？如果SOA不是关于技术的，而是关于构建随需应变的业务企业框架，那么整体视图就更清楚了。26揭开面纱
当业务过程和子过程确定并分配到具体的业务组件上，它们的战略价值和对企业的影响也确定了之后，就可以将注意力集中在特定的功能和相应的系列活动上，对它们进行增强。做到了这一步可以算是取得了很大的成功。但是，当做到这一步时，就可以确定一系列对业务很关键的业务任务，这些任务既可以通过人工来实现，也可以通过机器自动化的能力来实现。这些任务序列被IT架构师称为业务服务，也应该被业务架构师称为业务服务。哈！这是业务世界和IT世界交汇的时刻。双方都应该开展工作，确定*佳的业务服务集，这些服务不仅是为实现业务目标而服务，也对支付信息系统带来*大的影响。
通过确定业务的关键服务，就能够分析哪些已有的服务需要改进或替换，哪些没有的服务需要引入，才能实现战略目标。*近IT的进展让我们能够反映业务领域的这种想法。业务服务可以“封装”成功能单元，不仅能够采购、销售、兼并和外包，而且能够让架构师以创造性的方式进行组合，组装成新的功能，在特定的市场上获得比较多的优势。这正是SOA的真正好处：业务创新和强大的IT系统功能之间的相互配合。
在第1章中，我们展开了讨论，谈到SOA正在兴起，但还没有在世界各地的业务系统中产生真正的影响。市场的兴奋度可能逐渐减弱，但率先采用SOA的企业正在说，SOA的价值已经让他们在高度竞争的市场中，节约了大量进入市场的时间，或者在他们所处的行业中起到了改变游戏规则的作用。
本章中，我们粗略地讨论了SOA对于业务执行官、经理和专业人士的真正含义，在业务架构、BPM、业务组件方面的*近进展，以及这些进展如何创造出一种环境，让SOA可能发挥出全部的潜力。揭示这些好处需要有愿景、强烈的方向感、训练有素和知识——关于业务的知识和可用的IT技术的知识。
27developerWorks的文章链接
A21 Laningham, developerWorks Interviews: Dave Newbold on the IBM CIO 2010 Outlook
wwwibmcom/developerworks/podcast/dwi/cmint061907txthtml
28参考资料
Amenta, Peter SHistology, 4th ed, 1993, 138 Medical Outline Series Norwalk, CT: Appleton & Lange
Baker, James A“The Stakes for Themand Us,”Newsweek, April 6, 1993, 2426
“Descriptive Geometry,”Encyclopedia Britannica (1986), 7, 292
Friedman, Thomas The World is Flat, Farrar, Straus, and Giroux, 2005, 352353
Ibid108109第3章SOA治理第3章SOA治理
治理是有意图地使用政策、计划、过程和组织结构做出决定，并控制一个实体达到业务目标。SOA治理关注在实现SOA时需要的或创建的服务。
A31采用SOA的主要理由就是提供业务和IT的灵活性。SOA采用的是可复用的服务的方式，通过企业的架构来实现企业的业务战略。创建一个包含丰富的可复用服务，好处得到充分体现的环境，需要深思熟虑的、显式的、得到实现和维护的治理计划。SOA的真正好处是创建一个面向服务的企业（SOE）。SOE的核心是用更为水平的方式连接业务过程。
A32在用于全球企业和公共机构的治理模块中，我看到过两个极端。在二战之后的一代人中，军事化的治理很流行，这是由那些曾在军队中接受过领导培训的员工所主导的。项目通常很冗长，包含严格的官僚主义控制和大量的文书工作，导致了大爆炸式的结果，或者项目被取消。这种形式的治理仍然在许多政府组织中存在。
与此相反，在看到速度的需要的情况下，下一代的治理倾向于走向另一个错误的极端。业务单元控制他们自己的IT开发，或者IT开发小组被迫关注他们在垂直结构中的位置，做出一些局部优化的决定，注重的是及时交付项目，而很少考虑或理解对企业整体所带来的影响。这样的情况和兼并收购一起发生时，就造成了每个业务问题都有几个不同的应用程序，得到了过于冗余的系统。
SOE采取的是中间策略。某些控制是需要的，但我们需要正确的控制，也就是说，这些控制为创建“好的”服务和敏捷性增加价值，又不会变得太繁重。业务的需要驱动着IT，而不是其他情况。治理模型倾向于采用联合的方式，多个组织机构关注不同的任务，通过共同的治理政策、计划、过程和测量指标实现松散的协作。在这种方式中，SOE既可以通过企业架构以及相应的业务策略和IT策略“自顶向下”地发展，也可以“自底向上”地发展，利用已有的一组系统或项目，确定创建可复用服务的机会。
SOA是IT支持变化的催化剂，如果实施得当，将联合业务部门和IT部门，获得比较优势。例如，许多公司都有某种类型的基础设施部门，也许负责所有的消息中间件。相对来说，比较容易升级一个组织，引入SOA技术架构能力，例如使用企业服务总线（ESB）或扩展标记语言（XML）消息在不同系统中共享数据。尽管这样做是有价值的，也是在SOA道路上的**步，但只是更新技术架构也错失了真正的好处。从基础设施的观点来看，像XML和Web服务描述语言（WSDL）这样的概念是强大而有用的。但是，从它们自身来说，它们只是技术浪潮中*近的一朵浪花。实际上，SOA并不需要使用XML或WSDL。在将来的几年里，XML之外的其他技术肯定会出现，它们从技术的角度来看会更有价值。
因为SOA是一种分布式的架构，跨越了业务和IT之间的界线，所以更需要有效地治理在这些组织机构之间到底发生了什么。实际上，在组织机构中引入SOA通常可能是一个重大的转折点，从弱的治理转向强的治理。
A33本章关注SOA治理中应该考虑的方面，以及考虑它们所需的实践技术。您的企业不一定准备好了所有这些方面。这没什么。只要您意识到它们，并在决定中加以注意（“我不知道”将不是理由），您就很好地迈向创建富有竞争力的SOA治理功能之路了。本章将探讨SOA治理要考虑的三个领域：
SOA策略的治理。
SOA的组织。
SOA治理考虑。
在考虑SOA治理时，我们有意采用自顶向下的方式。也就是说，我们从策略和业务焦点开始，向下深入到日常SOA治理设计和模式的实现集。许多开始SOA之旅的组织会发现，他们从一开始就没有准备好利用SOA的战略跃迁，他们需要先找到更多的技术专家。也就是说，SOA通常会在IT组织中开始，这里会有专家队伍，有很好的教育，然后再开始转向价值链，考虑全面的、关注业务的、基于SOA的转变。在这种情况下，SOA治理实践者应该注意SOA策略的治理，但应该从实现本章的32和33等小节的相关部分开始。实际上，SOA治理通常采取一种分阶段的方式，首先关注服务开发生命周期，接着是SOA项目管理（利用33节中描述的过程），*后是转变到敏捷的企业（参见图31）。图31 典型的SOA治理阶段在需要的时候，我们以“理想通信公司”这样一个虚构的组织作为例子。
31SOA战略的治理
*有效的SOA治理必须能够控制并帮助提升企业战略，以创建SOE。这要求IT部门（信息技术部门）与业务部门并肩工作。另外，许多IT部门习惯于舒服地在自己的地盘上工作，没有能力考虑从订单到现金的循环，也没有兴趣考虑，更不必说去考虑业务在眼前的项目需求背后想要的是什么。SOA治理的职责是治理业务的敏捷性，需要改变这种状况（参见图32）。这种改变需要与企业架构部门和业务部门密切协作，加入必要的控制，推动敏捷性策略。如果没有专门的计划，企业永远也不能实现到SOE的跃迁。
图32例如，开发单位1的过程的2/3依赖于其他开发单位管理的服务的完整性、性能、
可靠性和传播。如果没有治理，单位1将独自完成，而不是采用可复用的服务
311IT治理的考虑
A34理想情况下，经过深思熟虑的IT治理能力已经存在，可以用于SOA治理。当然，让SOA治理独立于IT治理并与IT治理竞争，这是失策的。IT治理本身处在公司治理的环境下，例如，清楚地表达为“公司治理的OECD法则”。理想情况下，SOA治理应该关注IT治理中所需要的“服务”增强，因为它处于公司治理的总体背景下。
对于业务部门和IT部门来说，SOA常常是一种范式的转变，涉及他们如何协同工作以及需要怎样的治理。通常，IT治理的*佳实践是不知道的，或者因为每个副总裁都按自己的方式来做事，忽略了这些*佳实践。SOA治理的实践者理应评估目前IT治理的成熟度，在治理转变计划中准备好正确的行动。在没有IT治理或IT治理很弱的情况下构建SOA治理就像在流沙上建房子（参见图33）。幸运的是，现在的公司已经在IT治理方面考虑了很多。图33你应该在流沙还是坚实的基础上实现SOA治理“针对信息和相关技术控制目标（COBIT）”是由“信息系统审计和控制协会（ISACA）”和“IT治理研究院（ITGI）”创建的。COBIT提供了一套广为接受的测量、过程和*佳实践，目的是让信息技术和开发IT治理的好处*大化。在wwwisaca org/cobit，您可以找到COBIT的更多信息。
SOA治理实践者应该运用COBIT或类似的一组IT治理*佳实践来评估当前IT治理的状况。某些IT治理缺陷可以通过业界的一些*佳实践来解决，如“信息技术基础设施库（ITIL）”。ITIL在服务管理、基础设施管理、安全管理和应用程序管理等领域提供了运营指导。关于ITIL的更多信息，请参考wwwitilorg。
尽管创建战略业务敏捷性的模式的确存在，但在这个领域却没有类似的一组详细的*佳实践，像ITIL为IT运营创建的*佳实践那样。由于SOA的一个主要目标就是创建对业务过程的基本理解和一些模型，从而为业务服务和相应的IT设计提供信息，所以这个领域的SOA治理几乎总是处于当前IT治理的水平之上或之下。
本节余下的内容将关注在定位和敏捷性方面的SOA治理。
312IT定位到业务
业务和IT说着不一样的语言。业务使用“销售渠道”、“市场细分”和“货币化”等术语。IT使用“J2EE”、“XML”、“表单元素”等术语。虽然企业架构同时适用于这两个世界，但大多数人不能适应。然而，SOA希望这两个世界的人聪明地协作。要做到这一点，就需要针对业务和IT定位的过程进行治理考虑。
SOA治理这一节的目的是讨论如何治理及确定管理业务目标和IT目标的融合。这些目标被用于指导企业的SOA战略和组合管理。
业务目标可以印在一份整洁漂亮的文档上，实践要做的事情只是礼貌地要求得到一份复制。可能仍然需要拜访相应的业务利益相关者，澄清对这份文档的理解。很多时候，这样的文档并不存在，治理需要确保拜访业务利益相关者，然后表述业务目标。这可能包括CEO、COO或业务单位的经理。业务用户习惯于将IT作为一项技术资源，通常是从“他们的”IT应用程序、PC和电子邮件支持的角度来看的。SOA治理必须确保将正确的业务和IT利益相关者带到会议桌上，并且这种讨论是业务上的讨论。“理想通信公司”的业务领导有以下的业务目标：
将新产品上市的时间缩短为2个月或更少。
在今后2年里，将运营费用每年降低5%。
在12个月内，将我们在每个用户身上的人均年收入增加25%。
如果IT目标不是来自于业务目标，那么IT目标就会体现出技术本质。业务目标是驱动IT组合投资的正确动力，也用于指导SOA的旅程。从“理想通信”列出的业务目标，我们得到了以下的IT目标：
必须创建一个唯一的产品目录，集成订单录入、订单执行、寄送账单等工作，允许在不改变代码的情况下加入新的产品。
独立的产品运营支持系统必须与单用户界面结合起来，操作高效，且节省费用。
客户信息必须有规范的数据模型。需要创建一个联合的客户信息模型，让我们能从单个客户的角度来分析问题。
单靠IT部门，能够在没有对应业务目标的情况下创建出这些战略目标吗？虽然这只是一些高层的例子，但SOA治理实践者应该应用这一基本思想。也就是说，控制利用业务目标来指导和创建IT目标的过程。
313业务敏捷性
业务敏捷性是改变业务过程的能力，或创建立即可用的新业务过程的能力。目前的业务过程是如何成为今天这个样子的？是否有一个战略规划过程导致了完全理性的、无缝的一组业务过程？是否所有能够自动化的事情都已自动化？是否公司关注了所有的应该关注的功能领域，或者是否存在鸿沟？是否有多个部门在执行相同的业务功能，例如，是否有重要的重叠，导致冗余或未优化的业务操作？
业务敏捷性是采用SOA的一个主要原因。要创建能够提供敏捷性的SOA战略，有一些和前面的问题类似的问题需要分析。SOA治理有责任确保存在正确的团队来关注这些问题和其他类似问题，这些问题对于业务来说很重要，这些业务决定随后得到控制，并用于整个企业。理想情况下，这个过程将综合利用公司架构、非常理解当前工作模式的业务用户、一些业务预言家，可能还有外部的咨询顾问。不能理解并关注业务需求和优先级，将使得企业的SOA旅程变成一个西西弗斯式的徒劳任务：将业务价值这块大石头推上山，但当IT项目的关键时间到来时，它总是脱手，业务价值便重新滚回山下。业务的需求必须是*重要的，是SOA的驱动力。任何SOA任务（或者说任何IT项目），如果不能对应到业务上的驱动力，可能都应该取消，或者至少应该注意一下它是什么项目：IT维护项目没有直接的业务价值。在这样做时，通常会得到这样的结果，即减少没有业务驱动力的项目投资将解放资金压力，用于创建服务和真正敏捷的企业。
西西弗斯是希腊神话中的一个人物，用来形容足智多谋喜欢投机的人。——编辑注SOA治理必须确保在这个任务中投入正确的资源。抓住这个机会的一种好方法就是确保企业架构使用标准的业界功能图，该图可以反映企业当前的业务过程。接下来，确定当前的业务部门和它们的职责。对这些业务部门进行访谈，可以理解它们支持的业务功能，并理解这些功能中的不同细分市场。每个业务功能中的问题点都可以发现并理解。然后进行缝隙或重叠分析，确定优势的领域和提高业务敏捷性的机会领域。
例如，对于电信行业来说，“电信管理论坛（TM Forum）”已经创建了行业标准“TM论坛业务过程框架”，也称为“增强的电信运营图（eTOM）”(http://www tmforumorg/browseaspx?catID=1648)。图34展示了“TM论坛业务过程框架”的运营子集。
图34利用行业功能组件模型来指导业务敏捷性讨论和分析，如TM论坛
业务过程框架（即eTOM）第2级所示
对于我们虚构的公司“理想电信”来说，SOA治理团队与企业架构团队一起，在访谈业务单位时采用了eTOM，识别出有4个独立的业务部门执行eTOM中的功能“25 针对实例和服务的评分”。在某些情况下，同一个服务从公司中不同的销售部门获得时，价格是不同的。因此，有一个业务目标就是为理想通信的所有产品创建单一的评分功能，我们创建了一个SOA业务服务，名为“创建评分”。这个服务又由一组子服务组成：间接的使用记录、评分使用记录、分析使用记录，分别对应到eTOM第3级的业务功能图。以这种方式，业界业务过程图不仅推动了业务讨论，得到了对业务来说可以测量的好处，而且也推动了SOA业务服务创建策略的计划！另外，业务敏捷性讨论是建立关键执行标识（KPI）的好时机。在这个评分的例子中，要创建的一个明显的KPI可能“到年底时为所有产品提供单一的定价源”。这里更为偏重业务的KPI可能是“由于消除定价错误，使得DSL产品的利润增加2%”。
“理想通信”也使用eTOM来确定高价值业务优先级的影响，即对客户有360°的全方位视角。企业架构部门在实现（销售和订单处理）、保障（问题解决和客户QoS和SLA管理）、账单（开账单和收款管理）等方面识别出重要的不同客户视角。这些领域都由独立的总经理（GM）管理，一位负责业务，一位负责IT。负责实现的业务和IT两位总经理达成了一致意见，他们对客户的视角是正确的。不幸的是，负责保障和账单的总经理们也认为自己的客户视角是正确的。我们将在315一节展开更详细的讨论，这里的要点在于，行业功能组件模型是开始进行行业敏捷性分析的好地方，目的是识别出问题点，驱动SOA策略的治理。
314技术敏捷性
技术敏捷性是根据业务的需要，非常灵活地采用新技术，废弃老技术的敏捷性。许多组织还没有准备好业务敏捷性，应该从关注技术敏捷性开始他们的SOA旅程。如果IT部门是发起SOA的领导者，却发现很难引起业务部门的重视时，尤其如此。获得服务的经验，实现技术敏捷性是SOA旅程中有效的**步，并为将来针对业务服务的SOA能力奠定基础。这里，服务开发生命周期的治理控制是关键，在本章稍后会更详细地讨论。
不幸的是，许多企业允许每个开发部门在为他们的项目选择特定的技术服务和功能时，具有完全控制权。而且，由于兼并和收购（M&A），一个企业可能包含许多种技术功能，这些技术功能都是单独的。因此，这种情况下的集成问题就更加困难。并且，企业没有配合经济的规模来制定和维持与软件供应商之间的合同，就像采购合同应有的那样。与20个每年100万的供应商相比，与一个每年2000万的供应商谈判要更容易一些，更容易得到较大的折扣。
应该通过一个技术生命周期来管理评估、采用和弃用企业中用到的服务技术。这应该是IT治理技术生命周期的增强版。如果IT治理中还不存在这样的功能，SOA治理有必要制定这个生命周期，如图35所示。
图35SOA治理将通过对服务技术管理生命周期建立控制来维护技术的活力 治理需要帮助企业做出决写，在每个领域寻找2个或3个（*多）供应商，持续向他们提供采购资金。其他供应商应该在一段时间内退出。采购部门是这项活动的关键组织机构。所有采购订单（PO）必须通过采购部门的谈判和批准，这将作为一个质量关，向被批准的供应商了解他们的企业技术参考模型。开发部门如果试图在批准的供应商清单之外进行采购，他们的PO就会被拒绝，要么转向一个被批准的供应商，要么在相应的SOA治理控制点处收到一个异常。
315信息敏捷性
信息敏捷性是以可用、灵活的方式，理解、控制和利用公司的信息资产的能力。信息敏捷性通常在SOA策略中被忽视。这是不对的，SOA治理部门需要纠正这一点，因为如果企业SOA策略中包含深思熟虑的、很好实现的信息策略，将带来很大的业务好处。
众所周知，在今天企业的IT功能中，应用集成不是一个小问题。应用程序的开发常常会忽略强制的企业数据模型所带来的好处。COTS（商业上架销售）软件带有它自己的数据模型和隐含的业务过程，IT部门要么必须适应它，要么通过一个代价高昂的过程来调整当前的企业业务模型。当然，这个过程是一个不断带来痛苦的过程。不论是实施一个已经采购的COTS软件的新版本，还是根据业务对消息结构的扩展进行改动，都必须进一步进行调整。
应用集成的常见解决方案一直是点到点的接口解决方案，如图36所示。这样的解决方案，在操作得好的时候，会得到固化的企业业务模型。由于信息和功能模型的复杂性，要想根据其他应用而改变一个应用程序，甚至要想对已有的应用程序进行改动，都会变得代价高且充满风险。对一个系统接口改变可能导致许多改动，以及对所有需要适应这一改动的系统的测试。对于这样的项目，在投入使用之前花费1~2年的时间来分析、设计和测试，并不鲜见。同时，业务已向前发展了，于是IT被认为是不灵活的。 图36如果点到点的解决方案是常态，敏捷性是不可能的更一般地，以下问题被认为是大多数IT部门必须面对的典型问题：
多种技术和平台支持着业务系统。
业务过程模型混杂着人工工作、应用程序代码、人机之间的交互、系统之间的交互。
对一个系统的改动通常意味着在许多不同层面上的改动和对许多其他系统的改动。
没有一个完全能工作的解决方案能够与其他功能性解决方案协作。
在企业内部署一个私有的集成解决方案是复杂的、昂贵的、耗时的。
整个企业没有单一的数据模型、业务模型或过程模型，更少有这样的模型跨越企业边界。
归根到底，SOA就是提供一些IT系统，让业务能够在需要改变时灵活地改变。SOA着重强调互操作性，这是它的关键原则之一。互操作性指利用不同技术和平台部署的服务能够互相通信。第7章更详细地讨论了信息模式和信息服务的使用。
在SOA的旅程中，通过提出要求并给予指导，SOA治理可以帮助促进集成敏捷性。企业数据部门负责创建信息标准，SOA开发生命周期治理验证这些标准得到遵守。
数据拥有制是SOA治理的另一项关键考虑。许多不同的业务部门和IT部门都会声称自己是主要用户，因此拥有某些数据。SOA治理应该为每一个主要的信息领域确定其业务拥有者。这在将来会很重要，因为需要做出艰难的业务决定，以实现这些信息并实现信息敏捷性。
316组合管理
A35组合管理负责分析和选择企业中需要执行的计划和项目，目的是管理和控制这些计划。组合是一种机制，目的是实现企业业务战略中的要点。它包括一组选择的、批准的、持续发展的计划，与组合机制中的组织机构部分互相配合，以实现企业业务战略中的所有目标或部分目标。
针对组合管理的SOA治理涉及许多方面，包括前面提到的业务敏捷性、技术敏捷性和信息敏捷性。组合的结构应该覆盖到所有的企业计划。相关的业务案例应该进行复查和验证。有必要制定和批准计划，不断调整方向，通过阶段性的评估和复查预期目标的实现来完成控制。
大多数大型组织都采取年度预算的制度。这是SOA治理必须参与的工作。建议的项目必须进行评估，给出它们对改进组织的灵活性方面的优先级。用于决定哪些项目可行的投资回报率计算或类似的计算必须进行调整，将灵活性因素考虑在内。通过这种方式，组合将随时间进行调整，以支持更多的敏捷性项目。
32针对SOA进行组织
虽然有时候SOA确实会“有机地”成长，但是如果没有一个部门来专门负责其愿景和效力，这种方式注定会停下来。
321组织
如果企业中已有一个部门负责战略和战术愿景，在业务部门和IT部门之间有很好的接口和合作，执行业务案例分析和财务分析，有一个组合监管的角色，那么这个部门也应该负责SOA治理。如果还没有这样的部门，就应该创建新的治理组织（参见图37）。调查表明，这个部门的名称可以是SOA卓越中心（CoE）、集成竞争力中心（ICC）、集成卓越中心（ICE）和计划管理部（PMA）。它叫什么名字并不重要，重要的是您有一个部门负责SOA治理。我们在本章的后面使用“卓越中心”这个名称。
这个部门有以下任务：
负责SOA，并在SOA方面与所有IT部门和业务部门合作。
执行SOA治理任务，而不是SOA实现任务。
注意有这种可能，在SOA旅程的初期，某些服务能力在IT部门还不存在（如服务设计者技能、服务实现技能、SOA技术技能，甚至是企业架构技能）。在这种情况下，专家应该做一些示范，并借调到实现SOA服务的IT项目中。
领导管理和创建SOA治理原则、政策、过程的实现，指导SOA旅程。
管理SOA战略、战术和操作过程。
监控SOA计划的重要性，领导制定决定，包括改进技能、确定新的职责和职责的变更，改进SOA计划的成熟度和企业的灵活性
CoE应该有一个CoE掌舵委员会负责管理。它应该包含来自不同开发领域、企业架构部门、计划管理官员（PMO）和业务等方面的利益相关者。如果不符合SOA治理策略的项目未能得到CoE的批准，应该作为一个例外向这个部门提出申请。
SOA执行掌舵委员会是负责监管和指导SOA计划的机构。掌舵委员会有一个执行发起人，他是企业中SOA工作的领导，与CIO、董事会和公司的其他领导协同工作。这个人有时叫做首席转变官或SOA**人，他应该拥有经验、远见、热情，在业务部门和IT部门中都受到尊敬。
架构复查委员会负责在SOA开发周期中复查所有的项目，验证所有强制实现的SOA政策得到了遵守，并且验证在每个项目中复用了已有的服务，创建了新的服务。
图37SOA组织之间如何互动322角色和职责
要在企业中实现SOA，应该考虑某些角色和职责。并非所有这些角色和职责都与您的企业有密切关系，但是您可以参考并进行相应的调整。根据SOA的工作量规模和资源限制，某些不同的角色可以由同一个人来承担。大部分职位会在下属部门中，但某些职位会在SOA CoE中，特别是在SOA实现的**年，或者是那些为企业的控制带来更多好处的角色。我们发现，下面的SOA角色和职责值得作为考虑的起点：
CoE领导者是企业中SOA治理功能的领导。CoE领导者负责确保SOA活动发生，但通常不会亲自执行这些活动。他们负责为企业监管SOA。这意味着为面向服务的方式领导创建原则、政策和过程，并确保它们得到遵守。
服务架构师是服务技术专家。他们负责在企业中工作，提供服务技术方面的专业知识，指导和调整项目，以满足企业要求的SOA治理和技术标准。
服务设计是解决方案架构师，负责创建一致和完整的服务设计，满足所有技术和业务的需求和标准。这个角色可能开始是CoE的一部分，提供一致性和专业知识，但是*终应该迁移到下属部门中去。
服务开发者是软件工程师，他们根据服务设计给出的服务规格说明来创建服务。
服务测试者是测试工程师，他们创建服务测试计划，并验证服务能正确地工作，包括非功能需求。他们知道服务在整个服务层次结构中的位置，验证服务的变更不会对其他服务角色产生扩散的影响。
服务注册者是组织机构中服务资产的保管员。他们与架构团队和开发团队一起工作，确保服务敏捷性策略，并确保服务处于正常的工作状态。
SOA治理专家的日常职责是监管SOA治理任务，包括验证治理政策和过程，以及监管SOA工作的整体效力。如果没有这方面的工作，团队将很快丧失继续SOA旅程所需的效力。尽管自动化的工具可以帮助治理，但人的参与是不可少的。
业务服务领导者负责业务服务策略的效力、分析和创建。通常，这是一个业务人员，对IT有着很好的理解，或者是具有业务主题专业知识的IT员工。
业务过程分析师对整个业务过程和单个任务进行建模和优化。因为所需业务知识的深度，业务分析师通常专攻少数专门的业务活动领域。
业务过程开发者根据业务过程模型，创建可执行的业务过程。这些过程在合适的环境中执行，通常采用ESB。
33SOA治理的考虑
作为SOA治理的实践者，我们必须采取更有组织的方式来处理治理的艺术，尽可能地将它变成科学。为了做到这一点，我们必须考虑定义一种治理的成功范式，在本章的后面部分中使用。在治理的成功范式确定之后，我们将更详细地讨论一些治理组件，包括服务开发生命周期等。您也可以在本章介绍的治理组件之外添加额外的治理组件，这里描述的治理成功范式本质上是一个可复用的治理框架，同样也适用于您添加的治理组件。它将帮助您导出政策、标准、责任方、过程、机制和测量指标，您需要这些来治理本章中没有提到的那些治理组件。
首先，我们需要从一些治理术语的定义开始：
被治理的组件——标识治理所需的具体能力。
政策——一个明确的行动过程或方法，从其他的可选方案中选出，目的是对目前和将来的决定提供指导和判据。政策将应用于被治理的组件。
标准——由权威机构、客户建立，或者是类似模型或示例的承诺。被治理的组件必须遵守一致同意的标准。
MerriamWebster Online Dictionary, Policy wwwmwcom/dictionary/policy.
MerriamWebster Online Dictionary, Standard wwwmwcom/dictionary/standard. 责任方——一个人或一组人，负责管理被治理的组件。我们必须清楚每个组件的责任方是谁。
过程——执行一个任务的特定方法。过程确定了组件如何被治理。
机制——执行一个任务的特定方法。资产、方法学或*佳实践通过机制产生作用，帮助组件的治理。
测量指标——测量的标准。重要的是要准备好被治理组件是否成功的测量标准。
MerriamWebster Online Dictionary, metric wwwmwcom/dictionary/metric.331SOA治理范式
治理实践者有必要准备一个范式，一致地应用于被治理的实体。图38中的治理实体-关系图用到了我们前面讨论的定义，该图已经成功地应用于不同的治理咨询任务中。它似乎是一个值得参照的经验性范式。您可能决定对它做一些修改，但这是一个常用的起点。
图38治理范式332SOA治理检查清单
我们已经有了治理定义和治理范式，接下来就可以考虑SOA治理的每个不同治理组件。我们利用SOA治理范式来提供一个标准框架，讨论每个组件。为了提供一个有意义的上下文环境，我们使用“理想通信”作为被治理的企业。您的企业肯定会不同，但这些例子仍是实际的、有用的。
1服务开发生命周期（SvDLC）
这个领域的考虑包含对系统进行复查和强制实现一致同意的严格政策和过程，它可能涉及针对特定系统或项目的服务，也可能不涉及。不幸的是，项目及其开发团队常常为了满足项目的*后期限而走捷径。尽管这些捷径提供了短期的好处，但从长期来看付出了代价，在长期SOE好处上打了折扣。在SvDLC中及早确定这些问题对于按时交付和按预算交付是极为重要的。遵守一份SvDLC控制手册尤其重要，执行顺序如下：
（1）解决方案复查——解决方案架构师将创建一份解决方案架构文档，确定解决方案的实现方式和高层设计，包括识别项目中要创建的服务或要复用的服务。这是优化服务计划和项目开发计划的重要时刻，按以下方式进行：
a) 如果有机会复用已有的、还未被用过的服务，架构文档就应该更新。如果架构师预期到任何对已有服务的消息接口的改变，他们必须注明所有的向后兼容问题和服务的版本要求。
b) 如果有机会创建额外的服务，应该在这里关注。
c) 应该特别注意接口文档满足所有信息标准和技术标准。
d) 应该进行项目主要风险评估，并确定和选择减小风险的可选方案。
e) 验证业务需求得到满足。负责集成测试的测试团队应该复查解决方案架构文档和需求澄清文档，并根据需要进行修改。
f) 应该向服务注册者通知新的服务或服务的变更。
（2）服务设计复查——服务设计文档应该经过验证，然后再承诺允许的开发资源：
a) 服务规格说明应该切实遵守所有政策和标准。
b) 服务设计文档必须经过验证，符合解决方案架构文档，包括所有业务方面的、信息方面的、技术敏捷性方面的要求。
c) 所有关于服务提供者和消费者的考虑都必须关注，包括非功能需求（NFR）。
d) 需求可追踪性应该经过验证。负责集成测试的测试团队应该复查并确保他们理解了服务的设计，并能够对服务执行必要的测试。运行时刻策略应该进行复查。例如，具体的WS策略应该经过验证是足够的。
e) 安全性设计应该关注，确定它遵守*小的安全基线标准。
（3）开发到测试的复查——从开发过渡到集成测试包括：
a) 开发者将复查开发的范围，包括接口和消息，并提交已执行的服务和组件的单元测试。
b) 负责集成测试的测试团队将复查他们的集成测试计划，并征求反馈意见。验证服务的测试计划足以测试服务的设计、接口，以及与其他服务或应用的集成。如果改变了原有的服务，必须确保有足够的回归测试。
c) 需求可追踪性将进行复查。
（4）测试到验收的复查——从集成测试过渡到用户验收测试包括：
a) 测试者与用户一起复查他们的测试结果，包括解决方案、集成和性能测试。
b) 用户将复查他们的用户验收测试计划，并征求反馈意见。
c) 需求可追踪性将进行复查。
（5）签署证书——用户已验证需求得到满足：
a) 注册者接到通知，更新服务注册表。
b) 注册者确保向后兼容性，以及确保对已有服务的消费者使用了正确的版本。
c) 注册者验证运行时策略的元数据在服务注册表中得到了正确反映。
注意IBM的WebSphere服务注册和库会执行本章提到的所有注册功能，是SOA治理的关键工具。
理想通信公司使用下面的SvDLC（参见图39）。图39为理想通信公司修改过的SvDLC现在，让我们将采用的SvDLC和控制放到图38中的SOA治理范式框架中去，在本章前面曾对这个范式框架进行了讨论。结果见表31。表31SvDLC治理组件表
责任方架构复查委员会（ARB）政策所有项目都必须经过一次SvDLC控制复查的检查，目的是考虑复用已有的服务，并考虑他们是否应该创建新的服务
项目必须经过SvDLC复查，并满足所有当前接受的判定条件。所有例外必须经过ARB的批准
在服务部署到生产环境中之前，测试计划和结果必须经过复查和验证标准SvDLC控制手册、业务敏捷性服务计划、技术敏捷性服务计划、信息敏捷性计划、IT SOA设计标准、IT信息设计标准、IT测试计划设计标准过程使用SvDLC控制手册。安排复查时间，由项目管理官（PMO）来领导，和项目PM一起创建一份文档，记录结果。这份文档将放在SOA治理库中，以备将来参考机制复查由PMO来安排和领导，和PM一起创建一份文档，记录结果。这份文档将放在SOA治理库中，以备将来和ARB一起参考测量指标在分析中复用和创建的服务数目，在每个项目的设计中对服务改动的数目，每个项目中对测试用例改动的数目，在集成测试中发现缺陷的数目和严重程度，在验收测试中发现缺陷的数目和严重程度
2服务生命周期
服务生命周期的概念与企业使用的标准的开发方式有一点区别，因此需要单独讨论。参见图310中服务状态生命周期的例子，本节将使用这个例子。
图310“理想通信公司”使用的服务生命周期
可复用的服务是实际创建SOA的核心。正如在31一节中讨论的那样，服务的识别应该来自于业务策略的视角和项目的需要。所有因业务敏捷性、技术敏捷性、信息敏捷性计划而识别的服务，都应该放到服务注册表中，标识为“已计划”状态。因为服务注册表将作为企业已识别和已计划服务的唯一来源，项目规划者应该通过查看注册表来找到项目应该复用或创建的、已列入计划的服务。类似地，解决方案架构师将在服务注册表中看到他们打算复用的服务的状态，这种能力让他们能够评估服务在项目中的适用性。
当包含服务的解决方案架构确定之后，服务将进入“完成解决方案架构”状态。类似地，在通过SvDLD的每一个质量关时，服务注册者将更新服务注册表中服务的状态。
服务反映业务，所以当业务改变时，服务需要进行相应地改变。但是服务已有一些用户，改动需要明智地进行，不能干扰原有用户的正常运行。因此，原有用户对稳定性的要求与添加新功能的用户的需求产生了冲突。
服务版本支持这些相互冲突的目标。它让满足已有服务的用户继续使用未改变的服务，同时让服务演进，以满足具有新需求的用户的要求。当前的服务接口和行为被保留为一个版本，新的服务作为另一个版本引入。版本兼容性可以让希望调用某个版本的调用者去调用另一个不同的、兼容的版本。
要做到“向后兼容”，必须验证原有的消息接口schema、传输绑定，或未改变的操作。在WSDL文档中添加新的XML schema类型、传输绑定或操作可以支持向后兼容。如果服务的新版本不能够保持向后兼容（这应该是例外，而不是规则），服务注册者必须特别注意复查和考虑该服务当前所有的调用者。在所有情况下，当新版本创建好之后，旧版本都进入到“避免使用”状态。
SOA治理应该确保在服务应该维护的版本数目方面的政策。*好是*多2个版本，但3个版本也是可以接受的。当一个服务的版本*终停止使用时，它就进入“停止使用”状态。
现在，让我们将服务生命周期放到图38所示的SOA治理范式框架中，在本章前面曾对这个范式框架进行了讨论。结果见表32。表32SvDLC治理组件表
责任方服务注册者政策在成功通过SvDLC控制关后，更新服务的状态。服务版本必须很好地控制，确保向后兼容，尽可能少地出现例外情况。所有不向后兼容的服务变更都是一次“主版本”变更，如从12版到20版。如果服务变更是向后兼容的，就是“小版本”变更，如从12版到13版标准SvDLC控制手册，业务敏捷性服务计划，技术敏捷性服务计划，信息敏捷性计划，服务生命周期过程SvDLC方法与服务生命周期状态集成在一起机制服务注册表和服务注册表提供的管理能力测量指标处于每种状态的服务数目，有一个版本、两个版本和多于三个版本的服务的数目
3业务敏捷性
SOA治理必须确保在创建业务敏捷性时有效力。
理想通信公司针对它的业务敏捷性SOA治理模型，实现表33中的内容。表33业务敏捷性表
责任方SOA执行掌舵委员会和CoE政策为项目指定组合管理优先级，这将促进声明的业务敏捷性策略。业务敏捷性策略每年至少重新考虑并更新一次标准TMF的eTOM和Telco Application Map（TAM）是业界标准的业务运营图，理想通信公司用它来分析业务敏捷性，所有有关敏捷性的建议必须对应到这些标准。经过批准的业务敏捷性计划将成为制定IT组合优先级的标准过程业务敏捷性任务工作组将每季度聚会一次，包括理想通信公司全球的业务和IT负责人。工作组向SOA执行掌舵委员会报告，委员会将进行复查，批准、拒绝或修改工作组提出的每一项建议。PMO将利用业务敏捷性计划来为理想通信公司的项目提供优先级机制实现了TMF eTOM和TAM的行业建模软件测量指标计划创建的业务服务数目，过去一年间发起的业务服务数目
4技术敏捷性
SOA治理必须确保创建过程的技术敏捷性的效力，并确保正确地实现。具体来说，SOA治理必须验证企业中必不可少的部门遵守了技术敏捷性策略和标准，采取了相应的措施。
“理想通信公司”针对它的技术敏捷性SOA治理模型，实现表34中的内容。表34技术敏捷性表
责任方企业架构部门和CoE，CoE掌舵委员会政策促进技术敏捷性策略的基础设施项目将被赋予优先级。所有项目都要遵守硬件和软件标准，标准之外的任何采购都视为例外，必须由首席架构师批准标准经过批准的技术敏捷性计划过程技术敏捷性任务工作组将每季度聚会一次，包括理想通信公司全球的业务和IT负责人。工作组向企业架构首席架构师报告，他进行复查，批准、拒绝或修改工作组提出的每一项建议
所有的PO都要经过采购部门的复查，以满足批准的技术敏捷性计划的要求。例外必须经过CoE掌舵委员会的批准
CoE将定期复查SOA开发周期，验证技术服务计划得到正确地推进机制自动化的采购复查软件测量指标计划创建的技术服务数目，过去一年间发起的技术服务数目，因采购复查而改变的PO数和节省的金额，例外的PO数目和类型
5信息敏捷性
SOA治理必须确保创建过程的信息敏捷性的效力，并确保正确地实现。具体来说，SOA治理必须验证企业中必不可少的部门遵守了信息敏捷性策略和标准，采取了相应的措施。
理想通信公司针对它的信息敏捷性SOA治理模型，实现表35中的内容。表35信息敏捷性表
责任方企业架构部门和CoE政策促进信息敏捷性策略的项目将被赋予优先级标准TMF共享的信息数据（SID）将用作企业数据模型的起点。对企业数据模型的增补由企业架构部门批准过程信息敏捷性任务工作组将每季度聚会一次，包括理想通信公司全球的业务和IT负责人。工作组向企业首席架构师报告，他进行复查，批准、拒绝或修改工作组提出的每一项建议。CoE将定期复查SvDLC，验证批准的技术服务计划得到正确地推进机制在平衡计分卡和每月复查中加上信息敏捷性测量指标计划创建的信息服务数目，过去一年间发起的信息服务数目，使用企业数据模型的服务和应用数目
6组合管理
SOA治理必须确保选择的项目能够促进企业在灵活性方面的战略意图。这种意图在前面讨论的业务、技术和信息灵活性计划中有明确的展示。另外，SOA治理还必须确保有一个结构来提供全球计划管理，通常由一个计划管理办公室（PMO）负责实现。SOA治理部门应该与PMO密切合作，确保他们有工具、过程和政策支持，以正确完成他们的工作。理想通信公司针对它的组合管理SOA治理模型，实现表36中的内容。表36组合管理表
责任方PMO和CoE掌舵委员会政策项目的总体组合必须促进企业的敏捷性。所有涉及多个开发VP的项目将由PMO来管理标准批准的业务、技术、信息敏捷性计划过程PMO将以季度为单位执行组合计划过程，和财务部门一起，利用企业标准的ROI方法计算出ROI。这个ROI是考虑到敏捷性计划的。PMO将创造一种企业范围的项目报告机制，并每周与CoE掌舵委员会一起复查机制利用计划管理工具和软件来辅助追踪计划并生成报告测量指标按时交付的计划数目，按预算交付的计划数目，创建的业务服务和信息服务的数目
7择源
择源，在SOA的上下文中，强调的是某个服务如何被创建，它是在企业内部创建的、外包的、还是采购的。SOA治理负责确保有政策和过程来控制如何做出这个决定。如果让他们自行决定，开发部门就会认为只有他们才能构建正确的软件。但是，这忽略了业界的趋势，即全世界的人力资本正在帮助创建各种可复用的服务，适用于许多的企业。好的服务注册表将提供连接到外部的“统一描述、发现和集成（UDDI）”库，这些库中包含了从其他业务中暴露出的服务的技术信息。这些服务通常不是企业的核心业务（例如，处理信用卡交易），*好是购买这些服务，让宝贵的资源去开发那些能够提供竞争优势的领域服务。
理想通信公司针对它的择源SOA治理模型，实现表37中的内容。
8业务价值
项目批准通常是基于增收和节支的ROI分析。“业务价值”负责弄清楚在项目投入生产环境后，打算实现的价值是否确实实现了。企业财务部门通常负责此事。因为SOA是为业务提供敏捷性和价值，所以创造业务价值就变得更重要。业务价值方面的信息将用于未来的组合管理。SOA治理通过确保使用正确的测量指标来确定获得的业务好处，从而帮助实现这一过程。SOA建模和监控工具在这方面有丰富的功能。
理想通信公司针对它的业务价值SOA治理模型，实现表38中的内容。表37择源表
责任方解决方案架构师和CoE政策进行市场调查并确定是否已有服务或软件包能够满足我们的需要
确保供应商在财务方面没问题，在这个领域中有良好的洞察力，价格合理（每次采购）
如果评估已有的代码作为服务源，要确定业务功能是否相对比较模块化（好），还是“搅成一团的代码”（不好）
如果评估一个已有的应用程序，要确定应用程序功能是否相对地与数据输入/输出和其他非应用程序实体分离
如果评估一个已有的应用程序，要确定从业务的视角来看是否足够有意义，并具有可以复用的处理逻辑。确定提取这段业务逻辑的投资是否少于*初投资的20%
如果以上的五点考虑中有三点的答案是“是”，就采用。否则，如果只有一两点的答案是“是”，就重新构建标准采购标准过程利用择源政策，开发部门将针对购买还是构建进行评估并创建他们的计划
作为服务使用复查的SvDLC的一部分，开发部门计划可能因企业SOA战略而重写
开发部门可以请求择源政策的决定，并向CoE掌舵委员会要求例外处理机制UDDI查找，自动调查因特网上匹配的服务测量指标复用、购买、构建的服务数目
表38业务价值表
责任方PMO和CoE政策来自业务案例的业务价值参数将被建模和监控，并用在将来的组合管理决定中标准针对这个项目的业务案例过程针对提供资金的每个项目，PMO将识别业务案例中包含的业务价值参数，并将它们告诉给项目团队，以便在建模和监控中包含这些参数。PMO将要求并检查，验证包含这些参数将作为验收测试计划和后续检验过程的一部分机制针对建模和监控的中间件测量指标业务价值参数将在平衡计分卡中报告
9满足法规
许多业务都至少有一些行业或政府法规需要满足。例如，电信行业在美国有联邦通信委委员会（FCC），在英国有通信处（Ofcom），萨班斯•奥克斯利法案影响到所有美国的上市公司，不论是哪一国的公司。在国际资本框架要求方面，银行受到新巴赛尔协议的约束。法规则在不断变化，能够很容易提供满足法规的证明是敏捷业务的一个重要方面。
SOA治理必须确保所有业务都完全满足相关的法规。简而言之，这要求有一份法规的检查清单，并在SvDLC过程的正确时候告知所需的设计和实现。
理想通信公司针对它的满足法规SOA治理模型，实现表39中的内容表39满足法规表
责任方法律部门，架构复查委员会和CoE政策所有服务必须支持企业需要遵守的规则和法律标准法律部门提供一份批准过的法规检查清单过程在设计复查时，必须对照批准的法规清单进行检查。检查清单上的每一项必须要么与正在进行设计复查的服务无关，要么已经由设计满足机制法规检查清单的小结和服务设计复查结果将提供给审计复查测量指标支持法规需求的服务数目
10安全
安全很难，但所有应用程序都需要考虑。功能需要限制给授权用户使用，数据需要保护免受干扰。SOA治理必须确保存在一份服务安全标准，并且得到正确的遵守。对服务的访问必须受到控制，只给授权用户使用。用户身份必须传送到服务中，用于对数据访问的认证。
对于SOA来说，这一点更重要，也更难，因为服务事务的本质和传统的仓库式应用程序有所不同。后者倾向于在一个防火墙内安全地完成所有的工作。但是服务具有更为分布式的架构，整体安全架构不能够进行简单的假定。通常，必须选择基于安全协议的消息机制作为标准，然后通过SOA治理来强制实现。这包括认证、授权、加解密和不可抵赖性等方面的安全。
理想通信公司针对它的安全SOA治理模型，实现表310中的内容表310安 全 表
责任方安全部门，企业架构部门和CoE。ARB政策所有服务必须按照安全部门的要求，支持*小的基线安全策略。必须对SOA安全定期审计。整体服务安全计划必须实现，并定期更新。安全计划必须包括使用运行时的安全控制点标准安全部门的*小基线安全标准过程在设计复查时，应该针对遵守*小安全基线对服务进行评估。服务必须通过这项评估才能结束设计复查
在设计计划复查时，测试计划必须表明它将测试安全需求
安全部门将创建、实现，并定期更新针对分布式服务环境的安全策略。这份计划将由ARB复查、修改和批准机制进行自动化安全检查的软件将有助于安全测试。自动化的安全监控硬件和软件测量指标检查或发现的安全违反次数将记录在平衡记分卡中
11服务所有权
所有权这个词意味着拥有或控制一项财产。服务提供者和服务消费者的概念在SOA中是基本概念，也是考虑所有权时的重要概念。IT部门通常不习惯使用一项服务，而对它没有开发控制权。服务消费者这一方对服务的依赖关系是SOA过程中小矛盾的来源之一。服务提供者（所有者）总是对问题解决方案的执行和业务用户提出的修改负有一定的支持责任，但是现在第三方进入了问题解决方案和维护的关系之中（即服务消费者）。
这是围绕服务所有权过程要有好的治理的原因，这对于SOA很重要。服务提供者对服务消费者有一定的义务。服务是与一份契约绑定的（服务的规格说明），这样服务的消费者就知道他们得到的是什么，并知道服务提供者是他们可以信任的。服务所有者有责任保证正确性，允许/禁止执行、使用或访问每项服务或过程。有必要建立一个过程来处理服务再使用的请求、问题解决方案和服务修改。
SOA治理也必须确保有一个良好的过程，在需要时改变所有权。如果A部门拥有一个服务，但不能够在几年后为B部门创建一个新版本，那么B部门还有什么理由去使用这个服务呢？有可能当一个部门要求复用一个不是自己拥有的服务时，活动的水平和当前业务过程要求改变所有权。当前的所有者可能会抵制，所有围绕所有权变更事先建立起治理政策是有好处的。
理想通信公司针对它的服务所有权SOA治理模型，实现表311中的内容。表311服务所有权表
责任方PMO和CoE政策解决方案架构将指定新服务的所有权
已有服务的所有权变更应该在需要时由CoE执行
服务所有者负责支持拥有的服务的运行，支持服务消费者
服务所有者负责修改拥有的服务标准无过程新服务的所有权将在项目启动时决定。PMO办公室将领导这一过程，并与CoE协作
如果存在争议，CoE掌舵委员会将听取请求，并做出*终裁决
如果开发部门不能够及时提供新版本升级，或不能够及时提供支持，就会触发已有服务的所有权变更，这由CoE决定。所有争议将由CoE掌舵委员会*终裁决机制服务注册管理报告测量指标拥有服务的不同开发部门的数目将反映到平衡记分卡中
12服务资金支持
服务资金支持考虑的是如何为服务开发提供资金，以及如何针对服务消费对服务的复用进行收费并奖励服务提供者。存在三种可能的收费方式：按服务复用一次性收费，按每次使用收费，或者开发部门从项目资金中收到所需的资金。
理想通信公司针对它的服务资金支持SOA治理模型，实现表312中的内容。表312服务资金支持表
责任方IT财务部门和CoE政策服务提供者组织机构从项目资金中拿出一部分来支持创建*初的服务。修改的资金来自在于要求修改的项目标准将使用财务部门的标准过程部门提供的资金支持将由财务部门追踪机制财务部门的报告测量指标复用服务的数目
13沟通
对于IT部门和业务部门来说，服务方式通常是主要的范式转变。具体来说，IT部门会觉得将要发生的变化对他们是一种威胁，这种想法很自然。执行管理层必须不断宣传SOA方式的好处。重要的是CoE部门对项目的领导，创建并实现一份沟通计划，对组织机构进行教育和领导。
理想通信公司针对它的沟通SOA治理模型，实现表313中的内容。表313沟 通 表
责任方CoE和公司沟通部门协作政策对于SOA方式如何影响组织的重要性进行充分的沟通标准将使用公司的沟通标准过程在IT部门内部，定期举行（每月一次）1~2小时的全体会议，解释当前服务架构、技术或过程的某个方面。和IT开发者一起检查感兴趣的领域，然后举行午餐会来解释和展示这个领域。将SOA的信息放在公司内部网站上。与业务服务团队开会，解释服务的方式
找到一个“明白这个道理”的业务服务人员，尽量对他提供帮助，使其成为“模范”。自上而下，自下而上地在整个组织内部实现一份沟通计划。这包括业务单位和子业务单位。CoE主管每个月和每一个业务VP举行1小时的一对一会晤，讨论他感兴趣的SOA旅程的一些方面机制公司内部网，公司新闻邮件测量指标在平衡计分卡上包含沟通有效性调查问题
14教育和现场指导
通常，在新实施SOA的企业中，人们对服务的概念或业界标准是不熟悉的，这些业界标准对SOA来说很重要。重要的是对开发团队或其他希望获得好处的人提供培训和现场指导。SOA教育通常有几种不同的途径，包括业务分析师技能、架构师技能、应用开发者技能、集成开发技能、解决方案部署技能，以及解决方案管理技能。
如果企业有培训部门，应该向他们咨询，要求提供更多的基于服务的培训。这应该包括服务的概念，以及具体的技术培训（如XML、SOAP、WSDL和WSI）。
CoE中应该包含服务专家。这些资源需要利用，应该对项目成员进行在岗培训。对关键开发者提供一对一的现场指导或管理将加快服务计划。许多企业都有明确的现场指导计划，可以用于这个目的。如果没有，CoE应该建立一个服务现场指导计划，并提供给整个企业。
理想通信公司针对它的教育和现场指导SOA治理模型，实现表314中的内容。表314培训和现场指导表
责任方培训部门和CoE政策创建一份SOA培训计划，结合现场指导、教室培训、自主的在线培训和外部的教室课程。经理将为每个员工创建一份年度培训计划，根据预期的员工职位来利用这些课程。这份培训计划应该定期复查，并在经理和员工之间达成一致意见标准HR培训标准，批准的课程过程复查员工信息，与部门的经理一起，确定资助的培训课程，确定参加培训的员工
“培训培训者”——找到*好的员工和培训，然后影响整个组织机构
合适的时候，采用在线培训
现场指导——现场指导计划将评估技能水平，让有经验的SOA实践者指导没有经验的实践者
机制在线培训课程、教室培训、OTJ培训测量指标培训和现场指导进展将作为企业的平衡记分卡的一部分
333运营和监控
服务的方式将对当前企业采用的运营过程产生影响。SOA治理必须考虑这些影响，和运营部门一起关注它们。在SvDLC末端的服务认证质量关是移交操作信息，并根据运营支持需要进行培训的好时机。
复合应用程序包含了多个服务，只有这些服务可靠时，它才可靠。因为多个复合应用可以共享一个服务，所以单个服务失效可能影响到许多应用程序。必须定义服务层协议（SLA）来描述消费者可以信赖的可靠性和性能。服务提供者必须通过监控来确保他们满足了定义的SLA。
另一个相关的主题是问题检测。当一个复合应用程序停止工作时，也许很难确定原因。重要的是不仅要监控每个应用程序在正常运行，而且要监控每个服务（以服务提供者来分组）和每个提供者在正常工作。单笔业务交易包含的服务之间的相关事件是很关键的。
这样的监控有助于在问题发生之前检查和预防问题。它可以检测负载的不均衡和中断，在问题变得严重之前提出警告，甚至可以尝试自动解决问题。它可以测量使用量和时间的关系，帮助发现服务正变得越来越受欢迎，这样可以提升它们的负载能力。
334SOA迁移计划
对于正经历SOA旅程的所有企业来说，一项*佳实践就是制定一份迁移计划，由利益相关者进行复查并同意。企业中难免会有一些拒绝者，如果首席级别的主管在文档中说了应该这样，这些拒绝者就很难反对。迁移计划有助于集中所有的里程碑、沟通信息和信心鼓励的内容，这样SOA计划和SOA治理部门就有了一份深思熟虑的计划。
下面的例子是理想通信公司是针对CoE的一部分迁移计划。当然，您的计划会更完整，但图311中的迁移计划可以作为一个起点。图311SOA治理迁移计划34小结
成为真正的SOE决不会偶然发生。组织机构必须有此意愿并对此关注。必须有领导。必须有清晰的角色和职责。必须有深思熟虑的政策和过程，并实施。换言之，必须有SOA治理。
35developerWorks的文章链接
A31 Portfolio Management, an Introduction
wwwibmcom/developerworks/rational/library/oct05/hanford/indexhtml
A32 A Case for SOA Governance
wwwibmcom/developerworks/webservices/library/wssoagovern/
A33 EA & Services Oriented Enterprise (SOE), Services Orientation, Hype of Hope? Structuring the Enterprise around Services
wwwenterprisearchitectureinfo/Images/Services%20Oriented%20Enterprise/EA_ServicesOrientedEnterprise1htm
A34 Core Business Architecture for a ServiceOriented Enterprise
wwwresearch ibmcom/journal/sj/464/nayakhtml
A35 OECD Principles of Corporate Governance
wwwoecdorg/dataoecd/32/18/31557724pdf36参考资料
Hanford, M IBM developerWorks, Portfolio Management, an Introduction, October 15, 2005 wwwibmcom/developerworks/rational/library/oct05/hanford/indexhtml
Mitra, T IBM developerWorks, A Case for SOA Governance, August 16, 2005 www ibmcom/developerworks/webservices/library/wssoagovern/
Nayak, N et alIBM System Journal, 46:4, 2007, Core Business Architecture for a ServiceOriented Enterprise wwwresearchibmcom/journal/sj/464/nayakhtml
OECD, OECD Principles of Corporate Governance, 2004, wwwoecdorg/dataoecd/32/18/31557724pdf
Schekkerman, J Institute for Enterprise Architecture Developments, October 16, 2007, EA & Services Oriented Enterprise (SOE), Services Orientation, Hype of Hope? Structuring the Enterprise around Services wwwenterprisearchitectureinfo/Images/Services%20Oriented%20Enterprise/EA_ServicesOrientedEnterprise1htm
执行SOA-SOA实战指南 作者简介
p>作者简介：
Norbert、Bieberstein是IBM解决方
案架构师，负责沟通SOA在提供价值
方面的进展。他在IT和 计算机科学方
面的经验超过27年。
Robert G。Laird是旧M的IT架构师。
属于SOA高级技术组。自2006年5月
以来，为IBM全球范围的客户提供咨
询，主要领域是SOA治理和SOA架
构。
Dr．Keith Jones目前是IBM执行lT架
构师，属于SOA高级技术组。主要关
注为前沿客户提供面向服务的架构和
实现。他在IT行业有30年的经验。
书友推荐
- >
有舍有得是人生
有舍有得是人生
¥31.5¥45.0 - >
姑妈的宝刀
姑妈的宝刀
¥11.4¥30.0 - >
山海经
山海经
¥20.4¥68.0 - >
中国人在乌苏里边疆区:历史与人类学概述
中国人在乌苏里边疆区:历史与人类学概述
¥24.0¥48.0 - >
【精装绘本】画给孩子的中国神话
【精装绘本】画给孩子的中国神话
¥17.6¥55.0 - >
诗经-先民的歌唱
诗经-先民的歌唱
¥15.1¥39.8 - >
回忆爱玛侬
回忆爱玛侬
¥10.5¥32.8 - >
名家带你读鲁迅:故事新编
名家带你读鲁迅:故事新编
¥13.0¥26.0
本类畅销
-
2022图书×抽奖盲袋
¥9.9¥25 -
2023读书月阅读盲盒——天黑，闭眼，刀谁？
¥42.3¥158 -
-
2022读者节纪念徽章-三星会员专属
¥45¥45.6 -
2023读书月阅读盲盒——我什么场面没见过？
¥42.3¥158 -
2023读书月阅读盲盒——去码头整点什么薯条？
¥42.3¥158
