Software Architecture: Empathy is the Golden Rule
I'm a fullstack developer and my stack is includes .net, angular, reactjs, mondodb and mssql
I currently work in a little tourism company, I'm not only a developer but I manage a team and customers.
I love learning new things and I like the continuous comparison with other people on ideas.
If there is one element that distinguishes the great Software Architect from the merely experienced coder, it is not the mastery of the latest technology, but the capacity to deeply understand the people the system serves. True design is not a solitary technical exercise; it is an act of empathy toward the numerous stakeholders who are influenced—directly or indirectly—by our work.
This has been one of the most significant lessons I have learned: an architecture fails not only because of a bug or a bottleneck but because it fails to meet the needs and concerns of those who fund it, use it, or maintain it.
Who Matters: Mapping the Stakeholder Landscape
Identifying stakeholders is more than just making a list of names. It means understanding their interests, their decision-making power, and—crucially for us—how our architecture will impact their daily lives and the success of their work.
Stakeholders in a software project come in different types, and the architect must listen to them all:
Business Stakeholders: These are the people who define functional requirements and business constraints (Budget, Time-to-Market, ROI). Their language is that of profit and efficiency.
Technical/Operational Stakeholders: These are the developers, SREs, and DevOps personnel who must build, deploy, monitor, and maintain the system 24/7. Their concerns are maintainability, observability, reliability, and developer experience.
End-Users: These are the recipients of the product. Their needs focus on usability and performance. If the architecture is slow or insecure, they will be the first to suffer.
Constraints/Regulators: Legal and Compliance teams who impose non-negotiable requirements like GDPR, data security, or specific industry standards.
Reflection: In the past, I thought talking to the CTO was enough. Now I understand that if I don't talk to the DevOps team, I might design a system impossible to monitor or scale. If I ignore Legal, I might build an architecture that exposes us to penalties. Empathy, for the architect, means anticipating the problems of others.
Strategic Listening: Transforming Concerns into Requirements
The most delicate task is transforming the subjective concerns of stakeholders into objective architectural requirements. This process requires asking the right questions and not accepting superficial answers.
When a Business stakeholder says, "We need it to be fast!" the architect must reply: "What does 'fast' mean in measurable terms? Is a 500ms response time acceptable for 99% of requests? What is the cost if we fail at this?"
This process of questioning and specification brings to light the true architectural drivers (the critical quality attributes) and the necessary trade-offs.
Practical Example: Adopting a Document Database (MongoDB)
Let's imagine we need to propose the adoption of a new Document Database (MongoDB) for a product catalog management system, replacing a rigid relational DB. The goal is to support the rapid addition of new product fields and formats.
| Stakeholder | Initial Concern | Architectural Impact (Empathic Response) |
| Product Manager (Business) | "Does it work? How quickly can we add support for a new product type?" | Requirement: Agility/Time-to-Market. The strategy must highlight how MongoDB's flexible schema reduces the time needed for catalog modifications (no complex schema migrations needed), ensuring faster release of new features. |
| Development Team (Technical) | "We are used to relational JOINs. How do we manage references between documents without losing integrity?" | Requirement: Maintainability/Data Consistency. The architecture must provide clear embedding and linking document patterns. We might standardize the use of document-level transactions for coherence and define a Data Access Layer (Repository) that hides the complexity of relationship management. |
| DevOps/SRE (Operational) | "How do we handle sharding when the catalog grows? What about security (authentication, encryption)? We don't have much experience." | Requirement: Scalability/Security/Operability. The architecture must include a deployment plan (e.g., Replica Set) for high availability from the start, establish encryption policies (at rest and in transit), and define a proactive sharding strategy based on the expected read/write pattern, mitigating operational risk with specific training or the use of a DBaaS service. |
In this example, the architect doesn't just say: "Let's use MongoDB because it's NoSQL." but rather: "We are using MongoDB because its schema flexibility is the only way to achieve the catalog agility required by the Business. We will mitigate the data consistency risk for developers by defining strict data access policies, and we will address the operational risk by implementing a replica set and a proactive sharding plan."
This is the tangible proof that empathy is the true compass of architecture: it helps us navigate conflicting needs and justify technical choices in terms of human and business value. Successful architecture is not just what is built, but how and for whom it is built.
