Software Design vs. Software Architecture

You're right yes. The architecture of a system is its 'skeleton'. It's the highest level of abstraction of a system. What kind of data storage is present, how do modules interact with each other, what recovery systems are in place. Just like design patterns, there are architectural patterns: MVC, 3-tier layered design, etc.

Software design is about designing the individual modules / components. What are the responsibilities, functions, of module x? Of class Y? What can it do, and what not? What design patterns can be used?

So in short, Software architecture is more about the design of the entire system, while software design emphasizes on module / component / class level.

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 iterations where the whole process happens over and over.
4. Software development is complicated and difficult to plan anyway, but clients/managers/salespeople usually make it harder by changing goals and requirements mid-stream. Design and even architectural decisions must bemade later in the project whether that is the plan or not.

Even if the stages or areas of responsibility blend together and happen all over the place, it is always good to know what level of decision-making is happening. (We could go on forever with this. I'm trying to keep it a summary.) I'll end with: Even if it seems your project has no formal architectural or design stage/AOR/documentaiton, it IS happening whether anyone is consciously doing it or not. If no one decides to do architecture, then a default one happens that is probably poor. Ditto for design. These concepts are almost more important if there are no formal stages representing them.

Architecture is strategic, while Design is tactical.

Architecture comprises the frameworks, tools, programming paradigms, component-based software engineering standards, high-level principles..

While design is an activity concerned with local constraints, such as design patterns, programming idioms, and refactorings.

I found this as I was looking for simple distinction between architecture and design myself;
What do you think of this way of looking at them:

• architecture is "what" we're building;
• design is "how" we're building;

Yep that sounds right to me. The design is what you're going to do, and architecture is the way in which the bits and pieces of the design will be joined together. It could be language agnostic, but would normally specify the technologies to be used ie LAMP v Windows, Web Service v RPC.

Good question... Although the line between them is hardly a bright sharp line, imho, if you are using both terms, then Architecture encompasses more technical or structural decisions about how to build or construct something, especially those decisions that will be hard (or harder) to change once implemeneted, whereas Design encompasses those decisions that either are easy to change later (like method names, class <-> file organizational structure, design patterns, whether to use a singleton or a static class to solve some specific problem, etc. ) and/or those that effect the appearance or esthetic aspects of a system or application (Human Interface, ease of use, look and feel, etc.)

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.

(from Wikipedia, http://en.wikipedia.org/wiki/Software_architecture)

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.

(from Wikipedia, http://en.wikipedia.org/wiki/Software_design)

Couldn't have said it better myself :)

I view architecture as Patrick Karcher does - the big picture. For example, you can provide the architecture to a building, view its structural support, the windows, entries and exits, water drainage, etc. But you have not "designed" the floor layout's, cubicle positions etc.

So while you've architected the building you have not designed the layout of each office. I think the same holds true for software.

You could view designing the layout, as "architecting the layout" though ...

Pretty subjective but my take:

Architecture The overall design of the system including interactions with other systems, hardware requirement, overall component design, and data flow.

Design The organization and flow of a component in the overall system. This would also include the component's API for interaction with other components.

Software architecture is“concerned with issues...beyond the algorithms and data structures of the computation.

Architecture is specifically not about…details of implementations (e.g., algorithms and data structures.) Architectural design involves a richer collection of abstractions than is typically provided by OOD” (object-oriented design).

Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.

“architecture” is often used as a mere synonym for “design” (sometimes preceded with the adjective “high-level”). And many people use the term “architectural patterns” as a synonym for “design patterns.”

Check out this link.

Defining the Terms Architecture, Design, and Implementation

Architecture:
Structural design work at higher levels of abstraction which realize technically significant requirements into the system. The architecture lays down foundation for further design.

Design:
The art of filling in what the architecture does not through an iterative process at each layer of abstraction.

...long time ago in a faraway place philosophers worried about the distinction between the one and the many. Architecture is about relationship, which requires the many. Architecture has components. Design is about content, which requires the one. Design has properties, qualities, characteristics. We typically think that design is within architecture. Dualistic thinking gives the many as primordial. But architecture is also within design. It's all how we choose to view what is before us - the one or the many.

Software architecture is best used at the system level, when you need to project business and functions identify by higher architecture levels into applications.

For instance, your business is about "Profit and Loss" for traders, and your main functions involved "portfolio evaluation" and "risk computation".

But when a Software Architect will details his solution, he will realize that:

"portfolio evaluation" can not be just one application. It needs to be refined in manageable projects like:

• GUI
• Launcher
• Dispatcher
• ...

(because the operations involved are so huge they need to be split between several computers, while still being monitored at all times through a common GUI)

a Software design will examine the different applications, their technical relationship and their internal sub-components.
It will produce the specifications needed for the last Architecture layer (the "Technical Architecture") to work on (in term of technical framework or transversal components), and for the project teams (more oriented on the implementation of the business functions) to begin their respective projects.

Cliff Notes version:

Design: Implementing a solution based on the specifications of the desired product.

Architecture: The foundation/tools/infrastructure/components that support your design.

This is a pretty broad question that will invoke a lot of responses.

Architecture is the resulting collection of design patterns to build a system.

I guess Design is the creativity used to put all this together?

Software design has a longer history while the term software architecture is barely 20 years old. Hence, it is going through growing pains right now.

Academics tend to see Architecture as part of the larger field of software design. Although there is growing recognition that Arch is a field within it's own.

Practitioners tend to see Arch as high-level design decisions that are strategic and can be costly in a project to undo.

The exact line between Arch and design depends on the software domain. For instance, in the domain of Web Applications, the layered architecture is gaining the most popularity currently (Biz Logic Layer, Data Access Layer, etc.) The lower level parts of this Arch are considered design (class diagrams, method signatures, etc.) This would be defined differently in the domains of embedded systems, operating systems, compilers, etc.

Architecture and design are closely related; the main difference between them is really about which way we face. Architecture faces towards strategy, structure and purpose, towards the abstract. Design faces towards implementation and practice, towards the concrete.

As others also pointed out, laying out the architecture of a piece of software is actually taking the major design decisions which have overall influence over the software development or execution life-cycle; so simplistically architecture is just high level design.

Even if an architecture decision does not affect all components (is thus, local) it must still be globally relevant, i.e. it impacts the whole system in some way; otherwise is simply a local design decision.

What I'd like to point out though, that a more relevant question related to architecture might be Architecture vs Organization as defined by Hennessy & Patterson in Computer Architecture. Based on this we could think about architecture as the data model (input/output, state) abstraction of the system and the organization as the typical design decisions taken during the implementation (software development) process.