⚠ 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 grey boxes 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”
2 Replies to “On Software Architecture Decisions, Evolution and Engineering”
Hi Aman! This was an excellent write up that expresses feelings and thoughts that I have been struggling to voice! Do you mind if I shamelessly copy and paste (and possibly condense) some of this content for team reference with source credits pointing here?
hey Cole, I am glad some of my ramblings resonated with you. Do feel free to spread the word! 🙂