O papel do Arquiteto de Software | Fundamentos de Arquiteto de Software | Parte 04

O papel do arquiteto de software

Visão geral da seção: Nesta seção, o palestrante discute a importância do arquiteto de software e como ele é fundamental para manter a integridade dos componentes adicionados à solução.

A importância da arquitetura de software

• A arquitetura de um software pode ser explicada pelos componentes que compõem o sistema, suas responsabilidades e a forma como eles se relacionam.

• É fundamental ter uma estratégia clara e padrões coerentes que governem as tomadas de decisão com relação ao software.

O papel do arquiteto de software

• Embora o papel do arquiteto seja provavelmente muito importante, não é necessariamente indispensável.

• Muitas aplicações seguem uma receita padrão bem-sucedida sem um arquiteto explicitamente designado.

• À medida que mais componentes são adicionados à solução, torna-se mais difícil manter a integridade desses componentes. Surge a necessidade do arquiteto para garantir isso.

Exemplo comum de progressão da arquitetura

• Na maioria das empresas, existe uma progressão comum na implementação da arquitetura.

• Começa com um front-end implementado em alguma tecnologia moderna, um back-end implementado com .NET ou algo similar e um banco de dados relacional.

• Em algum momento surge a necessidade de implantar uma solução de caching ou banco de dados full-text para consultas mais poderosas.

• Eventualmente, há também a necessidade de sincronização entre os bancos relacional e full-text.

• Se precisar trabalhar com grandes montantes de dados, é necessário implantar alguma rotina mais sofisticada de integração.

• Em algum ponto, alguma requisição do usuário pode precisar de um processamento mais extenso e se adota algum mecanismo de mensageria.

A necessidade do arquiteto

• À medida que mais componentes são adicionados à solução, torna-se mais difícil manter a integridade desses componentes.

• Surge a necessidade do arquiteto para garantir isso.

O papel do arquiteto de software

Visão geral da seção: Nesta seção, o palestrante discute o papel do arquiteto de software e como ele é diferente do desenvolvedor sênior.

Arquitetos experientes são referências para a arquitetura

• Arquitetos experientes são referências para a arquitetura.

• Eles já participaram de muitos projetos e viram soluções arquiteturais serem implantadas várias vezes.

• Eles conseguem traçar uma relação entre o problema que a organização está enfrentando e uma solução natural que já foi implementada no passado.

O arquiteto não é necessariamente um desenvolvedor sênior

• O fato é que o arquiteto de software é responsável por perceber formas padrões para relacionar componentes, responsabilidades, relacionamentos e formular estratégias para atender aos objetivos do negócio.

• O arquiteto não é um desenvolvedor sênior. A maioria dos bons arquitetos de software são excelentes desenvolvedores, mas essa não é necessariamente uma regra.

Arquiteturas geralmente são implementadas por desenvolvedores seniores

• As arquiteturas geralmente são implementadas por desenvolvedores seniores que usam a experiência do passado para criar soluções arquiteturais no presente.

• Essas soluções costumam ser eficientes para tratar dos objetivos do negócio, mas pobres no cumprimento dos atributos de qualidade e das principais restrições.

O arquiteto é um orquestrador

• O papel do bom arquiteto é atuar como um maestro, juntando as competências do time para compor uma bela arquitetura.

• Ele deve chamar os especialistas para discutir a solução arquitetural e ouvir os imputs do time para começar a projetar a solução.

• O arquiteto deve conhecer boas arquiteturas e saber recorrer a essas referências para conseguir construir uma nova implementação com o apoio do time.

Arquitetura de software não é uma atividade solitária

• Arquitetura de software não é atribuição direta do arquiteto. Ele é um facilitador para o processo da arquitetura.

• O fato do arquiteto ser um orquestrador, um facilitador, torna-o tão importante.

Arquitetura de Software: Como se Tornar um Arquiteto

Visão Geral da Seção: Nesta seção, o palestrante discute como se tornar um arquiteto de software e as habilidades necessárias para ser bem-sucedido.

Experiência e Estudo de Padrões Arquiteturais

• Ter experiência em implementação de diferentes padrões arquiteturais ajuda a estabelecer uma relação clara entre um determinado tipo de problema e uma solução arquitetural que consegue resolver esse problema.

• É importante estudar padrões arquiteturais, que são diferentes dos padrões de projeto utilizados como soluções de design para implementação.

• Estudar boas soluções arquiteturais, como as usadas por empresas como Twitter e Facebook, pode ajudar a entender quais são os recursos arquiteturais e a forma como pensar os componentes para tratar necessidades específicas.

Comunicação Eficaz

• Um bom arquiteto precisa aprender a construir bons diagramas e representações para comunicar efetivamente suas ideias.

• O arquiteto deve ser capaz de falar com pessoas do negócio para atender aos objetivos do negócio respeitando as principais restrições e atendendo aos principais atributos de qualidade.

• É importante ajustar o vocabulário e discurso do arquiteto ao público que está sendo tratado, criando visões diferentes para explicar a mesma solução arquitetural para públicos técnicos ou não-técnicos.

Envolvimento das Pessoas

• Um bom arquiteto precisa aprender a envolver as pessoas e ter sensibilidade para entender que não sabe tudo e nem precisa saber todas as soluções técnicas.

• O papel fundamental do arquiteto é compartilhar abstrações com o time e envolvê-lo no processo, por isso é importante ter habilidades de comunicação eficazes.

Conclusão

O palestrante conclui que se tornar um arquiteto de software requer experiência em implementação de diferentes padrões arquiteturais, estudo de padrões arquiteturais, habilidades de comunicação eficazes e sensibilidade para envolver as pessoas no processo. É importante ajustar o vocabulário e discurso do arquiteto ao público que está sendo tratado, criando visões diferentes para explicar a mesma solução arquitetural para públicos técnicos ou não-técnicos.