Software Architecture & SDLC

Software architecture is the set of structural decisions that shape how a system is organized, how its parts communicate, where data lives, and how the system evolves under change. The software development lifecycle (SDLC) is the process that takes an idea from requirements through design, implementation, testing, deployment, and maintenance.

These two concerns are inseparable. Architecture without lifecycle discipline becomes whiteboard fiction that never survives contact with production. An SDLC without architectural thinking ships features that cannot scale, cannot be secured, or cannot be changed without rewriting half the system.

This section teaches both: the major architectural styles you will encounter in production, the SDLC models that organize how teams deliver software, and — most importantly — the requirements that should drive every choice. Prefer HOW to apply a pattern, WHY it exists, and WHAT constraints justify it over memorizing diagrams.

You will leave with a shared vocabulary for ADRs, quality attributes, process gates, and pattern selection — usable whether you are a staff engineer designing a platform, a tech lead choosing Scrum vs Kanban, or an AI agent generating architecture proposals that must cite evidence.

Architecture is the set of decisions that are expensive to reverse: service boundaries, consistency models, data ownership, trust boundaries, and deployment topology. Framework choice, folder naming, and library preference are design details unless they lock you into an irreversible path.

Good architecture creates options: the ability to change a database adapter, scale a hot path independently, or onboard a second team without a rewrite. Bad architecture creates accidental coupling — shared databases used as APIs, god modules, and undocumented temporal dependencies.

The SDLC is the organized sequence of activities that turn stakeholder needs into running, maintained software. Classic textbooks list phases; modern teams still perform the same kinds of work — they just overlap them in time and automate the repetitive gates.

Feedback loops close the cycle: production metrics and incidents feed new requirements; failed tests feed design changes; customer research feeds prioritization. A lifecycle without feedback is Waterfall theater regardless of sprint names.

Architecture answers structural questions: modular monolith or microservices? Sync APIs or events? Layered or hexagonal? SDLC answers process questions: Waterfall or Agile? Scrum or Kanban? When do we gate a release?

Architecture decisions typically crystallize during design phases but are validated (and sometimes reversed) during implementation, testing, and operations. Feedback from production — incidents, latency, cost — is an architectural input, not just an ops concern.

Not every architectural choice belongs at the start. Evolutionary architecture deliberately postpones irreversible decisions until evidence exists — but some decisions are expensive to reverse and need early attention.

Early decisions that usually deserve ADRs: consistency model (strong vs eventual), tenancy model (single vs multi), trust boundary (where authn/z lives), and whether the first deployable is a modular monolith or a set of services.

Late decisions that should stay flexible: concrete message broker brand, ORM, CSS framework, and hosting region — unless compliance freezes them. Prefer ports & adapters so these choices remain replaceable.

Work through these topics in order if you are new, or jump to the pattern matching your current decision.

The most common architecture failure is pattern tourism: adopting microservices because a conference talk praised them, or event sourcing because it sounds advanced. Every style below exists to satisfy a class of requirements — and imposes costs that only make sense when those requirements are real.

Functional requirements tell you what the system must do (place order, reset password, generate invoice). Non-functional requirements tell you how well (p99 latency under 200ms, RPO under 5 minutes, WCAG 2.2 AA). Architecture is primarily shaped by the NFRs and by constraints: team size, budget, existing systems, and regulation.

When stakeholders say "make it scalable," translate that into measurable quality attributes before choosing microservices. Scalability of what? By how much? At what cost ceiling? The requirements page shows how to do that translation.

Classic phases still describe the kinds of work that must happen, even when Agile collapses them into iterations. Process models differ in how they sequence work, how they handle change, and what artifacts they demand at gates.

Waterfall sequences phases rigidly. Agile iterates them in short cycles. Kanban optimizes flow across them. DevOps collapses build/test/deploy into continuous pipelines and shared ownership of production outcomes.

• Choosing microservices before domain boundaries are understood — distributed monolith with extra latency.
• Skipping NFRs until "later" — later means a rewrite under incident pressure.
• Confusing Scrum events with Agile outcomes — velocity theater without customer feedback.
• Treating architecture as a one-time phase instead of continuous decision-making with ADRs.
• Copying another company's architecture without copying their scale, team size, or compliance reality.
• Optimizing for hypothetical future scale while ignoring current delivery speed and operability.

For humans: start with How to Master Architecture & SDLC, then study requirements before any pattern page. Use Choosing Architecture & SDLC when facing a real decision.

For AI agents: fetch markdown via ?format=md or /api/markdown?path=.... Do not claim mastery from titles. After each stage, produce an ADR, a C4 context/container sketch, or a decision table that cites requirements — then self-critique against the page checklists.

Continue with System Design (scalability, CAP, case studies), CI/CD and Ops for delivery mechanics, and Security for threat modeling that feeds architectural constraints.

Learning path: Architecture & SDLC Roadmap sequences every topic in this section with time estimates for humans and AI agents.