If you are going to leverage “Fr‑Agile architecture”, as a target concept, then it is critical to improve confidence so that you can make change safe. To deliver more you will need to massively:
- Increase the frequency of releases
- Make changes that fundamentally evolve the product
- Use new tools and technology that increases acceleration
To enable this frequent evolution (while keeping reliability, predictability, and team confidence high), you need to work on all areas of your development teams and architecture.
Architects are key to helping teams see the benefits of these approaches, and you should work with engineering leads to embed new working practices.
I’ve picked out two examples of tooling that are a structural response to a world where the foundations are always moving. By using them they allow you to spot any large blast radius incidents, shorten feedback loops, and empower teams to learn quickly without placing the business at risk.
CI/CD and automated testing: confidence at speed
Continuous Integration, Continuous Delivery, and automated testing are not productivity tools; they are risk‑management mechanisms. When technology changes rapidly, the only way to move fast without accumulating fear is to have constant, repeatable proof that the system still behaves as intended.
Automated testing provides confidence that small changes have not introduced unintended side effects. CI/CD pipelines allow those changes to be integrated, validated, and released continuously, rather than being stockpiled into high‑risk, high‑stress moments. Together, they decouple rate of change from level of risk — which is essential to accelerating the business. .
Open source: accelerating by standing on other people’s work
Tech teams (similar to the business) don’t appreciate the layers of complexity needed to solve real world problems. Thankfully, I think there is has been a shift in the industry, from the early 2010’s the idea that one framework or tool can provide an end to end solution has faded. It is now accepted that the reality is that you have to build your solution from lots of point solutions. Most open source projects tend to be highly specialised components that do their job really, really well.
It is easy to part solve a problem from scratch each time (e.g. a date time picker), but developers struggle with that and teams inevitably spend hours, then days refining the idea, polishing it and securing it. Open source has allowed developers to just skip all that work / friction, otherwise sprints get gobbled up with small details not big leaos forward.
Open source shifts where learning happens and who discovers the issues first. By adopting widely used platforms and libraries, teams benefit from the failures, fixes, and hard‑won knowledge of a much larger ecosystem. This aligns closely with the principle of riding the wave of other people’s problems — gaining speed without being on the bleeding edge.
Open source has delivered on its promise to dramatically reduce the cost of getting started with complex solutions. Entire capability stacks (infrastructure / security / user experience) — can now be assembled rather than invented.
What this means for architects
In an immature technology landscape, architects are not guardians of stability — they are designers of resilience. The most valuable architectural decisions are those that:
- Reduce coupling and limit the impact of change
- Make failure visible early and cheaply
- Enable rollback, replacement, and learning
- Allow teams to adapt without large‑scale rewrites
This is less about choosing the right technology, and more about shaping an environment where making the next change is never terrifying.
Actions from this section
🛡️
Engineer for safe change
Build pipelines, tests, and deployment patterns that make change routine rather than risky.
Architect resilience
Shift architectural focus from choosing “the right” technologies to designs that limit blast radius and enable fast swap outs