Software architecture refers to the organization of a system, a reflection as to how all systems work together.
Software architecture is like housing architecture.
When building a house, you first architect it. Each room is designed for a specific purpose.
Piping and electricity is diligently planned to interact throughout the house.
Doors allow you to travel between rooms whereas walls block off access to rooms.
In other words...
Software architecture is the organizational makeup of the entire system.
It's one thing to know what a term means, but that is worthless if you don't know why you should know what software architecture is in the first place. Let's break down the importance of this tech term based on two high level categories. We'll walk through an explanation as well as provide a score, 1-10, that shows you how much you should care about software architecture.
The first will be if you do not have a product yet. This means that you don't have a physical product. Maybe you're in the ideation phase, or maybe you're almost ready to start development. Whichever it is, we'll get into why software architecture is important and why you should or shouldn't care about it if you do not have a product.
Your software architecture is going to be the foundation of your product, so it is important that you understand this term, why it matters, and ensure that your developers are planning ahead to build a proper architecture. If you skip over on this step and don't plan ahead, you will create many problems for yourself as you scale.
Live Product: 8/10
The second category is if you do have a live product. Maybe you just launched your business or maybe it's been live for years and you're continuing to improve its quality. Regardless of the scenario, if your product is live, software architecture carries a different weight.
This term is even more important once your product is live because with proper architecture comes proper scalability. As you want to build new features, integrate with other platforms, it is important that you do so in a way that aligns with scalable architecture.
So you know what software architecture is, by definition. You know if you should care about it or not depending on your situation as a business/company/product. To dig in deeper, we will walk through some examples so we can make sure you really have a solid grasp on software architecture.
10 common software architecture patterns:
We're going to walk through the 10 most common examples of software architecture. While 10 common examples is a lot, this will help give you a grasp as to the breadth of directions you can go when planning out your architecture.
- Layered Pattern
This is a simple way of outlining the layers of your architecture. This can be used if your software product can be simplified and broken down into high-level buckets. Typically in Layered Patterns, you'll find four categories: UI layer, Application or Service layer, Business logic layer, Data layer.
- Client-server Pattern
This pattern is to describe the relationship between two parties: a Client and a Server. A Client is representative of an end-user. A server is representative of the product itself. There typically will be multiple Clients with just one Server. An email provider is a perfect example of a piece of software that can be broken into a Client-server Pattern.
- Master-slave Pattern
Aligned with its name, this layer centers around a single master that directs slaves to do work. In order for this to suffice as a diagram, you need to be sure that you have one source of data that is the master with a multitude of other sources that are synced to the master, known as the slaves.
- Peer-to-peer Pattern
This type of architecture pattern is built to treat all components as equals, or peers. Each peer is able to send and receive information from one another - there is no master nor direction. The blockchain is a good example of a peer-to-peer pattern, as there is no centralized authority that dictates the actions of others.
- Event-bus Pattern
This pattern consists of four main categories: event source, event listener, channel, event bus. This pattern is used to break down patterns that are centered around events.
- Pipe-filter Pattern
This pattern is for filtering through a stream of data. Imagine a pipe with multiple filters, as the data flows through the pipe, it gets pushed through each filter, filtering out certain information. Once it has passed through all filters in the pipe, the resulting information becomes synchronized.
- Model-view-controller Pattern
The goal here is to divide an application into three main parts: model, view, controller (also referred to as MVC). The model contains the core function and data. The view will display the information to the user. The controller will allow the user to input information.
- Blackboard Pattern
This is going to be one of your more abstract patterns, as it is built for when there is no single strategy in mind to solve an equation. For example, with language recognition, you have to just continue aggregating data that you hear in order to eventually identify what the language spoken is. This pattern is broken up into three parts: blackboard, knowledge source, and control component.
- Broker Pattern
A broker pattern allows distributed systems to interact with one another via remove services. A broker itself is responsible for coordinating the communication of components.
- Interpreter Pattern
The goal here is to build a pattern that is meant to interpret information. The interpreter pattern will take in information of a consistent language and work to interpret that information.