Summary of "What is Application Lifecycle Management (ALM)?"

Overview

Application Lifecycle Management (ALM) is defined as the complete lifetime of an application — from idea and justification through development, deployment, ongoing changes, and eventual retirement. ALM is broader than the Software Development Life Cycle (SDLC): it includes governance, development, and operations, not just code-building.

ALM is the entire period an organization spends resources on an application, not merely the SDLC.

The three-part ALM model

ALM should be thought of as three interrelated and continuous parts:

Governance
Development
Operations

Each of these areas overlaps and influences the others. Weakness in any one reduces overall application value.

1. Governance (continuous)

Responsible for decision making across the app’s life:
- Business case development after idea/conception
- Project portfolio management during development approvals and execution
- Application portfolio management after deployment (prioritizing resources, scheduling updates, deciding end-of-life)
Makes lifecycle decisions including when to retire or decommission the application
Overlaps and influences every stage of the application lifecycle

2. Development (strongest between idea and deployment)

Runs the initial SDLC to create the application
Plans and executes subsequent development cycles for maintenance, updates, or major new versions (versioned SDLCs)
Applies project governance (project management) to each development cycle

3. Operations (begins before deployment; continuous thereafter)

Starts with operational readiness before production deployment
Monitors application health and performance continuously
Deploys maintenance updates and handles runtime issues until end-of-life

Lifecycle events

ALM has critical lifecycle events analogous to a human lifecycle:

Idea / Conception
- Capture requirements and define the business case
Deployment / Birth
- Transition from development to operations; ensure monitoring, support, and operational readiness are in place
Death / End-of-life
- Decommissioning and resource reallocation decisions governed by application portfolio management

Governance should be active across all these events.

Tool strategy

Prefer tools that provide horizontal integration within a discipline (for example, integrated development toolchains)
Aim for vertical integration across governance → development → operations, linking portfolio/project tools to development and ops tools
Evaluate vendor ecosystems for integration capabilities
Current tooling examples show some integration (e.g., Visual Studio, Team Foundation Server, Microsoft Project), but vendors can and should improve vertical linkage

Organizational capability and recommended practices

Treat ALM scope as the entire time resources are spent on an application, not only the SDLC
Assess and improve capabilities across all three ALM areas:
- Governance: portfolio and lifecycle decision processes
- Development: disciplined SDLCs and versioned development cycles
- Operations: monitoring, support, and maintenance processes
Take a holistic approach to ALM improvements; optimizing only one area undermines the application’s overall value

Examples and notes

The speaker criticizes treating “ALM” as merely a new name for SDLC
Tool/vendor examples referenced: Microsoft Visual Studio 2010, Visual Studio Team Foundation Server, Microsoft Project
Emphasis on vendors improving vertical integration between governance, development, and operations tools

Speakers / sources

Unnamed presenter / narrator (video speaker)
Tool/vendor examples referenced: Microsoft (Visual Studio 2010, Visual Studio Team Foundation Server, Microsoft Project)