1.1 What Is Software Architecture?
Software architecture is one of those terms that everyone uses but few define consistently. At its core, software architecture is about the fundamental structural decisions of a software system — the decisions that are expensive to change later. It describes which major components exist, how they relate to each other, and what principles govern their design and evolution.
Think of it like city planning. A city planner doesn't decide the color of every door — but they decide where the highways go, where residential and industrial zones are, and how water and electricity are distributed. These decisions are hard to reverse once buildings are in place. Software architecture works the same way: it defines the "roads and zones" of your system, leaving the details of individual "buildings" (classes, functions) to developers.
There is no single universally agreed-upon definition, but most converge on these themes:
- Structure: The system's building blocks and how they are organized
- Decisions: The choices that are architecturally significant — hard or expensive to change
- Trade-offs: Every architectural decision involves trade-offs between competing quality attributes
- Communication: Architecture serves as the shared understanding among all stakeholders
Architecture sits between requirements and implementation. It takes the "what" (requirements) and turns it into the "how at a high level" (structures, patterns, technology choices), which then guides the "how in detail" (code). But this isn't a one-way street — implementation experience feeds back into architectural decisions, and new requirements may force architectural evolution.
Key Terminology
| Term | Definition |
|---|---|
| Building Block | A general term for any structural element of a system — could be a module, component, subsystem, class, microservice, or library. The term is deliberately abstract to apply at any level of granularity. |
| Interface | The externally visible behavior and interaction point of a building block. An interface defines what a building block offers (or requires) without revealing how it works internally. |
| Component | A modular, replaceable, encapsulated unit of software that exposes one or more interfaces. Components are the primary building blocks in most architecture diagrams. |
| Module | A unit of software organization, typically at compile-time, that groups related functionality. In Java, a module might be a Maven module or a Java 9+ module; in .NET, it could be a project within a solution. |
| Architecture Decision | A design choice that addresses an architecturally significant requirement — one that is hard to change, expensive to get wrong, or that constrains many other decisions. |
| Architecture Pattern | A proven, reusable solution schema for a recurring architecture problem. Patterns are not copy-paste solutions — they must be adapted to context. |
1.2 The Role of the Software Architect
A software architect is not someone who sits in an ivory tower drawing diagrams that nobody reads. In modern practice, the architect is a hands-on technical leader who bridges the gap between business needs and technical solutions. They work closely with developers, talk to stakeholders, and often still write code.
The iSAQB curriculum describes the architect's responsibilities broadly. Here's what they actually look like in practice:
What Architects Do NOT Do
- Make all decisions alone. Architecture is a collaborative activity. Good architects facilitate decisions rather than dictate them. The team should own the architecture collectively.
- Work in isolation. The "ivory tower architect" who designs without understanding the codebase is an anti-pattern. Architects should be close to the code and understand the real constraints developers face.
- Ignore business constraints. Architecture doesn't exist in a vacuum. Budget, timeline, team skills, regulatory requirements, and organizational politics all influence architectural decisions.
- Design once and walk away. Architecture evolves. Requirements change, technologies shift, and the team learns. The architect must continuously validate and adapt the architecture.
Stakeholders
Every architectural decision has an audience. Different stakeholders care about different aspects of the architecture. Understanding who cares about what is critical for making good decisions and communicating them effectively.
| Stakeholder | Primary Concerns | How Architecture Serves Them |
|---|---|---|
| Developers | Clarity, consistency, feasibility | Clear building blocks, interfaces, and coding guidelines |
| Project Managers | Schedule, cost, risk | Effort estimates, risk identification, dependency mapping |
| Product Owners | Features, time-to-market | Modular design enabling parallel development |
| Operations / DevOps | Deployability, monitorability | Deployment view, infrastructure requirements, health checks |
| Testers / QA | Testability, traceability | Interface-based design, dependency injection, test strategy |
| End Users | Usability, performance, reliability | Quality-driven design decisions, SLAs |
| Management | Cost, strategic alignment, maintainability | Technology radar, make-vs-buy decisions, total cost of ownership |
| Security Officers | Confidentiality, integrity, compliance | Threat modeling, encryption strategy, audit trails |
1.3 Architecture in the Development Lifecycle
A common misconception is that architecture is a "phase" — something you do at the beginning of a project and then move on from. In reality, architecture is relevant throughout the entire lifecycle of a system. It's not a phase; it's an ongoing activity.
In a waterfall model, architecture might appear as a distinct phase between requirements and design. But in agile environments — where most modern teams work — architecture happens continuously. You make the most critical structural decisions early (because they're hard to change), but you defer less critical decisions until you have more information.
Architecture and Agile — Not Contradictory
There's a persistent myth that "agile means no architecture." This is wrong. What agile means is:
- "Just enough" upfront architecture — Make the hard-to-change decisions early (technology stack, deployment model, integration patterns). Defer the rest.
- Intentional architecture + emergent design — The big structure is deliberate; the details emerge through iteration and refactoring.
- Architecture as guardrails, not handcuffs — Good architecture gives teams freedom within clear boundaries. It says "we use event-driven communication between services" without dictating every implementation detail.
- Continuous validation — Every sprint is an opportunity to validate architectural assumptions against real feedback.
1.4 Relationship to Other Disciplines
Software architecture doesn't exist in isolation. It interacts deeply with other disciplines, and the architect needs to understand these relationships to be effective.
| Discipline | Relationship to Architecture |
|---|---|
| Requirements Engineering | Architects don't just receive requirements — they actively clarify, challenge, and refine them. Architects are particularly important for quality requirements (performance, security, availability), which business stakeholders often leave implicit. It's the architect's job to make them explicit and measurable. |
| Project Management | Architecture directly influences effort estimates, risk, and work breakdown. A monolithic architecture leads to different planning than a microservices architecture. The architect helps PMs understand technical dependencies and risks. |
| Testing / QA | Architecture must support testability. If building blocks have clean interfaces and loose coupling, they can be tested independently. If they're tangled together, testing becomes expensive and slow. The architect has a direct impact on test strategy. |
| Operations / DevOps | Architecture governs deployability, scalability, and monitorability. How a system is structured determines how it can be deployed, scaled, and monitored. Architects must work with ops teams to ensure the architecture is operable. |
| Development | Architecture constrains and guides implementation choices. It sets the guardrails (e.g., "all services communicate via REST") while leaving implementation freedom within those guardrails. Good architects stay close enough to the code to make realistic decisions. |
Architecture and Team Topologies
In practice, the relationship between architecture and organization goes deeper than the CPSA-F curriculum covers. Conway's Law tells us that systems tend to mirror the communication structures of the organizations that build them. This means the org chart is an architectural constraint whether you want it to be or not.
Modern approaches like Team Topologies (by Matthew Skelton and Manuel Pais) explicitly design team structures to support the desired architecture. They define four fundamental team types:
- Stream-aligned teams — aligned to a flow of work (a business domain or a user journey)
- Platform teams — provide self-service internal platforms that reduce cognitive load
- Enabling teams — help stream-aligned teams adopt new technologies or practices
- Complicated-subsystem teams — own components that require deep specialist knowledge
The key insight is the Inverse Conway Maneuver: instead of letting your org structure accidentally constrain your architecture, deliberately structure your teams to produce the architecture you want.
Architecture in the Cloud Era
The CPSA-F curriculum is technology-agnostic, but in practice, most modern systems are cloud-based. Cloud platforms (AWS, Azure, GCP) provide managed services that shift many architectural decisions from "build" to "buy." An architect today needs to understand:
- Managed vs. self-hosted services — When to use a managed database vs. running your own
- Infrastructure as Code (IaC) — Architecture isn't just diagrams; it's codified in Terraform, CloudFormation, or Pulumi
- The shared responsibility model — What the cloud provider handles vs. what you handle
- Cost as an architectural driver — Cloud costs are directly tied to architectural decisions (compute, storage, data transfer)
Summary
| Concept | Key Takeaway |
|---|---|
| What is architecture? | Fundamental structures + significant decisions + trade-offs |
| Architect's role | Collaborative technical leader — close to code, close to stakeholders |
| Lifecycle | Architecture is continuous, not a phase — relevant from start to decommission |
| Agile + Architecture | "Just enough" upfront, then evolve. Guardrails, not handcuffs. |
| Stakeholders | Different stakeholders need different views and information |
| Related disciplines | Architecture interacts with requirements, PM, testing, ops, and development |