As armadilhas ocultas da seleção de pilhas de tecnologia: um guia para diretores técnicos

A taxa de insucesso dos projetos de tecnologia empresarial é bastante surpreendente, uma vez que cerca de 70% deles não são bem-sucedidos devido a más escolhas de stacks. Os líderes tecnológicos são normalmente atraídos por novas arquiteturas e novas ferramentas de última geração, mas tais decisões conduzem frequentemente a uma elevada dívida técnica e a reescritas dispendiosas do sistema. Os erros mais comuns são previsíveis: focar em tecnologias da moda em vez de alinhamento de negócios, ignorar a necessidade de manutenção ao longo do tempo e escolher a ferramenta que não se encaixa no conhecimento da equipa. Esses erros resultam em refinamentos caros, gargalos de desempenho e equipas de desenvolvimento desmotivadas. A análise apresenta casos reais em que projetos foram prejudicados devido a decisões erradas em tecnologia, e as razões por trás do fracasso tecnológico são determinadas. Usando estudos de caso práticos, oferecemos estruturas práticas que podem orientar os líderes tecnológicos na tomada de decisões informadas que possam servir aos objetivos do negócio, capitalizar os pontos fortes da equipa e permitir um crescimento sustentável.

Os executivos de tecnologia caem repetidamente em armadilhas reconhecíveis que prejudicam as suas escolhas de pilha. As novas tecnologias são o tema de discussão que geralmente obscurece a visão dos impactos a longo prazo e as questões de implementação prática. A dívida técnica é cumulativa, na medida em que não há aviso de que uma organização está numa armadilha financeira de sistemas caros e ineficientes que impedem, em vez de apoiar, o crescimento dos negócios.

O fascínio das tecnologias em alta

Os diretores técnicos costumam escolher tecnologias que estão na moda na indústria, e não aquelas que são necessárias estrategicamente. Esse estilo cria um grande fosso entre as necessidades do negócio e a expansão técnica. A atratividade das novas estruturas tende a superar os padrões de avaliação prática. A validação social acaba por ser uma substituição prejudicial da tomada de decisões baseada em evidências. As organizações estão a seguir as tecnologias mais recentes devido à pressão para parecerem modernas como todos os outros e porque tal iniciativa é ambiciosa e atraente. A consequência dessa mentalidade de rebanho é a introdução de soluções complexas que exigem muitas soluções alternativas e manutenção adicional.

Conclusão sobre a manutenção implícita

As organizações muitas vezes não têm uma visão completa do investimento em tecnologia, no sentido de que o desenvolvimento inicial não é o fim. A análise de software empresarial mostra que, em grandes bases de código, a manutenção consome cerca de 75% do esforço total. Essa carga contínua envolve:

• Testes
• Detecção e correção de bugs
• Ajuste de desempenho
• Testes de compatibilidade
• Refatoração
• Atendimento ao cliente
• Documentação

As assinaturas de software geram novas armadilhas de custos. Embora não sejam caras no início, os custos são incorridos a longo prazo, especialmente com a expansão das equipas e a necessidade de comprar mais licenças. Recursos premium, serviços de suporte e atualizações de armazenamento geralmente têm cobranças ocultas que não eram evidentes no momento da análise.

Desalinhamento das capacidades da equipa

O alinhamento das competências da equipa é um dos aspetos importantes que não deve ser ignorado na seleção de tecnologia. Ao desenvolver novas estruturas, as organizações tendem a selecionar frameworks sem avaliar os seus programadores para entender quanta experiência eles têm no processo adequado de implementação e manutenção. As equipas que desenvolvem com tecnologias com as quais não estão bem familiarizadas têm de lidar com:

• Curvas de aprendizagem íngremes
• Ciclos de desenvolvimento mais lentos
• Taxas de defeito mais elevadas
• Má qualidade da implementação

A liderança pode ser técnica e superestimar o custo das especificações técnicas e subestimar o custo da formação, a complexidade da integração e as perdas de produtividade. Ferramentas que não se adequam às capacidades da equipa levam a uma adoção deficiente e a baixos retornos sobre o investimento. Pense na escolha do Ruby on Rails: ele é frequentemente escolhido por causa da sua velocidade de desenvolvimento, facilidade e uma grande variedade de bibliotecas que ajudam na prototipagem rápida. Mas essas vantagens só aparecem quando as equipas já conhecem Ruby. A curva de aprendizagem deve estar de acordo com a experiência dos programadores, para que não haja gargalos na produtividade. A qualificação forçada no meio do projeto pode destruir os ganhos.

Quando projetos de tecnologia falham, analisamos estudos de caso em diferentes setores e tamanhos de empresas para entender os motivos. Ambas as organizações enfrentaram graves problemas técnicos que podem estar diretamente relacionados às decisões sobre a pilha de tecnologia. As causas fundamentais revelaram-se inesperadamente semelhantes, entre arquiteturas demasiado complicadas e problemas de desempenho e escalabilidade. São apontados três casos ilustrativos nesta secção em que ocorre um desalinhamento entre as decisões da pilha e os requisitos do produto ou as capacidades da equipa.

Complexidade dos microsserviços em aplicações simples

Uma startup de SaaS sofreu por ter adotado microsserviços antes da hora. Em mais de 18 meses, a empresa criou várias tecnologias diferentes, o que levou a um debate sobre ter um sistema fragmentado, onde a propriedade ficava mudando de mãos entre os membros da equipa. No início, esse sistema parecia ser inovador, dividindo aplicações em aplicações menores que, em teoria, eram escaláveis. No entanto, a falta de membros da equipa com experiência ou atenção para operar a plataforma de forma eficaz transformou o sistema num caos. O erro essencial foi introduzir uma arquitetura complicada antes da exigência do produto. Os microsserviços são uma forma de lidar com a complexidade, mas isso não é um privilégio gratuito. Em vez de facilitar o crescimento, a abordagem dos microsserviços acabou por se tornar um fardo para um produto que exigia iterações rápidas, em oposição à sobrecarga dos sistemas distribuídos. A certa altura, a empresa não conseguiu adicionar novos campos e usar alguns gatilhos de API devido a limites da plataforma, o que levou a falhas nas funcionalidades principais. A solução complexa foi completamente abandonada devido à frustração dos membros da equipa, que passaram a usar folhas de cálculo em vez da pilha superdimensionada.

Restrições de desempenho em aplicações de jogos

Uma empresa de jogos testou o React Native para criar um jogo móvel de alto desempenho, mas isso criou dificuldades técnicas insuperáveis em experiências com gráficos intensivos. Embora o React Native tenha vantagens de desenvolvimento multiplataforma, ele basicamente não tinha recursos de desempenho para suportar os requisitos altamente complexos dos jogos. A equipa de desenvolvimento descobriu que o desempenho do thread JavaScript estava comprometido. Por mais que o React Native afirme ser capaz de fornecer pelo menos 60 quadros por segundo, o aplicativo continuava a perder quadros ao usar animações e interações complexas. O diagnóstico do desempenho indicou que qualquer processo que exigisse mais de 100 ms criava atraso para o utilizador. Essas restrições eram desastrosas para jogos que precisavam de física ou renderização mais complexas. A equipa tentou otimizar os módulos nativos, mas a disparidade básica da ferramenta e a necessidade ainda persistiam. Embora o React Native permita o desenvolvimento em várias plataformas usando apenas um conjunto de bases de código, isso tornou-se menos importante quando o produto final não conseguiu atingir um padrão mínimo de desempenho.

Vulnerabilidades de dimensionamento de bases de dados em aplicações financeiras

Um aplicativo financeiro de tecnologia financeira foi lançado com um banco de dados SQL monolítico mais antigo e, inicialmente, funcionou bem. Mas, à medida que os volumes de transações cresciam, o sistema não conseguia funcionar e escalar. A latência e os atrasos no processamento em lote tornavam a análise em tempo real praticamente impossível. O principal erro cometido pelo diretor de tecnologia foi não prever as necessidades de escalabilidade do processamento de dados financeiros. O design da base de dados não foi concebido para suportar:

• Escalonamento horizontal
• Métodos de balanceamento de carga
• Picos de volume de transações

O desempenho ficou muito ruim e o tempo de resposta à consulta aumentou para minutos. Essa degradação foi desastrosa em aplicações onde a velocidade das transações é muito importante para o utilizador e em aplicações financeiras. Depois de fazer uma avaliação técnica bem detalhada, a empresa mudou para um banco de dados distribuído com arquitetura HTAP (Hybrid Transactional/Analytical Processing). Essa mudança permitiu processar milhares de transações por segundo com baixa latência e, ao mesmo tempo, fazer análises em tempo real.

Nos estudos de caso, foram observados três padrões de falhas que causaram falhas na pilha de tecnologia. Todos os padrões são indicadores de uma grave desconexão nas abordagens de seleção e implementação de tecnologia nas organizações.

Desalinhamento da complexidade entre negócios e tecnologia

Um dos erros mais comuns na escolha da pilha tecnológica é quando as organizações obtêm uma arquitetura artificialmente complicada que não corresponde às exigências do negócio. A maioria das empresas apresenta várias camadas e subsistemas, cada um dos quais supostamente o melhor do setor, mas o sistema global é lento, pouco fiável e caro. O resultado dessa prática é:

• Aplicações mais lentas causadas por um grande número de camadas
• Complicado por várias transferências
• Não é confiável, pois cada camada tem diferentes modos de falha

No caso de negócios baseados em clientes, qualquer escolha inadequada de tecnologia tem um efeito direto na experiência do cliente, em termos de tempos de carregamento lentos e interrupções, o que aumenta as taxas de rotatividade.

Dívida técnica e refatoração

Investir cedo na tecnologia errada gera dívidas técnicas que ficam cada vez mais difíceis de resolver. Na verdade, a maior parte dos orçamentos de TI das empresas é destinada à manutenção e suporte de software, e não à inovação. Depois que as organizações investem pesadamente em pilhas problemáticas, a falácia do custo irrecuperável pode se tornar eficaz para impedir a necessidade de mudar as coisas. A refatoração deve ser valiosa e deve se concentrar em atender às necessidades reais, em vez de especulações. A refatoração em grande escala, que não pode ser acomodada nos processos normais de desenvolvimento, é um desafio para muitas organizações. A reformulação de elementos arquitetónicos essenciais geralmente envolve a remoção e recriação de recursos, o que expõe dados comerciais importantes a riscos.

Pontos fracos na documentação e integração

Falhas e deficiências na documentação da empresa resultam em altos custos ocultos, pois o processo de integração é mais demorado do que o necessário quando as práticas de documentação são deficientes. Muitos departamentos de engenharia estão a ficar para trás na produção de documentação interna de qualidade, mas o preço da inconsistência é muito mais alto do que o custo de integrar a documentação nos processos. Os novos membros da equipa perdem muito tempo à procura e redescobrindo respostas, ou cometem erros que poderiam ser evitados se as informações estivessem devidamente documentadas. Esse cenário causa um alto nível de atrasos na produtividade, em que alguns programadores não conseguem entregar resultados de forma eficaz durante semanas e até meses.

Para evitar armadilhas de seleção de pilha, é essencial ir além da evitação de palavras da moda. Isso requer que você pense cuidadosamente sobre o que está construindo, a pessoa que está construindo e a maneira como o seu sistema irá crescer e se desenvolver.

Defina o âmbito do produto

Antes de comparar as ferramentas, determine a finalidade e a vida útil esperada do produto. Trata-se de um MVP que se desenvolve rapidamente e tem objetivos de curto prazo? Ou uma plataforma que se presume que cresça progressivamente em cinco anos? Além disso, antecipe a evolução. Quando você antecipar integrações, análises ou adição de funções de utilizador, escolha uma pilha que seja utilizável nesses cenários sem precisar reconstruir toda a pilha.

• Em produtos de curto prazo, sistemas de desenvolvimento rápido (por exemplo, MEAN ou Firebase) vão oferecer velocidade e flexibilidade
• Para sistemas de longo prazo, concentre-se em arquiteturas modulares e sustentáveis que não precisarão ser reescritas significativamente

No papel, uma pilha pode parecer perfeita, mas quando ninguém na sua equipa consegue depurar nada na produção, ou nem mesmo ajustar a pilha para ter um melhor desempenho, ela se torna um problema.

• Escolha tecnologias com as quais os seus engenheiros já estejam familiarizados, caso haja pressão para cumprir prazos de entrega
• Planeie com antecedência para usar uma pilha compatível com o futuro, mas reserve tempo para auditar o código, integrar e treinar

Considera os requisitos externos

As seleções de pilha não são feitas no vácuo. As necessidades de conformidade, orçamento e integração, entre outras, são necessidades reais que devem ser refletidas em todos os níveis da sua arquitetura. Conformidade e segurança: em fintech ou saúde, certifique-se de que a sua pilha seja compatível com logs de auditoria, controle de acesso baseado em funções e criptografia sempre compatível com versões superiores. Orçamento: Conta com licenciamento, infraestrutura, serviços geridos e o custo de outros custos ocultos, como o uso de API de terceiros ou até mesmo bloqueio. Integração: Pode haver falhas se a sua pilha não se integrar com outros sistemas. Acumule o fluxo de dados para cima e para baixo.

Avalie a sustentabilidade a longo prazo

O que é sustentável hoje pode não ser amanhã. Procure por:

• Atualizações estáveis: atualizações instáveis ou falta de suporte da comunidade podem se tornar um problema
• Ecossistema bem documentado e estabelecido: isso vai facilitar a integração e reduzir a dependência de conhecimentos internos
• Simplicidade operacional: quando a tua pilha precisar de ajustes ou manutenção de devops, ela pode não ser escalável para uma equipa pequena

Desempenho e complexidade operacional

Escolher uma pilha implica uma troca:

• Modelo de escalabilidade: É possível escalar horizontalmente com a adição de mais instâncias ou está limitado a escalar verticalmente com um monólito?
• Desempenho sob carga: Algumas pilhas são melhores para fazer transações simultâneas e leves (por exemplo, Node.js) ou são melhores para executar transações com processadores transacionais pesados (por exemplo, Spring Boot)?
• Complexidade da operação: A sua equipa implementa e mantém a operação de forma fiável ou trata-se de uma operação improvisada que está a implementar?

Toma decisões de pilha que facilitem o crescimento e não a dívida técnica.

Não existe nenhuma pilha à prova de futuro, mas existem pilhas mais flexíveis. A decisão certa está alinhada com a sua visão de negócio, missão do produto e competências da equipa e requisitos de escala. Permite o crescimento rápido no nosso tempo e não é um obstáculo no futuro. Os CTOs mais eficazes não se limitam a selecionar ferramentas. Eles constroem sistemas que duram.

Construir uma pilha de tecnologia é uma das decisões mais importantes que os diretores de tecnologia tomam na carreira. Quando feito da maneira certa, torna tudo escalável, eficiente e mais rápido. Se for mal feito, vai causar dívida técnica, inovação estagnada e equipas de trabalho frustradas. Toma cuidado para não tomar decisões no início que te impeçam de avançar no futuro. Pensa antes de agir, planeia e investe numa pilha que se expanda à medida que tu te expandes. É tudo uma questão de compromisso entre:

• Exigências de curto prazo e perspetivas de longo prazo
• Competências da equipa e necessidades do negócio
• Inovação e sustentabilidade

Os líderes tecnológicos podem tomar decisões estratégicas que facilitam o desenvolvimento organizacional, em vez de o dificultar, evitando as armadilhas e utilizando estruturas estratégicas.