Software Architecture - Map of Content
This domain explores the principles, patterns, and practices of software architecture. Architecture sits at the intersection of technical design, organizational dynamics, and strategic decision-making. Unlike coding or detailed design, architecture deals with the structures that shape how systems evolve, scale, and serve their purposes over time.
The content here builds from foundational concepts (what is architecture, what makes it complex) through practical frameworks (modularity, characteristics, styles) to the human elements (team dynamics, decision-making, career development). This organization reflects how architectural thinking develops: understanding the problem space, learning the solution patterns, and developing the judgment to apply them wisely.
Core Reference Works
Start here for comprehensive coverage of architecture fundamentals:
Primary Literature:
- Fundamentals of Software Architecture - Richards & Ford - 2020 ⭐ - Modern, comprehensive architecture reference
- Software Architecture: The Hard Parts - Trade-off analysis for distributed architectures (Ford et al., 2022)
- No Silver Bullet - Brooks - 1986 - Classic exposition of essential complexity
Foundational Structure Notes:
- Defining Software Architecture - What architecture is and isn’t
- Expectations of an Architect - The role’s scope and responsibilities
- Architecture by Principle - Principle-based architectural thinking
🏛️ Architecture Fundamentals
What Is Architecture?
These notes establish the foundation for architectural thinking:
- Architecture Versus Design - Where architecture ends and design begins
- The-Four-Cs-of-Architecture - Communication, Collaboration, Clarity, Context
- Defining Software Architecture (structure note) - Complete definition and scope
Laws and Principles
Fundamental truths that guide architectural decisions:
- Laws of Software Architecture (structure note) - Hub tying the three laws plus classical and other laws
Richards & Ford’s three laws:
- Everything in software architecture is a trade-off. - First Law: No perfect solutions
- Why is more important than how. - Second Law: Rationale over implementation
- Most architecture decisions are on a spectrum between extremes - Third Law: Context-dependent positioning
Classical and other laws:
- Law of Implicit Dependencies - Hyrum’s Law and API design
- Conway’s-Law - How organization structure shapes architecture
- Wirth’s Law - Software complexity outpacing hardware gains
- Law of Software Envelopment - Zawinski’s Law: programs expand until they can read mail
- Constantine’s Equivalence (Beck’s Restatement) - Cost of software ≈ coupling
- No Silver Bullet - The Fundamental Argument (structure note) - Brooks’s argument in structural form
🧩 Modularity & Component Design
Modularity is the organizing principle that makes complex systems manageable. These notes explore how to identify, define, and compose architectural components:
Core Concepts:
- Modularity - What makes a system modular
- Component-Definition - Architectural building blocks
- Component-Granularity - Finding the right component size
- Component-Identification-Process - Discovering component boundaries
Design Principles:
- Cohesion - How tightly elements belong together
- Functional-Cohesion - Degree to which operations interrelate
- Coupling - How components depend on each other
- Static-Coupling - Compile-time dependencies
- Dynamic-Coupling - Runtime dependencies
- Afferent-Coupling - Incoming dependencies (who depends on this)
- Efferent-Coupling - Outgoing dependencies (what this depends on)
- Semantic-Coupling - Inherent coupling in problem domain
- Implementation-Coupling - Coupling introduced by architecture choices
- Stamp-Coupling - Passing more data than needed in contracts
- Orthogonal-Coupling - Independent concerns that must intersect
- Connascence - More nuanced view of coupling
- Architecture-Partitioning-Approaches - Strategies for system decomposition
Quality Metrics:
- Abstractness - Ratio of abstract to concrete components
- Instability - Measure of component volatility
- Abstractness-Instability-Metric - Balancing abstraction and stability
- Distance-from-Main-Sequence - Combined abstractness/instability metric
Anti-Patterns:
- Big-Ball-of-Mud-Anti-Pattern - What happens without modularity
⚙️ Architecture Characteristics
Architecture characteristics (also called “quality attributes” or “-ilities”) define what makes a system successful beyond its functional requirements. Understanding, measuring, and designing for these characteristics is central to architecture work:
Foundational Concepts:
- Architecture-Characteristics-Categories - Operational, structural, cross-cutting
- Architecture-Characteristics-Extraction-Process - Identifying what matters
- Explicit-Architecture-Characteristics vs Implicit-Architecture-Characteristics
- Granularity-of-Architecture-Characteristics - Where characteristics apply
Types of Characteristics:
- Operational-Characteristics - Performance, scalability, reliability
- Structural-Characteristics - Modularity, maintainability
- Cross-Cutting-Characteristics - Security, accessibility
Measuring Characteristics:
- Measuring-Architecture-Characteristics - How to quantify quality
- Operational-Measures - Runtime metrics
- Structural-Measures - Design-time metrics
- Process-Measures - Development process metrics
- Latency-Percentiles - P50, P90, P95, P99 as the correct lens for measuring response time
- Service-Level-Indicators - SLI/SLO/SLA framework for formalizing performance targets
Architecture Scope:
- Architecture-Quantum - Independently deployable unit with high functional cohesion
- Unitary-Architecture - Single quantum systems
- Monolithic-vs-Distributed-Architecture-Characteristics - How distribution affects characteristics
Core Quality Attributes:
- Maintainability - Ease of adding, changing, or removing features
- Testability - Ease and completeness of testing
- Deployability - Ease, frequency, and risk of deployment
- Scalability - Ability to remain responsive as load increases gradually
- Elasticity - Ability to handle erratic spikes in load
- Availability - System uptime and accessibility
- Fault-Tolerance - Ability to fail and continue operating
- Consistency - Strong consistency (linearizability) in distributed systems
- Partition-Tolerance - Operation despite network partitions
Governance:
- Fitness Functions - Automated architecture verification and integrity assessment
🏗️ Architecture Styles & Patterns
Architecture styles provide proven templates for solving recurring structural challenges. Each style makes different trade-offs around characteristics like scalability, simplicity, and fault tolerance:
Monolithic Styles:
- Layered-Architecture-Style - Classic n-tier organization
- Pipeline-Architecture-Style - Sequential data transformation
- Microkernel-Architecture-Style - Plugin-based extensibility
Distributed Styles:
- Client-Server-Architecture - Foundational separation of client and server across process or network
- Service-Based-Architecture-Style - Coarse-grained services
- Microservices-Architecture-Style - Fine-grained, independently deployable
- Event-Driven-Architecture-Style - Asynchronous event processing
- Space-Based-Architecture-Style - Distributed caching and processing
- SOA-Service-Oriented-Architecture - Enterprise service architecture
Comparison & Selection:
- Architecture-Style-Selection-Framework - Choosing the right style
- Monolithic-vs-Distributed-Architectures - Fundamental trade-offs
🔧 Distributed Architecture Patterns
When systems are distributed across services, new patterns and challenges emerge. These notes explore decomposition, communication, data management, and workflow coordination in distributed systems:
Decomposition & Modularity
Drivers and Forces:
- Modularity - Breaking systems into separate deployment units
- Architectural-Modularity-Drivers - Forces driving system breakup
- Service-Granularity - Size and scope of service functions
- Granularity-Disintegrators - Forces pushing toward smaller services
- Granularity-Integrators - Forces pushing toward larger services
- Component-Based-Decomposition - Breaking monolith into components
- Tactical-Forking - Duplicating code to enable decomposition
Boundaries:
- Component-Definition - Architectural building block with business/infrastructure function
- Bounded-Context - DDD concept defining semantic boundaries
Communication Patterns
Communication Types:
- Synchronous-Communication - Caller waits for response before proceeding
- Asynchronous-Communication - Caller doesn’t wait for response
Coordination Approaches:
- Orchestration - Workflow coordination with central orchestrator
- Choreography - Workflow coordination without central mediator
Workflow State Management:
- Workflow-State-Management - Managing transient workflow state
- Front-Controller-Pattern - First service in chain owns workflow state
- Stateless-Choreography - Build workflow state on-demand via queries
Code Reuse Patterns
Different strategies for sharing code across services:
- Code-Replication-Pattern - Duplicate code to avoid coupling
- Shared-Library-Pattern - Shared functionality via compiled dependencies
- Shared-Service-Pattern - Shared functionality via service calls
- Sidecar-Pattern - Separate operational from domain concerns
- Service-Mesh - Linked sidecars for operational control
- Hexagonal-Architecture - Ports and adaptors pattern
Data Management Patterns
Data Forces and Ownership:
- Data-Disintegrators - Forces pushing data schemas apart
- Data-Integrators - Forces keeping data schemas together
- Data-Ownership-Patterns - Assigning table/schema ownership to services
Data Access Patterns:
- Interservice-Communication-Pattern - Ask owning service for data
- Column-Schema-Replication-Pattern - Replicate data columns across tables
- Replicated-Caching-Pattern - Synchronized in-memory caches across services
- Data-Domain-Pattern - Shared database schema across services
Transactional Patterns:
- Contract - Interface between two software parts
- Strict-vs-Loose-Contracts - Contract flexibility trade-offs
- ACID - Atomicity, Consistency, Isolation, Durability properties
- Atomicity - All-or-nothing transaction property
- Consistency - Strong consistency (linearizability) in distributed systems
- Eventual-Consistency - Data becomes consistent over time
- Partition-Tolerance - Operation despite network partitions
- CAP-Theorem - Consistency, Availability, Partition tolerance trade-offs
- Distributed-Transactions - Transactions spanning multiple services
Saga Patterns
Managing distributed transactions with compensating actions:
Foundation:
- Saga-Pattern - Managing distributed transactions with compensations
Saga Pattern Variations:
- Epic-Saga-Pattern - Synchronous-Atomic-Orchestrated saga (SAO)
- Phone-Tag-Saga-Pattern - Synchronous-Async-Choreographed saga (SAC)
- Fairy-Tale-Saga-Pattern - Synchronous-Eventual-Orchestrated saga (SEO)
- Time-Travel-Saga-Pattern - Synchronous-Eventual-Choreographed saga (SEC)
- Fantasy-Fiction-Saga-Pattern - Async-Atomic-Orchestrated saga (AAO)
- Horror-Story-Pattern - Async-Atomic-Choreographed saga (AAC)
- Parallel-Saga-Pattern - Async-Eventual-Orchestrated saga (AEO)
- Anthology-Saga-Pattern - Async-Eventual-Choreographed saga (AEC)
🌐 Distributed Systems
Distributed systems introduce fundamental challenges that don’t exist in monolithic architectures. These notes explore the inherent difficulties and their implications:
Core Understanding:
- Fallacies-of-Distributed-Computing - Eight false assumptions
- Tail-Latency - Why slow outliers amplify in fan-out distributed calls
💾 Data Architecture
Database Types
Different database paradigms for different use cases:
Traditional SQL:
- Relational-Databases - Table-based ACID-compliant databases
NoSQL Databases:
- Key-Value-Databases - Simple key-value NoSQL storage
- Document-Databases - JSON/XML document-oriented storage
- Column-Family-Databases - Wide-column NoSQL storage
- Graph-Databases - Node and edge relationship storage
Analytical Data Architecture
Evolution of analytical data patterns:
Centralized Approaches:
- Data-Warehouse - Centralized analytical data with ETL transformation
- Data-Lake - Centralized raw analytical data repository
Decentralized Approach:
- Data-Mesh - Decentralized domain-oriented analytical data
- Data-Product-Quantum - Data mesh deployment and ownership unit
🎯 Architectural Decision-Making
Architecture is fundamentally about making decisions under uncertainty. These notes cover frameworks, techniques, and anti-patterns for architectural decision-making:
Core Frameworks:
- Architecture-Decision-Records - Documenting decisions and rationale
- ADR-Format-and-Structure - How to write effective ADRs
- Architecturally-Significant-Decisions - What decisions warrant ADRs
- Architecture-Decision-Criteria - Evaluating alternatives
Risk Management:
- Risk-Assessment-Framework - Identifying and quantifying risks
- Risk-Storming - Collaborative risk identification
- Risk-Storming-Process - How to run risk storming sessions
- Risk-Matrix - Prioritizing risks
Trade-offs & Context:
- Trade-Offs-and-Least-Worst-Architecture - No perfect solutions
- Trade-Off-Analysis-Technique - Framework for analyzing architecture decisions
- MECE-Lists - Mutually Exclusive Collectively Exhaustive technique
- Architecture-Style-Selection-Framework - Choosing among styles
Anti-Patterns:
- Architecture-Decision-Anti-Patterns - Common decision-making failures
- Covering-Your-Assets-Anti-Pattern - Avoiding responsibility
- Groundhog-Day-Anti-Pattern - Re-litigating decisions
- Email-Driven-Architecture-Anti-Pattern - Decisions lost in email
Governance:
- Architectural-Governance - Maintaining architectural integrity
- Architectural-Checklists - Ensuring completeness
📐 Documentation & Communication
Architecture must be communicated effectively to diverse stakeholders. These notes cover visualization, documentation, and presentation techniques:
Diagramming Standards:
- Architecture-Diagrams-Standards - Creating clear diagrams
- C4-Model - Context, Containers, Components, Code
- UML-Architecture-Diagrams - UML for architecture
- ArchiMate-Standard - Enterprise architecture notation
Frameworks:
- TOGAF-Framework - Enterprise architecture framework
Communication:
- Architecture-Presentation-Techniques - Presenting to stakeholders
👤 The Architect Role
Architecture is as much about people as it is about technology. These notes explore the human side of architecture:
Role Definition & Skills
What Architects Do:
- Expectations of an Architect (structure note) - Complete role overview
- Effective-Architect-Profile - Characteristics of successful architects
- The-Four-Cs-of-Architecture - Core competencies
Breadth vs Depth:
- Breadth vs Depth (structure note) - Complete exploration
- 01-Technical-Breadth-vs-Depth - The fundamental trade-off
- 02-T-Shaped-Skills-Model - Depth in one area, breadth across many
- 05-Specialist-vs-Generalist-Trade-offs - When to specialize vs generalize
- 12-Duties-Skills-Knowledge-Model - Organizing architect capabilities
- 14-Learning-Agility-Fluid-vs-Crystallized - Continuous learning
Staying Current:
- Staying-Current-in-Architecture - Managing technology change
- ThoughtWorks-Technology-Radar - Assessing and communicating technology adoption; tracking emerging technologies
- Personal-Radar-Development - Building your own radar
- The-20-Minute-Rule - Daily learning practice
Leadership & Collaboration
Working with Teams:
- Software-Architect-as-Leader - Leadership without authority
- Pragmatic-Yet-Visionary-Leadership - Balancing pragmatism and vision
- Team-Warning-Signs - Recognizing team dysfunction
- Team-Boundaries - Establishing healthy team limits
- Growth-Mindset-in-Software-Teams - Fostering learning cultures
- Agile-Retrospectives - Team retrospectives as feedback loops for process improvement
- Code-Review-as-Feedback - Code review as a feedback mechanism for quality
Negotiation & Facilitation:
- Negotiation-Facilitation-Skills - Core facilitation competencies
- Negotiating-with-Developers - Technical conversations
- Negotiating-with-Business-Stakeholders - Business alignment
- Negotiating-with-Other-Architects - Architecture collaboration
Knowledge Management:
- Architect-as-Knowledge-Facilitator - Enabling knowledge flow
- Knowledge-Silos-Pattern - Breaking down information barriers
- Bus-Factor - Minimum people whose loss stalls a project; quantified fragility
- Knowledge-Flow-in-Software-Architecture (structure note) - Complete framework
- Knowledge Flow vs Knowledge Stock (structure note) - Flow vs accumulation
- Knowledge Pyramid - Richards & Ford - Data → Information → Knowledge → Wisdom
- Data-Information-Knowledge-Understanding-Hierarchy - DIKU framework
Architect Anti-Patterns
What not to do:
Decision-Making Anti-Patterns:
- Armchair-Architect-Anti-Pattern - Deciding without context
- Control-Freak-Architect-Anti-Pattern - Micromanaging technical decisions
- Covering-Your-Assets-Anti-Pattern - Avoiding accountability
- Email-Driven-Architecture-Anti-Pattern - Hidden decision-making
- Groundhog-Day-Anti-Pattern - Re-litigating decisions
Personality Anti-Patterns:
- Ivory Tower Architect - Isolated from implementation
- Frozen Caveman Anti-pattern - Stuck in outdated thinking
- Architecture by Archaeology - Historical justification without current rationale
- Architect-Personalities - Understanding different architect types
🧠 Complexity & Essential Challenges
Software is inherently complex. These notes explore what makes it complex and what we can do about it:
Understanding Complexity:
- Essential vs Accidental Complexity (structure note) - The fundamental distinction, implications, and Gray Zone
- Essential Complexity - Complexity in the problem domain
- Accidental Complexity - Complexity we introduce
- Algorithmic Optimization - Managing computational complexity
- Feedback-Loops-in-Systems - Circular causal relationships that shape system behavior
Silver Bullets:
- No Silver Bullet - Brooks - 1986 (literature) - Classic essay
- Are AI & Low-Code Silver Bullets? (structure) - Modern context
📚 Synthesis & Structure Notes
These structure notes combine multiple atomic concepts into complete frameworks and arguments:
Distributed Systems Frameworks
- Pulling-Apart-Monoliths-Decomposition-Framework - Complete decomposition decision framework
- Data-in-Distributed-Architectures-Patterns - Data ownership and access patterns
- Distributed-Workflows-Orchestration-vs-Choreography - Workflow coordination trade-offs
- Code-Reuse-in-Distributed-Architectures - Reuse patterns and decisions
Data Architecture Evolution
- Analytical-Data-Evolution-Warehouse-to-Mesh - Historical evolution of analytical data patterns
Knowledge & Learning
- Knowledge-Flow-in-Software-Architecture - How knowledge moves through organizations
- Knowledge Flow vs Knowledge Stock - Accumulated vs flowing knowledge
- Breadth vs Depth - The architect’s learning challenge
Performance & Reliability Governance
- Performance-Measurement - Why Percentiles Not Averages - Why averages mislead and how percentile ladders + tail latency amplification inform better measurement
- SLO-Driven Architecture Governance - SLI→SLO→SLA hierarchy, error budgets, and fitness-function enforcement as a continuous governance loop
Other Cross-Cutting Themes
- Essential vs Accidental Complexity - Comparison and architectural implications (structure note)
- Feedback - Concepts & Frameworks - Feedback loops in architecture
Laws and principles:
- Laws of Software Architecture - Hub tying the three laws plus classical and other laws
- Law of Software Envelopment - Zawinski’s Law (structure)
- No Silver Bullet - The Fundamental Argument - Brooks’s argument (structure)
- Constantine’s Equivalence (Beck’s Restatement) - Cost of software and coupling (structure)
Navigation Tips
For beginners: Start with Defining Software Architecture, then explore Expectations of an Architect to understand the role. From there, dive into Modularity and the Architecture Characteristics section.
For practitioners: Focus on Architecture Styles, Decision-Making, and the Architect Role sections. The anti-patterns provide valuable lessons from common failures.
For leaders: Emphasize the Architect Role section, particularly Leadership & Collaboration, and the Knowledge Management notes.
For deep dives: Each section builds from atomic concepts (single ideas) to structure notes (synthesized frameworks). Follow the links within each topic area to explore connections.
Sources
This is a navigation/organization note. For sources, see individual linked notes. The domain is primarily built from:
- Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Ford, Neal, Mark Richards, Pramod Sadalage, and Zhamak Dehghani (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 978-1-492-08689-5.
- Brooks, Frederick P., Jr. (1986). “No Silver Bullet – Essence and Accident in Software Engineering.”
For complete citations, see the Literature notes and individual atomic notes.
Note
This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.