by Eoin Woods
An important part of an architect’s work is identifying the priorities and constraints that need to be respected if a system is to maintain its technical integrity and meet its key requirements—particularly its (nonfunctional) quality properties. A common problem is how to capture and communicate these architectural constraints without being excessively prescriptive with regards to their implementation and making a lot of up-front decisions that should really be made later on by other people.
Architectural principles are a deceptively simple idea that record actionable constraints, goals, and priorities along with clear rationale to allow their importance and applicability to be understood. Well-defined principles can provide the context for design decision making and allow people to understand how their design decisions relate back to the goals of the architecture.
However, although a simple concept, it is difficult to create a well-defined and useful set of architecture principles. While we often talk about the “architectural principles” of a system, it is rare to find principles being used to their full potential to guide teams in design decision making.
Eoin Woods (re)introduces the idea of the architectural design principle, shows how to define one as well as the characteristics of a good one, and uses examples to explain how they can help to provide effective guidance for a software team.