Skip to content
Software Architecture Guide

Role of the Software Architect

Explanation

Section titled “Explanation”

A software architect is responsible for meeting the requirements and creating the architecture design of a solution. This work sits within the overall project responsibility.

What the architect decides

Architecture means the “big decisions”: how the software is structured, which frameworks and technologies it uses, and which patterns it follows. It also covers how functional and non-functional requirements are met. Architects decide how to split the system into building blocks. They also decide on cross-cutting concerns, such as persistence, communication and the user interface.

Architectural work should be driven by the need to achieve or improve specific qualities. See the article Quality Attribute.

Making decisions visible

Architects make, justify, communicate and document their decisions in a systematic way. They coordinate refinements of requirements with stakeholders. They also describe the architecture through views that address stakeholder concerns. See Architectural Decision and Architecture View.

Leadership

One author argues that the most basic responsibility is technical leadership of the teams the architect works with. Within their defined scope, the architect is the final arbiter of architectural decisions, and developers are bound by them. Even so, architects should keep solo decrees to a minimum and rely on consensus.

Technical expertise is necessary but not enough. Nobody can be an expert in everything. Architects therefore also need interpersonal communication and consensus-building skills.

Hands-on, not ivory tower

Good architects keep their coding and delivery skills sharp. They mentor the team and listen to developers. The industry still often sees architects as “ivory tower” figures who offer little practical value or act as roadblocks. Fowler and Hohpe call the setup where architects define in a penthouse how developers build an anti-pattern, because it lacks feedback. Architects should be involved in, and accountable for, delivery.

Role versus title

One view holds that most of what architects traditionally did should be done by developers, by tools, or not at all. So the role matters more than the job title.

Example

Section titled “Example”

A team builds an online booking system. The architect splits it into building blocks and picks how they communicate. They write down why, and show the decisions to stakeholders in simple views. They sit with developers, write some code themselves, and listen to concerns. When the team disagrees, they seek consensus first. They make the final call only inside their agreed scope.

Trade-offs

Section titled “Trade-offs”

Final authority gives clear direction, but heavy use of solo decrees weakens team buy-in, so consensus is preferred. Staying hands-on keeps decisions practical and costs time that could go to wider coordination. Tools and developers can take over much traditional architect work, so the role can be shared rather than held by one titled person.

Checks

Section titled “Checks”
  • Architectural decisions are documented together with their justification.
  • The architect’s scope of decision authority is defined.
  • The architecture is described in views that address stakeholder concerns.
  • Cross-cutting concerns such as persistence, communication and GUI have an explicit decision.
  • Architectural activities trace back to specific qualities to achieve or improve.
Section titled “Related”

Sources

Section titled “Sources”