What Is an SDLC Path?

This chapter defines an SDLC Path as an approved configuration of lifecycle phases, activities, roles, controls, artifacts, evidence, gates, and IT Operating Environments for a specific scope or reusable class of work.

Canonical Definition

An SDLC Path is an approved sequence and configuration of Systems Development Lifecycle phases, activities, roles, controls, artifacts, evidence, readiness gates, and IT Operating Environments selected for a specific Asset, Product, Service, Solution, Release, or defined class of work.

Enterprise SDLC Versus SDLC Path

Types of Paths

The canonical path represents the complete 13-phase reference lifecycle. A standard path is an approved reusable pattern for a known class of work. A tailored path adjusts a canonical or standard path using approved rules. An exceptional path contains formally approved deviations, compensating controls where needed, and authorized residual-risk acceptance.

Enterprises may define paths for low- or high-risk Custom-Built Solutions, Acquired SaaS, infrastructure changes, data platforms, emergency maintenance, artificial intelligence, regulated capabilities, or retirement. The categories should remain understandable and manageable.

Risk, Environments, and Methodology

Risk, criticality, consequence of failure, data sensitivity, integration complexity, supplier dependency, novelty, reversibility, and recovery difficulty influence phase depth, assurance, evidence, Environment selection, and gate authority.

Agile, Waterfall, and Hybrid affect path execution but do not independently determine which lifecycle outcomes are required. A Release should be linked to the exact approved path version used.

Example

A healthcare payer uses three governed SDLC Paths. A minor portal text change follows a lightweight path with peer review, focused testing, approval, and deployment evidence. A new claims-pricing API follows a standard path that includes architecture, security, Systems Integration Testing (SIT), User Acceptance Testing (UAT), and production-readiness review. A new payment platform follows an enhanced path with prototyping, regulatory validation, penetration testing, disaster-recovery testing, and executive risk oversight. The paths differ, but each preserves accountable ownership, required evidence, and formal progression decisions.

Common Antipatterns

Enterprises should avoid creating so many specialized Paths that the catalog becomes unmanageable. Defining a distinct Path for every conceivable variation undermines the purpose of having reusable Paths at all — the catalog becomes as hard to navigate as having no standard Paths, and practitioners revert to ad hoc decisions because they can’t find or trust the right Path for their situation.

Connections to Related IF4IT Practices and Inventories

The IF4IT Enterprise Model, Enterprise Capability Models, and the Capabilities Inventory and Attributes keep this chapter’s decisions and responsibilities connected to enterprise structure, capability ownership, and measurable business outcomes.