Day 22: Architects Choose Trade‑offs, Not Just Draw Diagrams

Assume a hospital wants to build an Internet registration system. Patients demand a simple, one‑click registration experience, security staff require strict authentication, authorization and auditing of medical data, managers want fast rollout with controlled cost, and operations need high‑peak reliability and rapid recovery. These reasonable requirements often conflict, and the system architect is responsible for resolving the trade‑offs.

01 One Sentence to Remember

Architects turn diverse stakeholder demands into documented, reviewable, implementable and evolvable system‑level architecture decisions.

Architects are not tasked with finding the "latest technology"; they must choose the most appropriate solution among business goals, quality attributes, technical constraints and cost, and explain the rationale and trade‑offs.

02 What Is System Architecture?

System architecture is the high‑level structure of a system, encompassing:

Main components

Responsibilities of each component

Connections and interactions between components

System constraints

Design principles guiding evolution

In the Internet hospital example, architecture questions include whether registration, payment and consultation should be separate components, synchronous vs. asynchronous communication, data ownership, scaling during peak registration, fault recovery, and security mechanisms. A UI detail such as button colour is not an architecture decision.

Four questions help decide if an issue is architectural: does it affect multiple stakeholders, involve quality attributes, require cross‑team coordination, or have long‑term impact? Multiple “yes” answers indicate an architectural concern.

03 What Does a System Architect Do?

The official tutorial describes the architect as the project’s "chief designer" whose responsibilities compress into five activities:

1. Understand and Confirm Requirements

Business goals

Functional requirements

Quality requirements

Technical and business constraints

Identify conflicts and risks

For example, "good performance" must be refined by asking about expected load, concurrency, response‑time targets, degradation options, and recovery time objectives.

2. Make System‑Level Architecture Decisions

Component decomposition

Component responsibilities

Component communication

Data ownership

Chosen architectural style

Deployment strategy

How key quality attributes are satisfied

These decisions are costly to change, so the rationale must be recorded.

3. Express and Communicate Architecture

Architecture must be shared beyond the architect’s mind via:

Documentation

Architecture views

Models

Quality scenarios

Interface specifications

Architecture decision records

Different audiences care about different aspects: developers need module boundaries and interfaces; operations need deployment, monitoring and recovery details; security needs authentication, authorization and audit information; managers focus on cost, schedule and risk.

4. Identify and Mitigate Technical Risks

Feasibility of technology

Performance adequacy

Legacy integration

Completeness of security mechanisms

Single points of failure

Team’s technical capability

High‑risk items are addressed early with prototypes, minimal viable systems, stress‑test models or interface validation programs to prove feasibility before full implementation.

5. Guide Implementation and Preserve Architectural Integrity

Define development standards and technical constraints

Guide teams to follow the architecture

Inspect code and deployment for deviations

Feed implementation feedback back into the architecture

Drive evolution when requirements change

The architect does not abandon the project after drawing diagrams; they stay involved to ensure the built system matches the intended architecture.

04 Who Is Not a System Architect?

Architects differ from product managers (who answer why, for whom, and what), project managers (who manage people, schedule, cost, resources and project risk), and senior developers (who focus on concrete code). Architects translate goals into system structure, satisfy quality requirements, and handle technical constraints and risks.

05 Who Are Stakeholders?

Stakeholders are people, teams or organizations that affect the system or are affected by it. In an Internet hospital they include:

Hospital managers – business value, cost, compliance, launch schedule

Patients – functionality, user experience, response time, privacy

Doctors – consultation workflow, medical record completeness, efficiency

Project managers – schedule, cost, resources, project risk

Developers – component boundaries, interfaces, technical feasibility

Testers – testability, acceptance criteria, failure scenarios

Operations – deployment, monitoring, scaling, recovery, supportability

Security & compliance – authentication, authorization, audit, privacy, regulations

Maintenance – documentation, modifiability, impact of changes

The simple rule is: "Who cares about what?"

06 Why Must Architects Make Trade‑offs?

Stakeholder demands frequently clash (e.g., user convenience vs. strict security, rapid launch vs. long‑term maintainability, multi‑data‑center resilience vs. cost, real‑time consistency vs. performance). An architect cannot maximise every goal simultaneously; they must select the most suitable solution under the given constraints.

Architecture is not about picking the best technology, but about choosing the most appropriate solution within constraints.

07 Six Sub‑processes of the Architecture Lifecycle

Requirements → Design → Documentation → Review → Implementation → Evolution

Mnemonic: 需、设、档、审、实、演 (need, design, document, review, implement, evolve) or the action verbs: ask, decide, write, check, do, change.

Step 1: Architecture Requirements

Answer: What problem does the system solve?

Gather business goals, functional needs, quality requirements

Identify technical, cost, regulatory constraints

Pre‑identify components

Review the requirements

Examples: support massive concurrent registration during peak hours, recover core services within a defined time, ensure patient records are accessed only by authorised personnel, retain audit logs for all sensitive operations.

Step 2: Architecture Design

Answer: How should the system be organised?

Select architectural style

Decompose components

Define component responsibilities

Specify interfaces and interactions

Determine data relationships

Formulate the architecture solution

Conduct design reviews

Examples: split registration, payment, scheduling and notification into separate components; use asynchronous messaging for notifications; deploy redundant registration services; apply authentication, authorization and auditing to patient data.

Step 3: Architecture Documentation

Answer: How to make the architecture understandable and executable?

Describe system composition

Show component connections

List interfaces and constraints

Explain key decisions

Detail how important quality requirements are met

Documentation should be written from the user’s perspective, provided to relevant developers, and kept up‑to‑date as the architecture evolves.

Step 4: Architecture Review

Answer: Is the architecture reasonable and what risks exist?

Invite representatives from users, domain experts, developers, testers, operations, security and independent technical staff. Check whether the architecture satisfies requirements, reflects quality attributes, has sensible component boundaries, clear interfaces, explicit documentation, and whether technical or collaboration risks are present. Prototypes or minimal systems can be built to validate performance and integration risks.

Step 5: Architecture Implementation

Answer: How to turn the blueprint into a real system?

Implement components according to architectural constraints

Reuse components from a component library where possible

Develop missing components

Assemble according to defined interfaces and interaction patterns

Perform component and system testing

Verify that the implementation conforms to the architecture

If infeasibility is discovered, the issue must be fed back to adjust the architecture and its documentation.

Step 6: Architecture Evolution

Answer: How does the system adapt to future changes?

New business features

Growth in user numbers

Regulatory changes

Technology upgrades

Deployment environment shifts

Legacy component replacement

Evolution means continuously adjusting the architecture under constraints rather than a one‑time design.

08 Case Study: Internet Hospital Registration System

Stakeholder identification includes patients, doctors, hospital managers, project managers, developers, testers, operations, and security/compliance staff.

Refined architecture requirements:

Functional: registration, cancellation, payment, query

Performance: handle high concurrent load at 8 am

Availability: rapid recovery of core services

Security: authentication, authorization, encryption, auditing

Modifiability: future online consultation and e‑prescription

Constraint: must integrate with existing hospital systems

Design actions:

Divide into registration, payment, scheduling and notification components

Define component interfaces and data ownership

Use caching, rate‑limiting and horizontal scaling for peaks

Apply redundancy and fail‑over for core services

Enforce authentication, authorization and audit for patient data

Documentation and review involve creating views, inviting business, domain, security and operations stakeholders, and validating performance and integration risks with prototypes.

Implementation guidance includes establishing interface and development standards, checking conformance, assembling components and performing system tests.

Evolution example: when online consultation is added, analyse impact, plan evolution, add a consultation component, update interactions, retest and conduct a technical review.

09 Recommended Answer Approach for the Case

First identify all stakeholders and analyse their business goals, quality needs and constraints; then decompose the system, define interfaces, interaction and deployment principles to form a documented architecture; use stakeholder reviews and technical prototypes to uncover performance, integration and security risks early; during implementation verify compliance with architectural constraints; finally, when requirements change, perform impact analysis, modify components, re‑assemble, retest and hold a technical review to drive evolution.

10 Five Common Mistakes

Assuming stakeholders are only customers and end users.

Confusing the architect with the project manager or the most senior developer.

Treating architecture as merely a technology selection or a single deployment diagram.

Leaving architecture documents static; they must evolve with the system.

Thinking architecture is a one‑off activity before launch; it continues throughout the system lifecycle.

11 Closed‑book Self‑test

Multiple‑choice questions (answers provided at the end) cover the core responsibilities of architects, stakeholder definition, differences between architects and project managers, the correct order of the architecture development model, mapping of activities to lifecycle phases, and the importance of trade‑offs.

12 Memory Palace for the Six Sub‑processes

A mnemonic technique maps each sub‑process to a familiar physical location (e.g., community gate → sculpture → fitness equipment → pavilion → playground → bench). Visualising vivid actions at each spot helps recall the sequence: Requirements, Design, Documentation, Review, Implementation, Evolution.

Today's Minimal Flashcards

Architects translate stakeholder demands into system‑level architecture decisions, handling overall structure, quality trade‑offs, technical risk, communication documentation and architectural integrity.

Stakeholders are people, teams or organisations that influence the system or are influenced by it.

The six architecture steps are: Requirements, Design, Documentation, Review, Implementation, Evolution.

Mnemonic: 需、设、档、审、实、演 (need, design, document, review, implement, evolve) or ask, decide, write, check, do, change.

Architecture is not about picking the flashiest technology but about making justified, explainable choices that balance business goals, quality attributes, technical constraints and cost.