| Topic | Key Takeaway |
|---|
| What is architecture? | Fundamental structures + significant decisions + trade-offs |
| Architect's role | Collaborative technical leader — close to code, close to stakeholders |
| Building blocks | General term for any structural element (module, component, service) |
| Interfaces | Provided + Required; explicit contracts; keep them small (ISP) |
| Coupling & Cohesion | LOW coupling between blocks + HIGH cohesion within = good design |
| SOLID | SRP, OCP, LSP, ISP, DIP — apply at class, module, and service level |
| Cross-cutting concerns | Logging, security, error handling — affect all building blocks |
| arc42 | 12-section documentation template — know all sections and their purpose |
| 4+1 View Model | Logical, Process, Development, Physical + Scenarios |
| iSAQB 4 Views | Context · Building Block · Runtime · Deployment |
| Quality scenarios | Source, Stimulus, Artifact, Environment, Response, Response Measure |
| ISO 25010 | 8 quality characteristics — know all + sub-characteristics |
| ATAM | Trade-off analysis: sensitivity points, trade-off points, risks |
| Conway's Law | System structure mirrors org structure — plan for it or it plans you |
| DIP | Both high- and low-level modules depend on abstractions |
| Technical debt | Deliberate vs. inadvertent · Prudent vs. reckless — track and manage it |
| Misconception | Reality |
|---|
| "Architecture is only done at the start" | ❌ Architecture is relevant throughout the entire lifecycle |
| "The architect makes all decisions alone" | ❌ Architecture is a collaborative activity |
| "UML is mandatory for documentation" | ❌ Any consistent notation with a legend is acceptable |
| "Quality is only about testing" | ❌ Quality is designed in by architecture, not tested in |
| "Performance is always the top priority" | ❌ Quality goals depend on stakeholder needs + trade-offs |
| "Tight coupling is always bad" | ❌ Within a cohesive module, tight coupling is natural and fine |
| "Microservices are always better" | ❌ Depends on context: team size, complexity, operational maturity |
| "More documentation is always better" | ❌ Document just enough — focus on architecturally significant decisions |
| "Patterns solve all problems" | ❌ Patterns are templates, not recipes — they must be adapted to context |
| "Architecture is only about technology" | ❌ Architecture also includes organizational, business, and quality concerns |
| Term | Definition |
|---|
| ADR | Architecture Decision Record — captures a single significant design decision with context, alternatives, and consequences |
| arc42 | A template for architecture documentation with 12 sections, widely used in the iSAQB ecosystem |
| ATAM | Architecture Tradeoff Analysis Method — structured evaluation of architecture against quality goals |
| Bounded Context | (DDD) A clear boundary within which a domain model is defined and consistent |
| Building Block | General term for any structural element of a system (module, component, service, subsystem) |
| Cohesion | Degree to which elements within a module belong together. Higher is better. |
| Component | A modular, replaceable unit that exposes interfaces and encapsulates implementation |
| Conway's Law | System structure mirrors the communication structure of the organization that builds it |
| Coupling | Degree of interdependence between modules. Lower is usually better. |
| CQRS | Command Query Responsibility Segregation — separate read and write models |
| Cross-cutting Concern | An aspect affecting multiple building blocks (logging, security, error handling) |
| DDD | Domain-Driven Design — approach to architecture driven by deep understanding of the business domain |
| DIP | Dependency Inversion Principle — depend on abstractions, not concretions |
| Fitness Function | An automated test that verifies an architectural property or constraint |
| Information Hiding | Hiding internal details behind interfaces — only expose what's necessary (Parnas, 1972) |
| Interface | The externally visible behavior and interaction point of a building block |
| ISO 25010 | International standard defining 8 product quality characteristics for software |
| Microservices | Architecture style where a system is composed of small, independently deployable services |
| Module | A unit of software organization, typically at compile-time |
| Quality Scenario | A concrete, measurable specification of a quality requirement (6 parts) |
| Saga | Pattern for managing distributed transactions via a sequence of local transactions with compensating actions |
| Sensitivity Point | (ATAM) A property critical to achieving a specific quality goal |
| SOLID | Five design principles: SRP, OCP, LSP, ISP, DIP |
| Technical Debt | The implied cost of future rework caused by choosing a quick solution over a better but slower one |
| Trade-off Point | (ATAM) A property that affects multiple quality attributes in opposing ways |
| Ubiquitous Language | (DDD) A shared language between developers and domain experts, used consistently in code and conversation |
| View | A representation of the system from a specific perspective, showing a specific set of concerns |
| Resource | Type | Best For |
|---|
| iSAQB Foundation Curriculum (official) | PDF | Definitive exam content |
| Software Architecture in Practice (Bass, Clements, Kazman) | Book | Quality attributes, ATAM, architectural tactics |
| Fundamentals of Software Architecture (Richards & Ford) | Book | Modern, practical architecture overview |
| arc42.org | Website | Free template, examples, FAQ |
| arc42 by Example (Starke & Hruschka) | Book | Worked examples of arc42 documentation |
| Clean Architecture (Robert C. Martin) | Book | Dependency rule, hexagonal architecture |
| Domain-Driven Design (Eric Evans) | Book | Bounded contexts, ubiquitous language |
| Building Microservices (Sam Newman) | Book | Microservices patterns and practices |
| Designing Data-Intensive Applications (Martin Kleppmann) | Book | Distributed systems, data architecture |
| C4 Model (Simon Brown) | Website | Practical architecture diagramming |
Use this checklist when starting a new project or making a significant architectural change: