What is software architecture?

Every software system has to adhere to certain requirements. Most of the time this means making the life of users easier by providing functions relevant and helpful for their work. Additionally, the system has to be equipped with features, which make it usable in the first place, e.g. accessibility, performance and stability. But all in all, it boils down to meeting certain requirements, whether they are functional or non-functional, well-known or unknown. The architecture explains how the system is going to fulfill those requirements.

The architecture does not address each requirement individually since there are lots of requirements which are very similar (e.g. “display this” and “display that”). Rather, it addresses classes of requirements which form the same kind of problem to the system. The architecture provides solutions to these problems – let us call them concepts.

Here we find two of the most important quality criteria for software architecture:

• There should be only one concept for each problem.
• The concept should be appropriate and befitting the problem, i.e. it should be as lightweight and easy as possible.

Now, we have a definition for software architecture:

A software architecture provides an appropriate set of concepts as a solution to and befitting the functional and non-functional requirements of a system.

Architecture - a set of concepts

Let us look at an example to make this clearer: an application has to be build, which shall enable its users to input and store user complaints, which can also be displayed again later on. With this way of putting it, the requirements are roughly defined, and already group into classes of requirements since we don’t mention each single type of complaint but only talk generally about “user complaints”. Thus, our architecture has to provide concepts for the following problems:

1. Feature a GUI with possibility to input textual and structured data
2. Define data structure to memorize the “complaints”
3. Validate the data
4. Store the data persistently
5. Transport data between the GUI and the store
6. Read the data back from the store
7. Display complaints read from the store in the GUI

These concepts only address the functional requirements. Most probably, our architecture also needs concepts for non-functional aspects like:

1. Accessibility of the GUI for the users (e.g. with a web browser)
2. Failover functionality, in order to recover from failure
3. Transactions to prevent users to change the same data at the same time
4. Backups to recover from data loss

The longer one thinks about the issue, the more items may appear on the list. The bottom line here is: the architecture is defined through this list of concepts. But, all of these concepts have to be addressed anyway in order to make the application work. What can be influenced is how they are addressed, i.e. which concrete concepts are chosen to address the issues. This leads to one further insight:

There is no software system without architecture. What matters is: was the architecture chosen by chance or by a deliberate and controlled process?