Chapter 01 Flashcards — Introduction
flashcards fsa introduction architect-role
What are the four dimensions of software architecture?
?
- Structure — how components are arranged and how they relate (deployment topology, partitioning)
- Architecture characteristics — the “-ilities” the system must support (performance, scalability, security, reliability, testability, deployability)
- Architecture decisions — the technology and structural choices made, with their trade-offs documented (via ADRs)
- Design principles — guidelines that steer team decisions within the architecture without prescribing every detail
State the First Law of Software Architecture.
?
“Everything in software architecture is a trade-off.” No architectural decision is purely beneficial — every choice gives up something to gain something else. There is no universally best architecture, only better or worse fits for a specific context. Corollary: if something appears to have no trade-offs, the analysis is incomplete.
State the Second Law (and corollary) of Software Architecture.
?
“Why is more important than how.” Understanding why a decision was made — what trade-offs were accepted, what alternatives were considered, what constraints existed — is more valuable than knowing how the system is built. This is the core motivation for Architecture Decision Records (ADRs).
What is an architecture characteristic?
?
An architecture characteristic (often called a non-functional requirement) is a structural quality the system must support regardless of its domain functionality — examples include performance, scalability, reliability, security, testability, and deployability. The authors prefer “architecture characteristic” because “non-functional” undersells their architectural importance. Every system must explicitly identify which characteristics matter most, because optimizing for all of them simultaneously is impossible.
How do Richards and Ford distinguish architecture from design?
?
Architecture covers decisions that are hard to change, broadly impactful, and concern the overall shape of the system. Design covers locally scoped, easier-to-reverse implementation decisions within a component. There is no sharp line — it is a spectrum. Architects should be involved wherever decisions become difficult or expensive to reverse.
What is the “Ivory Tower Architect” antipattern?
?
The Ivory Tower Architect makes decisions from a distance — no ongoing engagement with the codebase, the team, or production realities — delivering architectures that are theoretically sound but practically unimplementable. Richards and Ford explicitly argue against this: architects must retain technical engagement and stay connected to the teams building the system.
What is “Architecture by Resume”?
?
Architecture by Resume is selecting technologies because they are fashionable or the architect wants CV experience with them, rather than because they fit the problem. It produces over-engineered systems optimized for the architect’s career growth rather than the project’s needs.
What are the eight core expectations of a software architect?
?
- Make architecture decisions (guide, don’t prescribe every detail)
- Continually analyze the architecture (systems decay — actively monitor health)
- Keep current with latest trends (architectural decisions have long shelf lives)
- Ensure compliance with decisions (decisions not enforced are merely suggestions)
- Have diverse exposure and experience (broad breadth across technologies)
- Have business domain knowledge (trade-offs require understanding business priorities)
- Possess interpersonal skills (teamwork, facilitation, leadership, negotiation)
- Understand and navigate politics (architectural decisions are political decisions)
Why must architects keep current with latest technology trends?
?
Architectural decisions have long shelf lives — a style or platform chosen today may constrain the system for 5–10 years. Missing an important trend (containerization, serverless, AI-native architectures) leads to decisions that age poorly. Architects must consume conference talks, technical blogs, and experimentation as ongoing habits to avoid making decisions that will be outdated soon after they are made.
What does “ensure compliance with decisions” mean, and how is it achieved?
?
Architects are responsible for ensuring that architecture decisions and design principles are actually followed by teams. Decisions not enforced are not decisions — they are suggestions. Compliance is achieved through: fitness functions (automated architectural tests), linting/static analysis rules, architecture governance gates in CI/CD, code reviews, and direct communication with teams when drift is detected.
Why is business domain knowledge required for architects?
?
Architectural trade-offs — performance vs. cost, consistency vs. availability, speed-to-market vs. technical quality — cannot be resolved without understanding what the business actually needs. An architect who does not understand the domain, competitive pressures, and regulatory environment cannot make good trade-offs and risks building technically elegant systems that solve the wrong problems.
What is the architecture quantum, as introduced in Chapter 1?
?
An architecture quantum is the smallest independently deployable artifact with high functional cohesion and high static coupling. A monolith has a quantum of 1. A microservices system has a quantum per service. The quantum concept defines the granularity of independent operability and is used throughout the book to reason about deployment and coupling.
What is the relationship between architecture and engineering practices like CI/CD and DevOps?
?
Modern architecture is inseparable from engineering practices. Continuous delivery makes deployment pipelines a first-class architectural concern — architectures must support independent deployability. DevOps requires designing for observability (logging, metrics, tracing) from the start. Evolutionary architecture requires fitness functions and incremental change capability — architecture that cannot evolve safely is not complete.
What makes interpersonal skills architecturally important, not just “soft skills”?
?
Architecture is a collaborative discipline — architects persuade stakeholders, negotiate trade-offs with engineers, align business and technology leaders, mentor developers, and run cross-team design sessions. Technical excellence alone is insufficient: architects who cannot communicate or build consensus will see technically sound proposals rejected or poorly implemented. The ability to influence without direct authority is a core architectural competency.
What is the “Frozen Architect” antipattern?
?
The Frozen Architect treats the architecture as a fixed artifact that should never change, even as business requirements evolve, teams grow, and technology changes. In a world of continuous delivery, this rigidity causes the architecture to become a liability rather than an asset. Architecture must be designed to evolve safely — through fitness functions, ADRs, and engineering discipline.
Why is documenting the why behind architectural decisions more important than the how?
?
When the why is missing, teams either reverse good decisions unnecessarily (not knowing the constraints that required them) or maintain outdated constraints indefinitely (afraid to change them without understanding them). Architecture Decision Records (ADRs) capture the context, alternatives considered, and trade-offs accepted — enabling future teams to make informed decisions about whether to preserve or replace a decision.
What is the significance of the statement “if it appears to have no trade-offs, you haven’t fully analyzed it”?
?
This corollary to the First Law is a diagnostic tool: any architectural option that seems purely beneficial is a signal that the analysis is incomplete. Hidden trade-offs include: lock-in, operational complexity, team skill requirements, cost at scale, or constraints on future evolution. Architects must actively search for these hidden costs before committing to any decision.
How does politics intersect with software architecture?
?
Almost every significant architectural decision is also a political decision — it affects team ownership, budget allocation, vendor relationships, and organizational power structures. An architect who ignores organizational dynamics will see technically sound proposals rejected. Effective architects anticipate political dynamics, build coalitions of support, frame decisions in business terms, and navigate competing stakeholder interests as part of their core work.
What is the architect’s role regarding design principles, and how do they differ from architecture decisions?
?
Architecture decisions are specific technology or structural choices (e.g., “use event-driven communication between services”). Design principles are broader guidelines that steer the team without prescribing every detail (e.g., “prefer asynchronous communication,” “never allow direct database access from outside the owning service”). Principles give teams autonomy to make local decisions while remaining consistent with architectural intent.
What distinguishes architecture characteristics from functional requirements?
?
Functional requirements describe what a system does — the features and behaviors that serve business goals (e.g., “users can place orders”). Architecture characteristics describe how well the system does it — the structural qualities the system must have regardless of domain (e.g., performance, security, reliability). Characteristics are typically not visible in user stories but are critical architectural concerns; neglecting them at design time makes them expensive to add later.
Priority: HIGH — foundational definitions and laws that underpin every subsequent chapter