Stewardship in Agile Software Architecture and Design
Rebecca Wirfs-Brock wrote an article titled "Software Architecture Stewardship"—and the title alone got my attention. Developers talk about “owning” the code, and product managers talk about being “president of the product”—but the concept of stewardship is what really struck me.
Large projects require multiple teams with each owning a part of the solution. Without centralized architectural and design guidance, those solutions can easily become a hodgepodge of siloed components. Over time, they evolve in different directions, using different techniques and practices.
A look at the entire codebase would be like a walk through a roadside auction, where the depression glass sits next to a stack of VHS tapes on top of a mahogany and marble commode. The only thing the products have in common is a white paper price tag tied on with white cotton string and a price written in the same hand.
Stewardship is an interesting way to think about architecture. The architects typically don’t own the products that the individual teams are creating, yet the architects help define a cohesive approach to developing the products. Architects are often responsible for defining (constraining?) how the different products interoperate. And architects often help teams improve the trickier bits of integration, resolve performance issues, etc.
Agile development implies emergent design. The goal of delivering something valuable in every iteration biases teams against doing big up front design. Good architecture is thoughtful, scalable, and ready when you need it—two contrasting viewpoints of build as you go and be ready when you get there.
Arjit Sarbagna writes in "Agile Architecture: How Much Is Just Enough?" about finding this balance. The key is to keep the two contrasting ideas in your head simultaneously and strike a balance while embracing both concepts—but never to the point of refuting either.
When Frederick P. Brooks discusses agile vs. waterfall in The Design of Design, he expresses this as the debate between empiricism and rationalism. As architects, we should be thinking about both what is needed now and what will be needed in the future—should we happen to survive the now.
It isn’t practical to expect architects to predict how a single product will evolve and create the correct architecture for the long term. Asking them to predict how a collection of products will evolve is even more unreasonable.
However, asking them to be stewards who help the individual teams evolve their products in the context of an evolving architecture (or ecosystem) is both challenging and reasonable.
