SOFTWARE ARCHITECTURE is the process of designing the global organisation of a software system, including: · dividing the software into subsystems · deciding how these will interact · determining their interfaces The output — the ARCHITECTURAL DESIGN — is the earliest design decision set, and it is the CRITICAL LINK between design and requirements engineering, because it identifies the main structural components and their relationships. A SUBSYSTEM is a system in its own right whose operation does NOT depend on the services provided by other subsystems. Subsystems are composed of MODULES and have defined interfaces used for communication with other subsystems. A MODULE is a system component that provides services to other components but would not normally be considered a separate system. WHY ARCHITECTURE IS THE FIRST THING DECIDED — three reasons Sommerville gives, each with a concrete consequence: 1. STAKEHOLDER COMMUNICATION Architecture is a high-level presentation of the system, which can be used as a focus for discussion by a range of different stakeholders. It is the only design artefact a non-engineer can meaningfully review. 2. SYSTEM ANALYSIS It makes explicit the analysis of whether the system can meet its NON-FUNCTIONAL requirements. You can reason about performance, availability and security from a box-and-line diagram — and you cannot reason about them from code. 3. LARGE-SCALE REUSE The architecture may be reusable across a range of systems with similar requirements — this is what a REFERENCE ARCHITECTURE or a product line is. THE THREE ADVANTAGES OF EXPLICIT ARCHITECTURE, restated: it supports discussion, it permits early evaluation against the NFRs, and it enables reuse at the largest granularity available.

ARCHITECTURAL DESIGN IS A CREATIVE PROCESS, so the activities differ radically depending on the type of system. However, a number of common DECISIONS span all design processes, and these decisions affect the non-functional characteristics of the system. THE EIGHT QUESTIONS (Sommerville's list): 1. Is there a GENERIC APPLICATION ARCHITECTURE that can be used as a template? 2. How will the system be DISTRIBUTED across hardware cores or processors? 3. What ARCHITECTURAL STYLES are appropriate? 4. What approach will be used to STRUCTURE the system? 5. How will the system be DECOMPOSED into modules? 6. What CONTROL STRATEGY should be used? 7. How will the architectural design be EVALUATED? 8. How should the architecture be DOCUMENTED? Note that questions 4, 5 and 6 are the three following topics of this syllabus — system organisation, modular decomposition and control styles. They are not independent choices bolted together; they are three views of one structure. THERE IS NO GENERIC ARCHITECTURAL PROCESS. Architectural design is a creative activity, and although specific activities may be part of all design processes, the ordering and the emphasis vary by system type. THE FUNDAMENTAL ASYMMETRY — WHY EACH DECISION IS EXPENSIVE: A component can be replaced. A component's PLACE in the structure cannot, because every other component's assumptions are built around it. Concretely: changing an algorithm inside a module → hours changing a module's interface → days, and the callers changing which subsystem owns a responsibility → weeks changing the control style → a rewrite changing the data ownership model (one shared DB → per-service DBs) → a multi-quarter programme

THE MOST EXAMINABLE POINT IN THIS TOPIC: the architecture you choose is largely determined by the non-functional requirement that matters most — and the choices CONFLICT. PERFORMANCE → localise critical operations, minimise communication, use LARGE-GRAIN rather than fine-grain components (fewer, bigger components = less communication overhead) SECURITY → use a LAYERED architecture, with critical assets in the INNER layers and a high level of security validation applied to those layers SAFETY → localise safety-critical features in a SMALL NUMBER of subsystems, to reduce the cost and the problems of safety validation AVAILABILITY → include REDUNDANT COMPONENTS and mechanisms for fault tolerance, so components can be replaced and updated without stopping the system MAINTAINABILITY → use FINE-GRAIN, self-contained, replaceable components, and avoid shared data structures THE CONFLICTS ARE UNAVOIDABLE AND EXPLICIT: PERFORMANCE wants large-grain components. MAINTAINABILITY wants fine-grain components. → THESE ARE DIRECTLY OPPOSED. You cannot have both maximally; the architect must decide which the system's success depends on, and record the trade-off. AVAILABILITY wants redundancy. SECURITY wants a small attack surface. → more replicas = more machines holding the data = more places to breach. SAFETY wants critical logic concentrated for validation. MAINTAINABILITY wants concerns separated. → concentration eases certification and worsens modularity. THIS IS WHY "just apply best practice" is not an answer. Every architecture is a chosen POSITION in a space of conflicting goals, and the architect's job is to know which conflict this system's success turns on.

THE SYSTEM: online licence renewal, national scale. THE NON-FUNCTIONAL REQUIREMENTS, ranked by the business: 1. AVAILABILITY 99.9% monthly (≈ 43.2 min downtime/month) 2. SECURITY holds citizen identity data; a breach is a national news event 3. PERFORMANCE p95 < 2 s at a July peak of 500 concurrent users 4. MAINTAINABILITY a small in-house team of 6 maintains it CHECK 1 — is 99.9% achievable on a single server? A single commodity server plus its OS, network and power realistically achieves ~99% (≈ 7.3 h/month down). Target is 43.2 min/month (0.1% of 30 × 24 × 60 = 43,200 min). Using availability = MTBF / (MTBF + MTTR): one server, MTBF 720 h, MTTR 4 h → 720/724 = 99.45% ✗ misses the target add a standby with automatic failover, MTTR 5 min → 720/(720+0.0833) = 99.988% ✓ DECISION: redundancy is not optional. The architecture must have no single point of failure → rules out any design with in-process session state, because a failover would drop every logged-in user. CHECK 2 — can 500 concurrent users be served? Assume p95 target 2 s and a mean service time of 200 ms per request, with each user issuing a request every 10 s (think time). offered load = 500 users / 10 s = 50 requests/second server capacity per core at 200 ms = 5 req/s cores needed at 100% utilisation = 50/5 = 10 But queueing theory says response time explodes as utilisation → 1. At 70% utilisation, the practical planning figure: cores needed = 10 / 0.7 = 14.3 → 15 whole cores DECISION: the application tier must scale horizontally → stateless application servers behind a load balancer. (Which is the SAME conclusion the availability analysis reached, from a different direction. That agreement is a good sign.) CHECK 3 — security. Identity data must not be reachable from the internet-facing tier. DECISION: LAYERED architecture — presentation, application, data — with the database on a private network reachable only from the application layer, and audit logging in a separate store the application cannot delete from. CHECK 4 — maintainability with a team of 6. Microservices would give fine-grain replaceability, but a 6-person team cannot operate 15 independently deployed services (each needs monitoring, deployment, on-call). DECISION: a MODULAR MONOLITH — one deployable unit, strong internal module boundaries. This deliberately trades fine-grain replaceability for operational simplicity. THE RESULTING ARCHITECTURE: load balancer → 3+ stateless application instances (modular monolith, layered internally) → shared session store (Redis) — external, so failover preserves logins → primary database + synchronous standby, private network → append-only audit store, separate credentials EVERY BOX IS TRACEABLE TO AN NFR. That is what a defensible architectural decision looks like — and note that the maintainability decision (monolith) went AGAINST the textbook "fine-grain for maintainability" guidance, because the real constraint was team size. Guidance is not a substitute for analysis.