Evolutionary Architecture - A Survior's Guide

Delivering modern software development in an agile world requires the architecture to evolve together with the business functionality, not to be built up-front. This is where the term Evolutionary Architecture pops up.

"An evolutionary architecture supports guided, incremental change across multiple dimensions"
-- Neel Ford, Rebecca Parsons & Patrick Kua - Building Evolutionary Architecture, Support Constant Change - O'Reilly

To me, as a solution architect, the word "guided" is the most important in this quote. The solution architects need to have some kind of roadmap pointing out the wanted direction for the overall architecture, to let the development teams build the best solutions according to the Agile Manifesto:

"The best architectures, requirements, and designs emerge from self-organizing teams."
-- Agile Manifesto Priciples

That being said, I have never been part of a project where the requirements emerged from the team, rather refined and specified by the team based on requirements from functional experts

Another important precondition for evolutionary architecture to be successful is to agree on the most important "-ilities" for the overall architecture and for the key elements of it. This is where architecture gets difficult, and this is where each architect has his/her own vision, and this is where architecture is getting closer to religion. We all stand by our personal "favorites" of the "-ilities", and the discussions can release a lot of tension. To reduce this during the evolution of the architecture, a few key choices should be stated clearly from the beginning, and maybe a top 5 list for your project/system/application to be created, like:

1. Developers efficiency
2. Runtime independent applications
3. Security
4. Performance
5. Usability

If you create a list like that, the discussions going forward is a lot easier, since you can refer to your list stating that in your case developer's efficiency is more important than both Performance and Usability, if they are set up against each other. And by the same list you have stated that that if Performance and Usability is set up against each other, performance will win.

Of course, it is not that simple, because for all the items in the list there are some limits/boundaries to consider, e.g. performance cannot be worse than 10 seconds to return the result from a search. According to your list this needs to affect the usability, since it is below in rank, but sometimes you need to look above in the list to find a better solution. If that is the case this should be marked as an exception to the rule, and documented for future reference.

When you are building your system/application using an evolutionary architecture, you need to align the evolution of the architecture to the functional requirements and the order they should be implemented. The requirements should be evaluated for possible architectural and application style impact at an early stage. If they are not evaluated and aligned, the architecture might evolve in suboptimal ways and you will quickly end up with delays in implementation due to missing architecture components and/or several different implementations of architecture for related functionality.

Another aspect that needs to be present for evolutionary architecture to be successful, is the support from the stakeholders to rebuild, recreate and reorganize the architecture as you go. If you lack this kind of support (time and funding), the architecture quickly becomes a reactionary architecture, where problems is not handled before they get close to being, or even becomes, a disaster. As a system owner you cannot use the term evolutionary architecture to reduce up-front cost for later on claiming the architecture to be done and just build on top of it. Then you haven't understood the concept. Evolutionary indicates that you adjust it, reconstruct it and extend it along the way. If a bridge was built and dimensioned for horses to pass, you cannot just build a railroad on top of it and let the freight trains pass, you need to take a step back, strengthen the foundations, broaden the bridge and measure the load it can handle. In real world everyone understands this, but in the world of software people tends to think "I hear what you say, but it hasn't been proven to be a real problem before the bridge collapse, and the goods needs to be delivered to the customer tomorrow".

To conclude: Evolutionary Architecture is an important way of building software in modern agile projects, but it comes with a lot of responsibilities to be handled by experienced stakeholders. Don't use it if you doesn't accepts the responsibilities.