应用管理由哪些活动组成?
发布时间:2010年06月02日点击数: 作者:ITGOV中国IT治理研究中心 来源:ITGOV中国IT治理研究中心
【字体: 收藏 打印文章
摘要:
应用管理流程包括两组流程:  第一组是关于对应用系统的业务量和业务价值进行规划和管理的流程,这些应用系统和能力、框架以及进行有效的应用管理所需的工具一起支持组织的业务需求;  第二组是关于整个应用管理生命周期内每个应用系统的开发和管理的流程。

应用管理流程包括两组流程:

第一组是关于对应用系统的业务量和业务价值进行规划和管理的流程,这些应用系统和能力、框架以及进行有效的应用管理所需的工具一起支持组织的业务需求;

第二组是关于整个应用管理生命周期内每个应用系统的开发和管理的流程。

第一组流程“管理业务价值包括下列几个阶段

整合业务和IT

高级别的业务和IT体系结构

关键业务驱动因素和SMART目标

组合管理和应用组合

准备就绪评估和交付战略

集成应用管理生命周期

贯穿应用管理生命周期

第二组流程应用管理生命周期包括下列几个阶段(见图-1):

需求;

设计;

构建;

部署;

运营;

优化。

1.1.1 管理业务价值

为企业创造价值的不是技术,而是技术得以部署从而满足业务需求的方式。通过在规划和实际创造IT的业务效益的过程中实施应用管理,应用系统可以支持组织大部分的业务需求。

1.1.1.1 整合业务和IT

整合业务需求和IT主要是在应用管理流程中进行的。必须建立业务和IT管理规划和评审流程,据此业务负责人和IT管理人员可以识别企业内部的业务功能(业务单元和部门),也可以了解那些处于变化之中的业务流程和业务目标。这个管理规划流程对于实现IT和业务的整合是非常关键的,并有助于对IT应用系统的开发和部署进行规划和支持IT基础架构。

规划流程应该使用一种建筑学的方法根据组织的业务功能描绘现有的和需要的IT服务和应用系统。

1.1.1.2 高级别的业务和IT体系结构

组织需要制定适当的业务和IT体系结构来指导IT的开发以支持组织的业务功能。该体系结构的范围可由战略整合目标模型(SAOM)来表示。

战略整合目标模型是基于这样一个原理,即业务流程是由应用系统来支持的,而应用系统又构成了下面模型中右边的IT系统和IT服务的主体部分。进而,可以确立如下列模型右边所示的关键业务驱动因素和服务级别协议(SLA’s)以及运营级别协议(OLA’s)之间的关系。

战略整合目标模型中各组件之间关系的特性可以由图17-2所示的实体联系图来表示。

战略整合目标模型提供了一个很好的工具来根据业务驱动因素和应用需求显现关键业务功能和IT服务和能力之间的关系。

1.1.1.3 关键业务驱动因素和SMART目标

支持应用管理生命周期控制的前提假设是关键业务驱动因素,可定义如下:

定义关键业务驱动因素是一种ITIL最佳实践的作法。他们控制了企业愿景和使命的实现情况。对这些关键业务驱动因素统一地加以考察有助于对那些全企业都应该集中精力去做好的事情形成一个普遍的认识。无论一个公司怎样定义其关键业务驱动因素,它们都应该具有如表17-3所示的几项公共的特征:

上述的SMART属性不应仅限于关键业务驱动因素,而应该拓展至由这些关键业务驱动因素所推导出的目标和需求。尽管SMART概念在设定目标(包括关键业务驱动因素)方面并不是一个项创新,但它通常仍然没有得到一贯的应用。许多项目没有成功地完成,也是因为这些项目都基于一些模糊的或定义不清的目标。

这里的挑战就在于如何将关键业务驱动因素与应用管理生命周期结合起来,从而对整个生命周期的结果加以控制。

1.1.1.4 组合管理和应用组合

大多数企业都有许多的应用系统在其业务流程中支持其业务功能。组合管理是应用管理规划流程的一部分,它帮助企业管理大型和复杂的应用系统,帮助了解这些应用系统在数据共享、支持端到端业务流程以及对IT基础架构的使用方面是如何协同工作的。

应用组合可被视为一个可以存储大部分应用属性和提供一个关于应用系统之间关系的结构图的信息系统。应用组合还可以提供有关特定的应用系统或应用系统套件的信息,还可帮助了解一个应用系统与另外一个应用系统发生关联的方式。这使得可以更早地规划业务驱动性的变更以及更快地做出有关的投资决策。

1.1.1.5 准备就绪评估和交付战略

许多IT部门在不具备构建和管理复杂应用系统的能力的情况下就开始安装一些复杂的应用系统。因此,规划流程必须要确保有一个胜任的部门来创建和管理应用系统,该部门要能够维持必要的人员、流程和技术。

安装复杂的应用系统,无论是定制的还是统一封装的,都需要规划一个开发良好的协调系统来确保组织能够控制开发团队之间的合作以及对应用开发和管理指南的遵守。引进新的技术要求IT部门具有足够的灵活性,从而能够尽快地吸收新的信息并将不熟悉的技术嵌入组织的方法和流程中去。能力评估和成熟度模型,如CMM,通常被用来确定一个IT部门可以开发或支持复杂的应用系统的准备就绪度。

在应用系统的购买或支持过程中利用第三方供应商可以提供另一种应用系统交付战略,在规划业务应用和应用基础架构产品组合时值得考虑。

1.1.1.6 集成应用管理生命周期

应用开发和应用管理之间通常具有很大的区别。在应用管理生命周期方法下,应用开发和服务管理被紧密结合在一起,对它们的活动也需要加以协调。

ITIL中的应用管理主要是基于服务管理角度的。对IT服务提供具有重大影响的服务管理方面的问题在应用管理生命周期早期阶段就应该得到处理。最重要的一个方面是需要在整个生命周期各个阶段都实现基础性支持结构和工具的更好的集成。为了实现服务创建和提供之间更好的契合,需要下列信息:

应用组件及其相互依赖关系;

规划中的应用发布;

规定可以表明一个应用系统的状态和绩效的警报和事件;

规定用于监控一个应用系统的主要交易的具体指标;

服务级别;

运营需求;

支持需求。

为了补充与应用管理相关的信息,通常有必要通过应用组合、应用体系架构和应用框架来定义一个应用系统是如何与其它应用系统以及应用基础架构发生关联的。这将可以取得如下的效益:

可以加强应用开发、基础架构开发和服务管理三方之间对其相互依赖关系的互相了解,从而确保在应用管理生命周期早期就做出审慎的决策;

从第一次设计大纲到最后的部署,实现完整的应用规划;

有关能力和绩效的数据可以较早地纳入应用管理生命周期,从而能够为引进应用系统做好基础架构方面的准备;

对开发、测试和运营环境的管理得到控制,从而极大地减少了定义、构建、变更和终止上述各种环境的成本;

可以开发参考体系结构和框架,从而使创建服务(如推出服务时间)和服务提供(如可用性)两方面的需求都得到了考虑;

为阶段转换定义绩效指标时开发人员和服务经理可以使用一种共同的语言;

开发人员在构建应用系统时可以考虑服务经理的需求,从而使应用系统在移交以前可以得到管理。

1.1.1.7 贯穿应用管理生命周期

由于应用管理具有反复进行的特性,一个应用系统在任一个时间点上都可能同时处在多个应用管理生命周期的多个阶段上。这需要严格的版本控制、配置管理和发布管理。这些问题基本上都包括在《ITIL服务支持》一书中。取决于所选择的开发方法的不同,一个应用系统在某几个阶段的进展可能比其它阶段要快得多。同样,一个应用系统在部署前可能经历了几个完整的应用管理生命周期。然而,所有的应用系统在其生命周期内都必须多次经历应用管理生命周期的所有阶段。

组织需要测度一个应用系统在其生命周期内的效果和效率。流程中的变更和应用管理生命周期内各阶段之间的信息交流对应用系统的质量具有一定的影响。正确地评价每个阶段的原有特性以及某个阶段内的决策是如何影响其它阶段的活动对于应用管理生命周期内的综合管理方法是至关重要的。这种评价以及相应的行动在很大程度上决定了方法和工具的选择。

在应用管理中还需要考虑应用系统的使用寿命。维护的效果和效率受到文档记录质量的影响,而文档记录的质量又受到用于分析、设计和开发的技巧、方法和工具的影响。有些应用系统在组织愿意停用或替换之前很长一段时间可能已经过时了,这就产生了相应的维护问题。

1.1.1.8 其它生命周期模型

这里陈述的生命周期是指用于应用管理生命周期中的一种重复性的方法,如在应用开发中用到的RAD和RUP。也有一些传统的应用开发方法,如瀑布法,但这些方法一般都不鼓励使用重复和递增步骤。

使用重复性方法的主要原因是将与传统开发方法相关的风险减小到最低。这种使用递增步骤的方法意味着,一个应用系统需要在许多小步骤中逐渐交付。这种方法的优点在于,对于应用开发期间由不确定性引起的风险更易于管理,针对某些需求推出相应服务的时间也被降低了。

京ICP备06004481号   Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved