static coupling analyzes operational dependencies, and dynamic coupling analyzes communication dependencies.

By codifying rules about code quality, structure, and other safeguards against decay into fitness functions that run continually, architects build a quality checklist that developers can’t skip. A few years ago, the excellent book The Checklist Manifesto by Atul Gawande (Picador) highlighted the use of checklists by professionals like surgeons, air

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.

High functional cohesion refers structurally to the proximity of related elements: classes, components, services, and so on. Throughout

All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison. Paracelsus

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

Static coupling Represents how static dependencies resolve within the architecture via contracts. These dependencies include operating system, frameworks, and/or libraries delivered via transitive dependency management, and any other operational requirement to allow the quantum to operate.

High static coupling implies that the elements inside the architecture quantum are tightly wired together, which is really an aspect of contracts.

Thus, here’s our advice for modern trade-off analysis in software architecture: Find what parts are entangled together. Analyze how they are coupled to one another. Assess trade-offs by determining the impact of change on interdependent systems.