Design Vs Architecture

• Architecture is strategic, while Design is tactical.
• Architecture comprises the frameworks, tools, programming paradigms, component-based software engineering standards, high-level principles.
• 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.
• Architecture without design does nothing: it can too easily remain stuck in an ‘ivory-tower’ world, seeking ever finer and more idealised abstractions. Design without architecture tends toward point-solutions that are optimised solely for a single task and context, often developed only for the current techniques and technologies, and often with high levels of hidden ‘technical debt’.
• Both architecture and design are essential. We may only arrive at appropriate, useful, maintainable solutions when architecture and design are both in use and in appropriate balance.
• While design is an activity concerned with local constraints, such as design patterns, programming idioms, and refactorings.
• 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
• 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.

Smaller projects often don't have enough scope to separate out planning into these to stages.

• 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.)
• Newer ways of thinking about the SDLC 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.
• 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.

One of the reasons that good architects are relatively rare is that, to work well, the architecture must cover an ever-wider scope, linking across more and more domains, yet still remain grounded in the immediacy of everyday practice. Designers need only focus on the single task at hand (though it always helps if they pay attention to proven architecture principles such as re-use, re-purpose, consistency and so on).