BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News How to Do Just Enough Up-front Design

How to Do Just Enough Up-front Design

This item in japanese

Bookmarks

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):

image

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:

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:

image

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • A well tested technique that has stood the test of time.

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with the article, but I personally want to make clear that conceptually, C4 isn't anything new. In the realms of RUP, which I used to practise almost exclusively before I took to Agile development, this was the way I for one, architected systems and we're going back about 13 years. Indeed, such context specialisation have their roots in SSADM! Which predates even me. It can also feed a large number of other practises and techniques, such as CRC cards (at component level), workflow modelling, logical-to-physical development, context specialisation etc.

    A lot of architectural schools follow breaking such problems into increasingly finer contexts or greater specificity. Whether this is TOGAF's enterprise continuum, Kruchens 4+1, RUP, SSADM contexts etc. It's a technique which has stood the test of time.

  • A well tested technique that has stood the test of time.

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with the article, but I personally want to make clear that conceptually, C4 isn't anything new. In the realms of RUP, which I used to practise almost exclusively before I took to Agile development, this was the way I for one, architected systems and we're going back about 13 years. Indeed, such context specialisation have their roots in SSADM! Which predates even me. It can also feed a large number of other practises and techniques, such as CRC cards (at component level), workflow modelling, logical-to-physical development, context specialisation etc.

    A lot of architectural schools follow breaking such problems into increasingly finer contexts or greater specificity. Whether this is TOGAF's enterprise continuum, Kruchens 4+1, RUP, SSADM contexts etc. It's a technique which has stood the test of time.

  • Re: A well tested technique that has stood the test of time.

    by Simon Brown,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for the comment Ethar and you're right, C4 is a simple approach to decomposition and there have been many others tried and tested over the years. The difference here is that all levels in the C4 model are focussed around the static structure of the software system in question, albeit at different levels of abstraction. Traditional approaches to modelling a software system typically use a number of separate views ... logical view, functional view, module view, development view, etc. In my experience, many people (myself included) find them confusing. My approach blurs some of these together to create, what I think, is a simpler way to describe a software system with software developers as the primary stakeholder.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT