What Is Agile Architecture?

I was recently asked to deliver a training course on agile architecture. Although the materials were provided for the course by a third party, it soon became clear to me that they did not meet the client’s specific needs around understanding exactly what agile architecture involves. Indeed, there seems to be a broader issue, judging by the lack of explicit material published in this area. There wasn’t even a Wikipedia page until I began to create one as part of the course (please contribute to it!)

Why is agile architecture a difficult topic to teach? It seems that there are parts of the Agile Manifesto that are problematic for the architect. While the manifesto rates processes, tools, documentation and planning as less important than agile features such as interactions, working software and responding to change, those traditional components are at the heart of architecture, particularly in large scale systems. Further complicating the question are the different layers or levels of architecture, from the Enterprise Architect with a broad review of organisational systems, to the System Architect working on specific domains and services with software development teams.

The general consensus appears to be that the job of an architect is to do ‘just enough’ architecture at each stage of an agile project, but the difficulty is in defining what is ‘just enough’. Of course there is always an implicit architecture in a system, embedded in the code, and to some extent this can be serviced by techniques such as applying coding standards and using annotations. Another way of looking at architecture in an agile context is to see it as a collection of fragments, recorded as part of user stories. Stories that need to take account of architectural elements would include architectural fragments as part of the conversation around the story card. A more centralised view of architecture can be captured in the C4 model; Context, Component, Container and Class, that can be used to get a high level decomposed view of the most important aspects of a system.

Martin Fowler talks about architecture as being the things that are hard to change, and also discusses the idea that one job of an architect is to identify ways in which things that are hard to change are made easier to change, so that the whole process of developing an architecture can be more agile. One example of this would be to incrementally evolve a database schema, rather than believing it necessary to specify the schema early in a project.

One of the areas that seems to be important is the distinction between architecture as a noun, which relates to the elements of architecture that are explicitly documented outside of code, and architecture as a verb, meaning the role of the architect, which is much more about communication and supporting the development team. The role of the architect might be seen as a combination of transformational leadership, providing a vision and being a role model, and the more traditional agile style of servant leadership, enabling teams to perform.

So, what is the key job of an agile architect? Primarily it is to ensure that all stakeholders share the same vision, a vision that might be captured in a dynamic set of requirements and a set of models that may only be recorded informally, continually redrawn on whiteboards in discussions with stakeholders and teams, and continue to evolve with a constant eye on pushing critical decisions back as late as possible by, for example, exploring multiple architectures in parallel, and using tools and approaches that allow decisions to be reversed to, in effect, ’embrace change’ in the common mantra of agile development.

It seems that there is still a conversation to be had about exactly what it means to be an agile software architect, and perhaps the metaphor is the problem. A number of practitioners have questioned whether the concept of architecture relates closely to what we do in software development. One suggestion is that the role of city planner is a better metaphor than architect. This certainly resonates with the idea that city planning is a wicked problem, and that the challenges of designing large scale software systems share the same wicked characteristics