In “Think big, act small” – what does it mean in architecture?, Viktor Grgic says, "Let’s simplify things by talking about concrete things we actually do in software projects." Inspired by this, here's a summary of what I consider to be a minimal set of software architecture practices. Or to put it another way, here's what I do to get to a software architecture quickly.
The discussion about what I consider to be "just enough up front design" can be found in the sample of my "Software Architecture for Developers" book, but it's about...
Just to be clear, this isn't about gathering all of the requirements in any detail and it's not about big design up front either. A few short workshops to gather requirements and do some collaborative design is all it takes to get to a decent starting point. Since I'm a visual person, I'll even start to draft up a context diagram during workshops with non-techie people when we're gathering requirements.
That's basically it to be honest. I may do more if needed, but I don't generally do less than this. This isn't specifically an "agile" thing either, as I've followed this same basic approach for software projects of all shapes and sizes. The whole point of this is to introduce some direction and put some foundations in place that we can build upon. I have no problem with the architecture changing once we start writing code, but it should be done for a reason and in a structured way. Structure, risks and vision ... it's all about having a starting point for the rest of the delivery process, however you slice it up.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.