Solution Architecture Lifecycle: Phases and Responsibilities

Recently I posted a picture on LinkedIn about the solution‑architecture lifecycle that received over 1,000 views, and I plan to publish a more detailed version on my blog with brief annotations.

A solution architect works with planning and project teams to ensure the design, cost estimation, procurement, construction, and delivery of problem‑solving solutions, typically resulting in new processes and IT capabilities for the organization.

Solution architects handle problems of varying complexity, requiring a broad set of technical and business skills.

The work of a solution architect can be divided into several stages, each focusing on the problem at hand.

Solution Architecture Lifecycle

The following sections briefly discuss each layer of the solution‑architecture lifecycle, always aligning the focus with the top‑level problem.

Identify

Typically, a problem requires a working group to determine whether it is worth considering, such as a project bid or a newly emerging technical pattern that needs investigation (e.g., capacity, performance, or security incidents).

At this stage, the solution architect proposes possible options and helps trigger the next phase of activity.

Define Problem/Issue Context

Without a business case—a document that records the rationale, basic costs, and outcomes—no project or work plan truly begins. If the issue is technical, the architect must describe the context in simple terms from a system perspective.

Capture Requirements

During requirements capture, the architect spends considerable time focusing on the system aspects of the requirements and tries to understand component characteristics.

This stage emphasizes non‑functional elements of the system.

A minimum viable product can be identified, outlining the smallest set of functional and non‑functional components needed and the effort required for cost analysis.

Legal and compliance concerns, such as GDPR and enterprise‑architecture directives, must also be included.

Define Product Backlog and/or Level‑0 System Architecture

Once the problem is understood, documented, and broken down into clearly defined functional and non‑functional requirements, a Level‑0 system architecture can be generated to outline the solution.

Whenever possible, reusable components should be highlighted to shorten time‑to‑market and increase project savings.

The result of this stage is a Level‑0 design, which often leads to a product backlog.

The Level‑0 design helps determine the cost and effort needed to deliver the required outcomes.

Design Solution and Break Deliverables into Sprints

In this phase, the Level‑0 design is analyzed in detail, producing comprehensive design documents and subsequent technical sprints for project delivery.

Depending on the solution, lower‑level designs may be generated to support the overall design.

Implement Solution and Choose Implementation Approach

Various options—from doing nothing to building—are evaluated, and the choice is made based on cost, execution capability, existing relationships/services, and best value‑for‑money.

Deliver Solution to Production

Developed, acquired, or modified systems must be deployed to production; therefore, the architect defines environments (test, pre‑production, production) and often works with service architects to design operational elements inferred from non‑functional requirements.

When all these elements are combined and the architect’s involvement time is allocated, a diagram like the one below can be produced.

In summary, the solution architect is a crucial role that evolves with each engagement, bridging problem identification, design, implementation, and delivery of solution services.