Software Design vs. Software Architecture

In some descriptions of the SDLC (Software Development Life Cycle) they are interchangeable, but the consesus is that they are distinct. They are at the same time: different (1) stages, (2) areas of responsibility, and (3) levels of decision-making.

• Architecture is the bigger picture: the choice of frameworks, languages, scope, goals, and high-level methodologies (Rational, waterfall, agile, etc.).
• Design is the smaller picture: the plan for how code will be organized; how the contracts between different parts of the system will look; the ongoing implementation of the project's methodologies and goals. Specification are written during this stage.

These two stages will seem to blend together for different reasons.

1. Smaller projects often don't have enough scope to separate out planning into these to stages.
2. A project might be a part of a larger project, and hence parts of both stages are already decided. (There are already existing databases, conventions, standards, protocols, frameworks, reusable code, etc.)
3. Newer ways of thinking about the SDLC (see Agile methodologies) somewhat rearrange this traditional approach. Design (architecture to a lesser extent) takes place throughout the SDLC on purpose. There are often more answered 2009-12-24T15:39:40.507

(A fragment from http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)

Architecture is design, but not all design is architectural. Therefore, strictly speaking, it would make more sense to try to differentiate between architectural design and non-architectural design. And what is the difference? It depends! Each software architect may have a different answer (ymmv!). We develop our heuristics to come up with an answer, such as 'class diagrams are architecture and sequence diagrams are design'. See DSA book for more.

It's common to say that architecture is at a higher abstraction level than design, or architecture is logical and design is physical. But this notion, albeit commonly accepted, is in practice useless. Where do you draw the line between high or low abstraction, between logical and physical? It depends!

So, my suggestion is:

• create a single design document.
• name this design document the way you want or, better, the way the readers are more accustomed to. Examples: "Software Architecture", "Software Design Specification".
• break this document into views and keep in mind you can create a view as a refinement of another view.
• make the views in the document navigable by adding cross-references or hyperlinks
• then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details.
• you may want to take a look at an example of multi-view architecture document (here).

Having said all that... a more relevant question we need to ask is: how much design is enough? That is, when should I stop describing the design (in diagrams or prose) and should move on to coding?