Software Architect

The stakeholder in charge of Software Architecture.

Mindset
The architect:

carefully considers trade-offs oriented by software characteristics;

The architect knows that every decision is good and bad, and chooses the least worst
architecture by considering context;
understands that, on architecture, why is more important than how;
works collaboratively with other stakeholders - other architects, developers, managers and
even customers - towards the same goal: good architecture
The architect is responsible for bonding those parties and orienting them towards the
same goal

Responsibilities
To decide on architectural concerns
The most obvious responsibility. Not everything requires an (often expensive and time-
consuming) architectural decision, though. We don't want to over specify or to practice Big
design upfront. Decisions on local topics such as programming languages or frameworks are
better left to the development team, since those concerns barely scratch architectural concerns.

A more relevant part of the job consists on assessing Software Architecture > Trade-offs,
choosing what's best given what we know so far. Every choice will bring positive and negative
impact. This requires business knowledge, technical breadth and extensive discovery, since
Software Architecture characteristics are hugely contextual and can only be properly guided by
enterprise goal.

To live their architecture

As is the case with most things human beings get to touch, architecture needs management.
The architect is in charge of preventing natural long-term decay induced by poor practices and
lack of supervision. Decisions are nothing but words, and they won't be respected if no one
cares for them anymore.

Essentially, to ensure the architecture is performing well (and to constantly tune it, because
Architecture is organic), the architect must live and breathe their creation. Is tested code being
deployed often? Are developers complaining about architecture decisions? Why? Do they
understand the architect's motivations?

If the current architecture does more harm than good, there's no point on respecting it. The
architect needs feedback on the architecture, and living it along with the development team is
the most realistic way of discovering its weaknesses and virtues to ensure it is being properly
applied.

To keep up with technology

To decide on architectural concerns, one needs technical breadth. The architect shall keep up
with shiny new possible solutions to enterprise problems, and constantly hone their
fundamental practices. They aren't necessarily experts in everything, but they know a wide
range of technologies. Most often, the architect's answer to "do you know technology X?" is
"I've briefly played with it".

Getting too attached to the past is as dangerous as ruthlessly implementing the brand-new
JavaScript framework that gets released every day. The same principle applies to old problems
that are unlikely to happen again ("the frozen caveman", who wakes up in the 21st century and
develops a Bluetooth enabled dinosaur alarm).

To communicate with impact

The architecture role is a unique position in that it directly interacts with many other positions,
of varying technical expertise. An architect must be geeky enough when talking to developers,
and political enough to navigate upper management (or even C-level executives).

Architecture decisions often face resistance, especially from business stakeholders or managers
unable to naturally understand the value of technical structure. Instead of complaining, it's the
architects' role to articulate and propagate the relevance of their work. Pragmatism is key when
convincing many different people into buying the same idea, working towards the same goal.