如何融合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已死的信号,其实只是旧技术换了个新名字。

技术手册>更多

  • SOA生命周期

    服务生命周期管理是SOA治理向SOA及SOA服务的实际构建中的一个应用。然而,治理属于业务涉众,管理是技术人员(负责“实现”的团队)的权限。服务生命周期管理必然与SOA治理紧密结合,因为在软件交付的每个步骤(从业务分析人员到架构师到开发人员到测试人员,再到操作)上,确认了将要构建的内容结合了企业的明确业务需求是关键的。 

  • OSGI教程

    OSGI服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理,OSGI技术提供一种面向服务的架构,它能使这些组件动态地发现对方。

  • SOA与遗留系统详解手册

    遗留系统是一个已经运行了很长时间的,对机构来说是很重要的系统,但是往往不知道如何处理的大的软件系统。它与平台相关,但不能在网络环境中直接访问。另外,遗留系统不能直接访问存储在各种数据库管理系统中的数据,但由于遗留系统所完成的是关键业务,所以不能简单丢弃。本技术手册提供了一些意见和技巧,仅供参考。

  • 企业架构模式指导手册

    有效的企业架构对企业的生存和成功具有决定性的作用,是企业通过IT获得竞争优势的不可缺少的手段。SOA的目标就是实现灵活可变的IT系统,技术上通过服务组件的标准化封装、复用、松耦合可编排来实现一个一致的IT架构,并通过SOA的治理来实现架构在企业IT运营过程中提供一个策略,来保证架构的实施符合企业治理的需求。这与企业架构的概念、活动、流程和结果方面存在契合点。深入探究就会发现,SOA和EA是相辅相成、珠联璧合的两套方法论体系。SOA要落地,EA是最个最佳的利器。

TechTarget

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