One of my key points about software architecture is that it introduces structure and guidelines into a software system, which in turn leads to consistency and clarity of the overall design. Basically, I'm saying that there are some real benefits from thinking about your design upfront. This isn't a particularly groundbreaking statement, but you'd be surprised how few teams spend some quality time to do this. As I mentioned in Estimating a software system, this thinking doesn't need to take very long at all.
If you take a simple lightweight approach, you can map out the major functional requirements and come up with a design down to the major components in a couple of days. Then, you can do some high-level estimating off the back of this design. There are a number of ways that you can map out the functional requirements, although I find that user stories are a good way to summarise the key requirements.
Thinking about your software design on your own is great, but making it a collaborative exercise is even better and comes highly recommended. We're doing this at the moment for another project where each of us on the team has specialisms in different technology aspects of the overall solution. The benefit of this is that we all know how the technology in our own areas works, but the details of how those technologies collaborate is often unknown. Also, we sometimes tend to assume what responsibilities each technology will take on and it's only by discussing the overall solution as a group that we realise we've either doubled up on something or assumed that somebody else was looking after it. Essentially, software design as a collaborative exercise allows everybody's vision to meet so that the end-result is consistent and clear. As I've written before, often some of the basic foundations are missed.
For me, explicitly thinking about the components that make up the software system introduces structure, which in turn can be used as a template for building that system. From this, you get a consistent approach to solving common problems and a thought out design with a clear architectural vision. A couple of days upfront can really make a big difference to the big picture.
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.