Evolutionary Systems

Systems and architectures should be designed and built to evolve independently from other systems.


At this point in time we know less than what we'll know in 6 months. Our software should be able to evolve as we learn more. It should evolve both at a code level and also at a service level.


  • Systems and processes will need to be exposed through clearly defined, open APIs so that the underlying implementation can change and evolve without impacting the wider system. (Note: this does not mean that a component or system's internal APIs necessarily need to be approached in the same way.)
  • Components must be accessible through open, non-proprietary standards (with a preference for HTTP & in-particular REST). Embracing the best practices of the web gives not only the desired openness but also the scalability.
  • Standards that are derived from working software and not just working groups are preferred. Battle tested standards used by several organisations tend to be more useful than over-engineerd hot air. Most succesfull standards tend to be the ones that are adopted by Open Source communities.
  • This will rely heavily on the principle of Maintainability to validate that behaviour hasn't mistakenly changed or broken.
  • Consider patterns such as TolerantReader and the Principle of Robustness
  • These patterns will give us more robust systems and allow systems to evolve independently of each other. One system can change and it will not take down others.
  • Sometimes gradual/incremental change is insufficient as requirements change, so consider a Sacrificial Architecture as a pattern. Don't be afraid to throw away and re-write, as this is often faster and will lead to better quality. If we have kept things Small and Simple this should not turn into a painful Big Rewrite.

Points for discussion

  • If you change your system is it an isolated change with regard to other systems?
  • How many people does it take to release?
  • How often can you release?
  • Can Ops release during the day?
  • How many requirements do you put into one iteration?
  • How future proof is it for requirements that may not exist?

results matching ""

    No results matching ""