七个技巧削减供应商维护商业应用投入

日期: 2010-06-09 作者:Linda Tucci翻译:陈德彦 来源:TechTarget中国 英文

当谈到商业应用时,供应商持有这个王国的关键因素,而且停止供应商维护计划对于任何中端市场组织可能是可怕的。但是,据分析师讲,失败的风险可以缓解,特别是对已经可靠地运行的商业应用。   Gartner公司分析师、Grant Thornton LLP财政和人力资源系统前建设者和经理Pat Phelan说:“如果它已经运行了5年,还没有发生故障,你冻结了这个环境,且不改变它,那么有可能它将恰好保持继续运行。”   她说,通过了解你对商业应用的访问权限,了解它适应你的IT 基础设施的方式,检查整个应用程序堆栈的事故历史——首要的是——确保变更保持绝对最小,这样你可以保持应用远离伤害。

  在这里,我们列……

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

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

当谈到商业应用时,供应商持有这个王国的关键因素,而且停止供应商维护计划对于任何中端市场组织可能是可怕的。但是,据分析师讲,失败的风险可以缓解,特别是对已经可靠地运行的商业应用。

  Gartner公司分析师、Grant Thornton LLP财政和人力资源系统前建设者和经理Pat Phelan说:“如果它已经运行了5年,还没有发生故障,你冻结了这个环境,且不改变它,那么有可能它将恰好保持继续运行。”

  她说,通过了解你对商业应用的访问权限,了解它适应你的IT 基础设施的方式,检查整个应用程序堆栈的事故历史——首要的是——确保变更保持绝对最小,这样你可以保持应用远离伤害。

  在这里,我们列出了Gartner关于如何正确关注,并处理供应商支持项目中终止的商业应用的七个步骤。

  列出你拥有或者没有的工具、脚本和源代码清单。

  据Phelan讲,在打包应用的早期,厂商不出售维护服务,因此,就出现了包括源代码副本和维护副本的编译器的客户合约,或者作为交易的一部分,或者在供应商倒闭的情况下由第三方托管。今天,这种情况很少发生,但她说:“仍有包含源代码副本的有效合约。”例如,PeopleSoft公司和Siebel系统公司,公布了源代码和编译器作为交易的一部分。

  供应商也提供(付费的)诊断工具。它可以通过识别出现得错误,帮助调整和管理应用。最后,还有一些工具,作为许可协议的一部分,旨在让用户修改应用的展现层。

  底线?在你撤销维护以前,你应该知道你对应用的哪几层有访问权限,以及许可协议允许你或代表你的某人对应用做哪些技术变更。

  检查系统相关性,并确定基础设施涉及的所有元素。

  对数据库、操作系统和各种工具所做的修改可能会导致你已经脱离供应商维护的商业应用失效。如果应用程序运行在较老的数据库版本上,并且企业突然决定升级或改变已有的数据库,例如,从Oracle改为IBM的DB2,Phelan说:“你也许想知道关于数据库升级和替换的可行性。但你也许不得不冻结环境,因为你不能使脱离维护的应用工作在DB2上。”

  这同样适用于以友好的收购获得的软件工具。例如,如果SAP AG决定在不同的方面采用它的新的 BI工具——BusinessObjects,Phelan建议,你不希望一直升级到BusinessObjects不能在脱离供应商维护工作的这个点。

  考虑回滚支撑服务(操作系统、数据库和应用服务器)到以前支持的版本。

  Phelan说:“偶尔,我会让已经冻结操作系统或者数据库系统的旧版本的客户,为已经脱离维护的应用保留环境。”

  但是,通过升级直到应用中断,许多组织将商业应用推到尽可能远的地方。然后,他们终止恢复到某个版本。她说:“那样做,不是一件坏事情,但每次你这样做的时候,它正好引入了风险。我们的建议是稳定、保留环境和最小化变更。”

  实施保护层以减少安全问题。

  Phelan说:“这意味着在环境周围放置围栏,以便你可以最小化任何变更。”你隔离应用越彻底,它就有更少的可能性引入新的安全保护。

  她说:“我们还建议在系统前面放置一系列的可信赖的域名代理。”这样,应用不再获得新的安全威胁以辅助威胁的入侵,并需要保护层。

  只允许少数几个管理主数据的系统管理员访问应用程序栈的所有部分。

  Phelan说,这是艰难的,因为今天的打包应用被设计允许用户“对配置、主数据或者一切进行基于打包的变更。”告知所有员工,变更要得到管理部门的批准,可以是CIO或具有领导角色的某个人。

  她说:“你不希望人们进入那儿去引入配置变更,或者开始在周围胡闹,这个应用是如何部署的,因为这也算作变更。”

  考虑修改事件管理流程和监视规则,以至于可以尽早识别不能容忍的性能问题。

  Phelan说:“你的环境已变得僵化,因此任何事情都可能是一个潜在的问题,你需要尽早识别它们,因为你为解决这一问题的可选项已经潜在地缩水。”

  有事例吗?数据库开始变得不堪重负,你必须经历数据库重组。否则你将经历一个功能性事件,像年终处理。你必须监视性能。Phelan说,这对老的应用是很严肃的建议,即使它们处在供应商的维护计划中。在这些情况下,一个供应商无论如何也不可能为你做很多。

  Phelan说:“如果您有容量或性能问题,他们不会为那个旧版本核实一个修补措施。”最后,你只能为时间和专家建议向供应商支付费用,让供应商介入、分析和解决问题——如果你仍然有一个供应商的维护合同,这也是类似的。

  在应用停滞前,为了使用户预先知道而通知用户。

  Phelan说:“坦率地说,用户对此非常满意——‘哦,感谢上帝!每周,对我来说,你不会变更它。’。”

  然而,对此,另一方面,用户群不断地要求可定制化和变更。CIO们需要定期跟踪应用,以衡量在冻结的应用中可用的以及业务想要的之间的差距。Phelan说,如果分歧过大,就是继续前进的时候了。

作者

Linda Tucci
Linda Tucci

Executive Editor Linda Tucci oversees news and e-zine projects for SearchCIO.com and SearchCIO-Midmarket.com. She has covered CIO strategy since joining TechTarget in 2005, focusing most recently on big data, mobile computing and social media. She also writes frequently about the CIO role and CIO careers for SearchCIO.com's weekly CIO Matters column. Prior to joining TechTarget she was a business columnist for the St. Louis Post-Dispatch. Her freelance work has appeared in The Boston Globe and T

相关推荐