Application Lifecycle Management (ALM) involves the proactive management of all activities related to the business ideas and priorities that evolve into technical solutions. All companies that develop software as part of their business participate in the application lifecycle. However very few companies consciously manage their application lifecycle.
Managing the application lifecycle involves performing a series of activities that work together to provide value to the business. In many cases, these activities are performed in individual silos with poor communications and processes between the silos. This disconnected approach to IT projects causes businesses to waste money on projects that don't support their needs, to poorly execute on these projects, to deliver faulty or incomplete projects, and to not understand how or whether the projects deliver on the original business needs.
In the simplest case, the activities involved in an application lifecycle flow as shown below. In reality, the different activities are co-owned by different people and the flow between activities is usually blurred and contains many loops and dependencies. This figure summarizes flow between activities. The details may change depending upon individual project or organizational needs, but the basic flow should be similar.
The following list defines a baseline of the common activites that exist in an application lifecycle:
Project Request: Projects are captured at the beginning of the application lifecycle. Business ideas, demands and requests form the basis for IT projects. This may include input from a board of directors, executive management, business owners and even feedback from existing application users or IT. The key to managing requests is to understand how they impact each other and their overall cost and value to the business.
Plan: After projects are approved, they are planned. Ideas are prioritized based on their value and cost. Many other options feather into this as strategic projects drive resource plans. Critical projects may drive hiring or may pull resources from other areas. The plans will account for how and when a project will be performed.
Define: Define the project by eliciting and capturing the requirements for the project that will fulfill the original requests. Feedback from the project definition is likely to impact the original plans.
Design: Design a solution to meet the defined requirements. This may be a package solution, integration or custom development. The design should address all areas of the project and consider enterprise architecture requirements as well as operations, maintenance and test.
Construct: Build the solution. For application development project this includes implementing the software solutions to meet the design. Note that it also includes building other artifacts such as test cases, unit tests, build scripts, environments, training materials, etc.
Test: Validate that the constructed solution meets the requirements and performs as expected.
Release: Deploy the solution into production. This may be a phased approach starting with pilot users and take an extended period or it may be a simple single push into a production environment. Regardless, many organizations will require checks and balances for compliance before any changes are made into a produciton environment.
Maintain: Maintaining the solution after it is in production is hopefully where the applications spend most of their lifecycle. The cost of maintenance and support will frequently overshadow the initial project costs. Maintenance includes the entire tracking and support infrastructure and may drive additional iterations of construction, validation, and release.
Retire: Retirement is the termination of an application's lifecycle. The act of retiring an application may be short and simple but typically the act of sunsetting an application drives requirements for other applications. The planning and management can be a considerable effort. Just as the release of applications and changes may be phased, so too may the retirement of those applications.
Oversight: Unlike the previous activities, oversight is an ongoing activity. The purpose is to ensure that all other activities are following standards and guidelines. These standards may be imposed internally due to corporate policies (e.g., CMMI or ISO). They may also be externally focused due to legislation (e.g., Sarbanes-Oxley).
Manage: Like Oversight, Manage is an umbrella activity that spans other activities. This activity involves coordinating and monitoring activities against the plan.
This model is still somewhat simplistic but it starts to show the complexity involved with application lifecycle. Each of these activities involves different people, each focusing on different aspects of the problem. Within each activity there are many different steps that must be accomplished. Depending upon the organization, the processes that facilitate these activities may be well organized and understood or very informal. It is common for companies to have successful processes in place for some activities but severely lacking in others. As the saying goes,"a chain is only as strong as it's weakest link." A company with impeccable software development processes that successfully builds the wrong solutions due to problems in the requests, planning or definition will still end up with a failed project. The same can be said for failures in any of the activities.
The industry has, in general, created various disciplines to help companies successfully deliver in related activities. For our purposes, we focus on the following disciplines which support ALM: Project Portfolio Management, Project Management,Requirements Management, Application Development, Quality Assurance, Change Management and Operations Management. The relationship between these activities and disciplines is somewhat ambiguous as different organizations take different approaches; nonetheless this relationship is important in ALM.