Design Phase of the Systems Development Lifecycle (SDLC)

Defines the IF4IT SDLC phase in which approved requirements and constraints are transformed into an implementable, supportable, secure, operable, testable, and governable Solution Design across Architecture, components, data, integrations, Environments, controls, deployment, operations, recovery, and Retirement.

Purpose

The Design phase determines how the approved requirements will be satisfied. It converts the required outcomes into coherent structural, behavioral, informational, operational, and transition decisions before the enterprise commits irreversibly to implementation, acquisition configuration, integration, or Production change.

Typical Inputs

Inputs may include the approved requirements state, Architecture principles and Standards, research and prototype findings, Solution classification, sourcing decisions, constraints, Risks, supplier capabilities, current-state inventories, data models, Security and Privacy obligations, accessibility needs, operational requirements, recovery objectives, Technical Debt, and the SDLC Utilization Profile.

Core Activities

Define or refine the Solution boundary, components, responsibilities, technologies, data flows, interfaces, trust boundaries, deployment topology, Environment model, identity and access, Security and Privacy controls, accessibility treatment, resilience and recovery, observability, support model, migration, cutover, rollback, training, data retention, supplier responsibilities, and Retirement approach. Evaluate alternatives and tradeoffs, record material decisions and assumptions, prototype uncertain elements where necessary, and design the V&V and evidence strategy with the Solution.

Design Quality and Reviews

The Design should be feasible, internally consistent, traceable to requirements, appropriately modular, supportable, testable, secure, resilient, accessible, cost-aware, and aligned with enterprise Standards. Reviews should involve the authorities and practitioners needed for the actual risk profile. Review depth may range from peer review to formal Architecture, Security, Privacy, data, operational, supplier, or independent assurance review.

Outputs and Evidence

Outputs may include Solution Architecture, detailed Designs, Architecture Decision Records, component and responsibility models, interface and API specifications, data models and mappings, Security and Privacy Designs, Environment and deployment Designs, operational and support Designs, recovery Designs, migration and rollback approaches, Design Risks, exceptions, and an approved Design baseline or governed iterative equivalent.

Decision and Exit Criteria

Exit requires a sufficiently complete and approved Design basis for implementation or configuration, traceability to applicable requirements, resolved or governed material decisions, feasible V&V methods, known supplier and operational responsibilities, identified baseline and configuration controls, and a clear treatment for open Risks, exceptions, deferrals, and Technical Debt. Detailed Design may continue iteratively, but material Design changes must remain governed.

Application Across Solution Types and Methods

For Custom-Built Solutions, Design provides the engineering basis for code, infrastructure, data, integrations, and deployment. For Acquired Solutions, Design focuses on Product selection fit, configuration, extensions, integrations, data, controls, service responsibilities, and exit. Composite Solutions require component Designs and one end-to-end Design. Waterfall may formalize Design before Build, Agile may evolve Design incrementally with Architecture guardrails, and Hybrid may combine staged and iterative Design while preserving a coherent Solution baseline.

Crawl-Walk-Run Maturity

At Crawl maturity, preserve a current Solution diagram, material Design decisions, interfaces, data flows, controls, and operational considerations. At Walk maturity, use reusable patterns, formal decision records, multidisciplinary reviews, traceability, and integrated Design repositories. At Run maturity, maintain machine-readable Architecture and Design relationships, automated conformance checks, simulation and model-based analysis, and generative AI support grounded in approved enterprise knowledge.

Common Antipatterns

Enterprises should avoid beginning implementation before material Design decisions are resolved. Starting to build before Architecture, data, and control decisions are settled embeds assumptions in early code that a later Design decision can invalidate, forcing rework that a few more days of Design discipline would have avoided.

Connections to Related IF4IT Practices and Inventories

Use Enterprise Capability Models and the Capabilities Inventory and Attributes to trace stakeholder needs and solution decisions to the enterprise capabilities they enable, change, protect, or retire. Use Technology Portfolio Management (TPM) Best Practices and the Software Technologies Inventory and Attributes to select approved technologies, expose standards exceptions, record configuration baselines, and manage supportability and obsolescence.

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

Use the Non-Functional Requirements (NFRs) Framework for Software Systems to define measurable quality, security, resilience, usability, interoperability, maintainability, and operational requirements, together with explicit validation methods and evidence.