Visões Alternativas na Arquitetura de Software

No artigo anterior (leia aqui) foi apresentado uma breve definição do que consiste a Arquitetura de Software, porém qualquer definição meramente técnica do assunto não leva em consideração todas as forças que modelam e/ou são modeladas pela Arquitetura de Software.

Este artigo visa apresentar pontos de vistas mais alinhados às necessidades dos profissionais e das áreas de negócio que são diretamente influenciadas pelas decisões relacionadas a Arquitetura de Software.

Gerenciamento de Dependências

Considerando o desenvolvimento de sistemas com equipes distribuídas, um critério importante na arquitetura de software é, desde a concepção do sistema, facilitar o gerenciamento de dependências entre os profissionais.

Porém é importante frisar que a percepção de facilidade não deve ser imposta pelo projeto e deve respeitar a visão das equipes responsáveis pelo desenvolvimento.

Desejos e Motivações Humanas

Diversos livros de Arquitetura de Software acabam por remover de forma demasiada o fator humano do processo de concepção, focando basicamente em padrões e/ou formas de alinhar o projeto às necessidades do negócio.

A concepção de um sistema deve levar em consideração sentimentos como expectativas, experiências, sonhos, medos e motivações da equipe envolvida na construção do sistema.

A estrutura técnica do sistema modela e é modelada pela estrutura social da equipe e decisões objetivas e subjetivas são tomadas com base neste relacionamento.

Senso de Pertencimento

Poucos desenvolvedores desejam ter um trabalho tão especializado que reduza seu escopo de atuação a somente uma das responsabilidades de análise, projeto, codificação ou correção de bugs.

Em geral, os desenvolvedores querem estar perto dos clientes ou dos gestores de produtos, clarificando requisitos, modelando, construindo, corrigindo problemas, otimizando o sistema, etc…

Este desejo “pertencimento” ao trabalho é um fator crucial e influenciador na modelagem da arquitetura a ser utilizada, visto que bons projetos devem levar em consideração esta necessidade e ajudar a satisfazê-la.

Quando “Dar o Braço a Torcer”

O conflito entre o que é “certo” e o que é “necessário” é um fator importante para a modelagem de um sistema. Por um lado, a concepção de “certo” está muitas vezes alinhada com as experiências passadas do arquiteto (e/ou da equipe responsável pelo desenvolvimento) que tende a utilizar “soluções vencedoras” ao invés de olhar para o domínio do problema e modelar a solução que melhor atenda-o.

Por outro lado, a necessidade de avaliação constante das decisões para verificar se as mesmas estão alinhadas com a necessidade do cliente tende a gerar mudanças que, em geral, ocasionam insegurança na equipe e até mesmo podem afetar a relação de confiança entre o arquiteto e a equipe.

“Beleza está nos olhos de quem vê”

Cada profissional tem uma definição do que significa uma arquitetura de sucesso: do ponto de vista de negócio podemos ter um produto lucrativo, porém para os responsáveis pela sua manutenção podemos ter reclamações a respeito da estrutura do sistema. Por outro lado, há uma série de soluções “elegantes” que não se tornam um produto de sucesso.

Desta maneira a “estética” do sistema está mais alinhada com as percepções individuais e com os entendimentos que cada profissional possui sobre o domínio do problema e o formato da solução que seria melhor adequado.

O efeito prático disto é que cada pessoa é capaz de impor um “toque pessoal” nas suas atividades e a Arquitetura de Software deve ser capaz de equilibrar as decisões globais da construção do produto (e seus “trade-offs”), respeitar contribuições individuais e lidar com os possíveis conflitos que podem surgir das diferenças de percepções.

Conclusão

Os fatores humanos e de negócios são elementos importantes que fazem parte do quadro geral que o Arquiteto de Software deve levar em consideração ao realizar a modelagem de um sistema e, principalmente, fazer com que esta modelagem gere um “produto vencedor” do ponto de vista das pessoas envolvidas.

No próximo artigo iremos nos aprofundar na importância da Arquitetura de Software para aquisição de sucesso no desenvolvimento e evolução de um sistema. Até mais!!!

2 comentários

  1. Fala Anderson.
    Poderia entrar em detalhes/exemplos sobre ‘dependencia de profissionais’?. Seriam restrições (técnicas ou humanas do recurso)?

    1. Fala Moisés, tudo bem?

      Um exemplo prático foi discutido hoje no trabalho: imagine uma equipe A responsável por desenvolver uma API de Pedidos e uma equipe B responsável por uma API de Solicitação de Entrega. Gerenciar dependências neste cenário significa minimizar influências entre uma equipe e outra, ou seja, caso equipe A tenha que evoluir o seu trabalho (ex: criar um novo tipo de pedido), por questões de design do sistema, ela não poderia “obrigar” a equipe B a atualizar a API dela para simplesmente absorver esta mudança (salvo se isto fizer muito sentido no ponto de vista de negócio). O ponto importante é que o modelo da arquitetura não deve impor trabalhos desnecessários!!! E caso solicite mudanças, que o fluxo de comunicação entre estas mudanças seja claro, documentado, alinhado….e aí podemos considerar processos e ferramentas para resolver isto…

Deixe sua opinião