DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 964,423 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Aman Agrawal for Coolblue

Posted on • Originally published at amanagrawal.blog on

On Software Architecture Decisions, Evolution and Engineering - 1

⚠ If you are looking for a quick read, this post is anything but. Make sure you’ve grabbed a β˜• or two before you decide to read this! This topic is very important to me, I have strong opinions about this and I’ve been meaning to put my thoughts down for a long time! Real life case studies and examples appear in quoted text with cheesy titles.

In my 15 some odd years of practising software engineering, I have come across two extremes around software architecture and perhaps unsurprisingly so given I cut my teeth in the waterfall era: Big Design Up Front (no code until the design/architecture is nailed down to the last detail) and No Design Up Front (we follow agile so we are just going to get started hacking away at the code until something resembling an architecture emerges if at all, and if it works that’s a bonus!). Move fast and break things sort of mindset.

Neither is conducive to the long term health and the value of the system nor to the morale of the teams building them, and MUST be avoided! In the former, you never actually ship anything meaningful and in the latter, you get pwned by your β€œarchitecture”! There are some environments where the latter works well enough, start-ups, but here I am talking about my home turf – enterprise software or software systems built at large organisations with often bureaucratic management practices and mis-aligned incentives between engineering and business teams.

My current philosophy is that deliberate and thoughtful architectural decisions that solve real business problems and mitigate enough of the real risks, is the RIGHT and the MIDDLE PATH way to go. In this post I want to explore the following questions and demonstrate using examples how we make risk driven architectural decisions in my domain at work and how I as a Principal Engineer facilitate this practice amongst my teams in the hopes that it will resonate with others as well. There is also some helpings of grumpy old man-isms sprinkled here and there:

  • What is an architectural decision ?
  • How much architectural work should be done upfront ?
  • How should architecture evolve?
  • Our Architectural Decision Making β€œProcess”

Top comments (0)

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.