Software architecture has traditionally been associated with big design up front and waterfall-style delivery, where a team would ensure that every last element of the software design was considered before any code was written. In 2001, the "Manifesto for Agile Software Development" suggested that we should value "responding to change over following a plan," which when taken at face value has been misinterpreted to mean that we shouldn’t plan. The net result, and I’ve seen this first hand, is that some software development teams have flipped from doing big design up front to doing no design up front. Both extremes are foolish, and there’s a sweet spot somewhere that is relatively easy to discover if you’re willing to consider that up front design is not necessarily about creating a perfect end-state. Instead, think about up front design as being about creating a starting point and setting a direction for the team. This often missed step can add a tremendous amount of value to a team by encouraging them to understand what they are going to build and whether it is going to work.
In order to arrive at a software design, you need to make some design decisions. In discussing the difference between architecture and design, Grady Booch tells us that "architecture represents the significant decisions, where significance is measured by cost of change." In other words, which decisions are expensive to change at a later date? Following on from this, a good way to think about up front design is to ensure that you’ve made and understood the trade-offs associated with the "significant decisions." These significant decisions are typically related to technology choices and structure (i.e. decomposition strategies, modularity, functional boundaries, etc.) If you’re building a monolithic software system, the choice of programming language is likely to be significant for a number of reasons. Adopting a microservices architecture potentially reduces the significance of which programming language(s) you choose, but introduces other trade-offs that need thinking through. Similarly, adopting a hexagonal architecture allows you to decouple your business logic from your technology choices, but again there are trade-offs.
The up front design process should therefore be about understanding the significant decisions that influence the shape of a software system rather than, for example, understanding the length of every column in a database. In real terms, I’d like teams to really understand what they are going to build, how they are going to build it (at a high-level, anyway) and whether what they’ve designed will have a good chance of actually working. This can be achieved by identifying the highest priority risks and mitigating them as appropriate, writing code if necessary. In summary, up front design should be about stacking the odds of success in your favour.
