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.