Em um cotidiano cada vez mais dinâmico e exigente na área de tecnologia, as preocupações sobre a gestão e manutenção de produtos se tornam necessárias para o sucesso de uma empresa e a satisfação de seu público-alvo.

Entretanto, essas preocupações podem ser bastante complexas de lidar quando o produto possui uma má construção inicial e dificuldades relatadas pela equipe técnica, como falta de atualizações e modificações em suas funcionalidades.

Para deixar mais claro, imagine o seguinte cenário: “Sua empresa oferece um produto Saas que a sua produção inicial está dificultando atualmente a atualização e o seu próprio.” O que você consideraria para mantê-lo competitivo? A resposta para esse impasse não é trivial e, muitas vezes, requer sacrifícios e tempo por parte das equipes de gestão, mas tal situação poderia ser evitada caso houvesse maior atenção sobre o planejamento da arquitetura de software proposta para o produto.

Para debater um pouco sobre como definir uma boa arquitetura de software e a importância disso, estruturei esse artigo em modelo FAQ: frequently asked questions - Perguntas frequentes respondendo a 5 perguntas-chave que irão proporcionar clareza sobre o tópico abordado e algumas curiosidades comuns. Vamos a elas?

O que é Arquitetura de Software?

Segundo o blog XP Educação no artigo “O que é arquitetura de software?” Temos a seguinte definição: 
‍

“Arquitetura de software é um conceito abstrato, que se refere à organização de um sistema. Ela é responsável por definir os componentes que farão parte de um projeto, suas características, funções e a forma como devem interagir entre si e com outros softwares.”

Em outras palavras, Arquitetura de Software se refere aos padrões e cuidados necessários para se construir um produto com suas características bem definidas.

Ela define as bases de construção do projeto e visa uma boa separação e interação de responsabilidades e funcionalidades propostas pelo produto.

Trata-se de um trabalho totalmente técnico visando a produção de código direcionada e criação low level do produto.

Por que pensar em Arquitetura de Software?

Embora as definições anteriores demonstram certa relevância e formalidade sobre o tópico “Arquitetura de Software”, empiricamente nota–se que a adoção inicial do produto no mercado se dá pela sua funcionalidade direta e não pelas suas características de construção, visto que a construção de software não interage diretamente com as dores e problemas imediatos dos usuários. Portanto, um produto muito bem arquitetado tem, inicialmente, as mesmas capacidades de atuação e solução que um produto mal arquitetado!

Logo, temos a seguinte pergunta: “Por que pensar em Arquitetura de Software? Quais os benefícios que tal operação pode me oferecer?”

Planejar e arquitetar um software demanda tempo e esforço. Caso um produto SAAS, por exemplo, seja formado por uma gama de serviços em software atuando em conjunto, sua produção pode ter um ganho elevado de tempo até a sua concretização inicial. Entretanto, toda essa formalidade será recompensada caso a perspectiva sobre o produto seja de atuação e permanência a longo prazo!

No primeiro capítulo do livro “Código Limpo”, o autor traz a seguinte reflexão:

“Todos já nos sentimos aliviados ao vermos nosso programa confuso funcionar e decidimos que uma bagunça que funciona é melhor que nada. (...) Conforme a confusão aumenta, a produtividade da equipe no projeto diminui assintoticamente aproximando-se de zero”

‍

Quando pensamos em arquitetura de software para projetos, estamos trabalhando e planejando a resiliência do produto ao longo do tempo, pois, dada uma boa produção arquitetural, as devidas alterações, atualizações e incorporação de funcionalidades se tornam menos custosas para a equipe técnica. Isso garante uma vantagem comercial ao produto pela sua grande capacidade flexível e rápida de evolução atendendo e satisfazendo mais seus usuários e se tornando mais atrativo para o público-alvo e mercados em expansão.

Mas aí, sempre surge a pergunta:

Arquiteturas muito rebuscadas não geram “Overengineering”?

Antes de entrar na resposta propriamente, vamos definir Overengineering da seguinte forma:

“Overengineering, em um contexto de arquitetura de software, refere-se a uma prática em que uma solução é projetada para ser mais complexa e/ou abrangente do que o necessário para atender aos requisitos atuais ou esperados do sistema”

‍

Portanto, tendo em vista o conceito de Overengineering, é bastante comum que se tenha uma legítima preocupação sobre a equipe de tecnologia em relação a produção de funcionalidades desnecessárias, Abstrações excessivas, Generalização excessiva e Complexidade desnecessária. Caso o contrário, o desperdício de tempo e a dificuldade de se atender as demandas prioritárias serão comuns e problemáticos no planejamento estratégico do produto.

Em volta do tema Overengineering, temos o seguinte conflito clássico entre as equipes de produto e tecnologia: “A equipe de produto argumenta que a equipe de tecnologia está praticando Overengineering em sua produção devido a necessidade de atualização rápida das soluções, enquanto a equipe de tecnologia afirma que tais produções são necessárias e condizentes com a arquitetura desejada”

Geralmente esse conflito se dá pela precariedade da comunicação entre tais equipes. É necessário um alinhamento de interesses e concessões de ambas as partes: Uma má arquitetura pode gerar problemas futuros na manutenção do produto, entretanto um planejamento com a melhor arquitetura prevista pode causar uma produção bastante demorada. Deve haver um ponto de equilíbrio e moderação entre a arquitetura desejada pela equipe de tecnologia e os prazos e evolução esperada pela equipe de produto.

Nessas horas, experiências anteriores são um grande diferencial. Tecnicamente, arquitetos mais experientes entendem a diferença entre construções “especuladas” e construções reais de softwares. Arquiteturas rebuscadas e complexas devem ser estudadas e ensinadas formalmente, entretanto, em situações reais e ambiente corporativo, é necessário a produção da arquitetura adequada ao caso: Que possua separação e isolamento das responsabilidades, mas com uma robustez controlada ao período de entrega previsto.

‍

Além disso, os arquitetos devem estar em maior contato com líderes de produtos para entender a necessidade imediata dos usuários e argumentar a favor de algumas necessidades técnicas ou débito técnico presente. O esclarecimento e debate sobre as previsões e produção de funcionalidades entre ambas as equipes pode se tornar um ritual produtivo e agregante para o produto final.

O que nos leva ao próximo tópico:

‍

Arquitetos precisam entender sobre estratégias de produto?

 Embora discussões sobre estratégias de produto e adequação para alcance de público não sejam uma das principais funções do arquiteto de software, esse tipo de conhecimento é bastante construtivo e agregador. Como respondido no tópico anterior, o contato e o alinhamento de expectativas entre as equipes de tecnologia e produto pode trazer boas colaborações para o produto final, porém essa interação se torna mais harmônica caso haja, minimamente, um conhecimento básico sobre os processos e atuações da área vizinha.

E embora ambas as áreas colaborem para o desenvolvimento de um produto funcional e necessário para as demandas do mercado, nota-se que suas atuações e responsabilidades são bastante diferentes dentro de uma corporação. Isso pode gerar desconforto e desânimo sobre a proposta de entender os objetivos da outra área, entretanto esse conhecimento ajuda na projeção de um trabalho colaborativo conhecendo melhor os limites e divisões entre tais atuações.

Passo a passo para definir a Arquitetura de Software

Definir uma boa arquitetura de software não é uma tarefa fácil. Como discutido ao longo desse artigo, temos muitas situações que podem ser problemáticas caso tal tarefa não seja executada da maneira adequada: Queda de produtividade futura, dificuldades de atualização do software, prazos e objetivos ofuscados, embates com a equipe de produto, Overengineering…

Para responder tal questão, vamos apresentar abaixo alguns pontos que podem atuar como guia para a construção de uma boa proposta de arquitetura:

‍

• Tenha os requisitos claros

Entender completamente os requisitos do sistema é fundamental! Isso envolve identificar os stakeholders, ou usuários de base, suas necessidades e expectativas, bem como os casos de uso do sistema. Tal esclarecimento pode vir a partir da interação com equipes de BI e produto.

• Crie uma Separação de Responsabilidades

A arquitetura deve separar as diferentes responsabilidades do sistema, como interface do usuário, lógica de negócios e persistência de dados. Isso facilita a manutenção, testabilidade e escalabilidade do sistema. Caso executado de maneira adequada, a percepção de tais responsabilidades em código pelos desenvolvedores se torna clara.

• Pense em Escalabilidade

A arquitetura deve ser projetada para permitir que o sistema cresça conforme necessário, tanto em termos de volume de dados quanto de usuários. Isso pode envolver a adoção de padrões como microsserviços ou escalabilidade horizontal e vertical. Lembre-se de trabalhar com modularidade dividindo o sistema em módulos ou componentes independentes com uma única responsabilidade clara e coesa.

• Considere o Desacoplamento

Reduza as dependências entre os diferentes componentes do sistema. Isso torna o sistema mais fácil de entender, testar e modificar. Padrões como Injeção de Dependência e Event-Driven Architecture podem ser úteis aqui.

• Segurança é FUNDAMENTAL!

A segurança deve ser uma consideração fundamental na arquitetura do sistema. Isso inclui autenticação, autorização, criptografia de dados, prevenção de ataques e conformidade com regulamentações de segurança (Não queremos ser processados por isso!)

• Performance deve ser levada em conta

Considere os requisitos de desempenho desde o início e projete a arquitetura de acordo. Isso pode envolver a escolha de tecnologias apropriadas, otimização de consultas de banco de dados, uso de caching e técnicas de escalabilidade.

• Documentação deve acompanhar o processo

Documente a arquitetura do sistema de forma clara e abrangente. Isso ajuda a garantir que todos os membros da equipe tenham uma compreensão comum do sistema e facilita a integração de novos membros na equipe.

Definir uma boa arquitetura de software vai muito além de puro conceito técnico e ferramental. São um apanhado de decisões que irão ditar o futuro, os desdobramentos e evoluções de um produto frente a equipe técnica, a equipe de produto e o próprio usuário final.

Embora seu planejamento seja repleto de dilemas e impasses, é importante o cuidado e a visão holística sobre todo o desenvolvimento e seus impactos de um modo geral.

Fiz o Tech Lead Program do IFTL e conheci líderes que estavam sofrendo os reflexos da má definição de arquiteturas e que aprenderam como modificar ou escolher a arquitetura de software ideal para os seus projetos a partir da aula do programa. Por isso, fica aqui a minha indicação para que conheçam essa mentoria. Ela é destinada para engenheiros que desejam migrar para um cargo de gestão, além de Tech Leads que acabaram assumindo a posição repentinamente.

Candidate-se aqui e se torne um líder técnico 100% estratégico.