Agile Architecture

Software architecture is difficult to define. Ask five different developers their definition of software architecture, and you’ll likely get five different answers. Arguably though, we can agree that software architecture represents the significant technical decisions spanning the breadth of the system. For instance, managing the dependencies between modules is a significant aspect of software architecture. Developing application frameworks that promote consistency across use cases is architecturally significant. Identifying application layers and the behavioral granularity of those layers is architecturally significant, as well. As Booch states:

Architecture is design, but not all design is architecture. Rather, architecture focuses upon significant decisions, where significant is measured by the impact of changing that decision. For this reason, architectural decisions tend to concentrate upon identifying and controlling the seams in a system, which are described in terms of interfaces and mechanisms and so typically mark the units of change in the system.

Essentially, we differentiate between architecture and design based on the impact of change. How easy is it to modify system modules if dependencies are not carefully managed? How difficult is it to change the dependency structure? How easy is it to reuse software components or services if the behavioral granularity is incorrect? How easy is it to refactor behavioral granularity? Traditionally, we attempt to make the right architectural decisions early due to the significant anticipated cost affiliated with making incorrect decisions.

This contradicts agile practices which have taught us to avoid up front design and architecture, and instead embrace change throughout the software development lifecycle. So how do agile and architecture come together? Conceptually, the goal of agile architecture is to eliminate the architectural significance of change by crafting software that can easily adapt to change. I provide an example of how to do this by focusing on the joints within a system. In practice, developing agile architecture is much more difficult. There are two simple truths we must be willing to accept.

  • Software architecture is organic. The architectural goals you set to achieve early in the lifecycle differ from those you’ll need to satisfy late in the lifecycle. Agile architecture is not only about what decisions you make, but when you make those decisions.
  • Software architecture is only as good as the source code it’s built upon. Shoddy source yields shoddy architecture. Therefore architecture must emphasize building the highest quality and structurally sound source code possible.

So how do agile practices promote agile architecture? To briefly paint a picture of agile architecture, we’ll explore a development scenario examining system growth and evolution.

Early in the lifecycle, change is rampant as new features are under development. An architectural vision that guides developers should be established that aligns technology adoption and implementation with business objectives. The time required to establish this initial architectural vision should be measured in days, not weeks or months.

Developers should stress closure by bundling code into larger modules, avoiding the unpredictability associated with complex implementation issues such as module granularity and transactionality spanning module boundaries. As the system grows, change and discovery occur less frequently. Modules should be broken apart, emphasizing independent deployment, clear separation of concerns, and even reuse. Smaller, self-contained modules are wired together via interfaces, further decoupling the structural relationships between modules.

Throughout the lifecycle, as business objectives change and new requirements emerge, the architectural vision evolves, yet still serves as the guide to implementation. Agile architecture is manifest as modules with minimal dependencies, concise behaviors, and clear points of extensibility. This drives architecture down to the class and code level, making the quality of your source code, and the coupling and cohesion of your classes, a critical factor in the resiliency of your architecture.

Agile practices play a critical role in agile architecture. Test-driven development lends you the courage to undergo architectural evolution. Continuous integration accommodates architectural shifts by ensuring issues encountered while refactoring are identified and corrected quickly. Supplementing your up-front design approach with an emergent strategy emphasizing spikes or proofs helps verify the architectural vision. Developing a robust infrastructure supporting incremental delivery allows your team to experience and identify architectural deficiencies related to performance, failover, usability, and more. Early and frequent discovery of inadequate architectural decisions provides the team with the time necessary to make architectural adjustments.

Shifts in architecture exists in a world beneath the trendy technologies du jour. It exists in a world separate from your decision on which web framework to use. Or which ORM framework you want to play with. SOA isn’t relied upon as a revolutionary architectural model. With agile architecture, technology becomes less significant because the architecture diminishes the impact of change. Crafting a robust architecture is not easy, but is at least possible if you allow architecture to evolve, and refactor as architecture must shift. Agile practices enable agile architecture.

That’s my definition of agile architecture. What’s yours?

10 thoughts on “Agile Architecture

  1. I am a Solutions Architect at AmerisourceBergen Specialty Group, serving the pharmacological industry.

    I’ve been engaged in what some might call agile architecture on my current project. I joined the team after the big architectural decisions were made, and we have challenged and changed many of them along the way. But the truth is that if I had been around to make those big decisions up front, I would have gotten them just as wrong.

    Each architectural change is accompanied by a large and painful refactor. XP and the agile methods that have followed are based on the premise that “the cost of change may not rise dramatically over time” (Beck, 23). Maybe we’re doing it wrong, but we haven’t found this to be true.

    So if the big decisions cannot be correctly made up front, and the cost of change does not stay flat, what then is the role of an agile architect?

    An agile architect, as I see it, is the advocate for quality. Whatever needs to be done to preserve and improve the quality of the product, that’s what he must do. Whether it’s taking on that big painful refactor, producing documentation where consistent understanding is lacking, or going toe-to-toe with project managers over the schedule. An agile architect slogs through the battles day after day, makes tough decisions, and owns the consequences.

  2. Nice article.

    Architecture is less about where to put things and more about decoupling and improving cohesion. In other words it is important to create an architecture that supports easy addition to the system when it changes and creates the ability to minimize changes to existing code when requirements change.

Leave a Reply

Your email address will not be published.