如何融合SOA与ITIL?

日期:2010-6-2来源:e-works

SOA   ITIL   IT体系结构   IT架构   

  毫无疑问,SOA部署是困难的。如果说,定义一个软件项目的成功与否是按照不超过既定成本与完成日期10%为目标,同时能提供所有预期的回报,那么可以说,软件项目的成功率只有30%左右。

  历来在IT上的变革与创新都是一种高风险系数的活动,对于那些迫于企业压力,要求进行商业革新,增加企业灵活性的CIO而言,SOA并不是一件“简单任务”。

  SOA与ITIL

  如今,有越来越多的企业开始实施ITIL来应对在优化流程,提供IT服务上的压力。ITIL活动是由上至下而驱动的。它需要得到企业管理高层的支持与推动,结合评估、战略和规划多方面的角色,以最合理的成本来满足商业部门的需求。

  SOA与ITIL在这方面相类似,成功的SOA也同样需要得到管理层的支持,梳理商业目标和资源,而不只是专注于部门层面的服务部署战略。鉴于这一原因,CIO则成为了SOA部署的关键,他们对最佳实践的判断和投资决策可以改善企业过渡到服务导向型架构的成功几率。

  IT将他们所提供的服务视为一系列技术的组合,而商业部门将服务视为一种表现形式。填补两者间的断层,以及拓展商业服务的范围,要求与企业管理层密切联合。

  SOA是一种战略

  SOA并非简单的技术部署方式,而是一种IT与商业部门之间关联方式的转变。SOA深深改变了企业IT投资和支持的方式,并要求企业内各部门间实现更畅通的沟通。

  大多数在早期成功部署SOA的企业都在治理方面经历过巨大的压力。譬如,大部分的SOA价值都源自于服务重用。一旦有多达五至六个部门在同时使用某种服务,而导致绩效下降,那么由谁来添加额外的服务器?谁来追踪服务的使用情况?谁来控制安全访问?何时需要变更服务?诸如此类的治理问题还有很多。

  一旦企业认识到SOA不只是光谈技术,那么投资ITIL及其它最佳实践也就不再有障碍。ITIL可考虑为成功实施SOA的基础。如果在IT里没有明确的流程,那么随着时间的发展,跨商业部门之间的协作就变成了一种负担,而SOA成功所必须的商业战略变更也无法有效执行。

  降低风险

  对于那些成功使用SOA来部署应用的企业而言,降低风险是最主要的回报。如果你的大部分软件项目都失败,那么风险就会随着项目的发展而逐步放大。专家发现,在成功的软件项目中,小型项目通常都占多数,而大型项目所占的比例却很少,而SOA恰恰可以弥补这一点。

  SOA本身是一种模块性质的架构。当一款应用以模块的方式来开发,那么它就等于是由一系列的小型项目所组成。这种灵活的开发方式在过去几年中发展很快,当它与某种基于服务的架构合而为一时,就能改善应用部署的质量和成功率。

  战略CIO

  IT管理人员有多种方式来改善企业SOA活动的成功机会,例如:

  由点到面——大部分成功的SOA实施都是从管理层开始入手,进行研究来发现重用、松耦合和模块化的目标,这是SOA增加商业价值的三种主要方式。

  然后他们逐步推广SOA到各个商业部门的管理人员,结合商业部门的实际情况来设定预期,解决潜在问题,展现回报。这些活动帮助IT与商业部门之间搭建了互通的桥梁,同时也让非IT管理人员参与到整个流程中,体验到SOA对他们的影响,并对企业贡献价值。

  发挥机动性——SOA的一大特征是机动性。这也是金融服务行业成为SOA主力军的原因所在,SOA活动能让他们的商业灵活性提升到一个新的等级。

  这些公司中的管理人员充分了解商业部门的要求,能够引导IT去找出合适的方法来解决持续的变革问题。就降低软件部署上的成本和风险来说,SOA是一种绝佳的选择。

  设定预期——我们常听到,在SOA部署的初始阶段是一种“烧钱”的活动。它需要大量的成本来更改软件基础架构,将现有应用平滑过渡到一个模块化的环境中,并培训开发人员来编写代码。不管是重新规划,还是拟定治理流程,都要求IT与非IT人员投入额外的时间与精力。

  而当服务重用走上正常轨道,随着软件开发可预测性的提高,以及治理流程所创造的新秩序,商业部门就可以看到预期的回报开始逐步展现。

  切合实际——SOA要求强大的技术能力,优秀的项目管理,管理层的支持,以及完善的商业流程。缺乏其中任何一环,都会抑制SOA的成功。

  SOA的成熟也需要良好的服务开发、可重复使用的流程,畅通的跨部门沟通,以及高于平均水平技术管理自动化能力。在其中,CIO负责判断在某个指定部门中,SOA回报是否大于风险。SOA当然不是万能药,但如果战略合理,部署切合实际环境,那么它就能发挥将IT与商业部门连结到一起的优势,并提高IT的能力,提供更具成本效益的服务,延伸可持续性。

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

SOA实施>更多

  • 持续DevOps文档:是必需的

    文档和管控的流程仍旧是防止企业陷入困境,保证员工不丢掉工作的有效方式,让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。

  • 避开软件容器:如何探索DevOps

    Bert Jan Schrijver,荷兰JPoint Java软件工匠,也是JavaOne大会的演讲者,他回答了SearchSoftwareQuality的有关DevOps的问题,并且回答了为什么有时应该忽略传统习惯。

  • DevOps和敏捷相结合 改进软件质量

    DevOps实际上是打破了开发人员和运维人员之间的壁垒。在运维团队,你所考虑的方面可能与开发团队不同。但如果我们能更加了解相互的工作,将会更为深入得理解所需的工具和设备。

  • AppDynamics引入应用集成平台

    AppDynamics的微服务架构应用集成平台(AIP)旨在对跨不同应用环境的应用进行统一监控,此前这一过程需要各种应用及架构相关的管理工具才能做到。

相关推荐

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

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

  • 揭秘New Relic APM技术细节

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

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

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

  • 是微服务还是SOA?

    专家认为像“微服务”和“12因子app”这样的术语未必是SOA已死的信号,其实只是旧技术换了个新名字。

技术手册>更多

  • REST开发者RESTful资源指南

    维基百科把表述性状态转移(Representational State Transfer ,REST)定义为“分布式超媒体系统、如万维网的一种软件架构形式”。Web服务的RESTful方案被广泛视为SOAP的一个更简单的替代方案。许多大型的Web服务提供商如亚马逊、Twitter和谷歌都在广泛地使用它。在这本技术手册中,我们将为您提供一些RESTful资源和技巧。

  • 企业架构师工具包

    企业架构师如何创建一个有用的工具集呢?目前实践者正在将UML和TOGAF以及其他工具连同使用,从而能够构建出软件模型解决业务构想变成工作系统最重要的一步。但是需要高度熟练的架构师,来创造业务架构参考模型。成功的软件架构师会发现和企业匹配的工作参考模型会成为他们自定制添加“工具”的框架。下面专家的一些建议可以为我们提供一些引导。

  • 解围应用集成困境指南

    集成是个很老的话题,很多时候在谈及新技术的时候,我们会避而不谈,但集成问题却一直贯穿在企业之中。应用集成就是建立一个统一的综合应用,也即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中,并使它们就像一个整体一样,进行业务处理和信息共享。要实现这样的效果并不简单,在这本手册中,我们会为您拨开一些迷雾,更好的解决应用集成所面临的问题。

  • UDDI(统一描述发现和集成)

    UDDI统一描述、发现和集成协议,是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。全称Universal Description, Discovery and Integration,它包含一组基于Web的、分布式的Web服务信息注册中心的实现标准,以及一组使企业能将自己提供的Web服务注册到该中心的实现标准。UDDI利用SOAP消息来查找和注册Web服务。并为应用程序提供了一系列接口来访问注册中心。

    UDDI(统一描述发现和集成) 提供一种发布和查找服务描述的方法。UDDI数据实体提供对定义业务和服务信息的支持。WSDL中定义的服务描述信息是UDDI注册中心信息的补充。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算