A few weeks ago, I presented my view of agile architecture, and followed that up with a post on DZone that presented two aspects of agile architecture. A process aspect, which is temporal, and a structural aspect. Here, I embellish.

Temporal Aspect

The temporal aspect of architecture pertains to when architectural decisions are made. It involves making sound and timely decisions throughout the software development lifecycle. In some cases, it means admitting that an architectural mistake was made and that the team needs to modify the architecture.  On the other hand, traditional architecture involves spending significant time early in the project defining the architecture. Once the vision has been established, teams tend to resist architectural change throughout the lifecycle. Traditional architecture is done up front, whereas agile architecture is done throughout.

Of course, with agile architecture, time is still spent early in the development effort establishing architectural vision. But effort is also devoted to architecture throughout the lifecycle, such as performing architecture proofs and spikes that verify architectural decisions. The temporal aspect of agile architecture is not chaotic architecture. Nor is it accidental architecture, where the architecture simply evolves without vision. Instead, the emphasis is on proving the architectural decisions that are made as soon as possible, while also embracing architectural change throughout the development lifecycle.

Agile architecture does not significantly impact what an architect does, though I admit there are various architectural practices that are heavyweight and wasteful. Alas, this is a topic for another day. In general, while agile architecture doesn’t significantly impact what an architect does, it does impact when the architect does it.

Structural Aspect

The structural aspect of agile architecture pertains to the flexibility of the architecture itself. Simply put, how easy is it to make an architectural change to the system. Agile architecture emphasizes the structural resiliency of the system so that change is possible. This involves using the right patterns, establishing the right extension points within the system, abstracting away areas of intense complexity, and more.

For large systems, we cannot manage architecture at the code level. We need higher level units, and modularity is a critical ingredient to agile architecture. Understanding and managing dependencies between those units is critical to accommodating change. The proof is simple. Is it easier to understand the impact of change when examining a system of 10000 classes or a system of 10 modules? Obviously, the latter. If we are able to assess the impact of change, we inherently have a better understanding of whether we are able to accommodate that change.

Consider this example. Early in the life of a system, we’re certain to be using Vendor X, and our code is tightly coupled to Vendor X. The lack of modularity makes it difficult to identify which areas of the system talk to the Vendor X product. A shift in business priorities now causes a shift in architecture. Vendor X is out and Vendor Y is in. How easy is it to change the system without knowing which areas of the system depend on Vendor X functionality? Not easy. But now imagine if all Vendor X dependent code is isolated to a single module. We know where Vendor X integration code resides. Change is now more palatable. Modularity is inherent for agile architecture, and it doesn’t matter if you’re developing an application, a service, or something else. Modularity matters!

The Inextricable Link

Without question, architectural shifts will occur throughout the course of the project. Sometimes, we anticipate correctly. Sometimes not. Agile architecture is defined by our willingness and ability to embrace architectural change. Yet to embrace architectural change demands that we have an architecture that can accommodate change. Simply because a process is employed that embraces architectural change throughout the software lifecycle does not mean that it’s possible to make that change. Here, the inextricable link between the temporal and structural aspect is established.

Whereas the temporal aspect of agile architecture demands that the architect be flexible, the structural aspect of agile architecture demands that the architecture be flexible so that the team is able to quickly make the change. Agile architecture demands both, and the absence of one precludes the presence of the other.

Modularity is a key ingredient of agile architecture. Modularity ensures that development teams understand architectural dependencies that are going to inhibit or accommodate change. Simply embracing an attitude of change is not enough. We must also be able to accommodate change efficiently. Modularity allows the development team to envision and manage change more easily, meaning they’ll be able to make the change they want to make when they want to make it.