Guiding Principles for an Evolutionary Software Architecture
Back in the dark old days of waterfall projects we invested heavily in big upfront architecture and design. Systems were well thought out and documented within an inch of their lives. All this happened before anyone cuts a single line of code. There was little or no room to change once things were in flight. Twelve months later we’d go through a horrendous regression test cycle and finally release a product only to find out that our clients needs had evolved and we’d ended up building something that nobody wanted, but hey at least it was well architected!
Thankfully, those days are gone my friend and big upfront design has no place in agile development . With agile development , teams still complete architectural work, but it’s done very differently. Instead of a big up-front design where decisions are made about the architectural needs for an entire system, Agile teams take an incremental and evolutionary approach. However, designing, building, and maintaining a robust architecture doesn’t come for free. You need to maintain focus on architecture throughout the entire process and stick to some guiding principles.
Evolutionary architecture gives us most of the benefits of enterprise architecture without the problems caused by trying to accurately predict the future. Here are a number of useful techniques and principles that will help you to maintain a clean architecture through the lifetime of your product.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Last responsible moment
The last responsible moment isn’t about encouraging procrastination, it is saying that you should delay decisions as long as you can but no longer. The longer you can afford to wait to make a design decision the more information you’ll have on hand and the better placed you are to get it right. Decisions made too early in a project are hugely risky. These decisions often result in work that has to be thrown away. Even worse, those early decisions can have crippling and unavoidable consequences for the future of the project.
Early in a project you should make as few binding decisions as you can get away with. Start small with a few critical stories but aim for working end to end software. Establish a skeleton architecture or ‘steel thread’ with an end to end data flow and establish your test approach.The driving technical requirements for a system should be identified early to ensure they are properly handled in subsequent designs and implementations. Choices like the programming language and the database technology need to be made at the start of a project but deciding on the right level of services decomposition will emerge later on. The last responsible moment makes sense for decisions which are costly to reverse and it will keep you from over architecting and designing for functionality that may never arise.
Establish lightweight documentation
The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely.Technical documentation is valuable but it needs to be kept at the right level if it has any chance of being kept up to date and surviving the duration of your project. Documentation becomes much more valuable when it takes on a collaboration nature. Wikis are a great way to socialise designs and to communicate both within your team and externally. The act of writing or sketching out a diagram helps you to think something through properly and increases your own understanding. You should focus on keeping things lightweight and relevant — make sure there is value in what you are documenting and make sure there is an audience that finds it useful. In general, system diagrams, design decisions , operational instructions and requirements should be documented to help you team understand what they are building and to help the others that come along after them.
Establish continuous integration and automation right from the get-go
Nothing builds or destroys agility more than a team’s commitment to continuous integration. Automated tests gives you a safety net that lets you refactor and change your code quickly knowing that you haven’t broken anything.
In order to evolve an architecture over time you need to maintain and grow all your automated tests — unit , integration, contract and end to end tests. Don’t get hung up on code coverage metrics but pay attention to tests that fail frequently, these will point you to the problem area’s in your code base that need your attention.
Without adequate automated tests your architecture won’t evolve freely. Making wholesale changes and restructuring existing code will becomes too risky and you’ll end up in a cycle of maintaining and extending poor code that compromises your architecture.
End to end tests are the slowest to run and the most brittle to maintain. When choosing the scenarios for an end to end test you should focus on the key workflows through your software. As the system grows don’t be afraid to throw away some of these tests and replace them with more valuable scenario’s. Your tests like you architecture need to evolve and sometimes that means they need to be deleted.
Simple code and simple designs are always best
Writing code is easy, writing code that is easy for others to understand is not so simple. Striving for simplicity when building complex systems should always be front of mind. Don’t let team members work alone, pair programming and code reviews help to make code more understandable and readable. When it comes to design, the easier things are to understand the better. Simple code and simple designs takes less time to understand, have fewer bugs, and are easier to modify. Beware of shiney new frameworks and abstractions for abstractions sake!
Remember Conways laws
Many years ago, Melvin Conway wrote a paper that proposed that the way an organization is structured would have a strong impact on how a system is created. He wrote
“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”
It is all too easy to focus purely on the technical challenges when architecting a system but you need to think about your organisation structure and assign the right work to the right teams. Having a single team work on and own an individual service is far better than having joint ownership across teams. Coordination and communication across teams is hard and all too often people find ways to avoid this altogether and you end up with large hard to maintain codebases with duplicate functionality added per team.
Finally, a word on robustness
Postels Law also known as the robustness principle is a great guideline when it comes to designing message contracts
“Be conservative in what you send, be liberal in what you accept”
As soon as you publish an API either internally or externally other systems will start to rely on it. Once it is the wild your API’s become much harder to change. When it comes to exposing data you should expose the bare minimum and no more and you should version all message contracts. Conversely when consuming an API its best to ignore parts of the message you aren’t interested in, you don’t care if these change over time.
Evolutionary architecture works but only when you focus and continually works through these guiding principles.
Your Turn
Like this post? please give it some love ;-)
