A importância do arquiteto de software

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Veja neste artigo qual é o papel do arquiteto de software e sua importância. Também serão discutidos temas como a descentralização de funções e equipes auto gerenciáveis.

Arquitetura de Software:  o papel do arquiteto

Figura 1: Arquitetura de Software: o papel do arquiteto

O que é um arquiteto de software?

De todas as engenharias do mundo, certamente a mais recente é a de software, no entanto, é a que vem sofrendo um maior número de inovações e quebra de conceitos ou paradigmas. Por exemplo, conceito de não replicar a informação, regra muito divulgada na década de 70. Atualmente, em algumas situações é inviável segui-la, como no caso dos bancos NOSQL, NewSQL e cache, dentre outros recursos que precisam de escalabilidade horizontal. Com esse ambiente, o papel de um arquiteto de software, a profissão dos sonhos de alguns profissionais de TI, se torna preponderante já, que a decisão de uma ferramenta errada no início vai impactar todo o ciclo do software em seu final.

Afinal, o que é arquitetura?

Antes de falar-se sobre o arquiteto, é muito interessante se falar do que é arquitetura de software. Apesar de ser um termo muito utilizado, não se chegou ao consenso do que exatamente seria essa ciência. Muitos autores já tentaram definir o seu conceito como, por exemplo:

"o conceito de mais alto nível de um sistema em seu ambiente [...] a organização ou estrutura de componentes significantes interagindo através de interfaces de modo que estes componentes mais importantes são compostos de componentes e interfaces sucessivamente menores". “Parte do sistemas que são difíceis de se modificar”. Martin Fowler

No geral, a estrutura do sistema macroscópico; isso se refere a arquitetura como uma abstração de alto nível de um sistema de software que consiste em componentes de alto nível e conectores, ao invés de detalhes de implementação.” Garlan & Shaw.

O que é fundamental para a compreensão de um sistema em seu ambiente". ISO/IEC/IEEE 42010

Um conjunto de decisões em um projeto de software”. Jansen, A.; Bosch, J.

Embora todas essas versões de arquitetura, ambos compartilham a mesma opinião sobre o arquiteto: eles precisam estar no projeto, precisam ter conhecimento técnico, estar envolvidos no projeto e conhecer profundamente o projeto e negócio.

Um arquiteto que não está a par da evolução do código e do produto não estar conectado com a realidade”. Larman.

Assim, o arquiteto precisa ajudar no processo de um software. Esse processo de software vem variando muito com o tempo. Uma de suas maiores analogias é com uma fábrica, mas por quê? Fábricas são repetitivas e fazem sempre o mesmo processo. Certamente foi um erro, mas como uma ciência nova, ela teria de ser comparada com uma já existente. Com o tempo, o processo foi evoluindo e ganhando seus próprios conceitos e metodologias. A filosofia ágil é a real prova disso, fazer com que o cliente faça parte do projeto e estar preparado para constantes alterações do projeto por parte do cliente (isso não acontece em um açougue, pastelaria, construção civil, etc. Acredite, um software é bem diferente dos exemplos citados anteriormente).

Uma das coisas que começou a virar tendência em alguns projetos fora do país (principalmente nas novas empresas e que trabalham com o desenvolvimento de tecnologia ou start-up), é que a responsabilidade de toda a arquitetura está em toda a equipe. O arquiteto é um profissional de grande experiência, seria um degrau acima de um engenheiro de software sênior, mas não é o único responsável pela tecnologia do projeto, ele também em alguns casos é o responsável por estar “prestando contas” para o projeto. Uma pergunta comum para os que veem esse modelo é: onde estão os gerentes? A verdadeira pergunta é: “Mas para que eles realmente servem?”.

Em uma equipe gerenciável não existe necessidade de um gerente determinando o que deve ser feito. Um outro fator é o delay Tier. Sim, eles em alguns casos podem estar atrasando o processo de desenvolvimento de um software, em alguns casos eles não tem ciência de como deve ser feito, tomando uma decisão por toda a equipe, o que vai gerar erros. Um outro fator para os gerentes não serem muito utilizados está em seu preço, eles custam em média o valor de 4 desenvolvedores e o seu papel pode ser feito por um desenvolvedor com maior experiência que também pode ser o “facilitador” ou servidor do projeto (as metodologias possuem seus termos específicos como Scrum Master ou Kaban Master, mas o seu papel é feito de forma semelhante). Aqui no Brasil ainda está popular o padrão de fábrica e os gerentes de projetos, talvez pela nossa cultura na educação ter semelhança com uma fábrica, processo contínuo e repetitivo de decorar para passar, e a escravidão ter durado muito tempo no Brasil, fazendo com que essa estratégia tenha sido replicada para outras áreas, mas isso não será o foco do artigo.

Outra vantagem de uma equipe descentralizada está na decisão da tecnologia. Um profissional de TI não tem muitas opções, ele tem que estar constantemente estudando para aprender novos conceitos, novas metodologias, plataformas, paradigmas, etc. Ou seja, ele precisa sempre estar aprendendo. Centralizar as informações em apenas uma pessoa ou uma equipe fora do projeto pode gerar sérias consequências. Caso o profissional se desestimule, o novo o projeto tende a se deteriorar rapidamente. O ato de ter conhecimento e buscá-lo constantemente não valeria de nada, caso não saiba o modo correto de estar utilizando essas informações. É muito importante saber dosar o know-how com know-why, ou seja, não basta apenas conhecer tecnologias, mas é necessário saber por que utilizá-la.

Mas afinal, qual o motivo de adquirir tanto conhecimento? Se formos analisar a evolução dos computadores pessoais, PC, reparemos que nas primeiras versões a placa mãe possuía todas as funções (vídeo, áudio, rede, cache, etc.). Com a evolução desses dispositivos, cada funcionalidade ganhou um componente (placa de vídeo, placa de rede, processador, etc.) com suas específicas complexidades. Assim são os softwares atuais, eles iniciaram com uma simples divisão entre a visão e negócio, mas com tanta complexidade e exigência do cliente, foram surgindo novas camadas e sub-camadas. O JavaScript veio ganhando notoriedade não apenas pelo aspecto dinâmico que os aplicativos web ganham com essa tecnologia, mas também para desempenho, já que processamentos na máquina no cliente geram menos trânsito de informações, diminuem o tempo de resposta, além de economizar os recursos do servidor. Caso se utilize um servidor nas nuvens, no qual normalmente se paga pelo que se consome, também será uma economia financeira.

Nesse artigo foi discutido um pouco sobre a importância do arquiteto no processo de desenvolvimento de software, a importância deles pertencerem ao projeto e conhecer bem o negócio. É um profissional que precisa estar em constante processo de aprendizado, mas além de obter muito conhecimento é necessário saber quando utilizá-lo. Outro fator muito importante é a descentralização das decisões do projeto com equipe.

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?