Evolving Architecture
Some years ago we were in a deep hole of massive tech debt, lots of crashes and dependencies and unclear responsibilities. It took its toll causing arguments, somewhat of a blame-culture, low efficiency and not so much fun at work.
It evolved into long discussions with everyone interested about how we could do things better. Developers around the organizations sat and discussed what would be the most efficient and fast moving way to work.
We ended up with some architectural principles. Not rules, not tech choices, no architectural diagrams just principles.
After a couple of years they were reiterated, one was added and a few were removed.
Recently we asked ourselves, have they helped us? Or did it become just another paper product? We decided to find out…
Our Present Guidelines
Inspired by the format of the agile manifesto we described then as one is good but the other better (e.g. Reusability is good but Adaptability is more important)
Adaptability over Reusability
- Adapt quickly to changing requirements
- Avoid premature optimizations
- Minimize dependencies
Free Tech Choices over Standardized Tech Choices
- Team feel responsible for choices and products
- To have a modern and attractive tech stack
Team ownership over Centralised Ownership
- Clarity around ownership
- Quick decision paths
Continuous delivery over Release Cycles
- Enable fast experiments
- Increase adaptability
Evolutionary architecture over Up-front Big Decisions
- We rarely know everything that lies ahead
What did we find out then?
First and most important, they’ve really helped us in our daily work, it’s not a paper product. It’s not something decided by someone outside of daily work.
As someone said
“Those who should decide on the architecture are those that will be on call for it”
Five Takeaways
Easy to Experiment and Adapt
We succeeded in making it easy building new services, testing out new tech and refactor old. It helped us keeping a modern tech stack.
We believe it also helps us keeping a high pace of innovation. Experimenting comes at a low cost.
Robust systems
We have few incidents and still don’t need an on-call organization. It’s easy to find and fix problems and most things are easily fixed from home.
Low Technical Debt
We stole Amazon’s motto “You build it, you run it” which might have helped us keeping the code base sound and in shape.
I rarely even hear a discussion in the teams which we were used to earlier
High Responsibility
Everyone in the team feels responsible for their product. Both when it comes to up-time as well as ease-of-use.
Contributing to that culture might come from high autonomy both when it comes to choosing tech but also when it comes to prioritizing.
Satisfied Users
Many people have a lot of opinions on what a public service-company should focus on and develop which is great. We regularly measure and look at independent surveys on user satisfaction with all our services and strive to be in the top tier.
High focus on UX, A11Y and on keeping the bar low for elderly and users in the low-end tech spectrum have helped us a lot.
Attractive Workplace
Former Netflix-CEO pointed out in “No Rules Rules” that high talent density is a success factor for Netflix.
We try to be an attractive workplace both for our own sake but also to make recruitment easier. We are proud to have a high eNPS which makes everything easier
End note
Of course many factors may contribute to these takeaways e.g. user-centered focus, recruiting for curiosity, an agile culture, a goal- and outcome-oriented Lean UX process,…
Even though many factors collaborate to create our environment, we believe our architectural principles have a high impact on these takeaways
If you have questions or want to discuss how you work with architecture, don’t hesitate to reach out…
