Architecture in combination with agile is my one my main interest and I therefore had to attend the “Principles of evolutionary architecture” session by Rebecca Parsons. I expected much from this presentation and she did live up to it.
In the early days of software development, businesses typically would have 5 year plans. Nowadays, this is unthinkable. Business lifetime is shortening and when not keeping up you will miss your window of fame.
There are two kinds of architecture in response to change:
- Evolutionary
- Emergent
With evolutionary architecture you have a clear goal and you think about “how do I get there”. Emergent is more ad hoc and the notion of what is good is vague. These have similarities, but they are on a different scale.
The principles of evolutionary architecture:
- Last responsible moment
- Architect and develop for evolvability
- Postel’s law
- Architect for testability
- Conway’s law
Last responsible moment
Delay your decisions as long as you can. In this way, you maximize the information you have to be able to make a better decision (not based on guesswork). This way you will minimize technical debt (any drag in your development process).
Most important is to know what your drivers are and prioritize decisions accordingly.
Architect (Design) and develop for evolvability
You have to have a sensible breakdown of the functionality considering life cycle and ownership. Ease of change is a key factor in this. You could ask: “In what part of the system, when we change something do you get nervous?” to expose any vulnerabilities.
Coupling is an attention point and should be appropriate. The low coupling solution is not always the best solution.
When doing agile some developers often then to skip documentation. This is not advisable. A better approach would be to have lightweight (easy to change and maintain) tooling and documentation.
In the development process you have to focus on ease of change using software quality metrics. Using these metrics is a continuous effort in which you have to focus on hotspots and trends.
Postel’s law
Postel’s law says to be conservative in what you send and liberal in what you receive. By being conservative in exposing contracts, you delay the actual decision of the contract. After exposing it, it will become harder to change. When a contract must be broken use version changes.
By being liberal in what you receive, you can change the software more easily. Therefore only validate what you actually need. Think about what the consequences are of changing your mind and act on it (for example adding extra layers).
Architect (Design) for testability
Tests help the business understand the product. Aiming towards testability produces a well-architected system. Use technologies for their specific purpose and be careful to introduce complexities that threaten the testability. Create your tests at many levels.
Conway’s law
Conway’s law says that organizations design systems reflecting their communication structures. Broken communication implies complex integration. Silos often result in broken communication. If you don’t want your product to look like your organization, change your organization.
Techniques
Certain techniques can be used to optimize evolvability like Database refactoring (break into small changes), Continuous delivery (integrate as soon as possible, automate your environment, deployment should be boring), choreography (decentralizing your architecture, distributes complexity), Contract testing (integration point, maximizes parallel independent work, document assumptions)
