What does just enough up front design actually mean?
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?
Too little vs too much
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.
The photos of the answers to these questions can be viewed online but here's a summary...
|How much up front design is too little?||How much up front design is too much?|
How much is "just enough"?
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:
- Understanding how the significant elements of your architecture fit together (i.e. structure ... components and their interactions).
- Ensuring that you identify and mitigate the key risks (e.g. non-functional requirements and the constraints of the environment).
- Putting some firm foundations down and ensuring that everybody understands the overall vision (i.e. "the big picture").
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.
Contextualising what "just enough" means to you
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:
- Will the architecture work? If not, why not?
- Have all of the key risks been identified?
- Is the architecture too simple? Is it too complex?
- Has the architecture been communicated effectively?
- What do people like about the diagrams? What can be improved?
- Is there too much detail? Is there enough detail?
- Could you give this to *your* team as a starting point?
- Is there too much control? Is there not enough guidance?
- Are you happy with the level of technology decisions that have been made or deferred?
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?