Connect APM to the Systems Development Lifecycle (SDLC) to keep the portfolio current as applications are built and changed

Overview

Applications do not change only at the moment of a formal portfolio review — they change continuously, through the ordinary work of the Systems Development Lifecycle. New applications are proposed and built; existing applications receive new versions, new technology dependencies, and new technical debt; and some applications are retired mid-cycle for reasons a periodic review would not surface until much later. An APM program that only updates its portfolio record at rationalization-review time is, by construction, always working from a partially stale picture.

Best Practice

Establish an explicit connection between APM and the Systems Development Lifecycle so that key SDLC events — a new application entering development, a major version or technology-stack change, technical debt introduced or resolved during a release — update the Applications Inventory as they happen, rather than waiting for the next scheduled portfolio review to capture them. This connection should be treated as a primary data source for the application lifecycle stages already governed elsewhere in this document, not as a parallel or duplicate tracking mechanism.

Where the SDLC discipline itself is governed by a separate function or document, name that dependency explicitly rather than assuming APM can observe SDLC activity without a defined data-sharing arrangement. Define what data APM needs from SDLC activity, at what frequency, and through what mechanism, consistent with how this document treats other operationally-homed data sources.

Where the organization manages application-related work through a dedicated product or project management system — tracking features, releases, or initiatives at the product level — treat that system as a complementary data source alongside the SDLC connection described in this chapter: product and project records often capture planned future changes and investment decisions before they reach active development, giving APM early visibility into what is coming rather than only what has already shipped.

Where feasible, link each application record directly to its source code repository and delivery pipeline — not merely to the SDLC process that governs it, but to the specific repository and pipeline identifiers themselves. This concrete linkage lets APM data cross-reference build frequency, deployment frequency, and repository activity as additional signals of whether an application is actively maintained or effectively abandoned, and gives incident responders and architects a direct path from the portfolio record to the actual codebase when they need it.

Benefit(s)

Connecting APM to the SDLC keeps the portfolio record current between formal review cycles, closing the gap where an application’s actual state and its last-recorded state diverge. Technical debt and technology-stack changes are captured as they are introduced rather than discovered retroactively at the next review, giving rationalization and risk assessments a more accurate, more current evidentiary basis. And because this data already exists as a byproduct of ordinary development work, connecting to it requires no additional manual data entry burden on development teams.