写点什么

SOA 治理基础

2008 年 1 月 10 日

** 采用面向服务的架构(SOA)的企业通常很快会发现,为了成功管理或者启动一个 SOA 项目必须迅速建立 SOA 治理。然而由于种种原因,在很多的企业内成功建立 SOA 治理并非一件容易的事情。

为了弄明白什么是 SOA 治理及其如何能在企业中成功启动,对 SOA 治理的原则和全面有效的 SOA 治理模型有清晰的定义和理解是非常有必要的。清晰的治理原则和面向组织的治理模型的建立能为更进一步的治理活动打下良好的基础。这里,清晰的治理原则是指在组织内部对 SOA 治理有一个共同的定义。

这篇文章的重点是解决在建立 SOA 治理过程中最基本的一些问题。首先,通过比较“战略治理”和“战术治理”,给出了 SOA 治理的定义。第二,展示了一个 SOA 治理框架,此框架是可定制的,它可以根据企业实施 SOA 成熟阶段的不同而做出相应的调整。文章的最后列出了实施 SOA 治理的一系列切实可行的步骤,这些步骤对企业 SOA 治理的起步和持续推进是非常有裨益。** * * *
负责治理的人员每个月碰次面、讨论一些有关 SOA 的议题、建立企业 SOA 策略然后再缩回到 SOA 象牙塔里头,这种工作模式是无法适应 SOA 治理要求的。事实上,建立 SOA 治理在企业所有的 SOA 努力中不仅仅是具有挑战性的工作,稍有不慎它就可能成为一项对企业非常具有破坏性和分裂性的工作。

SOA 过程人们这几年一直在强调,在企业启动 SOA 的过程中最大的障碍将存在于文化和政治层面上,SOA 要想在组织内部取得必要支持并获得成功,必须要克服这些障碍。因此,建立 SOA 治理——或者说组织一批精通 SOA 各个领域的专家来建立企业 SOA 策略——将是企业在实施 SOA 过程的早期不得不面对的一个问题。毕竟,政治是与生俱来寓于治理之中的。

政治斗争是不可避免的,并且其在很大程度上决定了 SOA 各个领域的人员安排和相应的治理责任。然而,在建立 SOA 策略的过程中,如果各个领域都有清晰的界限并且争夺对象有明确的定义,斗争的激烈程度是有可能减轻甚至斗争本身都有可能避免的。本文的目的就是要让读者了解有关此方面的一些基础知识。

SOA 治理:战略 VS. 战术

令一些人感到吃惊的是,成功地领导建立 SOA 治理的往往并不是那些自称是“SOA 治理委员会”的小组。在很多企业中,“SOA 治理委员会”往往倾向于从战略的高度去思考问题,他们对 SOA 治理缺乏必要的战术性考量,而这种考量却能对所有的企业 SOA 活动提供支持,并且这种支持是贯穿于其整个生命周期的。事实上,能在企业中成功实施 SOA 的小组要能正确地定义什么是 SOA、明确 SOA 应该得到什么样的支持,并且清晰地阐述小组在 SOA 治理模型中所处的地位。对 SOA 治理进行精确的定义和建模使得有关 SOA 的讨论和决策目的明确清晰,易于理解——这些正是避免组织分裂的关键性因素。

是的,在企业中领导 SOA 治理的小组可能不止一两个。事实上,许多企业采取分层的治理模型。虽然看起来比较复杂,但是只要认识到 SOA 治理从根本上分为战略和战术这两个层面,问题就会简单许多。

实施 SOA 的企业中需要一个由 SOA 实践专家组成的有代表性的社区,这个社区负责决策并且解决 SOA 的实施过程中发生的冲突。这个负责“战略性治理”的社区往往是组织中第一个进行 SOA 治理活动的小组。这个小组制定企业 SOA 策略,选择 SOA 实施的平台,并且给出企业 SOA 的参考架构。这些可都是大的决策!

实施 SOA 的企业中还需要一个由精通 SOA 各个领域的专家组成的小组,他们负责制定层次稍低或者说更细粒度的策略。这个小组实施“战术治理”,在新的 SOA 计划、工程或者项目准备实施时成立,其成员通常来自“战略治理小组”之外,并且分布在企业中的不同部门。因此,这个小组更加面向实现,更关注交付使用和最终的业务结果,同时他们要做大量与“战略”治理沟通一致的工作。

说明白一点,“战略治理”的结果通常就是一套完美的企业 SOA 策略,这些策略往往是基于尖端技术、仍在演变的标准和最新最伟大的市场架构,有时甚至是开发商刚刚宣布过此版本要一个季度后才能稳定下来。另一方面,“战术治理”的结果是在某个特定集成项目中,为每个治理策略配置具体的 SOA 平台。这两个方面必须保持一致才能使治理落到实处。

让我们举个实际例子给大家以感性的认识。FastCom 是一个虚拟的通信公司,为了在某些市场投放某款产品,它需要与另外一个名为 SpeedyCable 的虚拟的通信公司进行业务集成。这两个公司的“战略治理”小组都各自有一套完美的企业 SOA 架构和策略。在首次“集成碰头会”上,架构师们将分别阐述各自的“战略 SOA 策略”。这时很有可能发生的情况是两个企业在技术能力与策略上都有一定的差别。

此时,架构师们将会离场,只留下各个领域的专家去就策略进行谈判,从而形成一个“战术性”的集成方案。随后两个公司的开发人员和项目经理们会每周碰面,就安全、计划、标准、数据转换以及其他一揽子需求进行讨论磋商。“战略小组”决定策略的定义和策略审查的地点,而“战术小组”则决定具体采取哪些策略,在哪里制定这些策略以及策略用以哪些方面。

一言以蔽之,战略治理和战术治理不同之处在于对待企业 SOA 策略的方式不同。

SOA 的六根支柱

对一个成熟 SOA 项目的各个模块或者支柱有全面的理解是取得良好治理效果的另外一个关键因素。一个企业的 SOA 项目当然可以只有基本的支撑机制,但是随着企业 SOA 项目规模的增加和不断成熟,更多的支撑是必不可少的。SOA 不同方面需要不同的 SOA 治理方法,同时它们对策略的影响也会不同。

在这里需要强调一点:策略是 SOA 治理的关键所在。因为所有 SOA 治理努力无非就是想给出企业自身的 SOA 策略的定义,规定哪些人来制定这些策略,这些策略存放在哪里,策略更改所需步骤,对策略进行复审的场所以及实施这些策略所需要的系统和工具,编制策略文档的团队成员等等。

这么说吧,支撑 SOA 策略的有六根支柱。下面就让我们简要介绍一下它们:

  1. SOA 生命周期模型
  2. SOA 组织结构
  3. SOA 过程
  4. SOA 服务集成组合
  5. SOA 工具
  6. SOA 技术

这些支柱支持“自上而下”和“自下而上”两种 SOA 项目开发模式。理解这些支柱可以对“自上而下”或者“自下而上”的 SOA 治理有更清晰的定义。“自上而下”的治理从战略出发。它始于模型,着眼于多个项目,然后一路向下,依次定义支撑企业 SOA 的人员、过程、服务、工具和技术。与此相反,战术治理小组自下而上,往往只定义某一个项目的技术、工具及其需要创建的服务。如果一个实施 SOA 的组织比较草根化,结果往往就是从单个领域面向服务的努力出发的“自下而上”的模式。此种企业通常的做法是在单个部门或业务单位做试点,首先开发出项目原型,然后再着手制定 SOA 战略,但是这么做的结果往往是增加了建立治理从而启动企业 SOA 的复杂性。

基于上述原因,我们从“自上而下”的 SOA 治理模式开始,首先定义 SOA 治理生命周期的概念。

SOA 的第一根支柱是企业 SOA 生命周期模型。“SOA 生命周期模型”简单地讲就是支撑和定义一个企业 SOA 工作的模型。需要强调的是 SOA 治理本身也是一个支柱。事实上也正是这个生命周期模型详尽地说明了治理对任何的 SOA 项目或者努力来说都是一个非常重要的模块。这个模型往往会详细阐述以下几个方面的内容(过程、组织、工具和技术会依次对应到相应的方面):

  1. SOA 业务管理
  2. SOA 计划
  3. 服务开发
  4. 客户发展
  5. 集成配置
  6. SOA 平台、服务与集成产品的支持
  7. SOA 项目市场推广
  8. SOA 报告与分析
  9. SOA 治理

典型的 SOA 生命周期的概念这里就不多谈了,如果有兴趣可以参考 http://en.wikipedia.org/wiki/SOA_Lifecycle

SOA 的第二根支柱就是企业的“SOA 组织结构”,即从事 SOA 的人员以及其组织方式。此方面既可以按职能划分也可以按机构部门进行划分,但最好是能以书面的方式确认各个人员的职能,然后将人员分散到各个部门中,形成人员与部门的松散耦合。以这种方式形成“SOA 组织”有很大的灵活性,因为机构部门内部总是在不断变化,但是从事 SOA 治理的人的职能却不会变,即使他们的头衔发生了变化。通常,“SOA 组织结构”将规定哪些人能参加 SOA 策略的讨论,谁将进行策略的最后决策,谁对配置 SOA 策略进行配置,谁有进行复审的权限等等。

第三个支柱就是企业的“SOA 过程”,也就是 SOA 在企业中的运作方式。非常重要的一点是,这些过程必须能映射到刚刚提到的 SOA 运作生命周期的各个方面。建立服务、集成配置、客户端开发、服务规划、将服务添加到服务目录、策略的制定与更新、SOA 平台和工具的产品支持等等都需要 SOA 过程的支持。这样才能将任务分配到人,规定开发规程中需要形成的制品,以及实施过程中需要交流沟通的地方和每个步骤所需要的时间。其实,在将 SOA 过程文档化的同时,治理也就慢慢以一种更加具体的形式建立起来。过程中的决策点将成为所谓的“治理门”,而且需要跟“战略治理”本体以及复审会话相一致。总之,建立“SOA 过程”对于企业由“部门 SOA”向“企业 SOA”的成熟过渡来说是至关重要的一环。

SOA 的第四根支柱是企业的“服务与集成组合”。这个支柱定义企业 SOA 所能提供的服务,这些包括已经部署、正在计划和业已产品化的等各类服务。这个支柱将企业服务映射为企业的业务功能,它将企业服务变为企业业务的一个实体单元和展示。这一块的治理主要是规定谁去创造和支持服务以及服务的部署时间。实质上,这个方面的治理就是围绕服务什么时候建立和如何验证服务的正确性上来制定策略。这往往是一个被遗忘的角落,以致相关的策略往往是最后才会制定出来。这里也正是既进行“自上而下”又进行“自下而上”治理的企业中这两者的汇聚点。

第五个支柱是企业的“SOA 工具”,简单地说,也就是一个企业用于支持 SOA 工作的工具和系统,其包括一些概念上的参考架构和在架构蓝图范围内的系统实现。它是一些 SOA 基础设施所要求的,目的往往是为了前期研究和存档需要。编制文档用以详细阐述系统需要支持的过程和在 SOA 中使用工具的人员,此项工作对实施 SOA 的企业来说是非常有用的,编制的文档为企业 SOA 中正确地选择工具提供了“用例”和“功能需求”。工具往往可以用来强制地实施策略或者成为储存策略的地方,这样看来编制这些文档变得至关重要。有三个用以存储 SOA 策略的工具,四个强制实施这些策略的工具,另外还有两个去建立这些策略的工具,这样的做法使情况变得复杂并且阻止了强有力的 SOA 治理的进行,因为不同的系统使企业的 SOA 策略变得无法管理,这些减轻治理手工劳动的自动化工具反而使治理的管理复杂化。基于此,我们建议,如果想要好的治理效果能尽快显现出来,治理工具应该在其他 SOA 的支柱都定义完成之后再行购买。

第六根支柱是企业的“SOA 技术”。这是指企业选择的用以支持 SOA 实施的技术标准。这个方面的治理围绕特定技术标准及其版本的选择展开。如果组织内部能舍弃刚刚发布的崭新的新标准,而就使用成熟而且具有最小共同性的标准达成一致的话,此方面的企业 SOA 策略的制定变得非常容易。这里最关键的工作是“战术小组”给出自身的技术选择,并且与“战略小组”配合使这些技术选择得以批准通过、在部门间得以标准化并且存档等。这些工作使得 SOA 服务得以汇聚,因为企业的服务组合能够得到时间的验证(组合服务也能更快捷简便地建立起来)。

治理的下一步

既然对不同类型的治理和治理对 SOA 六根支柱的支持有了清晰的理解,我们就对 SOA 治理建立起了基本的概念。

下一步,可以遵循一系列的步骤来使 SOA 治理工作变得规范化并且验证治理的目标是否得以实现。我们需要从回答以下这些重要的问题并且将其存档开始:

  1. 在我们的组织中“战略治理”体是什么?他们现在是否负责 SOA 治理决策的制定?
  2. “战术治理”小组都有哪些人组成?是哪些人在负责 SOA 项目策划及其启动工作?他们是否对技术标准或者过程编制了文档?
  3. 企业中是否有人对企业 SOA 模型进行了概念化工作?如果有的话,在哪里可以找到这些模型,在哪里可以对模型进行学习?
  4. 对企业目前支持的 SOA 功能是否进行了存档?谁负责将这些功能分配给具体的部门或者小组?
  5. 对支持企业 SOA 模型的过程是否进行了存档?建立服务、设计服务、部署服务、注册服务、配置服务以及得到帮助支持或者说询问策略中的异常情况处理方式的过程分别是怎样的?
  6. 对企业已经提供的服务是否进行了存档?是否能将这些服务与我们的某一业务领域,产品或者功能进行对应?是否有人对服务的发布进行计划并能说明计划中的不足?
  7. 是否有人对企业 SOA 的工具与 SOA 参考架构进行了对应工作?目前的 SOA 工具集能为企业提供些什么?是否遗漏了什么功能?是谁负责工具的选择工作?
  8. 是否有人对技术标准和具体的技术选择进行了存档工作?对技术上异常情况的处理方法是什么?如果有人未能遵循企业 SOA 策略须围绕 SOA 技术进行制定的规律,其结果会怎样?如果遵循了技术标准结果又是怎样?

结论

良好的治理一个重要方面是分清“战略治理”和“战术治理”的区别。成功地启动 SOA 治理的企业往往会在承认“战略治理”小组的权威性同时赋予“战术治理”小组实现商务价值的权利。两个小组都要对策略的异常处理路径提供支持。为了能达到互相配合,协同一致,避免不必要争论的目的,“战术治理”团队必须支持“战略治理”制定的策略标准集并且将其提供的“异常路径”过程落到实处。

剩下的一些治理工作都是脏活累活了。在企业里对治理进行定义往往是一项非常棘手的工作,它包括角色和功能以及人员、过程、工具、技术、服务的详细说明、存档、梳理以及将其集成到组织模型里等工作。虽然很多人认为这纯粹是在浪费时间,但是回答这些问题对企业 SOA 治理进行完整定义非常有用,我们坚信花在这个上的时间比寻找一些根本不存在的问题的答案的时间要少得多。如果能提出正确恰当的问题并且将其答案简单存档,基本的治理工作会在数周内实现。

关于作者

Ed Vazquez 是 MomentumSI 公司主管 SOA 业务创新的副总裁,目前主要领导企业的改革实践工作。Ed 有着超过十年的 Web 应用管理经验,其中的六年在从事 SOA 和 Web Service 实现管理工作,曾领导过 Sprint, Pfizer 等大公司的企业业务与 IT 组织改革项目。在专注于企业改革和创新工作之前,Ed 从事过 SOA 生命周期、SOA 治理和业务驱动 SOA 等方面重大专家课题的研究工作。Ed 毕业于堪萨斯大学 (University of Kansas),在那里他相继取得了学士和硕士学位。

查看英文原文: Service Oriented Architecture Governance: The Basics - - - - - -

译者简介:孙涛,华中科技大学物理电子学专业硕士毕业,现就职于 9spaces 网络中国分部,从事 Java EE 应用开发和管理工作。目前主要关注基于 SOA 的软件架构设计,RIA 以及信息检索和信息抽取等技术的发展和进步。曾发表有关电磁波算法应用类论文两篇,其中一篇被 SCI 索引收录。参与 InfoQ 中文站内容建设,请邮件至 china-editorial[at]infoq.com

2008 年 1 月 10 日 01:07886
用户头像

发布了 23 篇内容, 共 37352 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
  • SOA 与云计算有多大关联?

    在最近的ebizQ的云QCamp大会上有一个分会场讨论了云计算的当前状态以及它与SOA之间的关系等话题。与会成员达成的共识是云能够加强SOA所承诺的那些优势,并促使其为业务提供更坚实的基础。

  • 为 SOA 设立卓越中心

    随着SOA愈渐成熟,SOA治理的重要性也不断提高。SOA治理有助于提高对SOA的组织支持感并保证SOA实施过程中的纪律性。启动并实施SOA治理的一种办法便是设立SOA卓越中心。

  • 大咖对话 | 刘俊强:云计算时代技术管理者的应对之道

    使用云是一种手段而不是目的,我们的目的是实现IT现代化,通过标准化和自动化的云战略来辅助实现最终目的。

    2019 年 3 月 29 日

  • 文章:SOA 治理基础

    文章作者Ed Vazquez进行过大量有关SOA生命周期、SOA治理和业务驱动SOA等方面课题的研究工作,并且拥有六年的SOA和Web Service实现管理经验。Ed在文章中重点是谈论在建立SOA治理过程中最基本的一些话题。

  • 资助 SOA

    在Web上的一个快速搜索表明,资助SOA几乎像禁忌话题一样很少有人提到。Todd Biske为我们提供了一个Gartner应用体系结构开发与集成(AADI)高层会议上对这个话题讨论的概要。

  • 深入理解微服务架构:银弹 or 焦油坑?

    微服务与SOA究竟有什么关系?

    2018 年 7 月 14 日

  • SOA 的未解之谜

    eBIZQ的Joe McKendrick在他最新的一篇博文中谈到了SOA周围的一些未解之谜:SOA与云计算的区别,在人们还没有完全实施SOA之前何来SOA的失败,如何度量SOA的成功等。

  • 书评:《应用 SOA》

    《应用SOA》是由四位一流SOA专家合著关于SOA的新书,其主旨是帮助你成功地实施SOA。尤其是,这本书将帮助你把你的SOA项目与企业架构、IT治理、核心数据和BPM项目结合起来。

  • 抽奖|《DDD 实战课》沉淀成书了,感谢有你!

    留言区参与互动,将有机会获得作者签名书一本。

    2020 年 11 月 13 日

  • SOA 与微服务的比较和对比

    微服务与SOA这两种架构风格经常被人们拿来进行比较与对比,有些人认为这两者互不相干,而另一些人则相信他们具有密切的血缘关系。Matt Braiser最近在一篇文章中也对这一话题展开了讨论,他的观点倾向于后者,即两种架构具有很高的密切度。他相信,微服务的出现应当归功于SOA原则的成功,并在文章中给出了他的理由。

  • SOA 治理中的角色

    本文探索了成功的SOA治理需要的一套潜在的角色:“SOA领域架构师”角色,“SOA平台架构师”角色,“服务设计者”角色,“业务服务所有者”和“技术服务所有者”。你可以采纳这些名字,也可以选择一套更适合你当前情况的术语,但是我相信在接下来本文中提到的那些任务对应的角色需要在各种情况下正式的授予,这样可确保SOA能实现它做的所有承诺。

  • 先做好 DDD 再谈微服务吧,那只是一种部署形式

    想要做好微服务,关键在于服务的划分,而划分服务,最好先学习 DDD。

    2019 年 4 月 5 日

  • SOA 治理:企业视图

    SOA架构师Michael Poulin解释了SOA治理在确保SOA项目成功中的必要性,并解释了OASIS SOA参考模型以及SOA治理所对应的SOA参考架构。Michael从企业的视角观察了SOA治理的细节,并通过几个SOA治理策略的实例进行了阐释。

  • 企业 SOA 到头了?

    Joe McKendrick、Jeff Schneider与其他人讨论了企业SOA是否已踏上不归路,毕竟务实/非正式(pragmatic/guerilla)SOA可能是最佳方法。

  • Spring Bean 注册阶段:BeanDefinition 与单体 Bean 注册

    2020 年 3 月 5 日

  • SOA 治理:在流程与机动性之间取得平衡(作废)

    Mike Kavis声称“缺少可靠治理模型的SOA实现无异于一个没有指挥塔的机场”。在他最新的一篇文章里,他对如何在流程与机动性之间获得平衡给出了指引。

  • 案例研究:SOA 在 CISCO 公司取得成功

    Cisco公司的首席架构师在最近一次SOA联盟会议上分享了他们的制品、逸闻和技巧,内容涵盖由四步骤组成的成熟流程、主要的设计关注点和SOA平台。他还谈论了涉及人员、流程和技术维度的成功因素,包括企业参与的重要性,以及流程、策略和规则的业务所有权。

  • 怎样准备你的 2008 SOA 预算?

    行业内开始发出对于SOA项目的ROI警告之音,它已经被证明往往是长期且复杂的。尽管许多人仍然将重用和灵活性看作是主要竞争资产,但当他们在准备2008预算的时候,他们可能还是会彷徨:从哪儿开始呢?怎样快速地论证价值呢?怎样随时间推移增加我们的成熟度?我们的技能源自哪里?

  • SOA 的管理策略

    Mike Kavis为SOA协会撰写了一篇文章,他在文中将SOA的成功实现归结为4个因素:人员、流程、技术和业务。他认为,一个好的管理策略将创建和传达一个路线图,它将划分出这些领域中的可提交结果。

  • 中台落地第四步:中台的建设与接入(Delivery)

    如何采用精益的产品研发流程交付一个中台产品?中台建设过程中如何持续治理?怎么做中台的运营管理?今天我们一起来探索。

    2019 年 9 月 25 日

发现更多内容

Defi系统APP开发|Defi软件开发

开發I852946OIIO

系统开发

保障系统稳定高可用的方案

天天向上

极客大学架构师训练营

智慧公安大数据分析平台开发解决方案

t13823115967

大数据技术 大数据平台 智慧公安

Windows下常用软件配置

jiangling500

windows 软件配置

Defi挖矿软件系统开发|Defi挖矿APP开发

开發I852946OIIO

系统开发

只能用分布式锁,也能搞定每秒上千订单的高并发优化?

Java架构师迁哥

腾讯 WXG 后台开发工程师对 MySQL 索引知识点总结

Java架构师迁哥

Kafka 和 RocketMQ 之性能对比

公众号『中间件兴趣圈』

kafka 源码分析 RocketMQ 中间件 性能分析

Week 11 work

黄立

系统安全与高可用

天天向上

吴桐:2021年中国区块链产业发展的六大趋势

CECBC区块链专委会

区块链 新基建

Spring 源码学习 06:AnnotatedBeanDefinitionReader

程序员小航

Java spring 源码 源码阅读

《操作系统概述》-第六版

计算机与AI

操作系统

可参考才是有价值的,架构设计的技改之路从来都不容易

互联网应用架构

架构设计

公安警务大数据可视化平台开发建设

t13823115967

大数据 大数据平台 智慧公安

第二周作业

Geek_b9053c

依赖倒置原则

依赖倒置原则以及接口隔离方式实现接口设计

我们新四军不拿群众一针一线

拆解增长黑客之知识篇

丁一

产品 运营 增长

京东云的云原生理念及Serverless最佳实践

lidaobing

两年竞业禁止、没有赔偿的CTO | 法庭上的CTO(1)

赵新龙

CTO 竞业禁止 试用期

区块链如何解决互联网为基础的广告困境?

CECBC区块链专委会

区块链 互联网广告

LeetCode题解:52. N皇后 II,回溯+哈希表,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

架构师训练营第十一周

我是谁

极客大学架构师训练营

架构师训练营第二周课后作业

万有引力

第一周作业

极客大学 极客大学架构师训练营

智慧公安大数据分析平台开发,警务通APP系统开发

WX13823153201

架构词典: 复盘

lidaobing

架构 复盘

从战略到战略决策

Alan

战略管理 使命 愿景 战略思考 MVO

vue高级进阶系列——用typescript玩转vue和vuex

徐小夕

Java vue.js Vue 前端

区块链中的保险行业

13828808769

区块链技术应用开发 保险理赔

第二周 框架设计 作业一 「架构师训练营 3 期」

feiyun123

极客大学架构师训练营 框架设计

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

SOA治理基础-InfoQ