Pensamento Arquitetural
Quatro principais aspectos:
Compreender a diferença entre arquitetura e design e saber como auxiliar a equipe de desenvolvimento a implementar com sucesso a arquitetura.
Ter um amplo conhecimento em várias áreas e manter um profundo domínio em um nível específico, permitindo uma visão abrangente que o arquiteto percebe, mas os outros não.
Lidar com os "dependes" (ou "trade-offs", termo mais sofisticado em inglês). Nenhuma solução é perfeita; sempre haverá sacrifícios a serem feitos. A questão está em saber o que sacrificar e compreender as consequências disso.
E, o mais importante, uma visão arquitetural requer um entendimento de negócios. As decisões arquiteturais são baseadas nas necessidades do cliente e no contexto de negócios.
Arquitetura vs Design
Na abordagem tradicional, o arquiteto analisa todos os requisitos de negócio, define as características arquiteturais, seleciona os padrões arquiteturais e estilos que se adequam ao domínio do problema e cria os componentes. O resultado é então repassado à equipe de desenvolvimento, que é encarregada de criar os diagramas de classe para cada componente, desenvolver a interface do usuário, escrever o código-fonte e realizar testes.
É importante notar que, na abordagem tradicional, a comunicação é unidirecional, e o papel do arquiteto muitas vezes termina aí. No entanto, essa abordagem tradicional nem sempre funciona bem. O arquiteto deve fazer parte da equipe de desenvolvimento, e aqui estão algumas razões para isso:
Para ilustrar esse ponto, gostaria de compartilhar uma experiência recente que tive. Tive a oportunidade de projetar a arquitetura de um sistema para um cliente, mas, devido a várias razões, não pude acompanhar o desenvolvimento de perto. Algum tempo depois, fui convocado para uma reunião para discutir um possível problema no sistema. Esse problema não existia na arquitetura que propus e, no pior cenário, era mitigado. No entanto, durante o desenvolvimento, certas estruturas foram modificadas, e eu não fui informado sobre essas mudanças.
Outra situação que já vivenciei foi quando atuei como desenvolvedor. O arquiteto havia criado a estrutura inicial, mas não participou ativamente do desenvolvimento com a equipe. Como resultado, ele não percebeu os problemas e as dificuldades que a arquitetura apresentava para a equipe de desenvolvimento.
Mark Richards explica nesse vídeo de forma mais detalhada a diferença entre arquitetura e design, utilizando diversos exemplos. Recomendo assisti-lo para aprofundar sua compreensão sobre esse conceito.
Technical Breadth
A maioria de vocês já deve ter ouvido falar sobre o conceito de "desenvolvimento em T". Nesse modelo, você adquire conhecimento em diversas áreas, mas se especializa profundamente em um campo específico.
Por exemplo, um desenvolvedor de destaque terá um amplo conhecimento em um domínio específico, tornando-se um especialista nessa área. Portanto, seu perfil "T" se assemelha à imagem abaixo, com um grande conhecimento vertical em uma área específica, mas menos conhecimento horizontal em outras áreas.
No caso de um arquiteto de software, o conceito de "T" se assemelha mais à imagem abaixo. Enquanto ele pode ter especialização em áreas específicas, como uma forte compreensão da stack .NET ou da stack Java, ele também deve expandir seu conhecimento horizontal para avaliar e propor as melhores ferramentas, frameworks e linguagens para os projetos.
A pirâmide de conhecimento é uma representação conceitual que descreve a profundidade e a extensão do conhecimento de uma pessoa em relação a um determinado tópico ou campo de estudo. É comumente dividida em três partes:
O que você sabe: O topo da pirâmide é o conhecimento que você tem e reconhece ter. São informações, habilidades e conceitos que você possui e pode aplicar.
O que você sabe que não sabe: Essa camada representa o conhecimento que você reconhece não possuir, mas está ciente de sua existência. Inclui tópicos, habilidades ou informações que você sabe que precisa aprender ou explorar.
O que você não sabe que não sabe: está na base da pirâmide e representa o conhecimento que está além da sua consciência, coisas das quais você não tem conhecimento, e você não está ciente de sua existência.
Há muito tempo, eu estava envolvido no desenvolvimento de um sistema, porém, naquela época, meu conhecimento se limitava ao Asp.net WebForms. Eventualmente, deparei-me com a necessidade de uma solução mais adequada para um sistema específico, que, como descobri posteriormente, era uma Single Page Application (SPA). No entanto, naquele momento, eu nem sabia que existia algo chamado SPA. Para lidar com os desafios que o Asp.net WebForms não conseguia resolver, iniciei uma pesquisa e deparei-me com informações sobre frameworks como Ember e Angular, o que, por fim, me apresentou o conceito de SPA.
Como desenvolvedor, estamos constantemente em busca de aprimorar nossa base de conhecimento, visando ampliar o topo da "pirâmide de conhecimento". No entanto, é crucial reconhecer que o conhecimento que possuímos está sujeito ao avanço do tempo. Por exemplo, trabalhei com Angular há algum tempo, o que significa que ainda tenho algum entendimento sobre ele, embora meu conhecimento possa estar desatualizado devido às evoluções na área.
Um ponto fundamental destacado no livro é que a mudança de mentalidade de desenvolvedor para arquiteto implica, em grande parte, em equilibrar a expansão do topo da pirâmide com um foco na ampliação do "meio". Como arquiteto, é mais vantajoso possuir um conhecimento abrangente, mesmo que superficial, de diversos tipos de bancos de dados, em vez de se aprofundar em apenas um. Essa abordagem oferece uma visão mais holística e possibilita escolhas mais informadas ao projetar sistemas complexos.
Considero esse cenário bastante interessante. Compreendo o ponto de vista e, assim como os autores, acredito que essa seja a parte mais desafiadora durante a transição de carreira. É preciso fazer escolhas criteriosas sobre onde manter uma especialização e onde abrir mão, concentrando-se em expandir a base de conhecimento, já que nosso tempo é um recurso limitado.
Tive a sorte de ter trabalhado em ambientes nos quais fui exposto a uma ampla variedade de desafios. Embora meu foco de estudo seja predominantemente C# e o desenvolvimento no backend, tive a oportunidade de atuar em diversos contextos, envolvendo diferentes linguagens, bancos de dados, frameworks e áreas como frontend e desenvolvimento mobile. Essa diversidade de experiências tem enriquecido minha visão e habilidades, preparando-me para desafios mais amplos e complexos em minha carreira.
Trade-offs
A análise de trade-offs não é uma prática exclusiva de arquitetos. Desenvolvedores também devem considerar os prós e contras ao escolher uma estrutura de dados. Por exemplo, ao trabalhar em algoritmos complexos de otimização, uma decisão errada no código pode facilmente resultar em um StackOverflow.
No entanto, no caso dos arquitetos, o impacto de suas decisões é amplificado. As decisões arquiteturais afetam todo o ciclo de desenvolvimento de um projeto. Portanto, os arquitetos precisam ser cautelosos ao seguir tendências, pois nem todos os sistemas devem adotar uma arquitetura de microserviços, nem todos os bancos de dados precisam ser NoSQL. Múltiplos fatores devem ser levados em consideração.
Uma das restrições que, em minha opinião, mais influencia as decisões arquiteturais é a maturidade da equipe. Implantar uma arquitetura complexa em uma equipe com pouca experiência pode criar gargalos significativos no ciclo de desenvolvimento. Portanto, é importante considerar o nível de conhecimento e experiência da equipe ao tomar decisões arquiteturais.
Entender do Negócio
Ao criar uma arquitetura, uma das responsabilidades centrais de um arquiteto é a análise das necessidades do cliente. Isso envolve fazer as perguntas apropriadas para extrair os requisitos fundamentais do sistema e, em seguida, desenvolver a arquitetura com base nesses requisitos.
Frequentemente, o cliente expressa desejos que podem não se alinhar diretamente com as necessidades essenciais do projeto. Nesse cenário, cabe ao arquiteto gerenciar essas expectativas. Acredito que as habilidades interpessoais desempenham um papel crucial nesse processo, permitindo uma comunicação eficaz com o cliente e a capacidade de traduzir desejos em requisitos práticos.
Arquitetura e Codificação
Por fim, é importante destacar um aspecto do pensamento arquitetural, que é uma crença compartilhada pelos autores e que considero fundamental: o arquiteto deve ter experiência em desenvolvimento.
As estratégias para alcançar isso podem variar, e uma delas envolve a atuação do arquiteto como parte da equipe de desenvolvimento, embora em áreas que não causem gargalos para o progresso da equipe. Ou seja, funcionalidades críticas que impedem o avanço da equipe não devem ser de responsabilidade do arquiteto, já que ele tem outras funções a cumprir.
Outra estratégia proposta são as famosas POCs (Proof of Concept). A implementação dessas POCs serve para testar frameworks, tecnologias e bancos de dados. Além disso, essas POCs funcionam como um ponto de partida para que a equipe de desenvolvimento continue a implementação da funcionalidade.
Só uma coisa a se tomar cuidado nessas POCs. Geralmente quando fazemos POCs, pulamos algumas boas práticas para testar exatamente se aquilo é possível ser feito. É bom a gente tomar cuidado com isso, porque os desenvolvedores veem os arquitetos também como liderança técnica, então eles podem seguir o padrão da POC sem se preocupar com as boas práticas, fora que quantas vezes você não já viu uma POC entrar no código de produção? Aqui tem outra coisa que eu vou sugerir, esses códigos podem ser colocados como seu portifolio, mais um motivo para fazer um código bem feito.
Um outro ponto legal proposto é o arquiteto atuar em débito técnicos ou bugs. Eu acho essa abordagem muito interessante também porque é uma outra forma de avaliar os gaps ténicos da equipe e os gaps da própria arquitetura. Saber em que nível sua equipe de desenvolvimento está e como você pode ajudar eles a melhorar é um papel importante para o arquiteto. E você atuando nesses pontos, não afeta a equipe porque se não puder atuar não afeta o desenvolvimento, a revisão do código também ajuda a identificar esses gaps, não tem desenvolvimento, mas é sempre bom gastar um tempo analisando o código dos outros.
Por fim eu diria que a construção de bibliotecas, de uma sdk própria e ferramentas de automação ajudam a equipe a ganhar velocidade e ajuda a manter o conhecimento em desenvolvimento afiado.
Agradeço por ter chegado até este ponto!
Fique à espera dos próximos capítulos, nos quais, além dos resumos, compartilharei minhas experiências com as provas de conceito que venha a desenvolver e outros aprendizados relacionados ao desenvolvimento.
