Solutions Architecture and the Systems Development Lifecycle (SDLC)

Overview

The IF4IT Systems Development Lifecycle defines thirteen phases spanning the full life of a technology-enabled capability: Intake and Strategizing, Research and Prototyping, Planning, Requirements Capture, Design, Implementation and Build, Systems Integration Testing, User Acceptance Testing, Training and Education, Pre-Production Staging, Production, Operations and Maintenance, and Retirement, Decommissioning, and Disposal. It is explicitly an IT management governance framework, not merely a software-development process, and it is tailored per engagement through governed SDLC Paths and Utilization Profiles.

This tailoring includes whether a given solution is Custom-Built, Acquired, or Composite — a distinction Phase 3, Future State Solutions Options Determination and Vetting, develops further later in this document, since which form a Solutions Option takes shapes what its evaluation actually needs to cover.

A Solutions Architecture engagement’s work corresponds to the SDLC’s earlier phases: Intake and Strategizing, Research and Prototyping, Planning, and Requirements Capture, extending into parts of the Design phase, but rarely bleeding into Implementation and Build or the phases that follow. This is the same activity-type boundary established earlier in this document, expressed concretely in SDLC terms: Solutions Architecture hardens the viability of a solution through Design; the SDLC’s later phases carry that solution through actual engineering, testing, staging, and operation.

Solutions Architecture also helps establish the selection and high-level design of the IT Operating Environments a solution will require as it moves through the SDLC — a correlation the SDLC’s own documentation addresses in more detail through its environment-mapping guidance.

Best Practice: Align the SARB’s Early Work With the SDLC’s Own Early-Phase Artifacts, Rather Than Duplicating Them

Where an enterprise’s SDLC already produces artifacts for Intake, Planning, and Requirements Capture, the Solutions Architecture engagement’s Vision Development and Current State Collection work should reference and build on them rather than reproducing them independently. The SARB should cite the relevant SDLC artifacts rather than duplicate their content.

Benefit(s)

Aligning with, rather than duplicating, the SDLC’s own early-phase artifacts avoids redundant effort between two disciplines working the same ground, and gives engineering a clean, well-defined starting point at Implementation and Build, backed by a Solution Set that has already hardened viability through Design.