Introduction to Software Architecture for Aspiring Software Engineers

One software architecture definition to rule them all.

I might just have heard the perfect story about the importance of proper software architecture and design in our systems.

A couple of years ago, a colleague of mine bought an apartment in a block of flats that was still being developed. After he moved in, he heard about this other tenant, let’s call him Mr. SmartyPants, who bought a flat during the same period but with a twist.

Mr. SmartyPants had a great idea. Since the apartment layout was not yet definitive, he talked to the developer about making “small” adjustments. One of them was moving the kitchen to where the toilet should have been.

This might have looked like a good plan on paper, but considering the other tenants above him did not change their layout, you can imagine it was a 💩ty decision.

Can you imagine the smell Mr. SmartyPants has to endure every morning while eating breakfast?

This is a perfect analogy for software architecture. If you don’t care about your system architecture, you’ll end up having a shitty system.

What is Software Architecture?

You will get many definitions for software architectures depending on who you ask. But in essence, the architecture of a software system is the shape the system takes.

There are three aspects that characterize this shape:

1. the division of the system into components,

2. the ways in which those components communicate with each other,

3. and last but not least, the arrangement of these components.

Most software engineers consider only the first two. However, as we’ve seen earlier, the last one is essential if you don’t want a loose system.

Returning to our apartment metaphor, imagine that you wanted to create the architecture of a house.

The first step is to divide the house into components. In this case, it is pretty evident that the rooms are the components of our architecture: halls, bedrooms, bathrooms, living rooms, etc.

Next, you have to define how each room communicates with the other rooms:

• there is an entry point that brings you into the hall;

• from the hall, you can access the bedrooms, living room, kitchen, and bathroom;

• from the kitchen, there is an open space for the dining room.

Lastly, you have to decide how the rooms should be arranged. You don’t want the toilet next to the kitchen, or worse, above the kitchen and sharing the same pipes because, you know, of the smell.

It’s About The System Use Cases

If you had asked me 15 years ago about software architecture, I would have mumbled something about languages, frameworks, and database schemas.

However, when you examine the system from the perspective of its shape, you realize that software architecture is all about the use cases and less about low-level technical details.

If you look closely at the house architecture we defined above, you’ll realize that all the considerations we had to take—the number of rooms, how they communicate, and how they are arranged in the house—are based on how people use the house. It’s about the house's use cases.

Similarly, the software architecture should highlight the system’s use cases.

—Alex