任何一篇处理应用生命周期管理（ALM）的文章都必须先定义此术语。在David Chappell & Associates中的定义，ALM代表着一系列重叠的时间线，从治理通过开发，然后进入操作。如果你使用Keane的定义，它是这样的：开发>管理>合理化。通过这两个系统，随着应用的升级或新版本的发布，有一个通过开发和管理/操作阶段多次回来的周期。治理发生在整个生命周期过短，而合理化只发生在最后一点。

　　为了我们的目的，我们将认为ALM周期的开始是从软件设计者眼中的一眨眼时间，持续到它退化、死亡和消失殆尽。ALM常常被认为是一组工具或解决方案，而不是方法论（这也是服务于厂商一侧的架构方案合并）。然而，它只是一组原则，是应用程序的‘缩放’视图——考虑到它所有影响组织的管理方式。

　　ALM的益处和陷阱

　　ALM确实是全局的IT方法。这个系统没有外部效应。设计团队为开发团队负责，开发团队则负责操作、维护、支持等等。IT整体上负责组织的设计、开发、交付、维护和最终收回应用，从而更好地支持业务目标。

　　不幸地，ALM概念并不总是执行出该组织的期望。伴随着ALM时间线（或是在周期的某个地方重复）总会有一些地方的效益丢失了并且出现了性能问题。这个项目可能会慢慢停止，应用程序可能会达不到用户期望，或者它可能不会交付业务价值。我们看到了一些这样的问题，并考虑改进IT和应用程序本身的性能贯穿整个ALM流程。

　　治理：概念阶段

　　这一阶段通常视为是从创造应用的概念开始。但是可能吧，事实上是在这之前。概念不无缘无故就出现的。在一个被动的组织内，关于需要什么类型的应用的概念是来自于对现有问题的检查。评估和诊断组织的不足之处并不是什么错事，并且不要使用这些信息消除一些事情。然而，如果你发现你的应用程序不再如你所想的它们应用获得部署那样时，那么你就需要重新考虑这些方法了。

　　高绩效的、战备组织和IT公司会考虑他们所需要的应用在将来有怎样的使用，而不只是仅仅解决当前的问题。利用这种前瞻性的方法的一个好处是，它允许IT提前计划提供基础设施和设备来支持应用程序，一旦部署开始。它也迫使业务合作伙伴和IT伙伴在计划阶段共同工作，从而定合适的交付成果。业务利益相关者不能只是指着某一点，然后说“给我们一些东西来修复这个！”

　　在开发阶段为复杂性做计划

　　IT部门在交付执行良好的应用程序时，面临的一个重大障碍是通常会需要大量的时间和金钱做完工作，超出所有人的预期（或承诺）。需求渐变甚至会在应用程序落地之前，损坏IT和业务利益相关者之间的关系。当它始终未能在预算之内、按时生产工作应用程序时，IT就变得不称职或是欺诈性的了。然而，偷工减料来保持追踪通常意味着牺牲质量和最终应用的性能。

　　IT可以帮助业务用例提供更多的资源（时间、金钱、工具），在计划和开发阶段，通过曝光应用程序发挥作用的真正成本。根据Keane说，在任何给定的应用程序上最高的年度花费确实发生在最初的开发年。然而，维护和操作最终只占IT在应用服务周期内投入整个工作的70%。随着应用程序的生命周期接近尽头，每年成本越来越高，而且应用变得越来越难以维护。

　　坦率地说，业务利益相关者无论如何必须明白他们在应用程序上将要花费的资源——当他们轮到他们做时。他们也可能会预先做预算，并给IT一次机会生产更高质量的应用程序，在长时间内执行良好。当然，正确的ALM工具可以重用，随着时间的推移能使IT的增长它的ROI。

　　自动过渡到操作

　　开发、部署、管理，重复。这是应用程序在它的整个生命周期中不断重复的舞步。这在今天的敏捷开发环境中更是真理。就像是航空旅行最有危险的部分是起飞和着陆一样，在应用程序中出现最大风险的地方是新版本部署或升级。但总会担心一些暴跳的“未知”素拖垮整个网络。

　　操作可能会有一个很长的要做的事情清单，惟确保应用程序真正准备好了。同时，常常会有一个推力使补丁一直活跃，因此IT可以移向下一个任务。在ALM时间线上，部署恰恰是表现不佳的部分。在预部署测试和应用程序的实际安装中的自动化正是这类瓶颈的一个最有用的拯救方法。

　　合理化你的应用时，保持逻辑性

　　应用生命周期的结尾可能是很容易被忽视的地方，但它却对IT基础设施的性能有很大的影响。有一个服务器网络，到处充斥着废弃的东西或遗留应用，它会占用很多的资源，而这些资源在其它地方会更好的使用。定期回顾整个应用程序投资组合是必要的，从而可以确定是否有应用程序是多余的或比维持他们提供的ROI，花费过多公司的成本。如果某个应用程序还没有完全准备退休（在某种程序上是现代化的），可以将它移动到云上，让它闲置直到需要实例。或者，将它返回到设计和开发周期，重新修订，交付更好的性能和更高的业价值。