Understand the architectural drivers

There's a perception that software design is a complex process steeped in formality where you must produce a large number of diagrams drawn using a formal notation. I like to keep the process as straightforward and lightweight as possible, but really the important part of the process is understanding what drives the architecture.

The major drivers include the functional requirements (what the solution should do), the non-functional requirements (the technical characteristics or quality attributes), the environmental constraints that are imposed upon you and the architectural principles that you want to adopt. Understanding the drivers and how to work within them does more to contribute to successful software projects than using sophisticated modelling tools and formal methodologies. I'm not saying that you shouldn't use them, but you do need to understand the drivers so that you can make the right decisions and come up with the right design.

The drivers do contribute to the complexity of the problem space but they can also help in reducing the number of options that are open to you, particularly if you find that the drivers include complex non-functional requirements or major constraints such as restrictions over the deployment platform. In the words of T.S.Eliot, "Given total freedom the work is likely to sprawl". Give somebody one week to do a task and that task will take one week. Give them two weeks and that same task will take two weeks. Understand the drivers to reduce the number of available design options.