- Fundamental Organization
- Of a System
- Embodied in Its Components
- Their Relationships to Each Other
- Their Relationships to the Environment
- Principles Governing Its Design
- And Evolution
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Principles Governing Its Design
Until this point, the IEEE definition of architecture has focused on describing a system’s current state: its fundamental organization, its components, their relationships. Now, it turns its attention to why it’s organized this way, has these components, and includes these relationships.
Design is a decision-making activity in which each choice determines some aspect of form and function. Principles are rules or beliefs that guide decisions. Thus, architectural principles are the rules and beliefs that guide decisions about a system, helping determine its fundamental organization.
Good architectural principles assert what’s important to the system—perhaps reliability, security, scalability, and so on—and guide design toward those qualities. For example, a principle might assert that a notification delivery system should favor speed over reliability. In turn, that can support a decision to use a faster but less-reliable message-passing technology.
Principles can also accelerate decision making by designating a preferred approach out of many available options. For example, a principle might state that horizontal scaling is preferred over vertical scaling. We may be tempted to think of software engineering as driven purely by facts and analysis—that is, a system either does or does not meet its requirements—but often many designs may meet the requirements. Thus, design also involves judgment calls in which we choose among a set of acceptable alternatives.
Importantly, principles govern not just what we can do, but also what we cannot do. For example, consider a system composed of a set of services. A reasonable principle for the design of this system might hold that each service should be individually deployable without downtime. On the one hand, this principle frees architects for individual services, allowing them to determine when and how they will deploy updates. On the other hand, it constrains them: Their deployment strategy must not require that other services are updated at the same time, or that those services are temporarily disabled during the update. Thus, this principle simultaneously opens up some options for consideration while closing off others.
Without constraints, teams may spend too much time exploring a potential design space, which tends to slow down decision making while producing only marginally better outcomes. It’s a classic case of diminishing returns: Each new option takes significant time to explore, yet doesn’t deliver meaningful benefits over options already considered. A constraint that limits this exploration will save substantial time and effort while producing just as good a result. Of course, for this approach to work, the constrained designed space must encompass suitable outcomes—so these principles do need to be carefully considered.
Too much freedom in choice also tends to result in a lack of alignment, thus undermining the system’s fundamental organization. Schematically, suppose that three or four subsystems need to choose between approach A and approach B. If both approaches are roughly equivalent and no further guidance is available, the system is likely to end up with a mix of the two approaches. Because that outcome increases overall system complexity with a corresponding benefit, it’s a net-negative and should be avoided. A principle that guides all of these decisions toward the same option speeds decision making and constrains the outcome, driving simplicity and alignment.
When we’re not intentional about setting our principles, they tend to be set for us. And that means that we typically end up with implied principles such as “working within current organization boundaries,” “minimizing scope,” and “fastest time to market.” None of these principles speaks to developing a better product, and they won’t produce one. Establishing and adhering to principles developed through an intentional process is one of the more impactful activities an architect can undertake.