# Definition
Software architecture is not simply "making a box with arrows." It is the highest-level design of a system's structure. It comprises software elements, their relationships, and the properties of both.
In other words, architecture is about the decisions that are hard to change. Those that, if made wrongly at the beginning, will cost a lot of money and time to correct later.
# Architectural Drivers
What motivates an architecture? We don't design on a whim, but to satisfy needs. These needs are divided into two main groups:
Functional Requirements
What the system does. The tasks, services, or functions it must perform for the end user.
- Process a payment
- Generate a report
- Send a notification
Quality Attributes (Non-Functional)
How the system behaves. These are the characteristics that define the quality of the experience.
- Scalability: Does it support more users?
- Availability: Is it always online?
- Security: Are the data protected?
# Quality Attributes Detail
-
Performance: Focuses on efficiency and response times to stimuli or workload.
-
Scalability: Guarantees that the system can handle a significant increase in load without degrading its service.
-
Availability: Measures the proportion of time that the system is operational and accessible to the user.
-
Security: Protects the integrity, confidentiality, and availability of data against threats.
-
Maintainability: Defines how easy it is to correct errors or evolve the code given new requirements.
-
Usability: Ensures that user interaction with the system is intuitive and efficient.
-
Reliability: Guarantees that the system works correctly and consistently under specific conditions.
# Structures and Views
A software system is too complex to be seen from a single angle. That's why we use different structures:
-
Module Structure: How the code is organized (in packages, classes, layers). Focuses on maintainability.
-
Components and Connectors: How the parts interact at runtime (services, databases). Focuses on performance and availability.
-
Allocation: How the software maps to hardware or work teams.
# Measurements and Metrics: What isn't measured, doesn't improve
In the world of architecture, metrics are not just numbers; they are the evidence that supports our technical decisions. Measuring allows us to transform subjective perceptions (like "the system feels slow") into objective and actionable data.
Observability and Monitoring
It is not enough to know if the system is "alive." We need to understand its internal state. This includes Telemetry (Logs, Metrics, Traces) to detect bottlenecks before they affect the user.
Key Technical Metrics
- Throughput: Number of transactions per second that the system processes.
- Latency: Time it takes for a request to be processed (p95, p99).
- Error Rate: Percentage of requests that fail over the total.
In addition to performance metrics, we evaluate Technical Debt and Coupling. High coupling indicates that changing one piece will break ten others, which reduces delivery speed (Time to Market).
Define the availability commitment to the business.
Simulate extreme conditions to find the breaking point.
Measure the operational efficiency of the engineering team.
# Communicating Architecture (Documentation)
Documenting is not "writing for writing's sake." It is a communication tool to align teams and preserve the Context of Decisions. An architecture without documentation is a black box that no one dares to touch.
Why do we document?
Alignment
So that all developers row in the same technical direction.
Knowledge Transfer
Facilitates onboarding of new members to the team.
Analysis
Allows evaluating the impact of changes before writing a single line of code.
terminal ADRs and Living Diagrams
Today, we avoid 200-page static documents. Instead, we use ADRs (Architecture Decision Records): short, versioned logs explaining why we chose one technology over another. We complement this with C4 Diagrams (Context, Containers, Components, Code) which allow "zooming" into different abstraction levels of the system.
# Conclusion
Software architecture is the bridge between business requirements and technical implementation. An architect is not just someone who knows how to program, but someone who knows how to balance "trade-offs" (concessions): to gain scalability, perhaps simplicity must be sacrificed.
The Golden Rule
"Everything in software architecture is a trade-off. If someone tells you that a solution has no disadvantages, they probably haven't found them yet."