Dívida técnica para escalar: evitando a falência

A encruzilhada é a mesma coisa inevitável pela qual todas as empresas de software de sucesso têm de passar. Não é um MVP ruim que passou no teste de adequação do produto ao mercado, mas um sistema multifacetado que atende milhares ou milhões de utilizadores foi desenvolvido. Mas há algo por baixo da superfície. Novos lançamentos chegam lentamente. Semanas são gastas no desenvolvimento de mudanças simples. A taxa de correção de bugs é maior do que a taxa de correção de problemas antigos. A base de código está a fazer com que os engenheiros gastem mais tempo a lutar do que a criar novas funcionalidades. Esse cenário se repete com frequência alarmante no mundo da tecnologia. Empresas que pareciam destinadas a se tornar gigantes estão sendo sufocadas pelo seu próprio sucesso inicial e precisam ou continuar em um estado de estagnação indulgente ou retomar o seu desenvolvimento com esforços de reengenharia caros. Os culpados não são os programadores incompetentes ou a falta de recursos. Em vez disso, as origens residem nas escolhas arquitetónicas básicas que foram feitas durante aqueles meses iniciais decisivos, quando a velocidade de comercialização era mais importante do que a manutenção a longo prazo. Aprender como as decisões técnicas se mantêm ao longo do tempo é uma das áreas de conhecimento mais importantes para qualquer líder que comanda uma organização tecnológica em crescimento. As escolhas feitas hoje podem acelerar o crescimento no futuro ou criar amarras invisíveis que atrapalham todas as outras iniciativas. A diferença entre as empresas que crescem e as que fracassam muitas vezes está na sabedoria arquitetônica usada da maneira certa e na hora certa.

Existem atalhos entre o protótipo e o software pronto para produção que são feitos para durar pouco, mas têm um retorno bem demorado. O desenvolvimento nas fases iniciais vai focar mais em prototipagem rápida e funcionalidade direta do que em questões abstratas como modularidade ou extensibilidade. Esse método faz todo o sentido quando o objetivo principal é confirmar hipóteses e aproveitar as oportunidades do mercado antes que os concorrentes entrem. Mas essas vitórias táticas podem criar pontos fracos estratégicos. Arquiteturas monolíticas que pareciam ótimas para grupos pequenos acabam sendo um problema quando as organizações crescem. Esquemas de banco de dados que eram perfeitos no começo ficam difíceis de mudar para dar suporte a novos recursos. Centenas de sistemas de autenticação de utilizadores não aguentam milhares. Os padrões de integração que funcionavam bem com alguns serviços de terceiros ficam fora de controle por causa do tamanho do ecossistema.

Uma API ineficiente pode ser capaz de gerir a carga de tráfego atual sem qualquer problema, mas entrará em colapso miseravelmente quando a utilização duplicar. Uma base de código bem integrada pode permitir o desenvolvimento rápido de funcionalidades no início, mas o desenvolvimento paralelo pode tornar-se ainda mais desafiante com o aumento do tamanho da equipa. As empresas muitas vezes tendem a interpretar mal esses sintomas como dificuldades de crescimento que são temporárias e não sistémicas e precisam de correção arquitetónica. A liderança pode acreditar que mais engenheiros irão acelerar o processo de desenvolvimento, apenas para perceber que a sobrecarga de coordenação e os conflitos de código realmente retardam o desenvolvimento. As questões que surgem com o desempenho são tratadas aumentando a potência dos servidores, em vez de fazer uma melhoria básica de eficiência. As questões de segurança são resolvidas com uma solução pontual, em vez de uma revisão do sistema. As ramificações e o alcance económicos vão muito além da produtividade na engenharia. A experiência dos clientes é afetada porque os sistemas são menos estáveis e responsivos. Quando a plataforma não consegue acomodar potenciais clientes empresariais, as oportunidades de vendas são perdidas. As vantagens competitivas são reduzidas porque os recursos são desenvolvidos lentamente. Isso torna o processo de recrutamento mais difícil, porque os engenheiros não querem trabalhar em organizações com disfunções técnicas.

Construindo uma arquitetura modular

Para desenvolver uma arquitetura eficaz, é preciso conhecer os princípios que ajudam a criar um bom design, bem como as limitações práticas que devem ser consideradas ao decidir se algo deve ou não ser implementado. A base começa com a modularidade e a separação de interesses. Os sistemas desenvolvidos estruturam a funcionalidade em elementos discretos, interfaces definidas e responsabilidades. Essa estratégia permite que as equipas criem e façam alterações ou substituam partes individuais sem perturbar todo o sistema. As arquiteturas orientadas a serviços são uma boa representação desse conceito em geral. Em vez de desenvolver aplicações monolíticas com todas as funcionalidades usando a mesma base de código e implementando de maneira semelhante, as organizações podem dividir os sistemas em serviços dedicados que interagem por meio de APIs consistentes. Os serviços são independentes e podem ser desenvolvidos, testados e implementados por diferentes equipas simultaneamente, sem interferir uns nos outros.

O truque está em definir contratos distintos entre várias secções do sistema e não ter um acoplamento rígido que faça com que a propagação das alterações se espalhe em todas as direções por toda a base de código.

Considerações sobre a arquitetura de dados

Deve-se prestar atenção especial à arquitetura de dados, pois essas decisões podem se tornar as mais caras de desfazer no caso de bancos de dados. O esquema de otimização de casos de uso pode ser um sério gargalo na alteração de requisitos. Empresas eficazes investem em modelos de dados que são flexíveis o suficiente para suportar o crescimento sem a necessidade de migrações em massa. Isso pode ser feito da seguinte forma:

• A escolha de bases de dados de documentos em vez de bases de dados relacionais, com base nas suas necessidades
• O uso de uma estratégia de controle de versão de dados
• A criação de APIs que ocultam as implementações de armazenamento subjacentes

Equilibrando as necessidades presentes e futuras

Os requisitos de escalabilidade devem encontrar um equilíbrio entre os requisitos atuais e as oportunidades futuras. Quando se projetam soluções exageradas para problemas que talvez nunca venham a existir, está-se a desperdiçar recursos e a tornar as coisas mais complicadas do que precisam ser. Soluções subdimensionadas para acomodar o crescimento previsível causam dívidas técnicas que crescem exponencialmente. A melhor solução é reconhecer os gargalos de escalabilidade nos estágios iniciais e implementar uma arquitetura que possa ser escalada sob carga de forma elegante.

Observabilidade e segurança

A observabilidade é outro fator arquitetónico que é crítico e geralmente não é levado em consideração nas fases iniciais do desenvolvimento. Qualquer sistema que não tenha recursos completos de registo, monitorização e depuração torna-se mais difícil de manter à medida que se torna mais complexo. É muito mais barato incorporar a observabilidade em toda a arquitetura inicialmente do que posteriormente, mas as experiências são inestimáveis para a otimização e a resolução de problemas. O mesmo se aplica à arquitetura de segurança, que também é um investimento inicial. A adoção dos componentes básicos de autenticação, autorização e proteção de dados permitirá o desenvolvimento rápido de funcionalidades sem incorrer em dívidas de segurança. Por outro lado, a abordagem da segurança como uma reflexão tardia tende a ser dispendiosa para redesenhar nos casos em que as necessidades de conformidade ou os modelos de ameaças são modificados.

Tomada de decisões técnicas

As empresas que querem evitar armadilhas arquitetónicas devem implementar modelos de tomada de decisões técnicas que sejam equilibrados em termos de ritmo a curto prazo e resistência a longo prazo. Isso inclui:

• Desenvolver procedimentos de revisão arquitetónica sobre as principais escolhas técnicas
• Documentar as compensações
• Avalie frequentemente a dívida técnica incorrida em relação à prioridade do negócio

Testes e integração

O investimento em testes automatizados e integração contínua também compensa, pois permite refatorar com confiança e fazer investimentos arquitetónicos. Quando as equipas conseguem confirmar rapidamente as alterações, têm mais hipóteses de implementar ajustes proativos, em vez de adiar indefinidamente o processo de manutenção. O desenvolvimento paralelo também é possível através de conjuntos de testes abrangentes que identificam problemas de integração numa fase inicial.

Revisão de código e partilha de conhecimento

A revisão dos códigos deve verificar tanto as implicações arquitetónicas como a correção no funcionamento. Apenas as revisões que se preocupam com a funcionalidade imediata não darão a oportunidade de detectar e remediar problemas estruturais antes que eles se tornem arraigados. A melhoria da qualidade das decisões em toda a organização pode ser alcançada através da formação de engenheiros para identificar e comunicar compromissos arquitetónicos.

As apresentações técnicas frequentes e as reuniões de arquitetura permitem manter o entendimento comum no contexto das equipas de engenharia em expansão.

Revisões regulares da arquitetura

Avaliações arquitetónicas regulares oferecem a oportunidade de se distanciar do desenvolvimento diário e analisar a saúde dos sistemas em uma escala maior. Essas revisões devem determinar para onde a dívida técnica foi direcionada, se as arquiteturas atuais atendem às necessidades do negócio e o que pode ser feito para melhorá-las, a fim de oferecer o retorno mais otimizado do investimento em engenharia.

O processo pós-arranque para escalar está destinado a ser uma evolução arquitetónica, mas a forma como isso acontece não precisa de ser reescritas dispendiosas ou mesmo estagnação no desenvolvimento. As empresas que tomam decisões arquitetónicas prudentes desde o início estão em melhor posição para alcançar a sustentabilidade, enquanto as empresas que negligenciam os aspetos estruturais das estruturas geralmente acabam por ficar sem casa devido aos seus próprios feitos. A maioria das empresas de tecnologia que se orgulham de modelos de sucesso não considera a arquitetura como uma decisão, mas sim como uma disciplina contínua. Elas desenvolvem sistemas capazes de um desenvolvimento elegante, investem nas ferramentas e processos necessários para torná-los capazes de mudanças confiáveis e têm o conhecimento de arquitetura para fazer boas escolhas quando realmente importa. O custo da disciplina arquitetónica não é nada comparado com o custo da falência técnica. Ao perceber que as decisões tomadas numa fase inicial se multiplicam com o tempo e através da aplicação consistente de princípios arquitetónicos comprovados, as organizações serão capazes de desenvolver software que só aumentará o seu sucesso a longo prazo. A questão não é se surgirão problemas arquitetónicos, mas se eles serão percebidos e resolvidos antes que se tornem problemas aparentemente insuperáveis.