Chapter 1 — Introduction

Why it matters

Sets the framing that architecture is an engineering discipline lacking crisp definitions, and that the role is broad and evolving.

Core ideas

• There’s no single agreed definition of “software architecture.” The authors describe it along four dimensions: structure (the architecture style), architecture characteristics (the -ilities the system must support), architecture decisions (rules for how the system is built), and design principles (guidelines, not hard rules).
• Architecture vs. design is a continuum, not a wall. The “why” tends to sit on the architecture side; the “how” on the design side. Constant collaboration between architect and developer is required.
• Eight core expectations of an architect: make decisions, continually analyze the architecture, keep current with trends, ensure compliance with decisions, have diverse exposure/experience, possess business domain knowledge, possess interpersonal skills, and understand/navigate politics.
• The intersection of architecture with engineering practices (esp. Continuous Delivery), operations/DevOps, process, and data matters as much as the boxes and lines.

Trade-offs to argue

Breadth vs. depth of technical knowledge — architects trade some depth for wide breadth. Understand the “knowledge triangle/pyramid” idea: stuff you know, stuff you know you don’t know, stuff you don’t know you don’t know — architects should push knowledge toward the top (breadth) rather than maintaining deep expertise everywhere.

Terms to own

architecture characteristics, architecture decisions, design principles, technical breadth vs. depth.