fbpx
Pragmatismo nunca é demais
Publicado em: quarta-feira, 6 de ago de 2014
Categorias: Arquitetura
Tags: Concept

As empresas cada vez mais tornam-se especialistas em suas áreas, demandando cada vez mais complexidade de seu parque tecnológico. Enquanto no início de suas atividades poucos sistemas davam conta de todo o negócio. Com o passar dos anos, áreas especializadas na criação de novos negócios encontram novas formas de monetizar suas companhias. Independente da forma como esses novos produtos e serviços são criados sempre demandam novas funcionalidades em sistemas antigos, ou até mesmo a criação de novos sistemas.

O modelo mais comum de integração entre sistemas é baseado em bancos de dados compartilhados. Por meio de compartilhamento de SGDB’s, diversas aplicações manipulam porções comuns de dados para realizarem suas tarefas, realizando mudanças de estado que configuram insumo para uma outra ou mais tarefas do fluxo. Outros serviços ou sistemas, por sua vês, identificam que a nova massa de dados possui o estado necessário para sua execução. Nesse espiral, o fluxo continua, seguindo para uma ou diversas vertentes, muitas vezes iniciando fluxos completamente novos. Esses serviços podem estar segmentados em porções microscópicas, ou não, podem estar mapeados, ou não. Sob qualquer cenário, infelizmente esse tipo de processamento existe e continuará existindo, até que consigamos mudar este paradigma.FILOSOFIA-CITACOES-PRAGMATISMO[1]

O modelo apresentado acima é baseado em máquinas de estado, usando tabelas, colunas e status para a gestão do fluxo de trabalho. Esse modelo é eficaz, no entanto não é eficiente. Em algum nível, todas as demandas por novos produtos e serviços, trazem consigo a necessidade de repensar o modelo e o design usado. Para cada evolução é necessário dedicar, no mínimo alguns minutos para entender como endereçar melhor a solução, independente do parque de software que você possua. Analisar esses pontos faz com que você conheça as demandas e os gaps de sua plataforma. Muitas vezes não temos tempo ou dinheiro para realizar o modelo adequado, mas a verdade é que se seu modelo está muito divergente do modelo que atenderia a demanda corretamente, há uma boa chance de você ter passado por alguns dos pontos abaixo:

  • Seu modelo nasceu errado
  • Você não reavaliou seu modelo durante outras demandas intermediárias
  • Houve falta de comunicação, que não deixou que tivesse uma visão macro, sobre as vertentes possíveis e aplicáveis para o que estava fazendo.
  • Não houve investimento suficiente para que aplicasse uma solução adequada, e teve de tirar leite de pedra.

Bom, em algum momento passamos por cada uma desses cenários.

Mas você pode estar questionando-se sobre qual contexto integrações baseadas em banco de dados de integração tem relação com mudanças de design. Eu respondo: TODOS!

A complexidade trazida pelo modelo de integração baseado em bancos de dados de integração, torna inviável o redesign em detrimento ao custo, dessa forma workarounds são necessários para garantir o menor impacto nas demais aplicações e serviços. Podemos obter histórias e mais histórias do mercado e de nomes renomados do mercado para tomarmos como verdade a compreensão de que o custo de não fazer a coisa certa é infinitamente maior do que o custo de efetivamente refatorar aquilo que precisa ser refatorado. Talvez a maior dificuldade que encontrei pelas empresas que passei foi fazer com que compreendessem que:

A toda evolução precisamos avaliar se nosso design oferece suporte adequado às novas necessidades, e se não, devemos mudá-lo para que atenda. Essa mudança pode ocorrer a partir da primeira ou da décima mudança. Fechar os olhos para as necessidades de redesign é como abandonar e abdicar da chance de sucesso duradouro.

O pragmatismo surge como ferramenta, impondo rigidez aos conceitos e premissas acordadas, garantindo incorruptibilidade à estratégia.

Entenda:

  • Por mais estruturada e bem feita que seja a análise, em algum momento vamos errar.
  • Errar faz parte do processo, devemos aceitar o erro e sermos capazes de contornar os erros de forma rápida e eficiente.

Este conceito não significa ausência de qualidade, mas a real percepção de que as definições não são tão sólidas quanto se pensa, e a única certeza real que você pode assumir é a de que as coisas irão mudar. Sob posse dessas verdades, cabe a você usar essa sabedoria popular para tomar decisões que favoreçam as mudanças, e talvez devesse incentiva-las. Compreender que construímos e desenhamos soluções baseados na profundidade do nosso conhecimento sobre um determinado assunto, permite compreender que se sua visão muda, provavelmente haverão mudanças, talvez superficiais, no design da mesma solução se tivesse sido dada um ano antes ou depois. Com o passar do tempo, os argumentos se fortalecem, o seu produto se fortalece, as demandas que não foram bem especificadas se tornam mais claras, e a real necessidade passa a gritar sobre seus olhos.

A modelagem de dados é a mais afetada com visões minimalistas de problemas de negócio. Existem definições claras de como os dados devem ser armazenados, evitando, em qualquer cenário, suprimir informações e inibir modelagens que facilitam qualquer que seja o agente em detrimento da organização dos dados. Os dados devem ser estruturados da forma como eles efetivamente são, e se para isso forem necessárias 10 tabelas ou 100 tabelas, estas devem ser criadas. Geralmente desenvolvedores evitam modelar o que precisa ser modelado, aplicando uma visão minimalista, arbitrando que um determinado conjunto de informações pode ser considerado desnecessário e não precisa ser armazenado. Abordagens assim reduzem o custo do desenvolvimento da primeira release, no entanto aumentam e até inviabilizam a criação de novas funcionalidades.

O pragmatismo é fiel companheiro para garantir que o design levará em consideração o que precisa ser feito para a conclusão da tarefa, e não a forma mais simplificada de realizar uma tarefa. Embora possa parecer ilógico, abordagens simplificadas geram muito mais custo a longo prazo que abordagens pragmáticas e completas.

“Tudo deveria se tornar o mais simples possível, mas não simplificado”

Albert Einstein

Ao mesmo tempo, profissionais simplistas são de fato um risco para qualquer empresa. Mas o mais importante a ressaltar em toda essa explanação é que apenas alguns poucos sociopatas têm a capacidade de tomar ações erradas segundo seus próprios conceitos, ferindo seu senso de certo e errado. Para todos os demais, há uma convicção quase que óbvia e divina de que a ação a ser tomada, deveria ser aquela. Seja no âmbito corporativo ou criminal as pessoas que cometeram os maiores erros ou os maiores crimes, fizeram e fazem o que fazem com base na sua própria história, com base no que aprenderam com a vida e com suas experiências anteriores. Eles acham que aquela era a única opção, a correta para aquele cenário. Quebrar esse paradigma é determinante para trazer todos para perto das soluções e propostas que visam atender às estratégias de negócio. Conhecer essas características humanas, faz de você mais paciente, no entanto, mais responsável por ser um agente de mudança.

Esses foram meus minutos de explanação! Um bom agosto para todos!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

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

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.