# Be Software Architecture Wise > A complete, self-paced online course in software architecture from Be Wise (bewiseapps.com): thirteen chapters and 104 sections, from how software works to architecting AI-enabled systems. Every chapter has a narrated video introduction and every section a short narrated video lesson, with captions and a transcript. Optional chapter tests, a final examination and an architecture case study lead to a Be Wise Certificate of Completion (not accredited). Written in British English. Educational information, not professional advice. ## About the course - **What is Be Software Architecture Wise?** A complete online course in software architecture, in 13 chapters and 104 sections, with 117 narrated video lessons, from how software works to architecting AI-enabled systems, with optional chapter tests, a final assessment and case study, and a verifiable Be Wise Certificate of Completion. - **Who is the course for?** Beginners with no technical background, developers moving towards senior, lead or architect roles, experienced architects wanting a structured refresher, engineering and product managers, AI engineers and students. - **What do I need before I start?** No prior knowledge, just a phone, tablet or computer with a modern web browser, an internet connection for tests and ArchitectBot, and comfort reading English. - **What does the course cover?** Thirteen chapters: how software works; what architecture is; quality attributes; design principles; documenting architecture; monolithic styles and domain-driven design; distributed systems; data architecture; security, privacy and compliance; performance, resilience and operability; cloud-native infrastructure; evaluation and governance; and AI-enabled systems. - **How is the course organised, and how long does it take?** Each chapter has a narrated video introduction, an overview and eight sections, each with a narrated video lesson, a simple explanation, key points, the full treatment with diagrams and worked examples, self-check questions and sources. About 40 hours of reading, and about 60 hours in all with the tests and the case study, entirely self-paced. The 117 video lessons run to about 10 hours in all. - **How do the chapter tests work?** Each chapter test has 20 multiple-choice questions drawn from a bank of 64 and 2 written answers marked by AI against published criteria. Multiple choice is worth 70% and written answers 30%. The pass mark is 80% overall with at least 2 out of 5 on each written answer. Unlimited retakes after 10 minutes, with different questions. - **What is the final assessment?** After passing all 13 chapter tests: a 60-question final examination (pass mark 70%) and a written architecture case study of 1,500 to 4,000 words, marked out of 50 against a published five-part rubric (pass mark 25). - **How is the final grade worked out?** Overall score = 40% average best chapter test score + 30% final examination + 30% case study. Distinction: 90+ overall and at least 80% on the case study. Merit: 80+. Pass: all parts passed. - **What does the certificate show, and how can it be checked?** A Be Wise Certificate of Completion showing your name, the date, your grade (Pass, Merit or Distinction) and a unique number that anyone can check online. - **Is the certificate an accredited qualification?** No. It records that you completed this course and passed its assessments. It is not accredited, carries no academic credit and is not issued or endorsed by any university, professional body or certification scheme. - **What happens to my data?** No account is needed. Reading progress stays in your browser; test scores are kept against a random resume code with no personal details; your name is stored only if you claim a certificate, so that it can be checked. - **What is ArchitectBot?** The course's AI study assistant. It answers from the course first and searches the web for newer information. It can make mistakes and will not answer test questions for you. - **How is the content kept accurate and up to date?** Each chapter is checked against its cited sources before publication, sources are listed in every section, chapters are updated as practice changes, and mistakes can be reported. - **Which devices can I use, and is it accessible?** Phones, tablets and computers in any up-to-date browser; installable as an app; every chapter also as web pages and a PDF; every video has captions, an audio-only option and a transcript; diagrams have text descriptions. - **What the course is not** It is educational information, not professional advice; not an accredited qualification or exam preparation; not affiliated with any university or certification body; not a coding course; and has no live teaching, although every chapter and section has a narrated video lesson. - **How much does it cost?** At present the whole course is free: every chapter, the chapter tests, ArchitectBot, the final assessment and the certificate. If that changes, the price and exactly what it includes will be shown on this page before you start anything that is charged for. - Full details: https://bewiseapps.com/software-architecture-wise/about-the-course ## Chapters and sections ### [Chapter 0: Start Here: How Software Works](https://bewiseapps.com/software-architecture-wise/foundations/) Beginner. The groundwork for everything that follows: what a program is, how data and code are organised, how computers talk over networks, where data is stored, what APIs, servers and the cloud are, and how teams build software. No prior knowledge assumed. - [0.1 Programs, code and how a computer runs them](https://bewiseapps.com/software-architecture-wise/foundations/what-software-is): What hardware and software are, how source code becomes instructions a processor can run, what the operating system does, and what really happens, step by step, when a small Python program runs. - [0.2 Data, data structures and algorithms, and why speed depends on them](https://bewiseapps.com/software-architecture-wise/foundations/data-and-algorithms): How computers represent numbers and text, the everyday data structures (lists, dictionaries, queues, trees, graphs), what an algorithm is, and how Big-O explains why some systems slow down as data grows. - [0.3 Functions, modules, objects, interfaces, libraries and frameworks](https://bewiseapps.com/software-architecture-wise/foundations/organising-code): How programmers divide code into functions, modules, objects and interfaces; the difference between a library and a framework; the benefits and risks of dependencies; and a first look at coupling and cohesion. - [0.4 Networks, the internet and the web: IP, DNS, HTTP and the client-server model](https://bewiseapps.com/software-architecture-wise/foundations/how-computers-talk): How data crosses the internet in packets, what IP addresses, ports, TCP, UDP and DNS do, how HTTP requests and HTTPS work, why latency has a floor set by physics, and what happens when you type a web address. - [0.5 Files and databases: relational and non-relational storage, queries and transactions](https://bewiseapps.com/software-architecture-wise/foundations/storing-data): Why systems need databases rather than plain files, how relational tables, keys, SQL, indexes and ACID transactions work, the main NoSQL families, and why backups must be tested. - [0.6 APIs, JSON and how separate systems work together](https://bewiseapps.com/software-architecture-wise/foundations/apis-and-integration): What an API is and why it is a contract, how REST APIs use URLs, HTTP verbs, status codes and JSON, and how keys, webhooks, queues, versions and rate limits shape integration. - [0.7 Servers, operating systems, virtual machines, containers and cloud services](https://bewiseapps.com/software-architecture-wise/foundations/servers-and-the-cloud): What servers and data centres are, how virtual machines and containers share hardware, what IaaS, PaaS, SaaS and serverless hand to the provider, and how regions, zones, CDNs and scaling fit together. - [0.8 Requirements, version control, testing, delivery and the journey of one request](https://bewiseapps.com/software-architecture-wise/foundations/how-software-gets-built): How teams turn needs into user stories, collaborate with Git and pull requests, test at several levels, deliver through CI/CD and environments, and how one tap in a food-delivery app crosses every part of a system. ### [Chapter 1: What Software Architecture Is](https://bewiseapps.com/software-architecture-wise/what-is-architecture/) Beginner to intermediate. The definitions that matter (ISO/IEC/IEEE 42010 and the SEI), how architecture differs from design, why it decides cost and risk, what architects actually do, stakeholders, trade-offs, technical debt and where architecture sits in modern delivery. - [1.1 What software architecture is: the standard definitions and what they share](https://bewiseapps.com/software-architecture-wise/what-is-architecture/defining-architecture): The international standard, the SEI and leading practitioners define software architecture differently. Learn the main definitions, what they share, and the three kinds of structure every system has. - [1.2 Architecture, design and code: significance, scope and levels](https://bewiseapps.com/software-architecture-wise/what-is-architecture/architecture-vs-design): Architecture and design are one continuum of decisions. Learn what makes a decision architecturally significant, how strategic and tactical decisions differ, and how enterprise, solution and software architecture relate. - [1.3 Why architecture matters: cost of change, quality, risk and real failures](https://bewiseapps.com/software-architecture-wise/what-is-architecture/why-architecture-matters): Architecture decides a system's qualities, the cost and speed of every future change, its risks and how teams can work. Real cases from Knight Capital, HealthCare.gov and Prime Video show why. - [1.4 What an architect does: responsibilities, skills and kinds of architect](https://bewiseapps.com/software-architecture-wise/what-is-architecture/the-architect-role): What architects actually do day to day, the eight expectations described by Richards and Ford, the kinds of architect, breadth versus depth, and whether architects should still write code. - [1.5 Stakeholders, their concerns and how architecture serves them](https://bewiseapps.com/software-architecture-wise/what-is-architecture/stakeholders-and-concerns): Who has a stake in a system, what ISO/IEC/IEEE 42010 means by a concern, how to map and engage stakeholders, and how conflicting concerns become explicit requirements, decisions and views. - [1.6 Architectural decisions and trade-offs: reversibility and timing](https://bewiseapps.com/software-architecture-wise/what-is-architecture/decisions-and-trade-offs): Why every architectural choice is a trade-off, how a well-formed decision is structured, one-way and two-way doors, the last responsible moment, designing for reversibility, cognitive traps and the weighted decision matrix. - [1.7 Technical debt, architecture erosion and drift](https://bewiseapps.com/software-architecture-wise/what-is-architecture/technical-debt): What Ward Cunningham's debt metaphor really meant, principal and interest, Fowler's debt quadrant, why architectural debt costs most, erosion and drift, and how to detect, manage and explain debt in business terms. - [1.8 Architecture across the lifecycle: up-front, emergent and continuous architecture](https://bewiseapps.com/software-architecture-wise/what-is-architecture/architecture-in-the-lifecycle): Big design up front versus emergent design, what the Agile Manifesto really says, Fairbanks' risk-driven model, intentional architecture and the runway, continuous architecture, walking skeletons, spikes, and architecture in DevOps. ### [Chapter 2: Quality Attributes and Architecturally Significant Requirements](https://bewiseapps.com/software-architecture-wise/quality-attributes/) Intermediate. How to turn vague wishes like 'fast' and 'secure' into precise, testable requirements: ISO/IEC 25010, quality attribute scenarios, performance, availability, modifiability, security and usability, and how to elicit, prioritise and trade them off. - [2.1 Functional requirements, quality attributes and constraints](https://bewiseapps.com/software-architecture-wise/quality-attributes/functional-vs-quality): What a system must do, how well it must do it, and which choices are already fixed. Learn to spot the architecturally significant requirements that really decide a design. - [2.2 The quality models: ISO/IEC 25010 and how to use it](https://bewiseapps.com/software-architecture-wise/quality-attributes/the-quality-models): The ISO/IEC 25010:2023 product quality model and its nine characteristics, what changed since 2011, other lists such as FURPS+, and how to use a model as a checklist without drowning in paperwork. - [2.3 Writing quality attribute scenarios that can be tested](https://bewiseapps.com/software-architecture-wise/quality-attributes/quality-attribute-scenarios): The six-part scenario that turns 'fast', 'secure' and 'easy to change' into testable requirements, with examples for six qualities, common mistakes and the path from scenario to fitness function. - [2.4 Performance and scalability: latency, throughput, percentiles and load](https://bewiseapps.com/software-architecture-wise/quality-attributes/performance-and-scalability): Latency and throughput, percentiles and tail latency, Little's law, queueing and the utilisation cliff, Amdahl's law and the Universal Scalability Law, with worked calculations and an overview of performance tactics. - [2.5 Availability and reliability: nines, MTBF, MTTR and fault tolerance](https://bewiseapps.com/software-architecture-wise/quality-attributes/availability-and-reliability): What availability, reliability and fault tolerance really mean, how to calculate nines, MTBF and MTTR, how components in series and parallel combine, and the tactics, RTO and RPO that achieve them. - [2.6 Modifiability, testability and deployability: designing for change](https://bewiseapps.com/software-architecture-wise/quality-attributes/modifiability-testability-deployability): How to specify and design for change: what changes, who changes it and when, tactics that limit ripple effects, testability through controllability and observability, deployability, and the DORA delivery metrics. - [2.7 Security, usability, interoperability, cost and sustainability as qualities](https://bewiseapps.com/software-architecture-wise/quality-attributes/security-usability-and-more): Security as a measurable quality, ISO/IEC 25010's security sub-characteristics and tactics, usability and WCAG 2.2 accessibility, interoperability, cost per transaction, software carbon intensity, safety, observability and regulatory qualities. - [2.8 Eliciting, prioritising and trading off quality attributes](https://bewiseapps.com/software-architecture-wise/quality-attributes/eliciting-and-prioritising): Where quality requirements come from, how the SEI Quality Attribute Workshop and the ATAM utility tree uncover and rank them, how to handle conflicts between qualities, and how fitness functions keep them true. ### [Chapter 3: Design Principles and Fundamentals](https://bewiseapps.com/software-architecture-wise/design-principles/) Intermediate. The principles behind every good structure: modularity, coupling and cohesion, information hiding, dependency rules, SOLID at component scale, connascence, Conway's law, simplicity and how to measure structure. - [3.1 Modularity: dividing a system into parts](https://bewiseapps.com/software-architecture-wise/design-principles/modularity): What a module is at every scale, why we divide systems into modules, Parnas's rule of decomposing by likely change, logical versus deployment modules, granularity, and how to enforce boundaries in code. - [3.2 Coupling and cohesion](https://bewiseapps.com/software-architecture-wise/design-principles/coupling-and-cohesion): The two oldest measures of good structure: the classic levels of coupling and cohesion, afferent and efferent coupling, the extra forms of coupling in distributed systems, and tactics to loosen it, with a worked refactoring. - [3.3 Information hiding, abstraction and interfaces](https://bewiseapps.com/software-architecture-wise/design-principles/information-hiding-and-abstraction): Why modules should hide decisions, how information hiding differs from encapsulation, interfaces as contracts and design by contract, leaky abstractions, deep modules, Hyrum's law and how to keep APIs between components stable. - [3.4 Managing dependencies: direction, cycles and stability](https://bewiseapps.com/software-architecture-wise/design-principles/dependencies-and-layering): Which way dependencies should point and why: Robert C. Martin's acyclic, stable-dependencies and stable-abstractions principles, the instability, abstractness and distance metrics, breaking cycles, layering, and automated dependency checks. - [3.5 The SOLID principles applied to components](https://bewiseapps.com/software-architecture-wise/design-principles/solid-at-scale): The five SOLID principles explained precisely, each shown in Python and then at component and service scale, plus the REP, CCP and CRP cohesion principles, their tension triangle and the honest criticism of SOLID. - [3.6 Connascence: a finer measure of coupling](https://bewiseapps.com/software-architecture-wise/design-principles/connascence): Meilir Page-Jones's connascence names the hidden agreements between parts of a system, ranks them by strength and judges them by locality and degree, from positional parameters to timing between services. - [3.7 Conway's law and the shape of organisations](https://bewiseapps.com/software-architecture-wise/design-principles/conways-law): Melvin Conway's 1968 observation that systems copy the communication structure of the organisations that design them, the research evidence, the arithmetic of communication paths, the inverse Conway manoeuvre and team cognitive load. - [3.8 Simplicity, reversibility and measuring structure](https://bewiseapps.com/software-architecture-wise/design-principles/simplicity-and-measurement): Essential and accidental complexity, KISS, YAGNI, DRY as knowledge rather than text, reversibility as an option, and how to measure structure with cyclomatic complexity, LCOM, change coupling and fitness functions without falling foul of Goodhart's law. ### [Chapter 4: Documenting and Communicating Architecture](https://bewiseapps.com/software-architecture-wise/documenting-architecture/) Intermediate. Views and viewpoints, the C4 model, the UML that still matters, Architecture Decision Records, arc42, diagrams as code and how to present architecture to technical and non-technical audiences. - [4.1 Why and how much to document](https://bewiseapps.com/software-architecture-wise/documenting-architecture/why-document): Who reads architecture documentation and what each reader needs, what the Agile Manifesto really says about documents, how to decide what is worth writing down, and the rules that keep documentation useful. - [4.2 Views and viewpoints: ISO/IEC/IEEE 42010, 4+1 and Rozanski and Woods](https://bewiseapps.com/software-architecture-wise/documenting-architecture/views-and-viewpoints): Why one diagram is never enough: the ISO/IEC/IEEE 42010 model of stakeholders, concerns, viewpoints and views, Kruchten's 4+1, Rozanski and Woods's viewpoints and perspectives, and how to choose the views a system needs. - [4.3 The C4 model: context, containers, components and code](https://bewiseapps.com/software-architecture-wise/documenting-architecture/the-c4-model): Simon Brown's C4 model in practice: the four zoom levels, what a container really is, the notation rules that make diagrams self-explanatory, and a food-delivery platform drawn at context, container and component level. - [4.4 The UML diagrams architects still use](https://bewiseapps.com/software-architecture-wise/documenting-architecture/uml-essentials): UML's status today, Fowler's sketch, blueprint and programming-language modes, and the notation essentials of the six diagrams architects still use, each drawn for the food-delivery platform. - [4.5 Architecture Decision Records](https://bewiseapps.com/software-architecture-wise/documenting-architecture/architecture-decision-records): How to record significant decisions so their reasons survive: Nygard's format, MADR and Y-statements, statuses and superseding, where to keep records, what deserves one, review and anti-patterns. - [4.6 arc42 and other documentation templates](https://bewiseapps.com/software-architecture-wise/documenting-architecture/arc42-and-templates): The twelve sections of arc42, what goes in each and how much to write for small and large systems, a one-page arc42-lite example, the SEI and IEEE 1016 templates, and conformance with ISO/IEC/IEEE 42010. - [4.7 Diagrams as code and keeping documentation current](https://bewiseapps.com/software-architecture-wise/documenting-architecture/diagrams-as-code): Writing diagrams as text with PlantUML, Mermaid, Structurizr DSL and D2, drawing versus modelling tools, building documentation in the pipeline and the habits that keep it true. - [4.8 Communicating architecture to different audiences](https://bewiseapps.com/software-architecture-wise/documenting-architecture/communicating-architecture): Tailoring architecture to executives, product managers, developers, operations, security and auditors: explaining trade-offs, one-page summaries, following one request, design docs and RFCs, reviews, diagram design and building consensus. ### [Chapter 5: Architectural Styles I: Monoliths and Modular Designs](https://bewiseapps.com/software-architecture-wise/monolithic-styles/) Intermediate. Styles for systems deployed as one unit: layered, modular monolith, pipes and filters, microkernel, hexagonal and clean architecture, domain-driven design, and when a monolith is the right answer. - [5.1 Architectural styles, patterns and tactics](https://bewiseapps.com/software-architecture-wise/monolithic-styles/what-is-a-style): The vocabulary for the next two chapters: styles, patterns, tactics and reference architectures, technical versus domain partitioning, monolithic versus distributed deployment, and the architecture quantum. - [5.2 Layered architecture](https://bewiseapps.com/software-architecture-wise/monolithic-styles/layered-architecture): The most familiar style: presentation, business, persistence and database layers. Closed and open layers, layers of isolation, the sinkhole anti-pattern, why every feature touches every layer, and how to enforce the rules. - [5.3 The modular monolith](https://bewiseapps.com/software-architecture-wise/monolithic-styles/modular-monolith): One deployable application divided by business domain into modules with explicit APIs and their own data. How to enforce the boundaries, how modules communicate, what Shopify learned, and how it keeps the option of extracting services later. - [5.4 Pipes and filters and pipeline architectures](https://bewiseapps.com/software-architecture-wise/monolithic-styles/pipes-and-filters): Data flowing through a chain of independent steps: producers, transformers, testers and consumers joined by pipes. From Unix pipes to ETL, compilers and stream processing, with throughput, back pressure and error handling. - [5.5 Microkernel and plug-in architectures](https://bewiseapps.com/software-architecture-wise/monolithic-styles/microkernel): How a small core system plus independent plug-ins delivers extensibility: registries, contracts, isolation and versioning, real examples from IDEs and browsers, and a worked plug-in contract for country-specific tax rules. - [5.6 Hexagonal, onion and clean architecture](https://bewiseapps.com/software-architecture-wise/monolithic-styles/hexagonal-and-clean): Ports and adapters, onion and clean architecture: keeping business logic at the centre with dependencies pointing inwards, driving and driven ports, a Python example with a real adapter and a test double, and the costs. - [5.7 Strategic domain-driven design: bounded contexts and context maps](https://bewiseapps.com/software-architecture-wise/monolithic-styles/domain-driven-design): Finding boundaries in the business domain: ubiquitous language, core, supporting and generic subdomains, bounded contexts, context-map relationships, event storming, aggregates, and a context map of the food-delivery platform. - [5.8 When a monolith is the right answer](https://bewiseapps.com/software-architecture-wise/monolithic-styles/choosing-a-monolith): MonolithFirst, the microservice premium and the majestic monolith; when one deployment unit is the right choice, how far a monolith scales, the signs that it is time to split, and a decision guide for the Chapter 5 styles. ### [Chapter 6: Architectural Styles II: Distributed Systems](https://bewiseapps.com/software-architecture-wise/distributed-systems/) Intermediate to advanced. Why and when to distribute, the fallacies of distributed computing, service-based and microservice architectures, event-driven systems, synchronous and asynchronous communication, CAP and PACELC, sagas, serverless and space-based designs. - [6.1 Why distribute, and the fallacies of distributed computing](https://bewiseapps.com/software-architecture-wise/distributed-systems/why-distribute): The real reasons to split a system across machines, the eight fallacies that make distribution harder than it looks, partial failure, the costs, and the arithmetic of synchronous call chains. - [6.2 Service-based architecture and service-oriented architecture](https://bewiseapps.com/software-architecture-wise/distributed-systems/service-based-and-soa): Coarse-grained domain services sharing a database, the enterprise service bus era of SOA and why it faded, how microservices differ, and when service-based architecture is the pragmatic middle ground. - [6.3 Microservices: principles, benefits and costs](https://bewiseapps.com/software-architecture-wise/distributed-systems/microservices): What microservices are according to Lewis and Fowler, bounded contexts, independent deployability, database per service, gateways and meshes, how to decide granularity, the classic anti-patterns and the organisational price. - [6.4 Event-driven architecture: brokers, mediators and event streams](https://bewiseapps.com/software-architecture-wise/distributed-systems/event-driven): Events, commands and messages; broker and mediator topologies; Fowler's four event patterns; how Kafka's partitions, offsets and consumer groups work; delivery guarantees, idempotent consumers, schemas and dead-letter queues. - [6.5 Synchronous and asynchronous communication: REST, gRPC, GraphQL and messaging](https://bewiseapps.com/software-architecture-wise/distributed-systems/communication-and-apis): How services talk: the coupling created by synchronous and asynchronous communication, REST and HTTP semantics, gRPC, GraphQL and messaging, and the API design practices that let interfaces evolve without breaking consumers. - [6.6 Consistency models, CAP and PACELC](https://bewiseapps.com/software-architecture-wise/distributed-systems/consistency-cap-pacelc): What consistency means for replicated data: the models from linearisable to eventual, what the CAP theorem really says and what it does not, PACELC's everyday latency trade-off, quorum arithmetic and choosing consistency per use case. - [6.7 Distributed transactions, sagas and the outbox pattern](https://bewiseapps.com/software-architecture-wise/distributed-systems/sagas-and-distributed-transactions): How to keep data consistent when one business action spans several services: two-phase commit and why it is avoided, sagas with compensations, choreography and orchestration, isolation countermeasures, the transactional outbox and idempotent receivers. - [6.8 Serverless and space-based architectures](https://bewiseapps.com/software-architecture-wise/distributed-systems/serverless-and-space-based): Two opposite answers to capacity: serverless functions and managed back ends that scale to zero and bill per use, and space-based architecture that serves extreme peaks from replicated memory with the database off the hot path. ### [Chapter 7: Data Architecture](https://bewiseapps.com/software-architecture-wise/data-architecture/) Intermediate to advanced. Data ownership, choosing a database, transactions and isolation, replication and partitioning, CQRS and event sourcing, caching, schema evolution, and analytics, streaming and data mesh. - [7.1 Data ownership and database per service](https://bewiseapps.com/software-architecture-wise/data-architecture/data-ownership): Who may change each piece of data, why a shared database couples services, how to resolve joint ownership, and how to read, report on and contract for data you do not own. - [7.2 Choosing a database: relational, document, key-value, column, graph and time-series](https://bewiseapps.com/software-architecture-wise/data-architecture/choosing-a-database): What each family of database is good and bad at, from relational to vector and distributed SQL, and how to choose by data shape, access patterns, consistency, scale, operations and team skills. - [7.3 Transactions, ACID and isolation levels](https://bewiseapps.com/software-architecture-wise/data-architecture/transactions-and-isolation): What ACID really guarantees, the anomalies that isolation levels allow, how MVCC and snapshot isolation work, why level names mislead, and when to use locking, version checks or serializable transactions. - [7.4 Replication, partitioning and sharding](https://bewiseapps.com/software-architecture-wise/data-architecture/replication-and-partitioning): How databases copy data for availability and read scale, what replication lag and failover do to correctness, and how partitioning by range or hash, consistent hashing and secondary indexes shape a sharded design. - [7.5 CQRS and event sourcing](https://bewiseapps.com/software-architecture-wise/data-architecture/cqrs-and-event-sourcing): Separating the model that changes data from the models that read it, storing state as an append-only sequence of events, and the real costs: eventual consistency, event versioning and personal data. - [7.6 Caching strategies and their pitfalls](https://bewiseapps.com/software-architecture-wise/data-architecture/caching): Why caches speed systems up and what they cost: cache-aside, read-through, write-through, write-behind and refresh-ahead, TTLs and invalidation, stampedes, levels of caching, HTTP headers and eviction. - [7.7 Schema evolution, migrations and compatibility](https://bewiseapps.com/software-architecture-wise/data-architecture/schema-evolution): Changing database, API and event schemas while the system keeps running: backward, forward and full compatibility, expand and contract, migration tools, large backfills, and schema registries for Avro and Protocol Buffers. - [7.8 Analytics, streaming, warehouses, lakes and data mesh](https://bewiseapps.com/software-architecture-wise/data-architecture/analytics-and-streaming): How analytical data is architected: OLTP versus OLAP, warehouses and star schemas, ETL and ELT, lakes and lakehouses, stream processing with event time and watermarks, Lambda and Kappa, and data mesh. ### [Chapter 8: Security, Privacy and Compliance by Design](https://bewiseapps.com/software-architecture-wise/security-by-design/) Intermediate to advanced. Security principles, threat modelling with STRIDE, identity and access (OAuth 2.0 and OpenID Connect), encryption and secrets, zero trust, software supply-chain security, privacy by design under the GDPR, and security in operation. - [8.1 Security principles for architects](https://bewiseapps.com/software-architecture-wise/security-by-design/security-principles): The CIA triad, Saltzer and Schroeder's design principles, defence in depth, secure defaults, attack surface and trust boundaries, the OWASP Top 10 and a secure development lifecycle, with who owns what. - [8.2 Threat modelling: STRIDE, attack trees and data-flow diagrams](https://bewiseapps.com/software-architecture-wise/security-by-design/threat-modelling): Shostack's four questions, data-flow diagrams with trust boundaries, STRIDE and attack trees, rating risk without false precision, and a worked threat model of a food-delivery checkout. - [8.3 Identity and access: authentication, authorisation, OAuth 2.0 and OpenID Connect](https://bewiseapps.com/software-architecture-wise/security-by-design/identity-and-access): Authentication versus authorisation, NIST's current password rules, MFA and passkeys, sessions and JWTs, OAuth 2.0 with PKCE, OpenID Connect, RBAC, ABAC, relationship-based access and workload identity. - [8.4 Encryption, key management and secrets](https://bewiseapps.com/software-architecture-wise/security-by-design/protecting-data): Encryption in transit and at rest and what each layer really protects, symmetric and asymmetric cryptography, password hashing, KMS and envelope encryption, secrets, tokenisation for PCI DSS and data classification. - [8.5 Secure communication and zero trust](https://bewiseapps.com/software-architecture-wise/security-by-design/zero-trust): Why the trusted internal network failed, what NIST SP 800-207 and BeyondCorp mean by zero trust, and how mTLS, workload identity, service meshes, certificates and gateways put it into practice. - [8.6 Software supply-chain security](https://bewiseapps.com/software-architecture-wise/security-by-design/supply-chain-security): Why dependencies and build pipelines are an attack surface, what event-stream, SolarWinds, Log4Shell and xz utils teach, and how SBOMs, SLSA, Sigstore, pinning and the EU Cyber Resilience Act respond. - [8.7 Privacy by design and the GDPR](https://bewiseapps.com/software-architecture-wise/security-by-design/privacy-by-design): How the GDPR and UK GDPR shape architecture: Article 5 principles, data protection by design and by default, rights systems must support, DPIAs, transfers, pseudonymisation, retention and erasure across every copy. - [8.8 Security in operation: logging, detection and response](https://bewiseapps.com/software-architecture-wise/security-by-design/security-in-operation): Running a system securely: what to log and never log, audit trails, SIEM detection, vulnerability management with CVSS, EPSS and KEV, NIST incident response, ransomware-proof backups and breach notification deadlines. ### [Chapter 9: Performance, Scalability, Resilience and Operability](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/) Intermediate to advanced. Scaling strategies, load balancing and statelessness, queues and back pressure, timeouts, retries, circuit breakers and bulkheads, SLIs, SLOs and error budgets, observability, capacity planning and chaos engineering. - [9.1 Scaling strategies: vertical, horizontal and the scale cube](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/scaling-strategies): Scaling up and out and their limits, Abbott and Fisher's scale cube, statelessness, reactive, scheduled and predictive autoscaling, choosing a scaling signal, avoiding flapping, and sizing a fleet for a peak. - [9.2 Load balancing, statelessness and sessions](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/load-balancing-and-statelessness): Layer 4 and layer 7 load balancers, the main algorithms including the power of two random choices, liveness and readiness checks, connection draining, the trouble with sticky sessions, externalised session state and global load balancing. - [9.3 Asynchrony, queues and back pressure](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/queues-and-back-pressure): How queues turn spikes into backlogs, competing consumers, sizing queues with Little's law, back pressure, load shedding and prioritisation, token-bucket and other rate limiters, HTTP 429 with Retry-After, and dead-letter queues. - [9.4 Timeouts, retries, circuit breakers, bulkheads and graceful degradation](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/resilience-patterns): The stability patterns that stop one slow dependency taking down a system: timeouts and deadlines, retries with backoff, jitter and budgets, circuit breakers, bulkheads, fallbacks, idempotency and hedged requests. - [9.5 SLIs, SLOs, SLAs and error budgets](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/slos-and-error-budgets): How to measure reliability from the user's point of view with SLIs, set SLO targets, turn them into error budgets and policies, alert on burn rate and keep SLAs safely looser than internal objectives. - [9.6 Observability: logs, metrics and traces](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/observability): How to see inside a running distributed system: structured logs, metric types and histograms, RED, USE and the golden signals, distributed tracing with W3C Trace Context and OpenTelemetry, cardinality and symptom-based alerting. - [9.7 Capacity planning and performance testing](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/capacity-and-performance-testing): How to plan capacity before demand arrives and test that it is really there: forecasting, headroom and lead times, load, stress, soak, spike and breakpoint tests, open and closed workloads, coordinated omission and performance budgets. - [9.8 Chaos engineering, incidents and blameless learning](https://bewiseapps.com/software-architecture-wise/resilience-and-operability/chaos-and-incidents): How to find weaknesses before users do and learn from failures that happen anyway: chaos experiments and game days, incident command, severity levels and status pages, blameless reviews, the limits of MTTR and actions that change the system. ### [Chapter 10: Cloud-Native and Infrastructure Architecture](https://bewiseapps.com/software-architecture-wise/cloud-native/) Intermediate to advanced. Cloud service models, containers and Kubernetes, the twelve-factor app, infrastructure as code, CI/CD and deployment strategies, multi-region and edge, platform engineering, FinOps and lock-in as a trade-off. - [10.1 Cloud service and deployment models](https://bewiseapps.com/software-architecture-wise/cloud-native/cloud-models): IaaS, CaaS, PaaS, FaaS and SaaS, public, private, hybrid and multi-cloud, shared responsibility, zones and managed services, what cloud native means, and when renting is not cheaper. - [10.2 Containers and orchestration with Kubernetes](https://bewiseapps.com/software-architecture-wise/cloud-native/containers-and-orchestration): Images, layers, registries and the OCI standards; why orchestration is needed; the Kubernetes control plane, nodes, core objects and reconciliation loops; requests, limits, probes, and when Kubernetes is overkill. - [10.3 The twelve-factor app and cloud-native principles](https://bewiseapps.com/software-architecture-wise/cloud-native/twelve-factor): All twelve factors with what each means, why it matters and where it has aged; the principles beyond them (disposability, immutability, observability, security); and a worked audit of an existing service with prioritised fixes. - [10.4 Infrastructure as code and immutable infrastructure](https://bewiseapps.com/software-architecture-wise/cloud-native/infrastructure-as-code): Declarative and imperative infrastructure code; Terraform, OpenTofu, CloudFormation, Bicep and Pulumi; state, locking, drift, modules and environments; immutable infrastructure; GitOps; policy as code; and how to test it all. - [10.5 CI/CD pipelines and deployment strategies](https://bewiseapps.com/software-architecture-wise/cloud-native/ci-cd-and-deployment): How a change travels from commit to production: pipeline stages, build once and deploy many, trunk-based development, rolling, blue-green, canary and shadow deployments, feature flags, migrations and rollback. - [10.6 Multi-region, disaster recovery and edge computing](https://bewiseapps.com/software-architecture-wise/cloud-native/multi-region-and-edge): When and how to run across regions: latency, disaster recovery and data residency, the four DR strategies with RTO, RPO and cost, cross-region data, failover, cells for blast radius, CDNs and edge functions. - [10.7 Platform engineering and internal developer platforms](https://bewiseapps.com/software-architecture-wise/cloud-native/platform-engineering): Why organisations build internal developer platforms, golden paths and Backstage, running the platform as a product with self-service and guardrails, reducing cognitive load, measuring success with DORA and SPACE, and avoiding the common traps. - [10.8 FinOps, cost architecture and vendor lock-in](https://bewiseapps.com/software-architecture-wise/cloud-native/finops-and-lock-in): Treating cost as an architectural quality: FinOps phases, unit economics such as cost per order, common cost drivers, commitments and spot, tagging, showback and chargeback, and lock-in as a deliberate trade-off with an exit strategy. ### [Chapter 11: Evaluation, Decision-Making and Governance](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/) Advanced. How architectures are judged and governed: ATAM and lightweight reviews, fitness functions and evolutionary architecture, governance in agile organisations, Team Topologies, legacy modernisation, leadership, ethics and the business case. - [11.1 Architecture evaluation and the ATAM](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/architecture-evaluation): Why and when to evaluate an architecture, how the SEI's ATAM works step by step, what risks, sensitivity points and trade-off points are, and how CBAM adds costs and benefits. - [11.2 Lightweight reviews and risk-storming](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/lightweight-reviews): Why review boards often fail, and the lightweight alternatives that work: risk-storming, pre-mortems, architecture katas, TARA, RFC reviews and checklists, with a 90-minute review format. - [11.3 Fitness functions and evolutionary architecture](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/fitness-functions): How to protect architectural characteristics with automated checks: what fitness functions are, their categories, examples for structure, performance, security, resilience and data, and evolutionary architecture. - [11.4 Architecture governance in agile organisations](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/governance-in-agile): What architecture governance is for and how to do it without slow gates: principles, standards, guardrails, the advice process, advisory forums, technology radars, policy as code and enterprise architecture. - [11.5 Team Topologies and socio-technical design](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/team-topologies): How to design teams and software together: the four team types, three interaction modes, cognitive load, team APIs and fracture planes, with a worked redesign of the food-delivery teams. - [11.6 Modernising legacy systems: strangler fig and incremental migration](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/legacy-modernisation): Why big rewrites fail and how to modernise safely instead: the seven Rs, the strangler fig, branch by abstraction, parallel runs, change data capture, anti-corruption layers and careful data migration. - [11.7 Leadership, influence and decision-making](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/leadership-and-influence): How architects lead without formal authority: building trust, facilitating decisions by consent or consensus, handling conflict and politics, talking to executives, riding the architect elevator and growing other architects. - [11.8 Ethics, sustainability and the business case](https://bewiseapps.com/software-architecture-wise/evaluation-and-governance/ethics-and-business-cases): How to argue for architecture work in money, time and risk, with net present value and payback worked through; and how professional ethics, foreseeable harms and green software practice shape responsible design. ### [Chapter 12: Architecting AI-Enabled Systems](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/) Advanced. Machine learning and large language models from an architect's point of view: where models fit, retrieval-augmented generation, agents and tool use, evaluation, guardrails, cost and latency, LLMOps and responsible AI under the EU AI Act. - [12.1 Machine learning and large language models for architects](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/ml-and-llm-basics): What machine learning and large language models actually do, from training and evaluation to tokens, context windows, sampling and embeddings, and what a probabilistic component means for the system around it. - [12.2 Where models fit in an architecture](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/where-models-fit): Hosted, self-hosted or on-device models; online and batch inference; AI gateways, routing, cascades and fallback ladders; humans in the loop; choosing a model; and a reference architecture for a support assistant. - [12.3 Retrieval-augmented generation and vector search](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/retrieval-augmented-generation): How to ground model answers in your own data: ingestion and chunking, embeddings and vector indexes, hybrid retrieval and re-ranking, citations, access control, freshness, evaluation and failure modes. - [12.4 Agents, tool use and orchestration](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/agents-and-tool-use): How models call tools, how the agent loop works, when a workflow beats an autonomous agent, what the Model Context Protocol standardises, and how to make agents dependable with limits, idempotency, checkpoints and approval. - [12.5 Evaluating and testing AI-enabled systems](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/evaluating-ai-systems): How to test components whose outputs vary: golden sets, scoring methods, LLM-as-judge and its biases, offline and online evaluation, regression evals in CI, production monitoring, red teaming and confidence in the numbers. - [12.6 Guardrails, safety and prompt injection](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/guardrails-and-safety): Why a language model is an untrusted component: direct and indirect prompt injection, jailbreaks, the OWASP Top 10 for LLM Applications, the lethal trifecta, and layered defences that hold even when the model is manipulated. - [12.7 Cost, latency and LLMOps](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/cost-latency-and-llmops): The economics and operations of model calls: input and output tokens, time to first token and streaming, prompt and semantic caching, batching, cascades, rate limits and fallback ladders, versioning, tracing and cost monitoring. - [12.8 Data governance, responsible AI and the EU AI Act](https://bewiseapps.com/software-architecture-wise/ai-enabled-systems/responsible-ai): Turning responsible-AI principles into architecture: data provenance and personal data in prompts and logs, bias and fairness, transparency and model cards, human oversight, the EU AI Act as amended in 2026, the NIST AI RMF and ISO/IEC 42001. ## Other pages - [Glossary](https://bewiseapps.com/software-architecture-wise/glossary) - [How the course, tests and certificate work](https://bewiseapps.com/software-architecture-wise/how-it-works) - [A path for beginners](https://bewiseapps.com/software-architecture-wise/beginners-path): a suggested route through the course in six stages for people new to software, with a method for the harder sections - [A route for experienced learners](https://bewiseapps.com/software-architecture-wise/experienced-route): the chapters in the same order, 0 to 12, for people who already work with software, with guidance on what they may skim; every chapter test must still be passed for the certificate - [Check a certificate](https://bewiseapps.com/software-architecture-wise/verify)