
Software Architecture: The Hard Parts

An architecture quantum is an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling. A common example of an architecture quantum is a well-formed microservice within a workflow.
Mark Richards • Software Architecture: The Hard Parts
The authors built many distributed systems a few decades ago when they first became popular, yet decision making in modern microservices seems more difficult, and we wanted to figure out why. We eventually realized that, back in the early days of distributed architecture, we mostly still persisted data in a single relational database. However, in m
... See moreMark Richards • Software Architecture: The Hard Parts
Each understands the common scope under question: architects understand the coupling characteristics, developers understand the scope of behavior, and the operations team understands the deployable characteristics.
Mark Richards • Software Architecture: The Hard Parts
An architect implements fitness functions to build protections around unexpected change in architecture characteristics. In the Agile software development world, developers implement unit, functional, and user acceptance tests to validate different dimensions of the domain design. However, until now, no similar mechanism existed to validate the arc
... See moreMark Richards • Software Architecture: The Hard Parts
All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison. Paracelsus
Mark Richards • Software Architecture: The Hard Parts
Architects shouldn’t break a system into smaller parts unless clear business drivers exist. The primary business drivers for breaking applications into smaller parts include speed-to-market (sometimes called time-to-market) and achieving a level of competitive advantage in the marketplace. Speed-to-market is achieved through architectural agility—t
... See moreMark Richards • Software Architecture: The Hard Parts
An easy way to think about the difference is that static coupling describes how services are wired together, whereas dynamic coupling describes how services call one another at runtime.
Mark Richards • Software Architecture: The Hard Parts
Architects must watch out for composite architecture characteristics—ones that aren’t objectively measurable but are really composites of other measurable things. For example, “agility” isn’t measurable, but if an architect starts pulling the broad term agility apart, the goal is for teams to be able to respond quickly and confidently to change, ei
... See moreMark Richards • Software Architecture: The Hard Parts
High static coupling implies that the elements inside the architecture quantum are tightly wired together, which is really an aspect of contracts.