Why do we bother with design?

One of the great cultural shifts in IT over the past 15 years is to a more transparent relationship with our customers.

Hopefully the days when IT were given requirements, went off for a year or two, and then came back with a system are mostly gone. Mainly because the system that was delivered was at best what the business wanted two years ago and at worst something completely different.

Whilst we are trying to be more open and transparent (commercial concerns aside) there are still issues that we need to overcome. One of the closest to my heart is that of design. Installing servers or writing code has at least some tangible outcome which your customer should be able to relate to. But what about design. Let's take a slightly theoretical conversation.

Architect: We need to put some design time into the budget
Customer: Why?
Architect: Well, we need to write a design
Customer: Why?
Architect: Well, it's really important to know what we're building (thinking that this will clinch the deal)
Customer: Sounds fair enough, but how long will it take
Architect: [insert your own value here depending on the size/complexity/risk of the project]
Customer: Wow, that's a lot. What do I get for this?
Architect: A [insert number] page document that will only ever be read by other architects and given your lack of change management will probably be out of date before it's even finished. Developers will ignore it, customers mis-interpret it and project managers miss the whole point of the design and cut the important bits when budget is tight thus crippling the whole value proposition.
Customer: A week should be fine then
Architect: Uh, okay

I'm being a little harsh here but the point is that unless we know what the design is for, and most importantly who it is for, then we risk the whole thing. As I've written about before the who is far more important than the what.Saying that, I'm going to look at the what for now.

A wise old(ish) architect once told me that you don't need to publish everything. This is a key point. Whilst you may have plenty of working you don't need to show this. I'm as guilty as anyone of writing too much, as my colleagues will testify. The key is to write just enough.

So what is enough? One of my bugbears is when architects start debating how much detail should go into a design. Firstly there is no answer. You can't quantify detail; there is no unit of detail. Secondly, it is the wrong question. A far more useful way of looking at this is to consider what questions are we trying to answer through the design. I would suggest something along the lines of the following.

High Level Design -

• Does it meet the business need? Nice design, but will it actually meet the requirements?
• How is it going to work? Enough information is needed to enable the reader to say, "yes, I understand how this system is going to operate"
• Viability of the solution? Enough evidence to support the notion that the final system will indeed work
• Can it be supported? Some idea on how major components can be managed, changed and fixed
• Does it integrate with the rest of the landscape? I had to make up a word for this - integrability. Essentially what impact is this going to have on the existing IT landscape. We shouldn't break anything that's already out there
• Roughly how much is it going to cost?
• What are the main risks and how do we mitigate them?

Detailed Level Design (varying focus between infrastructure and software here)

• What do I need to build, component by component?
• What configuration is required for each component?
• What are the interfaces, responsibilities and constraints on each component?
• Does it deliver the system described in the High Level Design?

After this it's build guides or program specifications depending on your speciality.

So how long is the design. Simply, you decide. Do you feel comfortable that you have answered these questions and if you walked away it would make sense to someone who picked it up and started reading.

For a very simple system, a few pages should do it for a high level design. For something more complex then it takes a little longer.