Implementation and Build Phase of the Systems Development Lifecycle (SDLC)

Defines the IF4IT SDLC phase in which approved requirements and Designs are realized through software development, Product configuration, infrastructure creation, data preparation, integration development, technical documentation, packaging, and controlled Build processes that produce verifiable Release components.

Purpose

The Implementation and Build phase creates or configures the technical components that will become the governed Solution and Release. It should produce attributable, reproducible or sufficiently reconstructable, secure, supportable, and testable outputs rather than an informal collection of code, settings, scripts, and supplier changes.

Typical Inputs

Inputs may include approved requirements, Architecture and Design baselines, coding and engineering Standards, supplier Products and contracts, component approvals, Environment definitions, data mappings, Security and Privacy controls, accessibility requirements, Build and configuration plans, test designs, migration plans, Risks, exceptions, and the SDLC Utilization Profile.

Core Activities

Develop software and automation; configure acquired Products and platforms; create infrastructure and Environment definitions; implement schemas, data pipelines, APIs, integrations, identity, monitoring, and controls; prepare migration and deployment packages; create or update technical and operational documentation; perform peer review, static analysis, unit and component testing, component and license analysis, vulnerability checks, and Build verification; and package approved artifacts in trusted repositories with provenance and integrity information.

Engineering and Build Controls

Use controlled source repositories, protected change workflows, peer review, approved dependencies, dependency locking where appropriate, automated Builds, artifact repositories, secrets management, infrastructure as code, code and configuration analysis, component inventories, signing or integrity verification, and traceability from source and configuration to the resulting Build. Manual actions should be minimized, documented, authorized, and reconciled.

Outputs and Evidence

Outputs may include source and configuration, compiled or packaged artifacts, container images, infrastructure definitions, database and integration changes, configured Product states, migration utilities, unit and component test results, code-review evidence, composition and vulnerability results, Build provenance, technical documentation, known defects, updated Design records, and an identifiable Build or component baseline ready for integration.

Decision and Exit Criteria

Exit requires that the intended components have been implemented against an approved basis, material engineering controls have completed successfully, known defects and findings are dispositioned, artifacts and configurations are uniquely identifiable and protected, required documentation is current, and the integrated package is ready for Systems Integration Testing. A successful compiler, pipeline, or deployment does not by itself establish readiness.

Application Across Solution Types and Methods

For Custom-Built Solutions, this phase emphasizes source, dependencies, Build integrity, infrastructure, and engineering evidence. For Acquired Solutions, it emphasizes Product configuration, approved extensions, integrations, tenant setup, data preparation, supplier changes, and configuration evidence. Composite Solutions require coordinated component Builds and a controlled integration baseline. Waterfall may organize implementation as a defined stage, Agile may produce increments continuously, and Hybrid may combine iterative component delivery with formal integration and Release controls.

Crawl-Walk-Run Maturity

At Crawl maturity, use source control, peer review, named Build ownership, basic unit tests, approved repositories, and identifiable packages. At Walk maturity, automate Build, quality, Security, dependency, infrastructure, and evidence controls through governed pipelines. At Run maturity, use policy as code, signed and attributable artifacts, continuous provenance, automated environment promotion, predictive quality analysis, and generative AI assistance with protected data, review, and human accountability.

Common Antipatterns

Enterprises should avoid treating a successful Build as proof of readiness. A compiler, pipeline, or deployment script completing without error demonstrates that code was assembled correctly, not that requirements were satisfied, defects were resolved, or the package is actually ready for integration testing.

Connections to Related IF4IT Practices and Inventories

Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to ensure builds and tests use governed technologies and representative environments. 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.

Apply Release Management guidance together with IT Operating Environments Best Practices and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology to keep Release scope, environment progression, deployment evidence, cutover, rollback, and closure properly governed.

Apply Technical Debt Management Best Practices and the Technical Debt Inventory and Attributes to identify, qualify, record, prioritize, remediate, accept, and periodically reassess intentional, inherited, emergent, and deferred lifecycle obligations.