How to Do Just Enough Up-front Design

This article includes advice for doing enough up-front architectural design to provide the needed structure to start a project, aligning the team with the architect’s vision and assessing the possible risks.

The waterfall era of complete up-front design is gone, but does that mean one should start a new software project without sketching any design at all? What happens if without much consideration one starts typing code away to discover weeks later that a completely wrong technology choice was made in the first place? What happens if no thought is given to design principles and patterns and one ends up with a big ball of mud?

Also, if UML is largely seen as a hindrance in the developer’s way to just coding, does that mean that a team should not use any graphical way to communicate the design of the system they want to build together? Isn’t there a way to create just enough up-front design that is not becoming a burden for developers and ensures that the entire team will have the path to project’s success mapped out for them? Is there a way to communicate this design with all the team’s members to make sure they are building the same thing?

In his recent presentation at Craft Conference in Budapest - Agility and the Essence of Software Architecture -, Simon Brown, an European software architect and consultant, attempted to answer these questions and offered advice on creating a minimal initial design and a way to communicate it.

Starting from the assumption that “no architecture is not the solution”, Brown suggests doing enough up-front design down to the component level. He divides a system in several layers based on his C4 Model as shown in the following figure (taken from the session's slides - PDF):

First of all, one needs to consider how the system is going to be used and what are its dependencies on other systems. Then the containers are to be sketched up. A container is a deployable unit such as web server, app server, database, browser plug-in, etc. This involves making some decisions regarding the technologies to be used because the implementation of a system cannot be “technology agnostic”. Next comes the components which are inside containers. A component is usually a collection of highly related classes which together implement a certain feature of the system. Components are represented by modules or packages. Brown offered an example of such a component from his project techtribesje, shown in the next image:

The left side of the image shows the initial component made up of two layers, a service and a data access layer, each with its own package, but the component was later integrated into a single package, as shown on the right side of the image. In some cases, the DAO interface and the separation into two layers and packages is necessary, but for this case Brown decided to combine the two into one for simplicity. While this graphic shows interfaces and classes, the up-front design does not imply this level of detail. Only the component itself is decided not the classes or interfaces contained.

After designing the overall structure of the system down to component level, the process of up-front design includes two more phases as depicted in this graphic:

It is important for the architect to share his vision with the entire team so they would all build the same thing. Diagrams are helpful. They can be drawn with a tool or they can be sketched by hand. What’s important is to have a graphical representation of the system containing its structure, containers and components, a representation that one can refer to later at any time.

Another important phase is evaluating the possible risks in building the system. Brown proposes using risk storming to identify such risks. The whole team analyzes the architectural model, everyone pointing out where there could be problems implementing it. This phase is recommended to include a proof of concept or a prototype of the system.

The last advice is related to leadership. According to Brown, most teams perform best if having one leader doing the architecture of the system, while more mature teams can split the role up among multiple people if the system is large enough to warrant that.