Architects Architecting Architectures

For years, I have known developers who designed beautiful architectures. A lot of them are questioning the need for a software architect role.

It’s never too much to repeat – What I mean when talking about software architecture is: components, their responsibilities, and relationships.


This questioning may stem from a bureaucracy-intensive process, adopted by “diagrams-only” architects. Fortunately, it is not what I am talking about.

Team roles, work processes, and artifacts could (and should) be analyzed independently. Let’s see:

  • Team Role: Architect – A lot of organizations adopt a dedicated position responsible for the software architecture. Some architects DO WRITE CODE; others DO NOT. I have seen both fail and succeed.
  • Process: Architecting – There is no code when we are starting a new project. Right? There is a running system when the project is done. Between these two moments, we have a team performing some tasks. Some people will prefer to think about the entire system before to write any code. Some people, like me, will prefer to have an emergent architecture. Anyway, when the software is up and running it is impossible to determine which method was the adopted.
  • Artifact: Architecture – Just observing a running system, it is easy to infer a lot about the related architecture decisions (layers, collaboration model, persistence) – every software system has an architecture, even when that one was not properly designed.

So, let’s try to answer some questions:

Do we need someone with the “Software Architecture Role”? 

Sometimes yes, sometimes no! How big is the project? What is the domain complexity? What are the associated risks? The greater the design, complexity or risks, the more necessary will be the presence of an architect. Someone with experience and with some failing histories to share.

How should the architect behave?

Personally, I think the architect should behave as a maestroThe architect should listen to the team, customers, domain specialists, business people, and sponsors. The architect should make explicit the project strategy and ensure that the strategy is respected in all decisions.


What about the diagrams? Are they needed?

Yes! They are needed. The diagrams are communication tools. They are important to communicate the architecture to everyone.

Isn’t the code enough?

No, it’s not. Not every people knows how to read the code. The diagrams are not targeted only to the technical team. Like I said before, the diagrams are communication tools. Some diagrams are created before any code. Diagrams could express different levels of detail.

We do not have a software architect role. How to proceed?

For each project, it is a good idea to have someone – with experience – to perform this task. There are people defending architecting as a shared responsibility. I don’t believe in this.

Questions or comments? Let me know your opinion.



Compartilhe este insight:

Uma resposta

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

I believe that, from time to time, it is interesting to learn a new language or framework that takes us...
Dando continuidade a uma jornada iniciada há mais de 20 anos, comunico a fundação da Eximia! Trata-se de uma empresa...
Aqui, um registro da apresentação que realizei na abertura do IoT Weekend. O que você acha do que foi dito?
When designing systems that need to scale you always need to remember that using better resources could help you to...
Outro dia, meu amigo Giovanni Bassi compartilhou o seguinte tuíte: Ele e eu concordamos em discordar muitas vezes. Esta é...
07 de julho de 2016, aproximadamente 8:30 – Eu iria palestrar no TDC de São Paulo naquele dia. Aterrizamos em...
× Precisa de ajuda?