The difference between software design vs architecture comes down to scope and cost of change: architecture is the set of design decisions that shape the whole system and are costly to reverse, and design covers how each component is built. Microsoft’s guide says the two overlap, with no hard rule that separates them.
This article settles software architecture vs software design with a short test, then sorts eight common decisions with it, the kind that come up in custom software development.
What is the difference between software design and architecture?
Software architecture covers the design decisions that shape the whole system, while software design covers how individual components are built. The difference between architecture and design is mostly one of scope and cost of change, and the Software Engineering Institute (SEI) describes architecture as the set of design decisions that shape a system’s overall structure and behavior.
Microsoft’s Application Architecture Guide (2009) places the internals of individual components, such as data structures and algorithms, on the design side. The table compares software architecture vs design on seven points, and it is our summary of those sources.
| Question | Software architecture | Software design |
| Scope | The whole system and how its major elements interact | One component or module |
| Cost of change | High, so mistakes surface late and cost more | Lower, because the change stays local |
| Typical question | What are the major parts, and how do they communicate? | How is each part built? |
| Quality attributes | Shapes qualities such as scale and security across the system | Shapes how well one part performs and how easy it is to read |
| Who it affects | Every team that touches the system | The team that owns the component |
| What it produces | System diagrams and a record of key decisions | Specifications for components, such as class and interface details |
| Example | Splitting the product into services | The class structure inside one service |
What is software architecture?
Software architecture is the set of design decisions that shape a system’s overall structure and behavior, according to SEI. Those decisions let stakeholders judge in advance whether a system will meet qualities such as changeability and security.
Microsoft’s guide tells readers to understand the key engineering decisions and the areas where mistakes are most often made, and to get those decisions right the first time. It also says some aspects must be fixed early, and redesign there can be costly, which shows that architecture means balancing competing requirements. Our software architecture guide covers the subject in full.
Software architectural design is the work of making those decisions on purpose, and in our judgment, agreed software architecture practices help a team make them consistently.
What is software design?
Software design is the work of deciding how each component is built, including the algorithms it runs and the data structures it uses. Microsoft’s guide treats those choices as design concerns. For the wider process that design belongs to, see our guide to what software development involves.
Algorithms and data structures stay inside the component, so changing them costs less than changing the system’s structure. Design patterns work at this level, while system-level structures belong to architecture, which we cover in our guide to software architecture patterns.
How do you tell whether a decision is architectural or a design decision?
Ask whether the decision is costly to change and whether it touches more than one component. Then ask whether it shapes a quality attribute such as scale or security.
We call this the TekRevol Decision Test. Three yes answers point to architecture and zero or one point to design, while two mark a gray area for the team to decide together. The scoring is our judgment, built on criteria from SEI and Microsoft’s guide.
The table applies the test to eight decisions. The answers are our judgment, and a different team could score a row differently.
| Decision | Costly to change? | Many components? | Quality attribute? | Result |
| Split the product into separate services | Yes | Yes | Yes | Architecture |
| Use events or direct calls between services | Yes | Yes | Yes | Architecture |
| Choose the main data store | Yes | Yes | Yes | Architecture |
| Add a cache layer to meet a response-time target | No | Yes | Yes | Gray area |
| Choose REST or gRPC for one internal API | Yes | No | Yes | Gray area |
| Define the class structure inside one module | No | No | No | Design |
| Apply a factory pattern inside one module | No | No | No | Design |
| Pick a sorting algorithm for one report | No | No | Yes | Design |
Two rows land in the gray area, which is the point. A formula cannot settle them, so the team decides together.
How do software architecture and design work together?
Software design and architecture overlap, so they are better treated as one continuous activity than as two separate phases. Microsoft’s guide says the two areas often overlap and does not impose strict rules to separate them. It treats some decisions as mainly architectural and others as design decisions that help realize the architecture.
For where each activity falls in a project, see our guide to the phases of the software development life cycle.
Martin Fowler argued in “Who Needs an Architect?” (IEEE Software, 2003) that what counts as architectural depends on what the developers consider important, and that an architect’s key task is to reduce irreversibility. In our judgment, a decision can start as design and become architecture once many parts depend on it.
Here is a worked example. A team adds a cache inside one service to speed up a slow page, which is a design choice. When three other services start reading from the same cache, it becomes shared infrastructure that is costly to change and affects response times everywhere, so it now scores three yes answers on the test and deserves architectural review.
Who owns each decision is a separate question, which our post on software architect roles and responsibilities covers.
What goes wrong when teams confuse the two?
SEI warns that unmanaged quality trade-offs lead to delays and rework. In TekRevol’s judgment, that happens when an architectural decision is treated as a casual design detail.
The opposite error, in our judgment, is sending every local design choice through a heavy architecture review, which slows a team without protecting the system. Two habits reduce both errors: write down each architectural decision with its trade-offs, and leave design decisions to the team that owns the component.
How is system design different from software architecture?
System design vs architecture is a blurry line. In TekRevol’s reading, system design usually means planning how a whole system’s parts and its infrastructure fit together, and it overlaps heavily with software architecture.
In TekRevol’s reading, usage varies between teams, so the TekRevol Decision Test in this guide is a safer guide than the label. Also, in our reading, architecture is the structural decisions, and system design is the wider planning around them, which is not a standard definition.
How can TekRevol help with software architecture and design?
TekRevol is a software development company that can help you sort your decisions into architecture and design. Our custom software development work includes architecture planning in the design stage, so the costly decisions are made first.
Bring the decisions you are unsure about, such as a data store or a service split, and ask for a written record of each choice and its trade-offs. Start with a Free Consultation.
