<< Features vs Behaviour | Home | Smidig må kombineres med arkitektur >>

Contextualising just enough up front design

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.

Here's a summary...

How much up front design is too little?	How much up front design is too much?
No understanding of what and where the system boundary is. No understanding of "the big picture" within the team. No common understanding of "the big picture" across the team. Inability to communicate the overall vision. Team members aren't clear or comfortable with what they need to do. No thought about non-functional requirements/quality attributes. No thought about how the constraints of the (real-world) environment affect the software (e.g. deployment environment). No thoughts on key areas of risk, such as non-functional requirements, external interfaces, etc. The significant problems and/or their answers haven't been identified. No thought on separation of concerns, appropriate levels of abstraction, layering, modifiability, flex points, etc. No common understanding of the role that the architect(s) will play. Inconsistent approaches to solving problems. A lack of control and guidance for the team. Significant change to the architecture during the project lifecycle that could have been anticipated. Too many design alternatives and options, often with team members disagreeing on the solution or way forward. Unsure whether the design will work (e.g. no prototyping was performed as a part of the design). A lack of technology choices (i.e. unnecessary deferral).	Too much information (i.e. long documents and/or information overload). A design that is too detailed at too many levels of abstraction. Too many diagrams. Writing code or pseudo-code in documentation. An architecture that is too rigid with no flexibility. All decisions at all levels of abstraction have been made. Class level design and sequence diagrams for all interactions. Detailed entity relationship models and database designs (e.g. tables, views, stored procedures and indexes). Analysis paralysis and a team that is stuck focussing on minor details. Coding becomes a simple transformation of design artefacts to code, which is boring and demotivates the team. An unbounded "design phase" (i.e. time and/or budget). The deadline has been reached without any coding.

How much up front design is too little?

How much up front design is too much?

No understanding of what and where the system boundary is.
No understanding of "the big picture" within the team.
No common understanding of "the big picture" across the team.
Inability to communicate the overall vision.
Team members aren't clear or comfortable with what they need to do.
No thought about non-functional requirements/quality attributes.
No thought about how the constraints of the (real-world) environment affect the software (e.g. deployment environment).
No thoughts on key areas of risk, such as non-functional requirements, external interfaces, etc.
The significant problems and/or their answers haven't been identified.
No thought on separation of concerns, appropriate levels of abstraction, layering, modifiability, flex points, etc.
No common understanding of the role that the architect(s) will play.
Inconsistent approaches to solving problems.
A lack of control and guidance for the team.
Significant change to the architecture during the project lifecycle that could have been anticipated.
Too many design alternatives and options, often with team members disagreeing on the solution or way forward.
Unsure whether the design will work (e.g. no prototyping was performed as a part of the design).
A lack of technology choices (i.e. unnecessary deferral).

Too much information (i.e. long documents and/or information overload).
A design that is too detailed at too many levels of abstraction.
Too many diagrams.
Writing code or pseudo-code in documentation.
An architecture that is too rigid with no flexibility.
All decisions at all levels of abstraction have been made.
Class level design and sequence diagrams for all interactions.
Detailed entity relationship models and database designs (e.g. tables, views, stored procedures and indexes).
Analysis paralysis and a team that is stuck focussing on minor details.
Coding becomes a simple transformation of design artefacts to code, which is boring and demotivates the team.
An unbounded "design phase" (i.e. time and/or budget).
The deadline has been reached without any coding.

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").

Just enough up front design

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?

Add a comment

Posted by Simon Brown on 05 January 2012 22:40:41 GMT #

About the author

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.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.

Add a comment Send a TrackBack

Re: Contextualising just enough up front design Comment from Anonymous on 18 November 2018 06:20:57 GMT #
Title
Body	HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me	Yes No
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).