Architects and Agilists Can Get Along

Although it is less common today, I still often hear folks saying things like “Agile is incompatible with Architecture” or “Architecture isn’t necessary for Agile” or, even more worrisome “Agile teams are irresponsible with respect to architecture” or “Architects are useless to Agile teams”. To me, such notions reflect at a minimum an outdated understanding of architecture or a misunderstanding of agile or both. 

However, these ideas, particularly the latter versions, indicate a contempt for “those other people” that isn’t conducive to a productive conversation. My view is that architecture and architects have much to say and contribute to agile teams and that architects can learn from agile teams, particularly in how to cope with rapid change. The essence of Agile Meets Architecture is to bridge this divide between the camps and to facilitate productive conversations. 

I’d like to tackle these questions from both the perspective of the agilist (I will use this term to refer to a developer on an agile development team) and the perspective of the architect. Each has some valid points to make but each suffers from a lack of understanding of the perspectives and concerns of the other. 

First, though, let’s start by acknowledging that the agilist and the architect have very different drivers and definitions of success. The agilist is primarily motivated to deliver business value as quickly and as safely as possible, which is a short to perhaps medium term objective. The architect is primarily concerned with longer term issues of things like total cost of ownership, overall IT costs, tool proliferation, cost efficiency, and re-use, to name a few of the concerns. Is it any surprise that these individuals view the world very differently? When definitions of success diverge to this extent, an agreement is the exception, not the rule.

Another issue I’d like to tackle is the sad reality that some people just aren’t very good at their job. Many agilists will talk dismissively of all architects because they worked with someone who was dictatorial yet disconnected from the reality on the ground, or was insufficiently knowledgeable about the current tech stack but was still making technology choices, or, well, you get the picture. I know many architects that are very good at their jobs, although I have met some that really shouldn’t have been in that position. 

Conversely, there are developers who take some of the practices of agile software development, like limited documentation or limited upfront planning, and do not supplement those with the other practices like TDD, pairing, continuous integration, etc. that make the other practices safe. These developers aren’t good at their jobs either. Architects, however, will paint all agilists with that brush even though they aren’t irresponsible developers. So, we have two very good reasons that architects and agilists often don’t understand or trust each other. 

So, let’s look instead at what architects and agilists can learn from each other. Let’s start with what architects can teach agilists. Although the DevOps movement has made this less true, there are still many agilists who haven’t had to support their work once it’s gone live or over a long period of time. Thus, they haven’t had to live with many of the consequences of the choices they’ve made. 

Architects are in a position to help teams understand the requirements from the support and operations perspective. Architects can bring to the prioritization discussions the context from the operations and long term perspectives. We all know that cross-functional requirements must sometimes take precedence over functional requirements. However, the context for that decision making isn’t always complete. Architects need to help the agilists understand this broader context, so priorities can be appropriately set.

Now, what about the other ways around; agilists have things that can help architects as well. To explore this question, though, requires that we examine how architectural issues have evolved. 

For a long time, architects produced five or even ten year roadmaps for the architecture. The target architecture was up on a wall with lots of boxes and lines. These plans didn’t always reflect reality, but there was at least a hope that those decisions could survive for that long. Now, the current rate of technological change means that no roadmap could survive even a couple of years, let alone five or ten. Javascript frameworks come and go; new entrants like Docker impact architectural decisions even when Docker isn’t currently part of the ecosystem. In this kind of dynamic environment, tying architectural decisions to implementations is impractical. 

However, isn’t this just a cross-functional version of the problem agile software development solves for functional requirements? The agile software development process has clear mechanisms for delivering business value through things like stories, acceptance criteria, showcases, etc.; these mechanisms aren’t always used by operations teams, architecture teams, in the same way, but they can be. Architects can specify what outcomes need to be met by software delivered into the technology estate, as opposed to specifying how those outcomes should be achieved. By switching to more of an acceptance criteria approach, architects can be confident that their issues are being addressed while leaving the teams with the flexibility to choose how best to achieve those outcomes. 

Unlike code quality, which is mostly independent of the problem being solved or the organization creating the code, architectural quality depends on the specifics of the problem. In part, this dependence derives from the fact that we can’t simultaneously maximize all the different architectural -ilities. A common phrase from an architect is “well, it’s a trade-off”. 

One very important upfront decision that needs to be made for any development effort is a specification of the important architectural drivers for this particular system, in this particular organization, in this particular industry. A finance system has different needs from a healthcare system or a retail system or a media site. This early decision making about what the important drivers are and what architectural qualities need to be achieved provides the mechanism for the architects to communicate their concerns to agilists and then empower the agilists to achieve those outcomes in the most appropriate way for their system. This decision making also provides a great forum for the architects to help the agilists understand the architectural issues and for the agilists to give feedback to the architects about the issues they are facing in the delivery process. 

Architects have legitimate concerns that need to be addressed by delivery teams. Agilists have legitimate concerns about how to balance the needs of all of the stakeholders of the delivery of software. Understanding the history of conflict between these two groups is the first step in reconciling the legitimate concerns of these groups. Agile Meets Architecture is another step in this process, providing a forum for productive conversations about how we can address both sets of concerns by working together.