Oh My Learning

Role of the Software Architect

fundamentals/02 senior drafted · 4 min read

Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapter 3

Prerequisites fundamentals/01

Role of the Software Architect#

TL;DR#

The software architect's role balances technical leadership, team mentoring, architecture governance, and stakeholder communication. It requires staying hands-on while shifting focus from code details to systemic structures. Effective architects guide and align teams rather than acting as tech dictators.

The idea#

Systems fail when uncoordinated teams make conflicting technical decisions. Developers focus on their immediate components, which can lead to architectural drift, integration issues, and technical debt. The software architect role exists to maintain a cohesive technical vision across the organization.

An architect translates business goals into concrete system qualities. They ensure the system remains maintainable, scalable, and secure, while directly supporting the team's ability to deliver features.

How it works#

The architect's role spans four primary pillars: technical vision, automated governance, coaching, and stakeholder communication.

+------------------------+------------------------+
|   TECHNICAL VISION     |       GOVERNANCE       |
| Define styles, tools,  | Automate checks, lint, |
| and trade-offs.        | fitness functions.     |
+------------------------+------------------------+
|      MENTORSHIP        |     COMMUNICATION      |
| Coach developers, run  | Bridge business goals  |
| brown-bag sessions.    | and technical teams.   |
+------------------------+------------------------+

The Coding Balance#

Staying hands-on is essential. If an architect stops writing code, they enter the "ivory tower" trap. They start proposing designs that look beautiful on a whiteboard but are impossible or painful to implement in reality.

To stay grounded, architects should: - Write prototypes and proof-of-concept designs. - Tackle technical debt or refactoring tasks that are not on the critical path of feature delivery. - Pair-program with developers on difficult bugs or complex integrations.

Architecture Governance#

Adherence to architectural decisions must be verified, but manual code reviews do not scale. Instead, modern architects use automated governance. They write architecture fitness functions, which are automated tests that run in the CI/CD pipeline to verify structural rules.

For example, a fitness function might assert that no class in the controller layer can import database drivers directly.

Worked Example: Resolving a Data Conflict#

Consider a scenario at Sysops Squad where a billing system is being built.

The Context: - The development team wants to use MongoDB because it allows fast schema changes. - The finance team demands ACID transactional safety to prevent lost or double-counted payments.

The Architect's Action: - The architect does not simply pick a side. - They set up a workshop to discuss the trade-offs of both options. - The architect explains that the domain has two distinct sub-domains: payment ledger (requires strict ACID transactions) and payment invoice attachments (requires flexible schema storage). - They decide to split the data: PostgreSQL for the ledger and MongoDB for the invoice files. - The architect writes an Architecture Decision Record (ADR) documenting this choice and its trade-offs. - They write an automated check in the build pipeline to ensure the payment ledger code never references MongoDB drivers.

Pros#

  • Cohesive technical vision prevents systemic architectural decay.
  • Automated governance catches structural violations early in the development loop.
  • Strong technical mentoring improves developer skills and grows new leaders.

Cons#

  • Keeping up with broad technical trends requires constant study and time.
  • Context-switching between code, meetings, and business discussions can be exhausting.
  • The role carries significant responsibility for system failures, but successes are often attributed to feature delivery.

Alternatives#

  • Fully autonomous teams: Each team has complete technical freedom. This works well for small, decoupled startups but creates chaotic integration issues in larger systems.
  • The Ivory Tower model: The architect writes detailed specification documents in isolation and hands them off to engineers. Developers usually ignore these documents because they fail to handle real-world edge cases.

When to use it#

  • When multiple development teams must collaborate on a single system.
  • When technical choices have long-term operational or financial impacts.
  • When a company needs to align its software with evolving business strategies.

When NOT to use it#

  • Small, single-team startups where a lead developer can easily hold the system design in their head.
  • Simple, short-lived projects with zero scaling or maintenance requirements.

Key takeaways / mental model#

The architect is a guide, not a dictator. Staying hands-on keeps you practical, while automated governance allows you to scale your influence across multiple teams without micromanaging.

Self-check questions#

  1. What is the danger of an architect who stops coding completely?
  2. How can an architect enforce technical decisions without manual code reviews?
  3. Why are interpersonal and political skills as important as technical skills for an architect?

References#

  • Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapter 3