面向服务架构SOA的演进与IT治理

日期: 2008-08-14 来源:TechTarget中国 英文

  面向服务架构(Service-Oriented Arthitecture,SOA)提供了一种方法,可以把企业的业务战略和必要项目与IT项目结合起来。因而,SOA治理不但涉及技术,同样涉及组织问题以及人员如何协同工作来实现业务目标。


  IT治理涉及获得进行变更的批准,涉及权力,涉及谁拥有这种决策权,涉及在业务迅速变化的形势下这类决策需要多长时间。SOA通过减少决策的发生,从而大大减少了IT治理的需要。不过,为了获得这种好处,贵企业必须首先采用SOA。


  SOA的演进


  采用SOA并不能让你迅速获得投资回报,反而需要战略性投资,包括在结合IT和业务的治理和文化变化方面进的投入。不过据Gartner公司的分析,这不是SOA会不会取代如今架构的问题,而是完成这种演进需要多长时间的问题。


  想要采用SOA的许多公司面临的一大绊脚石,那就是目前的IT成本分摊模式。许多公司把项目开发和支持的成本与批准项目的业务部门一一对应起来。在SOA中,服务常常在多个应用和业务部门之间共享,这就意味着你可以就参与SOA战略的某个项目向以后使用服务的每个人收费。


  一种比较好的方法是为SOA应用资产设计共享分摊结构,甚至抵消可能高于采用非SOA方式的独立开发所需成本的SOA开发成本。因为只有服务被多方使用后,才能够得到重复使用的好处,所以要有激励措施确保来发布及设计可重复使用的服务。同样,也要有激励措施来促进充分利用现有的企业服务。如果你正在实施外包项目,对于应当加以的积极管理,特别难以实现。


  公司在与负责实施的合作伙伴打交道时,似乎更容易忽视治理和执行方面的工作。举例说,常常由IT部门外的个别业务部门决定把某些项目外包出来。即使在IT部门里面,针对批准厂商列表和采购的重点往往与内部治理流程和决策机制相脱节。


  IT治理和SOA采用


  SOA面临的挑战之一就是实施不是一蹴而就的,而是要通过跨越空间和时间的多个不同项目才能实施完毕。SOA项目的这种空间和时间分布使得治理对SOA的成功而言更加至关重要。SOA治理和可执行的策略是确保跨地域和跨时域,这也符合SOA的两大关键。


  空间分布、数量激增的服务(需要由企业内外的不同部门来维护)以及时间分布(随着支持的业务流程不断变化,服务本身或者服务组合随之不断变化),这一切使得治理特别具有挑战性。从很大程度上来说,只有服务符合服务级别协议(Service Level Agrement,SLA)在安全、可靠性、性能和成本等方面规定的要求,跨组织边界分布的这些服务才能够正常、有效地使用。只有设立合规办公室,对整个企业进行监管,并且由业务分析人员和软件开发人员等代表组成,才能最有效地进行识别、指定、创建,然后部署企业级服务,从而实现SOA治理。


  人们很容易纠缠于实施SOA方案的技术细节。幸好,SOA治理使得业务和技术之间合作的重要性重新受到关注。到最后,重要的不是技术,而是客户是否采用。如果最终用户认为自己能因而创造经济效益,才会采用及使用基于SOA的应用。


  传统和联合的治理方案


  过去有两种IT治理方案:集中式和分散式。


  至于前者,IT部门对开发预算及技术标准的采用保留控制权。业务和IT部门之间的这种关系有时很紧张。业务部门需要迅速实施新战略的敏捷性,于是把需求交给IT部门;不但实施所需的功能似乎需要很长时间,许多信息也常常会在需求文档到可执行系统之间的转变过程中丢失。至于后者,预算和技术事务方面的一定权力交给经营单位,甚至交给这些单位下面的单个部门。由于相对缺乏集中监管,这批独立用户最终开发出来的系统从长远来看协同工作的效果很可能不是特别好。


  由于只有这两种IT治理方案,IT部门只好面临这种取舍:要么现在牺牲响应时间,让权力集中在中央的IT部门,要么之后面临失去控制的分散环境带来的后果。


  不过,SOA有望采取中间路线。这是一种基于标准和服务的方案:注册中心(repository)和平台作为系统核心,而服务使用方进行的建模和应用开发为业务分析人员及其他分布的战术用户给予了很大的自由度。战术使用和战略监管的这种分离也为在特定情况下实行治理带来了机会。在这种联合架构中,SOA把IT方面与业务方面分离开来,为各自提供了一直寻求的东西。企业首次能够获得统一IT架构带来的优点,同时又能在IT方面获得新的灵活性,足以满足业务要求。


  SOA的一条根本原则就是业务逻辑与应用逻辑相分离。业务分析人员得到了这种能力:定义、变更及修改SOA服务支持的业务流程。IT部门的责任同样明确:它必须管理从应用逻辑直到物理基础设施的整个部分。IT要负责SOA的底层平台,即注册中心。


  这并不是说IT和业务以后根本不再协商;而是通过为业务部门提供使用关键业务流程、利用现有企业服务组建应用的敏捷性,从而减弱对接口的需要,并且减少相关问题。


  业务部门获得了这种能力:进行战略性变化,又不危及应用生态系统,无须通过IT部门对整体式应用(monolithic application)进行重大改动,再次让每方各取所需。


  当然,这种联合架构自身也带来组织难题。除了由传统的治理委员会监管服务和平台的完整性外,公司和CIO如今必须处理这个问题:到底把多大权力交给业务分析人员及其上司,还要考虑治理领域的范围和界限;每个领域里面谁有权施加影响、提供咨询,以及最后作出治理方面的最终决策。


  仍必须进行取舍,不过这回是在灵活性和组织复杂性之间进行取舍。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • SOA治理模型核心:人

    治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。