Software Design vs. Software Architecture [closed]

Question

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;

1. Architecture means the conceptual structure and logical organization of a computer or computer-based system.

   Design means a plan or drawing produced to show the look and function or workings of a system or an object before it is made.

2. If you are “architecting” a component, you are defining how it behaves in the larger system.

   If you are “designing” the same component, you are defining how it behaves internally.

All architecture is design but NOT all design is architecture.

What part is the Design, the How is the concrete implementation and the intersection of What and How is Architecture.

Image for differentiating Architecture and Design:

There are also design decisions, that are not architecturally significant, i.e. does not belongs to the architecture branch of design. For example, some component’s internal design decisions, like- choice of algorithm, selection of data structure etc.

Any design decision, which isn’t visible outside of its component boundary is a component’s internal design and is non-architectural. These are the design decisions a system architect would leave on module designer’s discretion or the implementation team as long as their design don’t break the architectural constraints imposed by the system level architecture.

The link that gives good analogy

I'd say you are right, in my own words;

Architecture is the allocation of system requirements to system elements. Four statements about an architecture:

1. It can introduce non-functional requirements like language or patterns.
2. It defines the interaction between components, interfaces, timing, etc.
3. It shall not introduce new functionality,
4. It allocates the (designed) functions that the system is intended to perform to elements.

Architecture is an essential engineering step when a complexity of the system is subdivided.

Example: Think about your house, you don't need an architect for your kitchen (only one element involved) but the complete building needs some interaction definitions, like doors, and a roof.

Design is a informative representation of the (proposed) implementation of the function. It is intended to elicit feedback and to discuss with stakeholders. It might be good practice but is not an essential engineering step.

It would be nice to see the kitchen design see before the kitchen is installed but it is not essential for the cooking requirement:

If I think about it you can state:

• architecture is for a public/engineers on a more detailed abstraction level
• design is intended for public on a less detailed abstraction level

My reminder:

• We can change the Design without asking someone
• If we change the Architecture we need to communicate it to someone (team, client, stakeholder, ...)