This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3. The Goal of Architecture
Modularity helps address the social aspect of software architecture, but it also helps us design more flexible software systems—that is, systems with resilient, adaptable, and maintainable architectures. Examining the earlier definitions of architecture leads us to the goal of architecture. The Johnson definition of architecture as quoted by Fowler makes it apparent that architecture is about the important stuff. In the following statement, Booch makes it clear that something is architecturally significant if it’s difficult to change (2006):
- All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
Based on these statements, it’s fair to conclude that the goal of software architecture must be to eliminate the impact and cost of change, thereby eliminating architectural significance. We attempt to make something architecturally insignificant by creating flexible solutions that can be changed easily, as illustrated in Figure 3.3. But herein lies a paradox.
)
Figure 3.3. The goal of architecture
3.3.1. The Paradox
The idea behind eliminating architecture isn’t new. In fact, Fowler mentions “getting rid of software architecture” in his article “Who Needs an Architect?” (2003). The way to eliminate architecture by minimizing the impact of cost and change is through flexibility. The more flexible the system, the more likely that the system can adapt and evolve as necessary. But herein lies the paradox, and a statement by Ralph Johnson presents and supports the idea (Fowler 2003):
- . . . making everything easy to change makes the entire system very complex . . .
As flexibility increases, so does the complexity. And complexity is the beast we are trying to tame because complex things are more difficult to deal with than simple things. It’s a battle for which there is no clear path to victory, for sure. But, what if we were able to tame complexity while increasing flexibility, as illustrated in Figure 3.4? Let’s explore the possibility of designing flexible software without increasing complexity. Is it even possible? In other words, how do we eliminate architecture?
)
Figure 3.4. Maximizing flexibility, managing complexity
3.3.2. Eliminating Architecture
As the Johnson quote clearly points out, it’s not feasible to design an infinitely flexible system. Therefore, it’s imperative that we recognize where flexibility is necessary to reduce the impact and cost of change. The challenge is that we don’t always know early in the project what might eventually change, so it’s impossible to create a flexible solution to something we can’t know about. This is the problem with Big Architecture Up Front (BAUF), and it’s why we must make architectural decisions temporally. In other words, we should try to defer commitment to specific architectural decisions that would lock us to a specific solution until we have the requisite knowledge that will allow us to make the most informed decision.
It’s also why we must take great care in insulating and isolating decisions we’re unsure of and ensuring that these initial decisions are easy to change as answers to the unknown emerge. For this, modularity is a missing ingredient that helps minimize the impact and cost of change, and it’s a motivating force behind why we should design software systems with a modular architecture. In the UML User Guide (page 163), Booch talks about “modeling the seams in a system.” He states (1999):
- Identifying the seams in a system involves identifying clear lines of demarcation in your architecture. On either side of those lines, you’ll find components that may change independently, without affecting the components on the other side, as long as the components on both sides conform to the contract specified by that interface.
Where Booch talks about components, we talk about modules. Where Booch talks about seams, we’ll talk about joints. Modularity, combined with design patterns and SOLID principles, represents our best hope to minimize the impact and cost of change, thereby eliminating the architectural significance of change.