There are no wrong answers in architecture, only expensive ones.

In this definition, software architecture consists of the structure of the system (denoted as the heavy black lines supporting the architecture), combined with architecture characteristics (“-ilities”) the system must support, architecture decisions, and finally design principles.

Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

One important thing to note is that agility does not equal time to market. Rather, it is agility + testability + deployability. This is a trap many architects fall into when translating domain concerns. Focusing on only one of the ingredients is like forgetting to put the flour in the cake batter. For example, a domain stakeholder might say somethi

Too many architecture characteristics leads to generic solutions that are trying to solve every business problem, and those architectures rarely work because the design becomes unwieldy. This suggests that architects should strive to design architecture to be as iterative as possible. If you can make changes to the architecture more easily, you can

Each architecture characteristic that an architect designs support for potentially complicates the overall design.

To quote Mark (one of your authors): All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner.

Never shoot for the best architecture, but rather the least worst architecture.

To use a physics analogy, software systems model complex systems, which tend toward entropy (or disorder). Energy must be added to a physical system to preserve order. The same is true for software systems: architects must constantly expend energy to ensure good structural soundness, which won’t happen by accident.