ArquiteturaColunistasDestaque + Editor's PickInovaçãoTecnologia

Arquitetura de Sistemas

1

Hoje a tecnologia faz parte do nosso dia-a-dia e quase tudo que vemos ou consumimos como por exemplo: aplicativos, sites, bancos, hospitais, transportes, comida, produtos. etc.

Em praticamente tudo, temos tecnologia aplicada. Nesse mundo binário e muito das vezes “invisível”, são aplicadas diferentes técnicas, conceitos e padrões que muitos desconhecem.

A concepção de um sistema muito se faz através da necessidades ou ideias na maioria das vezes embrionárias.

Porém o que poucas pessoas têm conhecimento é da quantidade de componentes e soluções que se faz necessário para estruturar um sistema, e muito se discute sobre padrões ou tendências estabelecidas por cases ou grandes corporações, mas será que existe um padrão a ser adotado? Ou podemos ter padrões situacionais?

Arquitetura de Sistemas

Arquitetura de Sistemas

“Padrão – Norma determinada e aprovada consensualmente pela maioria, ou por uma autoridade, que é usada como base para estabelecer uma comparação.”

Em poucas palavras, “Arquitetura de software” é uma forma de estruturar um sistema para que seja flexível, escalável, rentável e geralmente com um custo baixo e que atenda a expectativa de negócio.

Padrões de Arquitetura

Existem alguns padrões bem conhecidos por cases de sucesso, como “Micro-Serviços”, arquitetura implementada pelas gigantes Google e Amazon.

Outro padrão bem conhecido é a de Serverless onde o time de desenvolvimento não precisa se preocupar com o gerenciamento de servidores, alocação de recursos, capacidade, atualizações. Tudo fica a cargo do parceiro estabelecido na Cloud.

E por último, mas não menos importante, é a arquitetura baseado em “Eventos”, onde se depende de produtor e consumidor desacoplados, em ações sistêmicas onde parte é acionada conforme o evento ocorre, e seu assinante realiza alguma ação.

Exemplo: a partida de um motor no qual a ação de ligar o carro envia um evento “LIGAR” para o motor, que passa a funcionar.

 

Padrões de Arquitetura

Padrões de Arquitetura

Com tantos padrões e cases de sucesso por que ainda temos tantos problemas e erros na construção de um software?

Muitos não escalam, tem o custo elevado, sofrem atraso e posteriormente com manutenção, muitos são até refeitos quando acabam de ser entregues.

Se existem tantos modelos porque simplesmente não seguimos um manual passo a passo como a receita de um bolo? Acredito que assim todos estaríamos em um patamar único e sem nenhum problema em projetos.

Porém mesmo com tantos padrões e cases de sucesso nem sempre o “by the book” irá funcionar ou atender exatamente a solução esperada.

Prático x Estado da Arte x OverEngineering

Talvez o problema seja tentar elevar o máximo alguma arquitetura sem de fato se aprofundar no que se espera ser entregue.

Será que precisamos gastar com recursos de infra ou buscar algum produto tão caro e estabelecido para uma solução mínima de relatório? 

Ou talvez partir para de fato a construção de algo MPV ou até mesmo uma POC elevando assim o conhecimento da sua área de negócio, dando visão no que de fato irá trazer benefícios?

Acredito que o maior vilão dentro das corporações é de fato sempre visar a forma mais correta ou ideal para a construção de uma arquitetura perfeita, sem mesmo se aprofundar ou entender o que muitas das vezes é apenas um desejo.

Ou será que a melhor arquitetura é aquela que irá atender o TIME correto da minha empresa e no qual será possível atingir seu objetivo de uma forma mais rápida. 

Arquiteto de sistemas

Talvez um melhor engajamento de arquitetos de sistemas em TODAS as fases  de um projeto controlaria uma melhor arquitetura. Com 20 anos de experiência em projeto de tecnologia não houve uma vez na qual o time que desenhou a arquitetura esteve até o final da implantação.

Como é dito naquele ditado popular: “Os olhos do dono que engorda o gado”,  como um time que muitas das vezes comparecem apenas no início de um projeto, sem conhecimento de fato no que se espera, pode desenhar ou desejar algum padrão de arquitetura estabelecido, se mais de 50% do que se foi desenhado não é monitorado muito menos questionado?

Lembrando que projetos vivem sofrendo mudanças de escopo, seja por algo regulamentar, necessidade ou mesmo solicitação de negócio.

Será mesmo que o problema são as “N” possibilidades de arquitetura de sistemas que temos ou como se aplica o conceito dentro de um projeto?

Prático x Estado da Arte x OverEngineering

Prático x Estado da Arte x OverEngineering

 

Com isso ainda deixo aqui um questionamento será que nos falta padrões de arquitetura ou um TIME de arquitetura dedicado que entenda e monitore o andamento de uma construção sistêmica?  

Qual de fato o papel de um time de Arquitetura dentro de uma corporação? Falaremos em uma próxima matéria sobre a atuação de um Arquiteto dentro de um projeto.

Daniel Morais
A paixão por games, fez Daniel brilhar os olhos e ingressar nessa carreira maluca cheios de bits e bytes que é a T.I, com isso, hoje Daniel atua como Arquiteto de Sistemas, formado em Comunicação WEB e pós em graduado em Gestão de Projetos T.I. Com 15 anos de carreira e passagem por muitos modelos de negócio (telecom, financeiro, hospitalar, e-commerce, cosméticos, aeronáutico) Daniel sente-se cada dia mais apaixonado pela tecnologia e no que ela pode proporcionar para a humanidade. Instagram: @dancmoraiis

Apple anuncia iPhone 12 sem carregador e destaca 5G

Previous article

Inteligência Artificial agilizando classificação de grãos no Paraná

Next article

You may also like

1 Comment

  1. Muito bacana a abordagem, linguagem simples e objetiva de um profissional que conhece muito. Uma pena o espaço pequeno para um conteúdo tão vasto que dá para “voar”.
    Para a próxima, seria legal incluir um tópico sobre o ciclo de vida do software (até sua fase final, com um possível desligue, ou substituição) versus o papel do Arquiteto de Software.
    Ou ainda um comparativo dos erros mais comuns na construção de um software, e que jamais aconteceriam na engenharia (por exemplo, mudanças/adições de escopo, que causam mudanças estruturais em um software em fase final).

Leave a reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

More in Arquitetura