Architecture thinking

Last reviewed: 2026-06-28 — see the freshness policy.

Learning objectives

After this chapter you will be able to:

• Define an architecture as a set of decisions about elements, relationships, and properties.
• Separate functional requirements from the non-functional requirements that shape design.
• Reason about a design in terms of quality attributes and the trade-offs between them.

What "architecture" means

The architecture of a system is the set of significant decisions about its structure — the elements, how they relate, and the properties of both — where "significant" means hard and expensive to change later.

That definition has a useful corollary: if a decision is cheap to reverse, it is not architecture — let the team make it. Architects spend their scarce attention on the decisions that are load-bearing and sticky: data models, trust boundaries, the integration style between systems, where state lives, and which regulations bind which components.

Functional vs non-functional requirements

• Functional requirements (FRs) say what the system does: "clinicians can search a patient's medications."
• Non-functional requirements (NFRs) say how well: available 99.9% of the time, p95 latency < 500 ms, all PHI encrypted at rest and in transit, audit log retained 6 years.

Architecture is mostly driven by NFRs. Two systems with identical features can have completely different architectures because one must be HIPAA-compliant and multi-region and the other is an internal prototype. Write the NFRs down early — they are the forces your design must balance.

flowchart TB
  FR["Functional requirements<br/>(what it does)"] --> System
  NFR["Non-functional requirements<br/>(security, latency,<br/>availability, cost, compliance)"] --> System
  System["System architecture"]
  NFR -. drives most structure .-> System

Quality attributes and trade-offs

NFRs map to quality attributes — measurable properties of the system. The architect's craft is that these attributes trade off against each other: you cannot maximize all of them, so you make explicit, defensible choices.

Interoperability earns its own row in HLS: it is rarely optional (regulatory mandates force it — see FHIR profiles & regulation) and it trades directly against how freely you can shape your own data model.

An interoperability maturity model

Because "interoperable" is not binary, HIMSS defines four levels — a useful way to state how interoperable an NFR actually requires a system to be, rather than leaving it vague:

flowchart LR
  L1["1. Foundational<br/>can send/receive a payload<br/>(receiver need not understand it)"] --> L2
  L2["2. Structural<br/>shared message format/syntax<br/>(HL7v2, FHIR resource shape)"] --> L3
  L3["3. Semantic<br/>shared coded meaning<br/>(SNOMED/LOINC/RxNorm value sets)"] --> L4
  L4["4. Organizational<br/>governance, consent, trust,<br/>shared workflow across orgs"]

• Foundational — you can move bytes from A to B. A PDF discharge summary emailed to another system is foundational: the receiver can store and display it but not parse it.
• Structural — both sides agree on message shape. An HL7v2 ADT feed or a bare FHIR resource achieves this: fields are in known places, but a code might still be locally meaningful only.
• Semantic — codes carry shared meaning via standard vocabularies (terminologies): a LOINC-coded Observation means the same thing to every conformant system, not just to the sender.
• Organizational — the governance layer: consent, trust agreements, and workflow integration across organizational boundaries (a TEFCA QHIN exchange, or a health information exchange) — the hardest level, because it's mostly non-technical.

Use it to write a precise NFR. "The system must be interoperable" is not testable; "the system must achieve semantic interoperability for lab results via LOINC-coded FHIR Observations" is. Most HLS integration problems trace back to a mismatch in level — one side assumes semantic interoperability while the other has only shipped structural.

There is no free lunch. When you "improve" one attribute you usually spend another. The job is not to avoid trade-offs — it is to make them on purpose and record why (that is what an ADR is for, covered later in this part).

A worked micro-example

A digital-health startup wants a patient-facing API over PHI.

• NFR: HIPAA-compliant, p95 < 300 ms, run by a 3-person team, < $2k/month.
• Tension: a fully multi-region active-active design maximizes availability but blows the cost and operability budgets for a 3-person team.
• Decision: single-region, multi-AZ, managed services, automated backups + tested restore. Accept a higher RTO in a regional outage in exchange for cost and operability.
• That sentence — what you chose and what you traded — is the architecture.

How to think, in practice

1. Start from constraints, not solutions. List what is fixed (regulation, budget, team, existing systems) before drawing boxes.
2. Make the NFRs measurable. "Fast" is not a requirement; "p95 < 500 ms" is.
3. Name the dominant quality attribute. Most systems have one or two that win ties.
4. Generate at least two options. A design with no considered alternative is a guess.
5. Record the decision and its trade-off. Future-you needs the why, not just the what. The tool for this is an ADR — covered in the next chapter: C4 diagrams & ADRs.

Frameworks & methods (use them, don't worship them)

You don't have to invent the practice of architecture — mature frameworks give you vocabulary, checklists, and templates. Borrow what helps; skip the ceremony that doesn't.

Rule of thumb for an SA: TOGAF/arc42 for the enterprise and documentation altitude, C4 for diagrams, ADRs for decisions, Well-Architected for review. A two-person startup needs ADRs and a C4 sketch, not a full TOGAF ADM cycle; a hospital's enterprise architecture team may require TOGAF artifacts. Match the ceremony to the stakes — over-applying a heavyweight framework is its own failure mode.

Diagram

flowchart LR
  Constraints --> Options
  Options --> Decision
  Decision --> ADR["ADR<br/>(what + why + trade-off)"]
  ADR --> Build

Check yourself

1. Why is a cheap-to-reverse decision not considered architecture?
2. Rewrite this NFR to be measurable: "the system should be fast and reliable."
3. Pick two quality attributes from the table and describe a realistic situation where improving one degrades the other.
4. Two systems both exchange FHIR Observation resources but a query across them returns inconsistent results. Which HIMSS interoperability level are they missing, and why?

Further reading

• Bass, Clements, Kazman — Software Architecture in Practice (quality attributes).
• arc42 quality requirements
• HIMSS: the four levels of interoperability