内容


SOA 治理:如何迎接 SOA,第 2 部分

治理生命周期

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: SOA 治理:如何迎接 SOA,第 2 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:SOA 治理:如何迎接 SOA,第 2 部分

敬请期待该系列的后续内容。

服务生命周期和治理

服务是面向服务体系结构的核心。因此,SOA 治理特别关注服务的治理。在本节中,我们定义服务的生命周期并讨论建立治理的基本任务。

服务生命周期概述

所有服务都会经历一系列阶段:首先是形成最初的概念,然后依次经过分析、设计、开发、测试、部署和最终的退役,见图 1:

图 1. 服务生命周期状态图
服务生命周期状态图
服务生命周期状态图

这实际上是一个状态转换图,其中定义了所有有效状态,为了从一个状态转移到下一个状态,必须执行特定的活动。

与所有模型一样,这是实际情况的简化视图:例如,没有 “正在开发” 这样的中间状态,因为这种状态的定义是主观的,意义不明确。

但是,这个开发模型很好地定义了 SOA 开发过程:

  • 可以明确地定义导致状态转换的每个活动,然后把活动分配给具备适当技能的人员或团队反复执行,这样就可以保持一致性。
  • 因为明确地定义了稳定状态,所以可以通过质量保证 (QA) 检查(有时候称为 ‘控制门’ 或 ‘控制点’)判断每个活动的执行质量是否足够好,从而确保可靠地迁移到目标状态。
  • 因为活动是可重复的,所以对于需要部署大量服务的 IT 解决方案,可以预测和监视开发工作量。

服务生命周期的主要阶段包括:

  • 识别 —— 识别最初的需要并指定需求
  • 规格说明 —— 捕捉详细的需求和高层设计
  • 实现 —— 构造和部署服务
  • 操作 —— 在服务的生命期内管理服务,直到服务最终修订或退役

一定要注意,不能把所有东西都变成服务,而且不能(也不应该)公开所有服务。在 SOA 生命周期治理过程中,需要对候选服务进行资格测试,测试的结果可以建立一套确定服务质量的条件。这个测试包含以下问题:这个服务是可重用的吗?它会有多少用户?这个服务符合企业的目标吗?等等。选择了候选服务之后,下一步是决定是否应该公开它。公开一个服务意味着让其他人能够以明确的方式(比如通过注册表)使用这个服务。决定不公开服务有许多原因。例如,基础设施服务可能不需要在整个企业范围内可用,所以不应该公开;或者,安全限制和策略可能要求企业只向一部分用户公开服务。

服务生命周期与软件/系统开发方法 (SDM) 大体一致,比如快速应用程序开发 (RAD)、Rational Unified Process® (RUP®)、迭代式开发、螺旋式开发和敏捷开发方法。例如,Rational Unified Process® (RUP®) 由以下四个阶段组成:

  • 发起
  • 细化
  • 构造
  • 转换

实际上,对于每个服务,都要经历这些阶段。但是,阶段不完全一致,服务生命周期的操作阶段在某种程度上超越了 RUP 转换阶段的范围。

图 2. RUP 阶段
RUP 阶段
RUP 阶段

下图详细说明服务生命周期。橙色的框是与 QA 相关的步骤,用来确保对 SOA 开发过程进行有效的治理。橙色的框可以被看作策略实施点 (PEP)。例如,一个策略规定接收测试必须有 95% 的成功率,才能把服务向整个企业范围公开。另外请注意,图 3 底部显示的活动不属于 SDM,这意味着需要扩展当前的方法。

图 3. 详细的服务生命周期(Component Business Model (CBM),服务水平协议 (SLA))
详细的服务生命周期(Component Business Model (CBM),服务水平协议 (SLA))
详细的服务生命周期(Component Business Model (CBM),服务水平协议 (SLA))

启动 SOA 治理

为了实施 SOA 治理,需要考虑几个基本任务。

任务:定义 SOA Center of Excellence (CoE) 的章程

Wikipedia (http://www.wikipedia.org/) 把 Center of Excellence (CoE) 或 Center of Competence 定义为 “正式指定和非正式认可的关于某一主题领域的知识和经验团体。在这里为某一活动领域制定最高标准”。

SOA CoE 由人员、过程、技术和服务组成,它领导服务在企业中的实现过程。

从根本上说,SOA CoE 的主要任务是更改管理。参加 CoE 的每个人(从领导 CoE 的执行官到设计、开发和测试服务的专业人员)都必须肩负起这一任务。

SOA CoE 的目标应该是让服务成为关键的企业资产,因此应该:

  • 为与 SOA 相关的计划和实现建立一个跨组织跨功能的权威机构,通过它领导 SOA 计划和执行
  • 培养专家级的 SOA 技能,从而掌握最佳实践、技术、标准和与 SOA 相关的方法
  • 针对即将进行的 SOA 迁移,对组织模型和治理模型提供建议和帮助
  • 在 CoE 的生命期内实现预期的面向服务成熟度目标
  • 设计用于管理服务的基础设施改进,涉及的领域包括安全性、监视、性能、版本化和共享使用
  • 改进 IT 过程,从而促进服务的共享和重用以及服务的识别、设计和规格说明,包括解决相关的出资、共享和激励问题
  • 帮助计划培养 SOA 技能所需的教育和培训
  • 广泛传播 IT 部门发展 SOA 能力的战略意图,使 SOA 成为整个组织的核心战略能力,为组织提供长期的竞争优势

任务:识别支持 SOA 所需的角色和责任

与任何迁移过程一样,迁移到 SOA 也会带来新的挑战。成功地采用面向服务方法需要改变组织角色和责任。组织必须花费时间和精力创建适当的组织和支持结构,从而支持顺利地采用 SOA 原则。第一步是建立一个主要关注 SOA 的 Center of Excellence (CoE)。

我们将用单独的一节详细讨论 CoE。现在只需要指出 SOA 会引入新的角色和责任,比如服务注册员和服务架构师。

任务:定义服务所有权和开发出资模型

为了确保顺利地采用 SOA,需要明确地理解和宣传出资和所有权模型。出资模型应该鼓励共享、重用、高效的集成和简单化。如果没有明确的服务所有权和出资模型,服务仍然会像目前的应用程序和产品系列一样被隔离在组织壁垒中。

请考虑希望跨多个业务线统一用户体验的示例:

在最优的 SOA 解决方案中,我们创建一组共享的服务,它们跨所有业务线提供统一的用户体验,包括提供统一的数据访问的服务。

但是,创建这样的服务并不仅仅是技术问题。业务线需要回答以下问题:

  • 谁拥有这些数据?他们是否允许服务访问数据?
  • 如何授予访问获得的数据的权限?
  • 谁应该为共享的服务提供资金?谁拥有它,或谁为它的开发出资?
  • 如果服务出现问题,谁负责修复它?
  • 企业如何鼓励各个业务线重用企业资产和共享业务服务?
  • 由谁决定服务是否向其他应用程序公开?如果服务的潜在用户对它的内容不满意,应该怎么办?

建立明确的服务所有权和出资模型有助于一致且高效地解决这些问题。尤其是,必须特别关注用户未来的数据访问需求。

任务:识别成功因素、促进因素和重用激励因素

在考虑 SOA 和服务重用的成功因素和激励因素之前,一定要了解共享服务模型和重用的传统挑战和局限性。

  • 缺少公认的标准、厂商产品/平台互操作性
  • 跨域服务、服务发现和服务可见性的语义
  • 共享服务模型中的许可证模型会导致一些困难:如果现有的系统使用商业现成 (COTS) 产品,这些产品已经建立了许可证模型(例如,每 CPU、命名用户、基于席位),那么在把现有功能作为服务(或操作)公开并计划 “未来的” 服务消费者时,就会出现成本、合法性和组织问题,这些问题会妨碍服务共享。这些障碍会使感兴趣的服务提供者不愿意公开服务。
  • 缺少认证和支持:共享服务模型会增加可用性、可靠性和安全性方面的开销,而且往往不能保证服务的质量。

任务:设计策略和实施机制

要想成功地采用 SOA,SOA 治理模型需要发起人和其他相关人员(包括 SOA CoE)的全面支持。

如果不进行适当的检查和权衡,SOA CoE 创建的基本过程、标准和最佳实践很可能无法在实践中应用。

尤其是在 SOA 治理的早期阶段,一定要经常进行生命力检查、预演和交错审查,从而确保信息和过程顺畅。治理的实施要求实体有权控制不同层次的实施,从而有效地治理 SOA CoE 建立的标准。

下面是一些典型的实施实体,它们分别承担特定的责任:

  • SOA Steering Committee —— 对整个企业中的 SOA 活动进行战略性指导和管理。理想情况下,这个委员会应该是企业级治理委员会的子委员会。
  • SOA Control Board —— 对特定 SOA 任务进行战术性指导。同样,它应该是企业级治理控制理事会的组成部分。
  • SOA CoE (Center of Excellence) Advisory Group —— 负责对 SOA 活动进行日常指导。

服务管理和监视

企业经常犯的重大错误之一是只顾编写服务/Web 服务,而不考虑服务管理和监视。这种做法在许多组织中造成了大量麻烦。由于缺少服务管理和监视,服务的数量常常会失控,还会出现相同服务的许多版本,这些版本的功能基本相同,只有细微差别。因此,我们要在服务生命周期中解决这个问题。服务管理和监视应该是在设计时考虑的问题,不应该是只与 IT 操作相关联的后期问题。

高效地管理服务的关键是,把服务看作一种资源。服务需要保护、部署、监视和版本化,它们还应该有相关联的正式 SLA(服务水平协议)。

由于基于服务的解决方案是通过组合服务实现的,这在管理方面造成了新的困难。管理组成服务本身的资源很重要,但是管理服务之间的相互依赖性和维持期望的服务质量 (QoS) 同样重要。正如第 2 节中提到的,策略管理提供一种根据企业制定的策略分配 IT 资源的机制。因此,要在过程中识别出策略决策点 (PDP) 和策略实施点 (PEP),PDP 定义事件并做出决策,PEP 执行并监视策略。

尽管支持 SOA 的底层技术和标准在服务设计和管理方面提供了许多选择,但是仍然要花费时间和精力设计管理战略并一致地执行战略。

IT 管理和操作上下文中的服务管理

图 4. SOA 解决方案抽象层
SOA 解决方案抽象层
SOA 解决方案抽象层

上图是原子服务和复合服务的简化模型,显示系统、组件、过程和消费者之间的抽象定位和关系。

这个模型说明,有效地管理服务需要管理服务的相互关系和依赖性,还需要一个支持模型,它反映服务的相互关系以及服务与 IT 基础设施和业务过程层的关系。

可以通过日志、筛选、路由和转换等管理措施控制服务环境中的流程。集中的服务管理策略可以定义如何应用这些措施。

服务管理和监视任务

全面讨论服务管理和监视超出了本文的范围。下面简要描述支持 SOA 治理目标的两个基本任务。

任务:服务的认证和发布

在企业资产中添加新的 “服务” 实体需要通过某种方式向服务的潜在消费者公布它的状态和详细信息。服务的认证和发布对于采用 SOA 非常重要。这个任务的最大优点是可以避免随意地引入服务和部署服务。

尽管这不是 IT 操作过程中的全新步骤,但是它有一些不同于客户机-服务器系统的问题,比如松散耦合性质和新的互操作性困难。与这个领域相关的技术标准和工具(注册表、存储库等)正在快速发展。

服务的认证是 SOA 治理的重要部分。服务认证的主要目的是保证服务的总体质量,向服务的潜在用户保证它会得到全面的支持,能够满足他们的需要,从而促进服务的重用。

为了让服务的潜在消费者对这种服务保证有信心,需要满足更多可审计性需求,还要公布认证的详细信息。服务认证应该在质量保证部门的控制下进行,应该包含操作测试,这些测试应该模拟与预期使用场景相关联的部署体系结构。还可以明确提及与其他使用场景相关的信息,例如通过广域网使用服务(如果这不是最初的部署体系结构)。

认证步骤基于在识别服务重用可能性和潜在服务消费者期间已经取得的成果。

在服务设计和开发阶段开发和记录的各种工件(比如 SLA 和 QoS)也对认证过程有帮助。认证要正式地完成 QA 过程,然后才能向整个企业发布服务,这样就可以确保服务的质量并提供完整的支持资料。

例如,认证要确保服务元数据中包含必须有的信息,比如版本号、所有者、服务的负责人以及服务的分类和可用性。

认证和发布服务还有以下作用:

  • 帮助 IT 操作人员捕捉并记录与服务相关的元数据。这有助于以后的项目了解服务和分析系统,从而支持最初没有考虑到的潜在用户
  • 在采用 SOA 的早期阶段,它提供一条从 IT 操作人员到设计和开发团队的反馈渠道。IT 操作人员可以提出与服务部署的操作方面相关的重用问题和考虑因素,这可能会促使设计团队改进设计
  • 认证过程确保服务规格说明中服务合约的正确性
  • 它建立一个信息源,可以通过它获得关于服务生命周期、使用方法和预订方法的信息
  • 它证明服务已经经历了服务生命周期状态所需的步骤,包括其间的对等检查。通过定义正式的服务状态和允许的状态转换,可以明确地提供与服务所处阶段相关的信息
  • 认证检查让服务进入 “通过” 或 “失败” 状态。“通过” 状态表示服务已经可以发布了。“失败” 状态表示需要做更多工作,它才能被认证为合格的服务。

为了缓解不可控或频繁的变化对企业的冲击,可以把第三方服务(可能包含多个提供者的服务)隐藏在一个中间层后面,这样外部/提供者的变化就不会影响企业的核心业务。如果服务提供者改变了,治理过程应该检查处于企业控制下的中间 “提供者” 的注册表/存储库。在服务交付、接口、端点等方面发生任何变化时,都应该向受影响的消费者发出公告。

在实际实现服务并与服务消费者协商服务水平协议之前,其中一部分需求可能无法实现。

任务:服务版本化

服务的版本化需要通过某种机制跟踪并说明服务的更改。由于 SOA 驱动因素(重用、敏捷、企业协调一致等)和促进因素(技术组件和标准)的性质,随着时间的推移生产服务很可能不断变化。这些变化可能源于各种因素,比如出现了新的请求者、遵从性/安全性需求发生了变化等等。

在创建现有服务的新版本之前,需要谨慎地做出设计决策。如果合约或实际情况要求支持以前的版本,就必须保持向后兼容性。

当合约义务完成时或不再需要支持服务时,可以终止对旧服务版本的支持。一些消费者可以请求针对他们的特殊用途创建特殊的服务版本。

与当前应用程序环境中的常见状态不同,在服务环境中编程模型的一些性质有助于版本化。运行和组合过程的新解决方案(过程服务器)支持服务实现与关注点(比如过程实例)的分隔。

例如,通过指定有效的 “启始日期”,过程服务器能够决定在创建过程实例时使用已经部署的过程模板的哪个版本。重要的是,创建实例之后,它就针对这个模板版本运行,而不会受到以后部署的其他版本影响。

SOA 和 SOA 治理的组织

SOA 是 IT 行业合理演化的结果,仔细的计划和组织对于采用 SOA 非常重要。Gartner 的研究表明,到 2010 年,缺少有效的 SOA 治理将成为 SOA 部署失败的最主要原因,失败的可能性达到惊人的 80%。没有任何 SOA 最佳实践主张或支持一蹴而就地迁移到 SOA。

项目(或程序)管理的概念已经出现很长时间了,具有一定规模的 IT 部门或 IT 活动的大多数公司都有正式的程序管理办公室 (PMO)。这说明这些公司希望对项目应用严谨的项目管理方法。

企业要处理多个独立的项目,而这些项目涉及企业的方方面面,企业需要改进传统的项目管理方法来适应这种情况,因此就蕴育了正式程序管理办公室。面向服务要求相关人员更多的参与和协作,因为企业希望开发出在企业内各个地方使用的业务服务,希望在多个相互依赖的过程中进行协作和参与。

正如前面的 Gartner 统计数据所表明的,SOA 项目的失败风险很高:因此需要采用组织良好的非常系统化的方法。SOA 的组织需要了解程序管理、SOA Center of Excellence (CoE) 的概念、CoE 的角色和责任以及程序管理在 SOA 服务部署中的角色。

程序管理

程序管理常常由一个企业范围的程序管理办公室 (PMO) 执行。Project Management Institute (PMI) 把项目/程序管理定义为对项目活动应用知识、技能、工具和技术,从而满足项目需求。PMO 确保以相同的方式管理每个部门中的项目,确保这些项目向相同的目标迈进。这有助于提高效率、减少重复和成本并确保实现基本目标;这与 SOA 的目标非常相似。

程序管理的重点可以分三个方面:

  • 目标和战略 —— 创建或调整业务目标和实现目标的战略。识别出实现目标所需的程序,按多个维度定义它们,量化它们的潜在价值,判断相关的成本。
  • 动员 —— 为程序及其项目建立治理结构和角色。这包括开发/实现资源计划,调动人员,建立程序管理办公室 (PMO) 。它还包括定义/实现支持程序员工作所需的物质和技术基础设施。
  • 计划 —— 定义项目战略,包括开发和交付项目计划、计算总规模和各个部分的规模、定义工作进度表和为主要检查点建立里程碑。然后,确定进行总体检查、风险控制、质量和财务管理的具体措施。

治理在程序管理中扮演重要角色。通常,在实施强有力的程序管理的公司中,治理是公司文化的组成部分。因此,强有力的程序管理非常有助于实现 SOA。但是,SOA 具有独特的需求,所以仅仅有 PMO 是不够的。

下面讨论 SOA Center of Excellence (CoE)。CoE 实际上对 PMO 起补充作用。它关注的重点完全放在创建和部署企业级服务上,这些服务将在当前项目和计划的项目中使用。尽管可以在 PMO 结构内包含 SOA CoE 的角色和功能,但是建议让 SOA CoE 成为单独的团体,至少在 SOA 项目的初期应该这样做。这对于没有 PMO 的公司更有好处;他们能够建立自己的 SOA CoE 并启动 SOA 项目。

Center of Excellence (CoE)

SOA Center of Excellence (CoE) 是一个跨组织的团队,它指导与 SOA 目标和战略相关的 IT 投资、设计决策和实现,目标是实现战略性的共享的 IT 解决方案。

必须让服务成为关键的企业资产。CoE 通过以下活动确保实现这个目标:

  • 为与 SOA 相关的计划和实现建立一个跨组织跨功能的权威机构,通过它领导 SOA 计划和执行
  • 培养专家级的 SOA 技能,从而掌握最佳实践、技术、标准和与 SOA 相关的方法
  • 针对即将进行的 SOA 迁移,对组织模型和治理模型提供建议和帮助
  • 在 CoE 的生命期内实现预期的面向服务成熟度目标
  • 设计用于管理服务的基础设施改进,涉及的领域包括安全性、监视、性能、版本化和共享使用
  • 改进 IT 过程,从而促进服务的共享和重用以及服务的识别、设计和规格说明,包括解决相关的出资、共享和激励问题
  • 帮助计划培养 SOA 技能所需的教育和培训
  • 广泛传播 IT 部门发展 SOA 能力的战略意图,使 SOA 成为整个组织的核心战略能力,为组织提供长期效率

最初,CoE 团队负责指导和扩充 SOA 项目,包括选择采用 SOA 方式的项目和需要开发的服务。随着时间的推移,当 SOA 成为业务的 “常态” 时,SOA CoE 的职责可以转交给 Architectural Board 等其他团体。

角色和责任

SOA CoE 没有标准的组织模型。先进的 SOA 实践建议为 SOA CoE 设置以下责任。

图 5. SOA CoE 责任
SOA CoE 责任
SOA CoE 责任

实现这些责任的结构见图 6。注意,这个结构显示角色而不是个人。这些角色不必都是全职的,而且一个人可以在 CoE 中有多个角色。在 SOA 项目的早期阶段,CoE 的规模通常是 5 到 10 个人。

图 6. SOA CoE 角色示例
SOA CoE 角色示例
SOA CoE 角色示例

结束语

在本系列的第 2 部分中,我们讨论了治理生命周期以及应该如何组织 SOA 和 SOA 治理。在最后一部分中,我们将讨论治理成熟度、工具、生命力和治理成功模式。

致谢

我要感谢以下各位对白皮书原文做出的贡献。特别要感谢 Robert Laird 先生慷慨地贡献了他的时间和专业经验。

组织参与者
BoeingLes Robinson
Computer Sciences CorpJay Pollack
Harris CorpBob Riley
Harris CorpDavid Almeida
IBMMike Moomaw
IBMRobert Laird
IBMJohn Falkl
Lockheed-MartinAl Secen
L3 CommunicationsChris Francis
OraclePeter Bostrom
SITAKathy Kearns
SITAMansour Rezaei-Mazinani

相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=434645
ArticleTitle=SOA 治理:如何迎接 SOA,第 2 部分: 治理生命周期
publish-date=10122009