No artigo anterior, falamos sobre “Como definir uma boa Arquitetura de Software e por que é tão importante?”. Nele, nos aprofundamos em todas as complexidades técnicas e não-técnicas possíveis que podem interferir diretamente na produção operacional do software e, consequentemente, no futuro do produto.

Entretanto, não discutimos sobre a jornada para se tornar um bom Arquiteto de Software e as competências necessárias que tal líder deve desenvolver para exercer sua função com primazia. Nesse artigo vamos discutir um pouco sobre pontos técnicos e não-técnicos desse profissional, focando em sua atuação junto às equipes de tecnologia e produto.

Afinal, qual a importância de um Arquiteto de Software?

Segundo o blog  XP Educação, um Arquiteto de Software é definido da seguinte maneira:

“É o profissional responsável pelo planejamento, desenvolvimento e teste de uma aplicação web, que pode ser um software, um aplicativo, um website, um sistema operacional, entre outras opções.”

‍

Planejar a arquitetura de um software se relaciona com o futuro e a posterioridade do produto: um projeto bem arquitetado facilita as alterações e evoluções futuras de funcionalidades presentes, possibilita a fácil captação de bugs e problemas, além de permitir uma vantagem competitiva de um produto facilmente adaptável às necessidades do público-alvo.

Logo, tendo em vista a definição anterior e as características de seu trabalho, o Arquiteto de Software tenta unir as expertises técnicas da equipe de tecnologia visando os desejos futuros e metas da equipe de produto.

Embora sua atuação seja mais voltada à parte técnica, é notável sua interação indireta com as equipes de produto e o alinhamento com os objetivos da empresa.

Quais conhecimentos técnicos um Arquiteto de Software deve ter?

Como mencionado anteriormente, um Arquiteto de Software está mais voltado para a parte técnica do produto e seu contato maior é com a produção do sistema. Logo, nota-se que é necessário uma gama de conhecimentos técnicos e experiências diversas em diferentes tipos de softwares. Abaixo está uma lista com as habilidades que um Arquiteto deve possuir para atuar de forma assertiva:

1. Bom conhecimento sobre bancos de dados armazenamento de informação

Dados são o ouro do século 21. Toda interação que fazemos com clientes pensando em estratégia de negócios, tomada de decisões e perspectivas futuras de funcionalidades são analisados por meio de uma cuidadosa análise de dados.

Não é necessário que o Arquiteto de Software seja um analista de dados, mas é preciso que ele entenda sobre bancos de dados e armazenamento eficiente destas informações.

Considere, por exemplo, um sistema de entregas de pedidos online que possui cadastros de usuários e informações sobre produtos. Logo, temos o seguinte cadastro de informações:

• Informações de usuário
• Informações sobre produtos
• Informações sobre pedidos

Veja que as informações de usuário podem ser padrões para todos os registros (nome, email, idade, município), assim como os de produto (tipo, tamanho, peso, descrição), entretanto as informações de pedido abrem margem para uma não padronização:

• Pedido 1: Dois produtos do tipo 1, e um produto tipo 2
• Pedido 2: Um produto do tipo 1
• Pedido 3: Dois produtos do tipo 3

Portanto, podemos concluir que o modo de armazenamento das informações de usuários e produtos deve ser diferente do de pedidos, sendo os primeiros mais indicados para Bancos SQL e os pedidos em Bancos NoSQL

2. Conhecer as arquiteturas mais comuns e famosas‍

Arquitetos de Software devem conhecer algumas das arquiteturas mais populares e comumente discutidas para possuírem uma base de fundamentos. Desse modo, é possível prover conceitos clássicos para replicar ou gerar novos modos de arquitetura, dependendo da necessidade prevista. Tais arquiteturas são:

• Padrão MVC: É um padrão de arquitetura de software comumente usado no desenvolvimento de aplicativos web e de desktop. Publicada em 1979, ele separa a lógica de negócios (Controller), a interface do usuário (View) e a lógica de armazenamento e estados (Model).

• Arquitetura Hexagonal: Foi introduzida por Alistair Cockburn em 2005 como uma abordagem para desenvolver sistemas flexíveis, testáveis e adaptáveis. Organiza o código em torno de um núcleo independente, onde a lógica de negócios e as regras do domínio residem, sendo possível cercá-lo com adaptadores que permitem que o núcleo interaja com componentes externos, como bancos de dados, interfaces de usuário, serviços externos, etc.

• Clean Architecture: Padrão de arquitetura de software proposto por Robert C. Martin. A Clean Architecture enfatiza a organização do código em torno de camadas concêntricas, com a regra de negócio centralizada no centro e as camadas externas dependendo das camadas internas

‍

3. Entender de gerência de microsserviços e arquitetura de sistemas‍

É muito comum em empresas que seus produtos sejam formados pela comunicação de diversos sistemas distribuídos com responsabilidades diferentes (um para cadastro, outro para pagamento, outro para envio de emails, etc). Portanto, é necessário que o Arquiteto entenda sobre sistema em microsserviços, assim como alguns padrões de relacionamento entre eles, modos de trocas de informações, disponibilidade e monitoramento.

Logo, informações como computação em nuvem (comumente utilizados no AWS ou Microsoft Azure), conteinerização de aplicações e orquestração (com Kubernetes e Docker) e rastreamento (com Prometheus e Grafana) são alguns dos conteúdos técnicos bastante requeridos e necessários.

Vale frisar que o Arquiteto de Software não precisa conhecer a fundo as funcionalidades e as disposições de infraestrutura, mas deve possuir um conhecimento geral e básico sobre.

Quais conhecimentos não-técnicos um Arquiteto de software deve ter?

Como dissemos anteriormente, é necessário que esse tipo de profissional reúna a expertise da equipe de tecnologia com os desejos futuros da equipe de produto. Portanto, é necessário que ambos os interesses e forças sejam mediados e refletidos na arquitetura do projeto. Portanto, vamos listar os atributos:

1. Ponderação e interpretação de casos mediante a prazos

Mesmo possuindo um grande ferramental e entendendo sobre diversos modos de se produzir e construir software, a atenção aos prazos e demandas é relevante e precisa ser levada a sério. Logo, em muitos dos casos, a criação de uma arquitetura muito robusta e bastante desacoplada pode levar a um grande período de tempo e esforço, não sendo compatível com as projeções de prazos e entrega.

Diante disso, é preciso uma grande ponderação entre produção de software e prazos de entrega. É necessária a prospecção de uma arquitetura menos robusta que atenda as demandas de entrega e, ao mesmo tempo, se mantenha elegante e maleável para fácil alteração e evolução do produto.

2. Comunicação clara com profissionais técnicos e não-técnicos

Expressar e demonstrar ideias de funcionalidades e evolução técnica do produto é tarefa do Arquiteto de Software e, em vários casos, é necessário que haja comunicação não- técnica para facilitar a participação e engajamento da equipe de produto. Portanto, a utilização de uma linguagem mais visual e a apresentação de diagramas de atividades (em UML) são grandes facilitadores:

‍

3. Conhecimento geral sobre gestão de produto

Já falamos que o Arquiteto de Software é um profissional que se encaixa mais nas equipes técnicas de uma empresa, entretanto não é incomum o contato com as equipes de produto para conhecimento de suas aspirações sobre o projeto.

Embora o Arquiteto entenda os débitos e as fraquezas que habitam no projeto, é de grande ajuda o entendimento básico sobre gestão de produto e evolução de negócio para compreender melhor as demandas para a evolução desejadas do produto.

Desse modo, é mais simples prospectar as alterações técnicas necessárias para atender as dores de um grupo de usuários e também atingir o público-alvo ideal.

4. Entendimento básico sobre Agilidade e Metodologias Ágeis‍

Metodologias Ágeis estão totalmente ligadas a produção de software e entregas contínuas. São modos de conduzir projetos, visando a conclusão de tarefas e considerando incrementos pequenos para a evolução contínua do projeto. Além disso, tais metodologias promovem o feedback constante da produção, o refinamento necessário e a interação dos integrantes.

Tendo isso em vista, o Arquiteto deve ter conhecimento das cerimônias e organização de tarefas para que consiga ser um agente ativo e auxiliador ao Tech Lead na divisão de tarefas e organização, além da gerência na construção das funcionalidades arquitetadas.

Arquitetar e implementar software são tarefas complexas que necessitam tanto de conhecimentos técnicos e não-técnicos alinhados.

Boas arquiteturas são conhecidas e bastante discutidas, mas a formação de bons arquitetos leva em conta uma série de fatores que podem ser estudados, aprimorados e fixados com tempo e experiência.

O Tech Lead Program possui uma aula sobre Arquitetura de Software, onde é possível entender como garantir uma boa atuação no cargo a partir de use cases do mercado, além de uma visão aprofundada sobre as arquiteturas existentes do mercado, entendendo os reais impactos de cada uma, com acesso a um framework que auxilia na escolha ideal para cada projeto, de acordo com o contexto do negócio.

Entre os tópicos, essa aula também aborda:

• Principais padrões de arquitetura

• Event Driven

• Serverless

• Critérios para definir arquitetura para seus projetos