Agile Architectures

What is an Agile architecture? What makes an architecture Agile? Do you actually need an Agile architecture? What capabilities are you enabling with your architecture (e.g. scalability, extensibility, security, effiency, etc.)?

TL;DR; ‘Agile Architecture’ is a loose term, meaning different things to different people. I challenge you to make your goals explicit and not label architectures as ‘Agile’.

So let’s take a step back. Agile is a set of principles that put emphasis on quality, discovery and human collaboration. There is no direct relation with a software architecture. As Jim Coplien said “An architecture can’t be Agile, it doesn’t dance”. Your software architecture can enable Agility to a degree or be a result of an Agile process but not ‘be Agile’.

In the more literal sense, Agile means being able to change quickly. If your code base needs to support pivoting the product vision and implement really different kinds of features from one day to the next, then you need an Agile process and a change friendly architecture.

By the way, it’s really hard to design for unknown change. Spending effort on really clean code is a reasonable way to prepare for change, but if you have to throw large parts of your code away or rewrite big parts of the core domain code you might have been over-engineering.

Now, for some truth. Agile architectures are often not about changing on a dime for a dime. They are often something else entirely: productivity. For instance when software architects talk about standardization, having clear separation of components and roles, standardised deployments, etc. what does all that lead to? The capability to deliver fast and efficiently, giving you fast feedback, easy testing, etc. That in turn leads delivering more (small) features with the same amount of resources. So a clear architecture allows for rapid implementation (and efficient verification) of new features but it does not nececarely allow for rapid change of the architecture itself.

A good example is the use of micro-services. Microservices don’t allow for fast change of the architecture (undoing all the isolation is laborious) and thus moving your product into different markets with wildly different features is not helped by having them. And if your team structure is still changing a lot, your microservice layout probably can’t keep up with those changes. Micro services are a way to scale up and have different teams working in a relatively unchanging environment to get their features out quickly without bottlenecks in the communication or deployment process.

I would ask everyone to specify ‘What does that mean?’ when someone is talking about creating an ‘Agile’ architecture. What is your architecture enabling or supporting? Name your goals please and it’s okay if the goal is not being agile ;)

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade