Robert C. Martin mentions in his book “Clean Architecture” about such division that architecture is a high-level matter, and the project is about details and lower-level matters. An architect does the architecture, and programmers do the project. Going further, one can risk saying that an architect is a nobleman above programmers.
Reality is more moderate. Architecture and projects are the same. An architect is also a programmer, often the best, who leads the team in the intended direction. The architect still writes code, certainly less than before, but must continue to do so to stay in the game and be able to talk technically with programmers.
Every system consists of high-level decisions and low-level details. This is inseparable. It is very important that the system is created in cooperation between architects and programmers, not in isolation.
Think of designing a house where the architect designs almost every element from the shape, appearance, and layout of rooms to where the sockets should be located. These are high-level decisions.
When the architect is no longer there at the construction stage of such a house, the investor can decide exactly what these sockets should be or what color the walls are. These are low-level details.
So what is this architecture then?
Let’s analyze another well-known division. The division of the system into values:
- how the system should work, what it should do (behavior)
- how easily this system can be changed (architecture)
From the above division, it can be inferred that architecture describes how easily a given system can be changed. This boils down to architecture defining the cost of change, the cost of the entire system, and the amount of work needed to implement it.
Therefore, architecture describes a system aimed at minimizing the work required to implement and maintain the system.
Architecture Goal
The goal of the architecture is to preserve open possibilities for as long as possible. Architecture focuses on high-level decisions, not frameworks, databases, communication protocols, and tools. The architecture aims to establish rules allowing for the implementation of business requirements. Architecture focuses on rules, not details. The objective of good architecture is to facilitate:
- implementation of use cases
- system deployment
- system maintenance and upkeep
- further development of the system
- easy change of previously made decisions
Components of architecture
Architecture can be divided into several components:
- Architecture characteristics (also known as quality attributes) are the criteria for the system’s success, e.g., scalability, observability, performance, and availability.
- Architectural decisions – decisions that determine how the system should operate.
- Design principles – differ from architectural decisions in that they are guidelines for how something should be implemented. They are not hard rules like architectural decisions.
Summary
If you were to remember one sentence from this text, remember this:
Architecture is a description of a system, and architecture aims to minimize the effort needed to deploy and maintain that system. Good architecture makes working on software easier and keeps options open for as long as possible.
If you want to delve deeper into the issues described in this article, please read the books linked to the sources below. Buying through these links will also support my blog/newsletter.
Sources
- Clean Architecture: A Craftsman’s Guide to Software Structure and Design – Robert C. Martin
- Fundamentals of Software Architecture: An Engineering Approach. A Comprehensive Guide to Patterns, Characteristics, and Best Practices – Neal Ford , Mark Richards
