This chapter is from the book
This chapter is from the book
This chapter is from the book
And Evolution
The systems we build aren’t static. Release cadences vary, but any successful system must evolve to stay relevant. This may occur through the accumulation of small changes, less-frequent major changes, or some combination of the two. But it must happen.
And so also everything we’ve described so far—the organization of a system, its components and their relationships, its principles and designs—must also evolve. How does that happen?
Ideally, that evolution will be governed with intention, by a set of carefully considered, fit-for-purpose principles. We can understand architectural principles as working in two ways: governing design and governing the evolution of design. One set of principles; two methods of operation.
For example, we might hold a principle that services should be loosely coupled via well-defined interfaces (a commonly adopted principle for anyone designing cloud software). This is entirely reasonable, and quite actionable when designing those services.
However, it tells us little about the evolution of those services. As we add functionality and even new services, we can maintain this property, and that acts as a sort of basic constraint on their evolution. But it doesn’t address critical questions such as how to modify an existing interface, when to add functionality to existing services, or when to create a new service.
Adding new functionality to an existing system is one of the easiest forms of system evolution, and yet it can still go wrong. For example, suppose that two teams are both expanding their services with new functions. One team might choose to add a new service, favoring a larger set of smaller services. The other team might add new functions to an existing service.
When scenarios like this occur, the evolution of the system is proceeding in such a way as to undermine its fundamental organization. The problem here isn’t that one approach was right and the other wrong. In the abstract, either approach could be an appropriate response to the need to expand the system’s functionality. The damage arises from the differing responses, which make the system unnecessarily more complex. The principles governing the evolution of a system should head this off by articulating which approach will be used.
Adding new functionality is perhaps the easiest version of the evolutionary problem. A much harder version occurs when the principles themselves need to change. For example, perhaps an earlier principle focused on speed of delivery, so it favored designs that added code to a single, monolithic service. Later, the team might have adopted a principle of developing smaller, more loosely coupled services that can be independently updated and deployed.
Often this problem arises when teams shift from unstated design principles focused on minimizing change and quick delivery to intentional principles concerned with dependability, maintainability, and quality. When this happens, it’s not enough to apply the new principles to new and updated designs. Properties such as security, scalability, and cost tend to be constrained by their weakest link—that is, the components that don’t address these concerns. At the limit, to realize these kinds of principles requires every existing design to be reworked.
This is one of the hardest problems to solve in software development: how to evolve a system from one set of principles to another. At the same time, it’s also one of the most common problems because the principles we care about when we’re getting the first version or two out the door are often very different from what we care about once we have a successful, proven product. Our priorities quite naturally shift from shipping quickly to creating a quality, sustainable product.
One response to this challenge is a grand “re-architecture” project in which every element of the system is rebuilt to align with these new priorities. But this approach is not evolutionary—it’s revolutionary. It’s also rarely successful because it requires development teams to make a sustained investment in the old and the new at the same time. Add in the overhead of running both efforts, and you’ve easily tripled the cost of ongoing development. Few teams can sustain this kind of investment.
The good news is that an effective software architecture practice can address even this most challenging scenario. An effective software architecture team can lay out an evolutionary path for change. The key is to understand evolution not as something foisted on a system under duress, but rather as the natural state of the system. An effective architectural process makes change intrinsic, predictable, and controllable. Ultimately, the ability to govern the evolution of a system is the essence of architecture’s role.