I'm back in The Netherlands next week to deliver the opening keynote at the Agile Software Architecture Symposium, where I'll be speaking about agility and the essence of software architecture. But what does "agile software architecture" actually mean?
In my experience, people tend to use the word "agile" to refer to a couple of things. The first is when talking about agile approaches to software development; moving fast, embracing change, releasing often, getting feedback and so on. The second use of the word relates to the agile mindset and how people work together in agile environments. This is usually about team dynamics, systems thinking, psychology and other things you might associate with creating high performing teams.
Leaving the fluffy stuff aside, for me, labelling a software architecture as being "agile" means that it can react to change within its environment, adapting to the ever changing requirements that people throw at it. This isn't necessarily the same as the software architecture that an agile team will create. Delivering software in an agile way doesn't guarantee that the resulting software architecture *is* agile. In fact, in my experience, the opposite typically happens because teams are more focussed on delivering functionality rather than looking after their architecture.
If we look at the characteristics of an agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed. However, nothing in life is ever free. Building a software system like this takes time, effort and discipline. Many people don't need this level of adaptability either, which is why you see so many teams building software systems that are much more monolithic in nature, where everything is bundled together and deployed as a single unit. Although simpler to build, this style of architecture usually takes more effort to adapt in the face of changing requirements because functionality is often interwoven across the codebase. With pragmatism in mind, you can always opt to build a software system that consists of a number of small components yet is still deployed as a single unit. You need to understand the trade-offs and make your choices accordingly.
However you build your software system, creating a well structured architecture isn't something that happens all by itself. You need to put time, effort and discipline into it. In order to do this, everybody on the team needs to understand software architecture and contribute to its success. How you do this is what my talk is all about...