Agile Architecture or Accidental Architecture
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
Architecture is an overloaded term these days, and one that is not always easy to define. There's also a myth surrounding architecture and agile methods - some feel it isn't necessary. But architecture is a critical component of any software development effort, and the larger the project the more important it is. As Booch states,
Every interesting software-intensive system has an architecture
That architecture is either accidental or intentional. So how should teams treat architecture on agile projects? Like most agile practices - early and often.
I recently offered up my opinion of agile architecture, and established two simple truths surrounding agile architecture:
- 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.
Scott Ambler offers up a detailed explanation of agile architecture, stating that it's "a critical part of scaling agile approaches to meet the real-world needs of modern organizations." He provides some valuable guidance surrounding architecture, including two key nuggets of information - the importance of architecture throughout the lifecycle, and proving architecture with code.
Unfortunately, many teams using agile practices have foregone architecture altogether since many popular methods don't explicitly define any architectural practices. The thought is that architecture and design done "up front" is a Bad Thing.
UncleBob, a guy who knows a thing or two about agile, recently let us know his thoughts surrounding the myth that you shouldn't spend time up front making architectural decisions when he stated pretty bluntly, "Pardon me, but that’s Horse Shit." He was very clear that teams must spend time early dealing with architectural issues, but that the time spent is clearly a product of project size and complexity.
Across each of these explanations of agile architecture runs a common theme. Architecture is important. Some architecture must be done up front. Architecture should be proven with code. Architecture will evolve through the life of the project.
Yet there's another aspect to agile architecture, as well. Two aspects, actually. One as a process and another as an entity. Agile architecture is the process of architecting that results in a flexible and malleable software architecture. A lot of discussions focus on agile architecture as a process and less as an entity. In reality, both are critically necessary.
As a process, agile architecture is a technique, or set of practices, that an architect uses to create a software system. 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 changes throughout the lifecycle.
Traditional architecture is done up front, whereas agile architecture
is done throughout.
But 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. As an entity, 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. And throughout the course of the project, architectural shifts occur. Sometimes, we anticipate correctly. Sometimes not. Agile architecture is defined by our willingness and ability to embrace architectural change.
Whereas the process aspect of agile architecture demands that the team be flexible, the entity aspect of agile architecture demands that the structure of the system 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.