It doesn’t take a huge amount of knowledge and skill to get a program working. Kids in high school do it all the time. Young men and women in college start billion dollar businesses based on scrabbling together a few lines coding. Thousands of junior programmers around the world slog through massive requirements documents held in huge issue tracking systems to get their systems to “work” by the sheer brute force of will. The code they produce may not be pretty; but it works. It works because getting something to work—once—just isn’t that hard.
Getting it right is another matter entirely. Getting software right is hard. It takes knowledge and skills that most young programmers haven’t yet acquired. It requires thought and insight that most programmers don’t take the time to develop. It requires a level of discipline and dedication that most programmers never dreamed they’d need. Mostly, it takes a passion for the craft and the desire to be a professional.
And when you get software right, something magical happens: You don’t need hordes of programmers to keep it working. You don’t need massive requirements documents and huge issue tracking systems. You don’t need global cube farms and 24/7 programming.
When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized.
Yes, this vision sounds a bit utopian. But I’ve been there; I’ve seen it happen. I’ve worked in projects where the design and architecture of the system made it easy to write and easy to maintain. I’ve experienced projects that required a fraction of the anticipated human resources. I’ve worked on systems that had extremely low defect rates. I’ve seen the extraordinary effect that good software architecture can have on a system, a project, and a team. I’ve been to the promised land.
But don’t take my word for it. Look at your own experience. Have you experienced the opposite? Have you worked on systems that are so interconnected and intricately coupled that every change, regardless of how trivial, takes weeks and involves huge risks? Have you experienced the impedance of bad code and rotten design? Has the design of the systems you’ve worked on had a huge negative effect on the morale of the team, the trust of the customers, and the patience of the managers? Have you seen teams, departments, and even companies that have been brought down by the rotten structure of their software? Have you been to programming hell?
I have—and to some extent, most of the rest of us have, too. It is far more common to fight your way through terrible software designs than it is to enjoy the pleasure of working with a good one.
What Is Software Design and Software Architecture?
There has been a lot of confusion about design and architecture over the years. What is software design? What is software architecture? What are the differences between the two?
One of the goals of this article is to cut through all that confusion and to define, once and for all, what design and architecture are. For starters, I’ll assert that there is no difference between them. None at all.
The word “architecture” is often used in the context of something at a high level that is divorced from the lower-level details, whereas “design” more often seems to imply structures and decisions at a lower level. But this usage is nonsensical when you look at what a real architect does.
Consider the architect who designed my new home. Does this home have an architecture? Of course it does. And what is that architecture? Well, it is the shape of the home, the outward appearance, the elevations, and the layout of the spaces and rooms. But as I look through the diagrams that my architect produced, I see an immense number of low-level details. I see where every outlet, light switch, and light will be placed. I see which switches control which lights. I see where the furnace is placed, and the size and placement of the water heater and the sump pump. I see detailed depictions of how the walls, roofs, and foundations will be constructed.
In short, I see all the little details that support all the high-level decisions. I also see that those low-level details and high-level decisions are part of the whole design of the house.
And so it is with software. The low-level details (software design) and the high-level structure (software architecture) are all part of the same whole software. They form a continuous fabric that defines the shape of the system. You can’t have one without the other; indeed, no clear dividing line separates them. There is simply a continuum of decisions from the highest to the lowest levels.
In other words, software design represents the process of defining the specification of the artifacts which will help us implementing the software. It refers to designing individual modules, components, and classes and their roles in the whole software.
Software architecture represents the high level fundamental structure of a software system. First, we should prepare the software architecture and when it is approved then we define the software design. In software architecture the solution is structured in such a way so that it meets technical and operational requirements such as quality, maintenance, performance. All these factors contribute in the overall success of the software.
Here is a table showing an summarized overview the difference between software design and software architecture:
Software Design |
Software Architecture |
Software design is about designing individual modules/components. |
Software architecture is about the complete architecture of the overall system. |
Software design defines the detailed properties. |
Software architecture defines the fundamental properties. |
In general it refers to the process of creating a specification of software artifact which will help to developers to implement the software. |
In general it refers to the process of creating high level structure of a software system. |
It helps to implement the software. |
It helps to define the high level infrastructure of the software. |
Software design avoids uncertainty. |
Software architecture manages uncertainty. |
Software design is more about on individual module/component. |
Software architecture is more about the design of entire system. |
It is considered as one initial phase of Software Development Cycle (SDLC) and it gives detailed idea to developers to implement consistent software. |
It is a plan which constrains software design to avoid known mistakes and it achieves one organizations business and technology strategy. |
Some of software design patterns are creational, structural and behavioral. |
Some of software architecture patterns are microservice, server less and event driven. |
In one word the level of software design is implementation. |
In one word the level of software architecture is structure. |
How we are building is software design. |
What we are building is software architecture. |
Conclusion: Software Design vs Software Architecture
Software architecture and software design are two separate parts of one process that depend on each other for success.
Software architecture focuses on the high level structure of the system, while software design focuses on how the components interact with each other. The goal of these two concepts is to deliver extensible and high-quality software while minimizing the time and energy spent on development.