内容


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

治理成熟度、工具、生命力和成功模式

Comments

系列内容:

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

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

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

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

治理成熟度

如果您不知道自己在什么地方,那么有地图也没用。如果您不知道要去什么地方,那么有道路也没用。

成熟度级别常常用来预测某一方面或某些方面未来的绩效。但更重要的是,它有助于发现不足之处,有助于确定需要开发、改进或增强哪些方面。因此,它能够指出您当前的位置并帮助制定路线图。

无论您当前处于什么成熟度水平,都必须认识到不可能在一夜之间实现成熟的 SOA 治理。这需要整个企业的努力,需要改变企业文化(最好以渐进方式实现),需要按照一个路线图(其中包含定义良好的里程碑和可度量的结果)逐步发展。实现成熟的治理的第一步是评估和度量组织目前在各个治理领域的状态。度量有助于识别关键领域和确定进行改进的优先次序。

具体地说,SOA 治理决定组织在多大程度上符合 ISO 9000 或 CMMI 过程。CMMI 和 ISO 9000 规定良好的开发过程必须具备的性质(软件、集成和 IT 过程的可重复性和可检验性)。可以按照 CMMI 或 ISO 9000 实现特定的开发过程(比如敏捷开发、瀑布式开发、latest-flavor 等等)。实现 SOA 并不意味着现有的过程是不够的或已经过时了。实际上,治理模型必须提供把新概念注入现有过程和实践的机制。

因此,尽管 SOA 治理既是科学,也是艺术,但是 SOA 治理需要比以往更科学化。应该考虑现有的 IT 治理成熟度模型,然后应用服务方式实现 SOA 治理成熟度模型,我们可以使用这个模型以更科学化、更严谨的方式了解组织的治理需求。

Information Systems Audit and Control Association (ISACA) 和 IT Governance Institute (ITGI) 制定了 COBIT (Control Objectives for Information and related Technology)。COBIT 提供一套被普遍接受的度量、过程和最佳实践,用于尽可能发挥信息技术的作用和开发 IT 治理。可以在 www.isaca.org/cobit 找到关于 COBIT 的更多信息。

COBIT 提供一个 IT 成熟度模型,这个模型是从 Software Engineering Institute 的 Capability Maturity Model (CMM) 衍生出来的。例如,在 CMM 中,比较的基础是组织的软件开发过程。这个成熟度模型使用经过 COBIT 修改的标准 CMM 成熟度级别,见表 1。

表 1. 成熟度级别的定义
0 - Non-existent完全没有任何过程。企业还没有认识到需要解决治理问题。
1 - Initial / Ad-hoc有迹象表明企业已经认识到需要解决治理问题。但是,还没有标准的过程;而是针对不同的场景应用不同的过程。
2 - Repeatable but intuitive已经开发了治理过程,承担相同任务的不同人员采用相似的过程。还没有关于标准过程的正式培训或交流,责任由个人承担。因此,效果高度依赖于个人的知识水平,很可能出现错误。
3 - Defined Process治理过程已经标准化,有正式记录,并通知了相关人员。已经规定必须遵守这些过程;但是无法检测和纠正违反规定的情况。
4 - Managed and Measurable治理机构监视和度量组织是否遵守治理过程,并对过程无法有效地发挥作用的场景采取措施。过程会不断改进并提供良好的实践。以有限或零散的方式使用自动化和工具。
5 – Optimized经过不断改进,治理过程已经非常好了。在整个企业中,以综合的方式使用治理来提高质量和效率,让企业能够快速地适应变化。

度量和指标

为了发现不足之处,我们需要准确地了解目前的状态和希望实现的目标。然后,需要了解如何弥补这些不足。成熟度模型对此有帮助。根据组织在实现相关领域或操作实体的已知目标方面的成功程度度量成熟度级别。对于我们,相关领域是 SOA 治理。因此,我们需要识别出 SOA 治理中需要度量的领域。

内部度量/评估可能是一种高效且经济有效的方法。相关人员可以利用自己的现有知识进行度量。但是,他们可能不具备进行企业级度量所需的广泛的技能,也无法以全局的视角考虑问题。另外,这个活动会挤占其他项目的资源。另外,关注点的固有差异、行政和组织问题、对自己的工作成果的保护意识和其他因素都会影响这种度量方式。在大多数情况下,由第三方指导的度量更合适。第三方不牵涉企业内的行政和其他问题,通常更容易提供不带偏见的客观的结果。由与治理功能关系不太密切的内部人员和第三方专家进行度量,这种方法是很有效的。

应该度量什么

必须度量与 SOA 治理相关的所有领域和组件。没有这种领域和组件的标准列表。下图给出一些可以度量的领域的示例。

图 1. 要度量的治理领域示例
要度量的治理领域示例
要度量的治理领域示例

确定治理领域的优先次序

如果适当地设计和实现,SOA 治理会促进 SOA,SOA 可以帮助组织更快地实现业务目标,提高它对市场和客户的敏捷性和反应能力。不建议采用 “大爆炸” 方式实现 SOA,对于实现 SOA 治理,也是如此。应该评估治理成熟度级别,寻找不足之处,然后确定应该优先实现的重点领域。但是,缺少这样的研究应该不妨碍实现 SOA 的进度。在完成成熟度评估之前,还有机会确定优先次序。下面是推荐的方法:

  • 重点关注服务生命周期和它的治理需求。请记住,治理应该是完全公开的。如果把服务生命周期看作一个过程,其第一步是提出服务的思想,最后一步是废弃服务;那么服务生命周期的治理必须清楚地指出每一步应该做什么,在每一步中要使用或实施的策略、标准和模式,以及如何执行每一步和由谁执行。例如,每个人都应该知道一个服务所需的策略和标准以及谁应该审查结果。
  • 审查现有的项目生命周期,了解服务对项目生命周期治理的影响。
  • 最后,可以研究企业向 SOA 迁移的生命周期。
图 2. 在没有正式的治理度量/评估的情况下,实现 SOA 治理的推荐方法
在没有正式的治理度量/评估的情况下,实现 SOA 治理的推荐方法
在没有正式的治理度量/评估的情况下,实现 SOA 治理的推荐方法

治理工具

随着最佳实践和标准的发现和开发,与 SOA 治理相关的工具也在发展。在本节中,我们并不推荐特定厂商提供的工具,而是通过讨论一般的治理需要,指导您制定工具选择标准。

对于选择所需的工具,有许多可供选择的方法。当然,这些方法的组合会提供其他许多可能性。在本文中,我们介绍两种方法。第一种方法主要关注治理领域和每个领域涉及的组件。第二种方法是治理控制点。到撰写本文时,在这些领域还没有标准或最佳实践。最好由 SOA Center of Excellence 负责选择适当的方法。

确定工具标准 —— 方法一

确定 SOA 工具需求的一种非常有效的方法是,识别企业中 SOA 治理应该覆盖的领域和活动,把领域细分为组件,查明工具在哪些方面有帮助。下面是这种细分方法的示例。对于每个领域/活动,识别并简要描述两个组件。CoE 或组织中承担 CoE 责任的任何团队应该完成这种细分并确定准确的工具需求。通过这样做,可能会发现一些现有的工具可以满足一部分 SOA 治理工具需求。例如,需求管理软件包和资产管理软件包(可以作为企业资产处理 “服务” 和 “策略” 等资产)。

下面是可能的细分方式和两个组件示例:

  • 战略:
    - 业务愿景:创建和维护企业的业务愿景。创建和维护一个业务体系结构,可以识别服务领域、业务功能、业务过程以及它们到 SOA 服务和 IT 应用程序的映射。
    - 标准和设计模式:在服务的开发、部署等阶段必须遵守的相关标准和模式。
  • 启用:
    - 所有权和出资:由谁出资以及如何分配权力和责任。
    - 厂商管理:管理针对产品和厂商的策略和标准。
  • 开发:
    - 法律法规遵从性:确保符合州、国家和国际法律法规的规定。
    - 服务认证:创建、维护和使用服务认证过程标准。
  • 程序/项目管理:
    - 风险管理:识别风险的来源。
    - 更改管理:处理更改请求,为版本管理提供输入。
  • 操作:
    - 服务支持:问题报告和支持。发布管理。
    - 服务监视:设置并监视绩效指标。

确定工具标准 —— 方法二

另一种方法是关注与 SOA 治理相关的控制点。同样,也有不同的实现方法。可以使用上面描述的方法一并识别控制点。更好的方法是研究服务生命周期和服务的操作方面并识别控制点。

我们先定义控制点是什么。控制点提供一个度量过程的机会,可以在控制点上判断过程的执行是否需要调整。过程中的某些关键活动可以与控制点相关联。在每个控制点活动结束时,治理功能判断过程是否可以转到下一个活动。

了解过程中的哪些决策是关键的,以及这些决策需要哪些度量作为输入,这有助于决定把控制点放在哪里最合适。这是治理的重要部分。

下面是建议的一些控制点以及工具支持需求示例:

  • 业务需求控制点 – 业务目标和这些目标驱动的需求。识别和度量关键绩效指标。
  • 解决方案体系结构控制点 – 要遵守的标准和策略。记录和维护体系结构决策。
  • 服务识别和规格说明控制点 – 识别服务及其目标。完成服务规格说明。
  • 服务设计控制点 – 设计要遵守的策略和标准。使用数据消息传递模型和数据访问模式。
  • 服务构建控制点 – 规则是基于策略的。考虑现有的服务。
  • 服务测试控制点 – 负载测试和压力测试。测试安全性。
  • 服务认证和部署控制点 - 检查遵从性。
  • 服务生命力控制点 – 及时更新治理过程。

治理生命力

随着 SOA 的演化,治理过程也需要相应地演化。治理过程的演化是治理生命力的根本。另外,组织中许多方面的变化也要求治理过程相应地变化。在环境中采用 SOA 是为了快速响应市场和客户需求,提高敏捷性,所以治理需要支持必需的变化。治理并不是一次性的工作。不可能建立治理过程并指望它们永远有效。在真实世界中,所有东西都会变化,所以相关联的治理过程也应该相应地变化。

在本节中,我们讨论组织维持治理生命力的方式,还研究一些可能触发治理过程变化的事件。

如何做以及应该由谁做?

没有保证治理生命力的固定方法;生命力应该存在于生命力过程本身中!在治理计划过程中,要考虑应该度量 SOA 项目的哪些方面。还要考虑谁应该负责检查这些指标和检查的频率。观察所得出的意见应该总结成一个计划,其中对治理过程的哪些方面需要修改提出建议。应该通过明确的机制记录想法并召开审查会,确保记录的每个想法都经历严格的决策过程。治理生命力是一项重要的任务,它最初往往由 CoE 团队的成员负责。建立 SOA 治理并定义它与 IT 和企业治理的关系之后,更容易确定谁应该负责治理生命力以及应该如何触发 SOA 治理生命力过程。

最佳实践指出,标准组织的参与也有助于组织适应行业的变化。与技术标准保持一致常常有助于提高组织的效率。标准组织的参与还让企业有机会影响标准组织,确保行业标准符合企业的需要。

成功的治理并确保治理生命力的关键是,广泛宣传治理和相关工具如何帮助改进日常任务,而不是一味强制实施它们。这样的话,每个人都会积极参与改进治理。维持治理生命力的责任会深入整个企业。

触发 SOA 治理过程审查的事件

某些事件会触发治理生命力活动。正如前面提到的,SOA 治理是现有 IT 和企业治理的补充和扩展;因此,这些触发事件有助于考虑治理的相关问题(比如在哪里进行治理、治理什么和由谁负责)。

  • 业务战略变化。业务战略的任何变化都可能导致取消或更新现有的治理过程和策略。业务战略的变化可能很简单,例如增加或取消与客户/消费者/合作伙伴的交流渠道(比如取消邮政邮件,增加电子邮件);也可能很复杂,比如把一部分业务外包出去。
  • 业务过程变化。业务过程可能由于许多原因发生变化。例如,活动的次序发生了变化,或者在过程中增加新活动或取消现有活动。总是需要判断变化对治理过程的影响。一些组织对业务过程管理 (BPM) 采用 “过程治理” 的概念,SOA 治理生命力会受益于现有的治理机制。
  • 组织变化。随着组织的变化,决策权可能会转移。这就要求审查治理过程。
  • 法律和策略变化。法律和策略的变化可能要求对公司的运营进行重大调整(例如 SOX、BASEL II 等),因此需要调整治理过程。
  • 标准的变化。标准常常会取代治理过程中的专有部分。在缺少标准时,企业只好按自己的方式办事。标准开发出来之后,就需要审查现有的治理过程,寻找必须修改的地方。
  • 技术改进。组织总是在想方设法对过程进行自动化,从而提高生产力和节省成本。新技术会使现有的任务或过程更容易、更精确或提供更多控制能力。在许多组织中,由一个正式机构负责考察新技术,当他们发现有用的新技术时,通常会触发治理过程审查。
  • 对当前治理效率的评估。在 SOA ‘度量’ 阶段,获得的指标会表明 SOA 的效率。SOA 治理负责定期审查这些指标并对治理策略、标准和过程进行必要的修改。对于每个组织,治理生命力所用的指标各不相同,但是常常包含以下指标:控制门会议的数量(数量低可能意味着过程没有起作用,或者被绕过了)、认证的服务数量(认证过程是否太严格?是否所有服务都经过了认证过程?)等等。

治理成功模式

多年以来某些领域的成功实践衍生出了一些成功模式,它们是相关领域的成熟度的标志。在某些方面,通过采用已经证明有效的模式,SOA 已经发展到了一定的成熟度。我们目前仍然处于 SOA 运动的早期。但是,SOA 模式现在正在形成,我们已经可以使用一些 SOA 成功模式了。在本节中,我们讨论 10 种先进的实践,已经证明它们有助于成功地采用 SOA 和在 SOA 中成功地发挥 SOA 治理的作用。下面的模式的次序并不重要,不影响它们的优先次序。

确保管理层支持 SOA

实现 SOA 需要管理层的大力支持。应该有一位或更多管理层成员对 SOA 非常热心,他们了解 SOA 的好处,这对于顺利实现 SOA 有很大影响。他们一方面有助于推广 SOA 思想,另一方面可以提供必需的资源。在理想情况下,他们应该成为业务部门和 IT 之间的纽带。SOA 治理尤其应该强调并鼓励管理层在早期阶段的大力推动。

建立真正的或虚拟/临时的 CoE

治理需要某种形式的支持组织,至于这种组织叫什么名字并不重要。例如,实践已经证明建立 SOA Center of Excellence 在许多组织中非常有帮助。在 SOA 项目的早期,企业可能需要比较长的时间才能建立真正的 CoE,在这种情况下建立 “虚拟的” CoE 会有帮助。虚拟的 CoE 负责真正 CoE 的大多数工作,但是没有正式的组织结构。这应该是一个非常短的阶段。建立虚拟 CoE 的好处是,与根本没有 CoE 相比,它可以决定在短期内需要完成的初期 SOA 活动,尽管采用非正式的形式。但是,这也有缺点:因为 CoE 是非正式的,它可能无法提供必要的支持,可能无法产生所需的结果。虚拟或临时的 CoE 常常由企业中的 SOA 先驱建立。成员可能包括企业中已经认识到 SOA 的好处、热心推动 SOA 发展的人员,还可以包括已经了解了在非结构化环境中以专门方式创建服务的危害性的人员。

交流业务价值

最好的销售人员往往是最先购买或相信他们销售的产品的销售人员。这是因为他们真正了解了产品,确实相信产品能够满足所有承诺。SOA 的承诺是提供巨大的业务价值。SOA 治理必须确保这个承诺成为现实,而且必须以明确的方式让所有相关人员了解这一承诺。这样,受影响的每个人都能够了解 SOA 的目标,从而积极参与推动实现 SOA 的业务价值。

逐步迁移到 SOA,不要采用大爆炸方法

面向服务的概念以及可重用且可消费的服务提供的敏捷性让技术和业务人员都非常兴奋。在一些组织中,已经在快速开发服务。传统的应用程序僵化、缺乏灵活性,这促使人们考虑采用服务方式。但是,如果我们不注意创建新服务的方式,如果不考虑它们的粒度,如果不按照整个企业的全盘视角创建它们,这些服务很快就会变得与传统应用程序一样僵化,只不过更小而已。用数百个僵化的小型服务替代十几个僵化的大型应用程序,并没有什么好处。如果没有治理,相同服务可能有许多变体,这会增加开发和支持成本。

采用策略

策略可以使决策更快更好。通过为可能发生的情况制定策略,对这些情况的管理可以实现自动化,减少需要明确指导的情况。例外情况总是需要人为干预和决策过程。策略在服务开发生命周期、管理和监视方面扮演重要的角色。因此,策略对于 SOA 治理极其重要。例如,策略 “企业服务需要最少三个消费者” 有助于决定哪些服务可以成为集中管理的企业级服务。不满足这个策略的任何候选服务可以被自动地拒绝,或者归类为部门服务并与特定的资源约束相关联。

在网络资源管理中使用基于策略的管理,可以简化管理。可以通过策略实现安全措施(包括对部分网络的访问)或控制服务质量。在基于策略的管理中,策略实施点 (PEP) 和策略决策点 (PDP) 是两个重要组件。它们在 SOA 环境中非常有意义。PEP 组件向 PDP 组件发送消息,询问是否满足策略中的条件,并根据结果允许过程继续或停止过程。治理在定义 PDP 和 PEP 以及它们的行为方面起关键作用。

第 6 节讨论的控制点与 PEP 相似。

度量每一步

度量是有效的治理的关键。如果不度量效率,人们很快就会忘记愿景、任务和目标。良好的治理必须定义和强化愿景和任务;应该明确地定义目标以及决定目标是否实现的一组指标。这确保有可行的度量能力,能够了解距离业务目标还有多远。

使用工具并建立 SOA 实验室

实施治理有时候是重复的、枯燥的。工具和自动化会有帮助。当然,在选择工具的类型和功能时要考虑许多因素。选择适当的工具对于成功地实现 SOA 很重要,请参考第 6 节中的原则。

还应该建立 SOA 实验室,在实验室中构造早期原型、检查技术问题(硬件和软件)以及测试服务开发生命周期等过程。这种方式有助于及早发现技术障碍。通常由 CoE 控制这个实验室。实际上,CoE 的早期活动之一应该是建立 SOA 实验室。CoE 需要确定实验室中应该有什么、使用实验室的方法和用途、什么时候实验室应该成为操作性的以及持续多长时间。

了解自己的成熟度级别

在实现面向服务体系结构时,许多组织一上来就在 IT 环境中引入服务,过一段时间之后,他们就认为自己已经实现了 SOA。但是,仅仅因为几个 IT 人员决定编写 Web 服务而不是应用程序,就创建了一堆服务,这算不上是 SOA。需要在全盘考虑整个企业的情况下创建服务。为了了解以后怎么办,我们需要了解目前的状态。因此,了解当前的成熟度级别是非常重要的。这种成熟度评估应该在企业和 IT 治理的基础上进行,评估面向服务的状态。

创建和治理 SOA 路线图

创建 SOA 路线图是成功的 SOA 项目中必须有的部分。这并不容易,因为需要了解当前的组织,清楚地理解组织的愿景、任务和目标,以及如何通过面向服务实现它们。创建路线图并对它的实现进行治理是 SOA 项目中最困难最耗费时间的方面之一。

治理投资回报

在业务环境中,任何投资都应该有相应的回报。没有投资回报是不可接受的。迁移到 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=434652
ArticleTitle=SOA 治理:如何迎接 SOA,第 3 部分: 治理成熟度、工具、生命力和成功模式
publish-date=10152009