Behind every architecture there are people who make decisions, communicate them, and ensure they are followed. The software architect is that bridging professional between business and technology, between the overall vision and the concrete code. Yet it is one of the least understood roles in the industry: sometimes it is confused with that of a senior programmer, other times with that of a manager who draws diagrams and disappears. In this lesson we clarify what an architect really does, what types exist, what skills they need—both technical and soft—and how the role differs from that of a tech lead, a distinction that causes a great deal of confusion in teams.

1. What a software architect is and does
2. Main responsibilities
3. Types of architect
4. Technical skills
5. Soft skills
6. Architect versus tech lead

A software architect is the person responsible for the significant technical decisions of a system: those that affect its structure, its quality attributes, and its ability to evolve. It is not someone who merely draws diagrams on a whiteboard and delegates everything else; the best architects stay close to the code and the teams.

A useful distinction is Martin Fowler's between two archetypes:

The industry has evolved toward the second model: the architect as facilitator and mentor, not as an isolated technical dictator.

Responsibilities vary by organization, but these are the most common:

• Define the system's structure: styles, patterns, and boundaries between components.
• Manage quality attributes: ensure that performance, security, scalability, and so on are met.
• Make and document decisions: and, above all, record the why (with ADRs, which we will see later).
• Evaluate technologies: run proofs of concept, compare alternatives, manage risks.
• Communicate the architecture: to developers, managers, and business stakeholders, adapting the language to each audience.
• Mentor the team: raise the collective technical level rather than concentrating knowledge.
• Watch over consistency: verify that the implementation respects the decisions (lightweight governance, not code police).

A good motto: the architect is not the one who has all the answers, but the one who asks the right questions and helps the team answer them.

The title "architect" covers very different roles depending on scope and focus. It is worth knowing them so you know who you are talking to in each conversation.

This Mermaid diagram (graph TD, top-down) shows how the enterprise architect operates at the broadest level and the other roles operate in more limited domains. The arrows indicate a relationship of scope/coordination, not a strict chain of command: in many organizations these roles collaborate as equals with different focuses.

An architect must maintain a solid and broad technical foundation. They do not need to be the best programmer on the team, but they do need to understand deeply what they decide.

• Breadth over depth: they know many technologies well enough to evaluate them, even if they do not master them all in detail. This is the "T-shaped" profile: much breadth and at least one area of deep specialization.
• Architectural patterns and styles: layers, hexagonal, microservices, events, etc.
• Quality attributes and how to achieve them: caching, load balancing, replication, partitioning.
• Data knowledge: relational and non-relational modeling, consistency, transactions.
• Fundamentals of networking, security, and deployment.
• Ability to prototype: build a proof of concept to validate a decision before committing.

This Java snippet illustrates a technical decision typical of the architect: defining the PaymentGateway interface (a port in hexagonal architecture) so that the rest of the system does not depend on a specific provider. The StripeGateway class is one implementation that can be replaced by another (for example, RedsysGateway) without touching the business logic. The architect does not necessarily write all the code, but they do validate that the abstraction is correct and that the team understands it, possibly building this minimal prototype themselves.

This is where many technically brilliant architects fail. Soft skills are not the "soft" part of the role: they are its core.

• Communication: explaining the complex simply, tailoring the message to developers, managers, or clients.
• Negotiation and trade-off management: hardly any decision is perfect; you have to negotiate among interests and constraints.
• Active listening: the best ideas often come from the team working in the code day to day.
• Leadership through influence: the architect rarely has direct hierarchical authority; they persuade, they do not command.
• Strategic thinking: connecting technical decisions to business goals.
• Tolerance for ambiguity: deciding with incomplete information and under uncertainty.

A practical rule: an architect spends more time in conversations and explanatory diagrams than writing perfect UML diagrams. Architecture that no one understands or adopts is worthless.

This is one of the most common points of confusion. Both roles can be held by the same person, but conceptually they are distinct.

In small teams, one person plays both roles. In large organizations, they are usually separated: the architect defines the "what" and the structural "why"; the tech lead ensures the "how" and the "when" within their team. What matters is that they collaborate closely, because an architecture without someone overseeing its daily execution dissolves, and a tech lead without architectural vision accumulates debt without realizing it.

• The "ivory tower architect." Designing in isolation, without touching the code or listening to the team, produces architectures that look nice on paper but are unworkable in practice. Keep one foot in the code.
• Confusing authority with influence. The architect persuades with arguments and data, not by imposing through hierarchy. Imposing generates resistance and architectures that the team passively sabotages.
• Neglecting soft skills. Technical excellence without communication is a half-architect.
• Not documenting the why. Decisions without context get questioned over and over. Document the reasoning.
• Tip: specialize but keep breadth. Cultivate the T-shaped profile. Go deep in one area, but understand enough of the rest to decide with good judgment.

Exercise 1. In an 8-person startup with a single development team, would you separate the architect and tech lead roles? Justify your answer.

Exercise 2. Match each task with the most appropriate type of architect: (a) designing the integration between a client's HR system and payroll system; (b) defining the company's data retention and quality policies; (c) choosing the internal pattern of a microservice; (d) charting the company-wide 3-year cloud migration roadmap.

Exercise 3. An architect proposes migrating to microservices and the team resists. Without using hierarchical authority, list three concrete actions based on soft skills to achieve adoption.

Solution 1. It is probably not advisable to separate them formally: with 8 people and a single team, maintaining two distinct roles adds bureaucracy. The sensible approach is for one person to play both (or for architectural responsibilities to be shared within the team), reserving explicit time to think about structure and not just immediate delivery.

Solution 2. (a) Solutions architect. (b) Data architect. (c) Software architect. (d) Enterprise architect.

Solution 3. Valid examples: (1) Actively listen to the team's objections to understand the reason for the resistance (fear of operational complexity? lack of experience?). (2) Build a small proof of concept together so the team can see advantages and drawbacks with real data, not with theory. (3) Communicate the business problem to be solved (for example, scaling only the most heavily loaded module) instead of imposing the solution, letting the team participate in the design and take ownership of the decision.

We have seen that the software architect is responsible for the significant technical decisions, that there are various types depending on scope (software, solutions, enterprise, data, infrastructure), and that their success depends as much on technical soundness as on soft skills, especially communication and leadership through influence. We have also distinguished their role from that of the tech lead. That said, much of the architect's work consists of guaranteeing certain properties of the system beyond functionality: in the next lesson we will study quality attributes and non-functional requirements, the raw material on which the architect bases their decisions.