|The Systems Bible: The Beginner’s Guide to Systems Large and Small|
Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental. Most of the time it is both, born of the consequences of a myriad of design decisions made by its architects and its developers over the lifetime of a system, from its inception through its evolution. In that sense, the architecture of a system is the naming of the most significant design decisions that shape a system, where we measure significant by cost of change and by impact upon use. As such, all architecture is design, but not all design is architecture. Furthermore, while the code of a software-intensive system is the truth, it is not the whole truth: architectural decisions are often asserted as patterns that weave through the abstractions in a system, giving rise to textures that transcend raw executable code. At the highest level of abstraction, we can discern patterns that give each system a particular architectural style. For all systems of sufficient complexity, we can only understand and reason about a system’s architecture from multiple points of view, each view representing the concerns of a particular set of stakeholders. The challenge of the engineering process that makes any software-intensive system manifest is therefore to grow a set of architectural decisions that yield an optimal balance of the functional and non-functional forces that weigh upon each and every one of these views.