There still exists a common misconception that "architecture" and "agile" are competing forces, there being a conflict between them. This simply isn’t the case though. On the contrary, a good software architecture enables agility, helping you embrace and implement change; whether from changes in requirements, business processes, mergers, etc.
What is considered a "good architecture" is still up for debate of course but, for me anyway, the core characteristics of a good architecture relate to good modularity, reached through an appropriate decomposition strategy. If you've experienced the pain of making a major change to an existing big ball of mud, where seemingly unconnected parts of the codebase break, then you'll appreciate that having a well structured codebase (good modularity) is important.
A big problem I see with teams today is that they adopt, what George Fairbanks calls in his Just Enough Software Architecture book, "architecture indifferent design". In other words, teams adopt an architectural style without necessarily considering the trade-offs. This is often done because of hype, trend, fashion, and "CV-driven development".
In today's world, this is commonly manifested in teams adopting a microservices architectural style simply as a reaction to their existing monolithic codebase being considered a mess. Jokes about these same teams subsequently creating a "distributed big ball of mud" to one side, it turns out that the process of software design and decomposition is hugely important, irrespective of whether you're building a monolithic or a microservices architecture. Don't choose microservices because your monolithic codebase is a mess!
Summary
You don't get agility or a good architecture for free. Some conscious design effort is needed, and trade-offs need to be considered. This, again, is why creating that starting point with some up front design is crucially important. A good architecture enables agility.
Top comments (5)
Hi Simon, this is a great point, which people tend to really misunderstand... a few years ago I had a talk on this specific topic (how architecture empowers agility -> esilva.net/talks/#zoom_out_think-s...). I think the points you mention are very strong but I would add: "clearer alignment", i.e.: enable teams to understand the context and have a more well defined "direction" for their (agile) developments. By combining "direction" with "speed" (the only variable that "agile teams" tend to focus) you get "high velocity" (as in physics). This is still one of my major points to consider architecture ("the significant decisions") in Agile.
Agreed, alignment is very important ... this is covered in the other posts, from a couple of different angles. :-)
I know (read them all yesterday :p), but "repetition on the right places" is an acceptable "trait" (& "trade-off") :D Thank you for the series Simon, keep up with the great work!
Great series. Crisp, insightful and simplified.
Thank you. 🙂