Custom-Built vs. Acquired Solutions — Comparing Lifecycle Mechanics Across the SDLC

Compares how Custom-Built and Acquired Solutions satisfy the same Enterprise SDLC outcomes through different allocations of authority, work, evidence, and supplier responsibility.

Governing Principle

Use one Enterprise SDLC for both sourcing models while varying the mechanisms used to design, implement, evidence, accept, operate, and retire the Solution.

Required Lifecycle Treatment

Application Through the SDLC

Apply this discipline across the full lifecycle, from Intake through Retirement. Establish applicability and ownership during Planning, translate it into testable requirements and decisions during Design and Build, generate decision-ready evidence through SIT, UAT, and Staging, verify and monitor it in Production and Operations, and close out remaining obligations at Retirement.

Governance and Evidence

Assign clear ownership — an enduring Solution owner, Release Owner, discipline owner, evidence producers, and Risk Owner — and scale rigor to the work’s criticality, complexity, and reversibility. Record Risks, exceptions, and Technical Debt in authoritative systems, not narrative status. Generative AI may assist with analysis and evidence organization, but only accountable roles may approve outcomes, accept Risk, or authorize Production.

Example

A custom claims API gives the enterprise direct control over requirements, architecture, source code, build practices, testing, deployment, and remediation. A SaaS customer-service platform shifts many implementation controls to the supplier, so the enterprise emphasizes due diligence, contract obligations, configuration governance, integration testing, security attestations, service levels, data handling, operational support, and exit planning. Both solutions use the SDLC, but the evidence and control mechanisms differ because authority, implementation responsibility, and access to underlying technology differ.

Common Antipatterns

Enterprises should avoid assuming Acquired Solutions require less enterprise evidence than Custom-Built ones. Acquired Solutions substitute supplier artifacts and configuration evidence for source-level evidence; they do not require less evidence overall, and assuming otherwise can leave enterprise Validation and acceptance genuinely under-supported.

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 this practice to Release Management guidance, IT Operating Environments Best Practices, and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology, which together govern Release scope, environment progression, deployment evidence, cutover, rollback, and closure.