Software architecture is a very simple concept that is intuitive to most engineers, even with little experience. At the same time, it is rather difficult to give a formal definition of this concept. In particular, it is difficult to draw a clear line between design and architecture, as architecture is one aspect of a project that focuses on very specific things.
“Architectural solutions are difficult to change” or, in other words, “Solutions that are difficult to change are architectural”. And that’s really what matters most.
How difficult it is to change a solution determines how architecturally it is. It is also important that any decision is easy to change the day after it is made, or it is easy to change a decision that has little impact. Moreover, in this case, a “solution” is both a software solution and just an agreement (which sooner or later is still fixed by a software solution).
At the code level, this can be expressed as follows: architectural code or software is the one that is reused the most times. And this is true both for the code written by you and for the borrowed one.
Example: The degree of architecture of a database is the amount of data it stores. That is, the more data you store in that particular database, the more architectural it is for you. On the other hand, a database connected to a project, in which nothing is stored or already, is not an architecture. At the same time, it is important to focus precisely on how difficult it is to change this base later. For example, if you need to change MySQL to PostgreSQL, the architecture of MySQL will depend on the number of its specific features that you used.
What is important to lay at the beginning of the project
Of course, at the beginning of any project, many architectural decisions are made: how to store data, which programming language to choose, which framework? But it’s also important to understand what can still be changed in the early stages of a project. And only over time, these solutions become a real architecture – one that is difficult to change.
From this perspective, not all initial decisions will seem so straightforward architectural. For example, choosing a programming language is clearly an architectural decision, because changing it is almost tantamount to rewriting a project from scratch. And the choice of a key-value database is not a very fundamental decision, since there are many such databases and you can replace one with another much easier and more invisibly. It is not difficult to do this before the project is released into production.
Very often the philosophy dominates in new projects: “We need to do everything right from the very beginning, because then we will not have time to change something”. This is true because all the time is spent getting things right, not making adjustments along the way, which is the essence of the Agile process.
Building an architecture from your own code in long-running projects is very important. It all starts with simple code reuse: someone wrote a class or method and someone used it. The first good sign that you can do this is if the method you wrote is used by other members of your team without coercion. This suggests that it is easier for them to rely on your code as an architecture than to create something from scratch.