Você não é (ou, pode não ser) arquiteto de software. Saiba o porquê (e aceite isso)

A publicação original desse post ocorreu em meu blog, em 2011, e gerou uma bela discussão. Infelizmente, essa publicação não está mais disponível. Depois, foi publicado no linkedin gerando mais uma bela discussão. Penso que o conteúdo continua válido e, por isso, reproduzo aqui.

A publicação de hoje mostra minhas considerações sobre os papéis de arquitetura e desenvolvimento. Nessa posição, sou extremista (embora acredite que toda verdade extremista é fraca): arquitetos são arquitetos, desenvolvedores são desenvolvedores.

Vamos aos fatos…

O que é arquitetura?

Todo software possui uma arquitetura. Boa ou ruim, ela está presente. Planejada ou não, ela se forma, consiste e persiste. Ela pode estar “escondida”, mal-entendida, corrompida, vilipendiada, ignorada ou, até mesmo, esquecida. Mas está ali.

A arquitetura de um software pode até não estar descrita em documentos formais, representada em diagramas ou quaisquer outros tipos de artefatos. Mesmo assim, se há um software, há uma arquitetura.

A arquitetura é a expressão máxima das principais decisões relacionadas a um software. Ela contempla o conjunto de propriedades e comportamentos essenciais do software. Ela explicita o escopo fundamental do sistema.

A arquitetura é a visão fundamental do sistema. Mais que isso, ela define o sistema.

Em software, não há “visão do todo” sem profunda compreensão da arquitetura. Arquiteturas ocultas ou mal evangelizadas implicam em sistemas ruins e cheios de partes “descartáveis”. Um sistema com arquitetura “oculta” é um Frankenstein, uma colcha de retalhos, um pesadelo para o time, um pesadelo para todos os interessados.

A arquitetura de um software consiste de sua estrutura mais fundamental que são, por razões evidentes, praticamente imutáveis. Todo sistema possui uma estrutura fundamental, logo, todo sistema possui uma arquitetura.

Ao observar qualquer software, podemos identificar seus componentes principais -comportamentos e papéis. Além disso, conseguimos enxergar como esses componentes se relacionam com os outros componentes. A esse conjunto rico de informações chamamos arquitetura.

Sumarizando, a arquitetura de um software é descrita através da elucidação de seus componentes fundamentais – seus comportamentos, papéis e relacionamentos. É essa “visão” do todo – sem detalhes, sem internals desses diversos componentes, comportamentos e dos seus relacionamentos – que representa as decisões fundamentais de um software.

Toda arquitetura de sistema pode ser explicitada

Explicitando a arquitetura de um sistema

Fica claro e evidente que a arquitetura está presente em qualquer sistema. Entretanto, como identifica-la. Em outras palavras, como tonar a arquitetura de um sistema evidente?

Façamos um exercício simples:

  • Pense no sistema que está trabalhando agora;
  • Enumere as partes/componentes fundamentais desse sistema.
    • Primeiro em sentindo horizontal. Pense nos módulos de seu sistema (chamo-os, também, componentes);
    • Depois, em sentido vertical. Considere todos componentes que dão “sustentação” aos módulos (persistência, interface com usuário, regras de negócio, monetização);
  • Descreva, mesmo que superficialmente, as principais atribuições e comportamentos de cada componente;
  • Identifique as relações entre esses módulos e componentes;
  • Vá para um quadro branco…
  • Desenhe uma caixa para cada componente, começado do alto para baixo, na seguinte sequência;
    • Interface com o usuário ou sistemas externos;
    • Serviços (server side) e APIs expostas;
    • Módulos de seu sistema
    • Componentes de negócio compartilhados entre os diversos módulos;
    • Componentes de infraestrutura;
  • Desenhe setas ligando essas caixas para representar as relações mais importantes;
  • Elimine o que parece excesso. Generalize e não se prenda a especificidades de tecnologia.

De forma básica, garanta que sua estrutura tenha, pelo menos, uma descrição básica de componentes e relações semelhantes ao template que indico a seguir:

Esse modelo é útil para arquiteturas que estejam fundamentadas em camadas. Sinta-se a vontade se precisar criar representações alternativas (há patterns diferentes para representar arquiteturas diferentes).

Uma arquitetura devidamente explicitada facilita a comunicação com o grupo. Pratique esse exercício, compartilhe com seu time o resultado e verifique seus feedbacks.

Toda arquitetura pode e deve ser planejada

Não podemos confundir arquitetura emergente com anarquia arquitetônica. Em qualquer momento, o time precisa ter condições de descrever sua visão da estrutura fundamental de um projeto. Uma boa arquitetura dificilmente será obra do acaso. Uma boa arquitetura é resultado de um planejamento cuidadoso.

Não há razão para repetir velhos enganos. Mesmo trabalhando em uma área de conhecimento relativamente recente, há milhares de exemplos e experiências de projetos bem-sucedidos que podem servir como modelo para formação de uma boa arquitetura.Se há design patterns, há também patterns arquiteturais.

Construir e consolidar uma boa arquitetura colabora com o talento do time de desenvolvimento para uma definição mais clara das tecnologias que serão empregadas em cada componente. Uma boa arquitetura permite que seja selecionada a melhor tecnologia para cada escopo.

A definição dos componentes – seus papéis, comportamentos e relacionamentos – permite que o time perceba, o mais cedo possível, as entradas e saídas esperadas por cada componente, bem como oportunidades de generalização e reaproveitamento.

A construção de frameworks corporativos (entenda-se: componentes com alta possibilidade de reuso em novos projetos) é consequência de uma visão arquitetônica coerente. É comum que projetos sendo desenvolvidos em paralelo em uma corporação necessitem de componentes semelhantes.

Arquitetura não está relacionada DIRETAMENTE a atividade de desenvolvimento

Arquitetura não está relacionada diretamente a desenvolvimento

Pelo descrito, a arquitetura de um sistema nasce junto com o plano de como implementar esse sistema.

Repare que falo todo o tempo em componentes – papéis, comportamentos e relacionamentos. Não falo de classes, instâncias ou gestão de dependências. Logo,patterns para arquitetura não estão relacionados diretamente com patterns de design.

Arquiteturas emergentes decorrem da necessidade de ajustar componentes ou seus relacionamentos. Novos componentes surgem, ou componentes inicialmente percebidos como importantes perdem relevância. Relacionamentos ficam evidentes (junto com suas demandas), ou perdem seu propósito devido a uma melhor compreensão do domínio. De qualquer forma, isso ocorre durante o desenvolvimento e não por causa do desenvolvimento.

Arquitetos, geralmente, são (ou foram) bons desenvolvedores

Desenvolvimento de software é uma atividade relativamente recente e, por consequência, imatura. Mesmo com toda a relevância da arquitetura de software, poucos são os projetos que têm um desenvolvimento arquitetônico conduzido de forma coerente.

Na maioria dos casos, conta-se com a expertise dos desenvolvedores mais experientes que, por feeling e arrogância, tomam para si algumas atividades arquitetônicas. Infelizmente, o que temos na prática, na maioria dos casos, é a aplicação do mais do mesmo (até quando o “mesmo” não é o mais adequado).

Alguns desenvolvedores, geralmente com maior senioridade, percebem e valorizam a importância do projeto arquitetônico. Esses mesmos desenvolvedores percebem e evidenciam a necessidade de desenvolver competências distintas daquelas que já possuem visando maior efetividade e retorno.

Esses mesmos desenvolvedores acabam participando ativamente dos trabalhos de implantação e identificam rapidamente eventuais desvios (deterioração ou erosão arquitetônica) fazendo os ajustes necessários. Entretanto, que fique evidente: são desenvolvedores que também são arquitetos. Competência para arquitetura é distinta e isolada da competência para desenvolvimento.

Bons desenvolvedores não são, necessariamente, arquitetos

Todo software têm uma arquitetura definida. Fato!

Arquitetura pode ser, ou não, planejada. Fato!

Nem todas as empresas têm arquitetos (não estou falando de cargo, estou falando de alguém com competência para a atividade). Fato!

Toda empresa que faz software, possui desenvolvedores (mais ou menos qualificados). Fato!

Desenvolvedores não têm, necessariamente, habilidade para trabalhar arquitetura. Fato!

Você pode ser um excelente desenvolvedor (sênior até) e, mesmo assim, ter enorme dificuldade para identificar e planejar componentes – seus papéis, comportamentos e relacionamentos. Por quê? Porque nem todo desenvolvedor tem as competências (conhecimentos + habilidades + atitudes) para “desenvolver” arquitetura. Simples assim!

Enfim…

Pode ser que você seja um bom arquiteto e também um bom desenvolvedor. Parabéns para você!

Pode ser que você seja um bom arquiteto e seja um desenvolvedor bem ruinzinho (é raro, mas acontece!). Parabéns para você, também!

Talvez você seja um ótimo desenvolvedor, e não seja um arquiteto. Parabéns para você (com todo o meu respeito)! Se for uma opção, então, fantástico! Você deverá ser feliz com sua decisão.

Arquitetos fazem arquitetura. Desenvolvedores, não! São atividades diferentes, importantes, e com competências necessárias distintas.

Quer ser um arquiteto, estude para ser arquiteto. Não é o mesmo que estudar desenvolvimento.

Compartilhe este insight:

7 respostas

    1. Já vi acontecer, um colega de trabalho, começou como estagiário na equipe de arquitetura, sem conhecer muito de desenvolvimento. E com o dia a dia de arquitetura, aprendeu (com os mais experientes) desenvolver muito bem.

  1. Elemar,
    Na serra gaúcha, qual é a faixa salarial de um arquiteto de sw?
    Na internet existem informações muito discrepantes… nada melhor que alguém como você para responder 🙂

  2. Sou desenvolvedor senior e me identifiquei muito com esse post. Porém, por opção, se quero ser um arquiteto, tenho que estudar para me tornar um. E, acredito que a experiência que tenho como desenvolvedor irá me ajudar e muito nessa empreitada.

    Você recomenda algum livro sobre a arquitetura de software?

  3. Tenho 10 anos de experiência em desenvolvimento, e agora faço parte do time de arquitetura, tenho sentido a diferença que o texto apresenta. Realmente não é a mesma coisa, e exige muito estudo. Porque, hoje tenho que ver um sistema, não apenas no aspecto de desenvolvimento, mas também segurança, confiabilidade, extensibilidade, além de tomar decisões que afetam não apenas um determinado sistema mas todos sistemas da empresa onde trabalho.

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:

Um servidor de identidades é um artefato de sofware que centraliza os dados de usuários, bem como o processo para...
Tentando ser “Júnior” Minha carreira como amador remunerado em programação começou em 1992. Eu tinha quase 13 anos e era...
The example which motivated this post comes from the excellent book Designing Distributed Systems by Brendan Burns (co-founder of the...
As an experienced .NET developer, you have to deal with NullReferenceException occurrences every day. Am I right? I firmly believe...
Na vida, todos temos “momentos traumáticos”. Ou seja, aqueles momentos que, de repente, mudam tudo e, ao mesmo tempo, de...
Tentando ser “Júnior” Minha carreira como amador remunerado em programação começou em 1992. Eu tinha quase 13 anos e era...
× Precisa de ajuda?