Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

Defines reusable Custom-Built and Acquired SDLC Paths that configure one Enterprise SDLC for recurring sourcing patterns.

Best Practice: Establish the Governing Principle for Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

An SDLC Path is an approved, reusable, version-controlled configuration of the Enterprise SDLC; it does not create a separate lifecycle or replace the Release-specific Utilization Profile.

Benefits: Defining an SDLC Path as a configuration of the one Enterprise SDLC, not a separate lifecycle, keeps Custom-Built and Acquired work governed by the same underlying model even as their specific mechanics differ, preventing the fragmentation that would come from treating each sourcing pattern as its own independent system.

Best Practice: Define Required Lifecycle Treatment for Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

Benefits: Preserving common terminology and authoritative systems across every Path means a practitioner who understands one sourcing pattern’s Path can still navigate another’s without relearning basic lifecycle vocabulary, since only the mechanics change, not the underlying language.

Best Practice: Apply Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC Throughout the SDLC

Apply this discipline continuously from Intake through Retirement, translating the governing principle into testable requirements during Design and Build, generating decision-ready evidence through integration and acceptance testing, verifying the authorized state in Production and Operations, and closing remaining obligations at Retirement.

Benefits: Establishing Release-specific treatment for a sourcing pattern’s Path as early as Intake and Planning means the appropriate default mechanics are already in place before Design and Build begin, rather than being reverse-engineered mid-Release once the sourcing model’s implications become apparent.

Best Practice: Govern Decisions and Preserve Evidence for Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

Establish named ownership — Solution, Release, discipline, evidence, and Risk — proportionate to the work’s actual criticality and reversibility. Keep Risks, exceptions, and Technical Debt visible in authoritative systems, not buried in narrative updates. Generative AI may assist with analysis and drafting, but accountable decisions remain with named human authorities.

Benefits: Scaling rigor to criticality and reversibility, regardless of which sourcing Path a Release follows, keeps governance depth tied to actual Risk rather than to a sourcing label that might not, by itself, indicate how much oversight a particular Release genuinely needs.

Best Practice: Advance Maturity Deliberately for Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

At Crawl maturity, informally distinguish Custom-Built from Acquired treatment in a brief shared document, without a fully published Path catalog. At Walk maturity, publish versioned, criteria-based Paths for each sourcing pattern, reviewed and maintained by named owners. At Run maturity, recommend the appropriate Path automatically from Solution classification and sourcing data, with an accountable owner confirming the selection before it governs the Release.

Benefits: An informal distinction at Crawl maturity is enough to prevent the two sourcing models from being governed identically before the enterprise has volume to justify a formal Path catalog. Publishing versioned, criteria-based Paths at Walk maturity means every Custom-Built or Acquired Release starts from a proven, consistent configuration instead of being defined from scratch. Automating Path recommendation at Run maturity accelerates routine selection while keeping a human owner accountable for confirming it fits the actual Solution.

Best Practice: Avoid Common Antipatterns in Define and Publish Custom-Built and Acquired Solution Paths Through the SDLC

Enterprises should avoid creating a separate lifecycle for each sourcing pattern instead of one configured SDLC. An SDLC Path is meant to be a reusable configuration of the single Enterprise SDLC, not an independent lifecycle; treating Custom-Built and Acquired work as needing entirely separate lifecycles fragments governance and duplicates the common outcomes both sourcing models actually share.

Benefits: Avoiding this antipattern keeps the enterprise’s lifecycle model coherent across every sourcing pattern. It preserves the shared terminology and outcomes that let practitioners move between Custom-Built and Acquired work without relearning the basics.

Connections to Related IF4IT Practices and Inventories

Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to govern ownership, sourcing posture, lifecycle status, dependencies, and enterprise acceptance for custom-built and acquired solutions. Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to connect the decisions and responsibilities addressed in this chapter to governed technology choices, platform lifecycle, and environment controls.

Connect quality expectations to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance using the Non-Functional Requirements (NFRs) Framework for Software Systems.

Use Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology to select and tailor the delivery approach according to consequence of failure, decomposability, incremental deliverability, and timing constraints.