Define and Publish an Enterprise Systems Development Lifecycle (SDLC)

This chapter establishes the practice of defining, approving, publishing, maintaining, and continuously improving one authoritative Enterprise SDLC.

Best Practice: Define One Authoritative Enterprise SDLC

Define one authoritative, complete, enterprise-wide, methodology-neutral, sourcing-aware, risk-sensitive, measurable, and tailorable SDLC. It should govern technology-enabled capabilities regardless of whether they are built, acquired, configured, integrated, maintained, modernized, or retired.

Benefits: Defining one SDLC that governs technology-enabled capabilities regardless of sourcing model means the same governance applies whether a Solution is built, acquired, or maintained, instead of practitioners needing to guess which of several competing lifecycle models applies to their particular situation.

Best Practice: Publish a Complete Lifecycle Governance Model

The published SDLC should provide canonical phases, terminology, minimum outcomes, standard Paths, Utilization Profiles, roles, guidance, Artifacts, evidence, Gates, Environments, repository obligations, inventory updates, Technical Debt responsibilities, tailoring, conformance, and exceptions.

Benefits: Publishing minimum outcomes and standard Paths together, rather than outcomes alone, gives teams a proven starting mechanism for satisfying those outcomes instead of leaving each team to independently invent its own way of getting there.

Best Practice: Make SDLC Knowledge Authoritative and Accessible

Publish the SDLC through an Enterprise Architecture or IT Knowledge Portal and connect it to the Enterprise Document Repository, authoritative inventories, systems of record, and specialist guidance. Ordinary lifecycle knowledge should be enterprise-readable by default, with justified restrictions.

Benefits: Defaulting lifecycle knowledge to enterprise-readable, with only justified restrictions, means practitioners can actually find and follow the SDLC without needing special access requests for ordinary guidance. A default of restriction, by contrast, quietly discourages the very consistency the published model is meant to produce.

Best Practice: Assign Ownership and Continuously Evolve the SDLC

Assign an SDLC Owner and authorized governance authority. Control versions, effective dates, transition rules, change impacts, metrics, and Crawl-Walk-Run adoption. The lifecycle should be continuously improved from Release outcomes and operational evidence.

Benefits: Assigning a named SDLC Owner with authority over versions and transition rules means changes to the lifecycle model happen through a controlled process, rather than accumulating as informal local interpretations that gradually diverge from whatever was originally published.

Example

A diversified enterprise discovers that five divisions use different lifecycle terms, gates, templates, and approval practices. It establishes one enterprise SDLC with a common phase model, minimum outcomes, standard paths, decision rights, evidence expectations, and controlled tailoring. Divisions may retain local procedures where needed, but they map those procedures to the enterprise model. The SDLC is published through a shared portal containing policies, standards, templates, examples, and role guidance, giving practitioners one authoritative source while preserving proportional execution.

Best Practice: Advance Maturity Deliberately for Define and Publish an Enterprise Systems Development Lifecycle (SDLC)

At Crawl maturity, define and publish the SDLC through a concise document with a named owner, even before dedicated portal infrastructure exists. At Walk maturity, publish the SDLC through an Enterprise Architecture or IT Knowledge Portal with version control, effective dates, and a defined change process. At Run maturity, maintain the published SDLC through integrated systems that automatically reflect approved changes across dependent Paths, Profiles, and training materials.

Benefits: Starting with a concise, owned document at Crawl maturity ensures the SDLC actually exists and is used before investing in portal infrastructure. Publishing through a governed portal with version control at Walk maturity keeps practitioners working from the current, authoritative version. Maintaining automatic propagation at Run maturity prevents the lag between an approved SDLC change and its reflection in dependent materials that a manual process would otherwise introduce.

Best Practice: Avoid Common Antipatterns in Define and Publish an Enterprise Systems Development Lifecycle (SDLC)

Enterprises should avoid restricting access to ordinary SDLC guidance by default. Treating lifecycle guidance as confidential or need-to-know by default, rather than enterprise-readable with justified exceptions, makes the SDLC harder for practitioners to actually find and follow, undermining the very consistency the published model is meant to produce.

Benefits: Avoiding this antipattern keeps the published SDLC genuinely usable, not just technically published. It removes an unnecessary barrier between practitioners and the guidance they need to do their work correctly.

Connections to Related IF4IT Practices and Inventories

Use the IF4IT Enterprise Model together with Enterprise Capability Models and the Capabilities Inventory and Attributes to anchor this chapter’s decisions in enterprise structure, capability ownership, and measurable business outcomes. Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to place this SDLC decision in the context of application ownership, portfolio value, lifecycle state, and dependencies.

For Define and Publish an Enterprise Systems Development Lifecycle (SDLC), IT leaders and managers should establish explicit decision rights, accountable ownership, proportional controls, evidence expectations, performance measures, and continuous-improvement feedback tied to enterprise value.

Apply Enterprise AI Governance Best Practices and, where AI Agents are involved, the AI Agents Inventory and Attributes to govern approved use, ownership, data access, autonomy, validation, monitoring, supplier exposure, and human accountability for generative AI and AI-enabled solutions.