In our move away from the waterfall way of building software, it's common for software teams to ask how much up front design they should be doing. Just enough is a good starting point but what exactly does that mean?
I ran a session at the Software Architect 2011 conference in London (slides) that aimed to answer this question. This was done by asking the audience for their thoughts on how much up front design is too little and how much is too much.
Here's a summary...
|How much up front design is too little?||How much up front design is too much?|
It's easy to identify with many of the answers above but "just enough" sits in that grey area somewhere between the two extremes. My own definition is summarised below and applies whether you have a dedicated architect or everybody is an architect. It includes:
Even this is simply a set of guidelines and the "how much up front design is enough?" question needs one of those "it depends" type answers because all software teams are different. Some teams will be more experienced, some teams will need more guidance, some teams will continually work together, some teams will rotate and change frequently, some software systems will have a large amount of essential complexity, etc.
In reality, the "how much up front design is enough?" question must be answered by *you* and here's my advice ... go and practice architecting a software system. Those of you that have attended my conference workshops or the Software Architecture for Developers training course will have seen this in action. Find or create a small-medium size software project scenario and draft a very short set of high-level requirements (functional and non-functional) to describe it. This could be an existing system that you've worked on or something new and unrelated to your domain. With this in place, ask 2 or more groups of 2-3 people to come up with a solution by choosing some technology, doing some design and drawing some diagrams to communicate the vision. Timebox the activity and then hold an open review session where the following types of questions are asked about each of the solutions:
Think of this exercise as an architectural kata except that you perform a review that focusses additionally on the process you went through and the outputs rather than just the architecture itself. Capture your findings and try to distill them into a set of guidelines for how to approach the software architecture process in the future. Agree upon and include examples of how much detail to go down into, agree on diagram notation and include examples of good diagrams, determine the common constraints within your own environment, etc. If possible, run the exercise again with the guidelines in mind to see how it changes things. We do this on the Software Architecture for Developers training course where we have a couple of iterations with some guidance before the second iteration. In total the exercise takes 4-7 hours.
As I mentioned before, no two software teams are the same. Setting aside a day to do this within your own environment will provide you with a consistent starting point for tackling the software architecture process in the future and help you contextualise exactly what "just enough" up front design means to you and your team. A nice additional benefit of practicing the process of software architecture is that it's a great way to coach and mentor others into becoming more architecturally aware. Self-organising teams anyone?
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.