Architectural Thinking by Mark Richards

Main ideas & lessons

• Architectural thinking = deliberate thinking about system architecture, not just building components.
• A person can have the title/role/desire to be an architect, but still may not actually “think like an architect.”
• Mark Richards structures “thinking like an architect” into three factors and then explores them deeply.

The 3 factors of “thinking like an architect”

1) Understand/analyze/recognize tradeoffs

• For any solution choice, you must identify what you gain and what you sacrifice.
• If you don’t see a tradeoff, it likely means you haven’t found one yet.

2) Understand business drivers and translate them into architectural characteristics

Business stakeholders speak in terms like:

• speed to market
• competitive advantage
• regulatory compliance
• user satisfaction
• merger (as mentioned in the talk)

Architects translate these into technical quality attributes (“-ilities”), such as:

• agility
• fault tolerance
• testability
• low-risk deployments
• performance/availability reliability aspects that affect users

3) Maintain technical breadth while keeping sufficient technical depth

• Depth: being very good at a narrower topic.
• Breadth: knowing enough across many relevant technologies to make informed architectural decisions.

The talk emphasizes that breadth (often across many caching/tech options, etc.) is required for architecture.

Detailed tradeoff analysis methodology (as presented)

• Start with the question: “what matters more?”
• For each candidate approach, perform:
  • Identify benefits/opportunities of each option
  • Identify costs/risks/implications of each option
  • Compare based on the use case
• Conclude with the “least worst” tradeoff rather than a “right answer.”
• Use tradeoff analysis to facilitate discussions with stakeholders (architects don’t unilaterally decide; they enable informed alignment).

Tradeoff examples and what they illustrate

A) Non-software example: aircraft engine placement

Goal: show that architecture decisions depend on tradeoffs and use case.

Wing-mounted engines

Opportunities:

• Easier maintenance (engines closer to ground)
• Ability to have larger engines (more structural support under the wing)
• Helps control wing flutter (vibration/flatter issue affecting structures)

Downsides:

• If an engine fire occurs, it’s closer to the fuselage than tail placement
• Cabin noise is higher in economy/coach areas (exhaust nearer)

Tail-mounted engines

Opportunities:

• Engines quieter for cabin areas (exhaust further back)
• Less gravel/debris ingestion (higher above ground)

Downsides:

• Harder maintenance (harder access at height)
• Often restrictions on engine count/size due to tail structural limits

Lesson: There’s no universal “better”—the architect analyzes based on priorities and constraints.

---

B) Software architecture scenario: online auction bids (messaging choice)

Context:

• Producer sends bid events.
• Multiple consumers need different capabilities:
  • capture/track bids
  • analytics (average, max, etc.)
  • determine winner

Decision being compared:

• Point-to-point messaging (separate queue per consumer) vs
• Publish/subscribe messaging (publish to a topic)

Publish/subscribe: why it was recommended in the talk

• Extensibility: adding new consumer services (e.g., bid history) doesn’t require reworking the producer’s architecture.
• Decoupling: the producer doesn’t need to know about consumers.
• If you want to use the data, you subscribe—architecture changes are minimized.

Point-to-point: key tradeoffs and implications

• Producer knowledge/coordination required: producer must be aware of all consumers/queues.
• Reduced extensibility: adding a new consumer means modifying producers and adding queues.
• Data security/control: queues can restrict who receives data; with dedicated queues, access can be limited.
• Heterogeneous contracts: different consumers can receive different subsets of data.
• Operations/observability: ability to monitor queue depth for consumers and support autoscaling based on backlog is easier in a point-to-point queue model.
• Contrast point: in the described publish/subscribe model, queue depth may not be visible in the same way, reducing autoscaling/reactive control.

Lesson: architectural tradeoffs are about priorities (extensibility vs security/control vs operational scaling/contract heterogeneity).

---

C) gRPC vs REST (performance vs coupling)

Claimed benefit (in talk):

• gRPC (built over protobuf and HTTP/2) can reduce latency (illustrated as “100ms → ~8ms” range).

Tradeoff highlighted:

• Tight coupling between services
  • clients use generated stubs and remote procedure interfaces
  • changes can ripple more tightly than some REST approaches

Lesson: even when a choice looks clearly “faster,” the architect must understand coupling implications.

---

D) Service granularity: coarse-grained vs fine-grained microservices

Coarse-grained services (larger domain services)

Advantages:

• Better data consistency via fewer distributed interactions (fewer services called)
• Potentially simpler transaction semantics for business processes
• Better performance (less network chatter/cross-service calls)
• Better reliability (less dependency on network behavior)

Fine-grained services (small single-purpose services)

Advantages:

• Higher agility: easier and faster change to a single capability
• Function-level scalability rather than scaling an entire domain
• Better testability: easier to fully regression test a small unit
• Lower-risk deployability: small changes can be deployed frequently

Lesson: again, it depends on what matters more (agility/testability/deploy frequency vs consistency/performance/reliability).

---

E) Loose coupling: how to measure it and the real tradeoffs

System described: an order placement workflow using multiple services:

• order placement
• notification
• payment
• inventory
• warehouse
• supplier

Synchronous “REST-like” approach

• Order placement calls downstream services directly in sequence.
• The talk computes “total coupling level (CT)” using incoming/outgoing connections (afferent/efferent style).
• In the synchronous topology, coupling ends up high (example “CT = 10”).

Decoupled approach (via async messaging/queues/topics)

• Order placement publishes an event to a topic.
• payment/inventory/notification subscribe.
• inventory/warehouse/supplier interactions proceed via queues.
• result: “coupling level = 0” in the example because services don’t depend directly on each other.

Tradeoffs of loose coupling (what you give up)

• Workflow control: unclear when the overall process is “complete” end-to-end
• Error handling: e.g., if payment fails, the synchronous model allows immediate handling; the decoupled model can obscure “global state”
• Data consistency: synchronous/tightly coupled workflows provide better business-transaction consistency
• Avoiding these issues can require more messaging and more complexity

Key framing lesson:

• Loose coupling is not binary; it’s a gradient.
• “Tradeoffs” must be evaluated based on operational needs, consistency requirements, and control expectations.

“Business drivers” translation (anti-pattern: cart before the horse)

Anti-pattern described

• Choosing architectural styles because they seem new/popular rather than because they map to real business needs.

Architect process described conceptually

• Start from business driver language (e.g., time to market)
• Translate into architectural characteristics (-ilities) (agility + testability + low-risk deployments)
• Then choose styles that best support those needs.

Architecture styles mentioned as options

• layered monolith / layered architecture
• microkernel
• microservices
• service-based
• event-driven
• “space-based” (mentioned)

Examples given

• If the business driver is time to market:
  • map to agility/testing/deployability and choose accordingly
• If the driver is user satisfaction:
  • map to performance/availability/reliability/testability and choose architecture that supports it
• If constraints are budget/time:
  • map to simplicity and cost
  • warn that complex styles (e.g., microservices) may be too expensive for that constraint

Lesson: The “correct” architecture is the one that best satisfies translated business needs, not what’s popular.

Technical breadth: how to build it (the “20-minute rule”)

• The talk uses a knowledge “triangle” concept:
  • top: what you know you don’t know (or “unknown unknowns” region)
  • middle: what you know you don’t know (you could learn it)
  • base: what you know well
• Architects should focus on moving topics from “unknown/unheard-of” into the “middle” and then into competence over time.

Practical method: “20 minute rule”

• Daily routine:
  • Spend at least 20 minutes in the morning on learning something new (buzzwords/areas you haven’t heard of).
  • Then immediately check email after that, not later in the day.

Sources suggested

• infoQ / similar references (mentioned as “infoq”)
• dzone and refcards (DZone and “ref cards” mentioned)
• thoughtworks (thoughtworks website referenced)

Lesson: breadth is built by consistent short learning loops; don’t over-save it or postpone until after your productive time is consumed.

Conclusion / takeaway rules emphasized

• No right/wrong answers in architecture—only tradeoffs.
• Corollary: there’s never a perfect tradeoff; you choose the least worst option.
• Architects enable stakeholder alignment by:
  • identifying tradeoffs
  • translating business drivers to technical quality attributes
  • maintaining knowledge breadth to make informed judgments

Speakers / sources featured (end list)

• Speaker: Mark Richards
• Referenced people in talk: Victor; George; David; Len (referred to as Len and also as “Len talked…”); Carlos (as an example name for “-ability” joke); Ian (mentioned in the Tacoma Narrows flutter reference)
• Referenced technologies/concepts/sources: gRPC; protobuf; HTTP/2; REST; Saga; BASE transaction; microservices; service granularity; loose coupling; afferent/efferent coupling; “8 fallacies of distributed computing”; infoQ; DZone; Refcards; ThoughtWorks; Deep Image Priors; caching technologies; Tacoma Narrows bridge (flutter reference)