Gerenciando dívidas de tecnologia arquitetônica

Quando penso em dívida técnica, ainda me lembro da primeira aplicação que criei e que me fez perceber as consequências de uma arquitetura inadequada. Aconteceu no final da década de 1990, quando eu estava começando como consultor.

O cliente solicitou o uso da plataforma Lotus Notes para construir um sistema de compras para seus clientes. Usando o cliente Lotus Notes e um aplicativo personalizado, os usuários finais poderiam fazer solicitações que seriam rastreadas pelo aplicativo e atendidas pela equipe do proprietário do produto. Em teoria, era uma ideia muito legal – especialmente porque os aplicativos desenvolvidos para a web não eram predominantes e todos usavam o Lotus Notes diariamente.

O principal problema é que o design dos dados era muito relacional – e o Lotus Notes não era um banco de dados relacional. O design da solução exigia gerenciamento de esquema em cada documento do Lotus Notes e baseava-se em uma série de campos de vários valores para simular os relacionamentos entre atributos de dados. Foi uma bagunça.

Muita lógica no aplicativo Lotus Notes não teria sido necessária se uma plataforma melhor tivesse sido recomendada. O código-fonte era complicado de suportar. As melhorias na estrutura de dados resultaram em uma grande refatoração do código subjacente – sem mencionar a execução de trabalhos baseados em servidor para converter os dados existentes. Não me fale sobre o esforço por trás da criação de relatórios.

Desde o início da minha carreira, concentrei-me em fornecer uma solução que o cliente desejava, em vez de tentar oferecer uma solução melhor. Esta foi certamente uma lição que aprendi no início da minha carreira, mas nos anos que se seguiram a esse projecto, percebi que a consequência da dívida técnica arquitectónica é uma realidade infeliz que todos enfrentamos.

Vamos explorar um pouco mais o conceito de dívida tecnológica de arquitetura em um nível macro.

Dívida de tecnologia arquitetônica (ATD)

A Biblioteca Architectural Technical Debt (ATD) da Carnegie Mellon University fornece a seguinte definição .) de ATD:

Dívida técnica arquitetônica é uma abordagem de projeto ou construção que é conveniente no curto prazo, mas que cria um contexto técnico no qual o mesmo trabalho requer retrabalho arquitetônico e custa mais para ser feito mais tarde do que custaria para ser feito agora (incluindo aumento de custo ao longo do tempo) .

Na “Resposta rápida: Como gerenciar a dívida técnica da arquitetura” (publicado em 22/09/2023), o Gartner Group define ATD da seguinte forma:

Dívida técnica de arquitetura é aquele tipo de dívida técnica causada por desvios arquitetônicos, decisões arquitetônicas abaixo do ideal, violações da arquitetura de produto-alvo definida e das melhores práticas arquiteturais estabelecidas do setor, e compensações de arquitetura feitas para entrega mais rápida de software.

Em ambos os casos, os benefícios que muitas vezes produzem celebrações a curto prazo podem ser enfrentados com desafios a longo prazo. Isso é semelhante ao meu exemplo do Lotus Notes mencionado na introdução.

Para complicar ainda mais a situação, faltam ferramentas para ajudar a identificar e gerenciar a dívida tecnológica para a arquitetura de software em comparação com outros aspectos do desenvolvimento de software:

Para qualidade de código, observabilidade e SCA, existem ferramentas comprovadas com produtos como Sonarqube, Datadog, New Relic, GitHub e Snyk. No entanto, o segmento de arquitetura de software ficou para trás sem soluções comprovadas.

Isto é lamentável, dado o facto de a ATD ser consistentemente o maior – e mais prejudicial – tipo de dívida técnica, conforme encontrado no relatório “ Measure It? Gerenciar isso? Ignore isto? Praticantes de software e dívida técnica ”estudo de 2015 publicado pela Carnegie Mellon.

A ilustração a seguir resume a Figura 4 desse relatório, concluindo que as más escolhas de arquitetura foram claramente as líderes nas fontes de dívida técnica.

Se não for gerido, o ATD pode continuar a crescer ao longo do tempo a um ritmo crescente, como demonstrado nesta ilustração simples:

Sem mitigação, a dívida arquitetónica acabará por atingir um ponto de ruptura para a solução subjacente que está a ser medida.

Gerenciando ATD

Antes de podermos gerenciar o ATD, devemos primeiro entender o problema. Desmond Tutu disse certa vez: “Só existe uma maneira de comer um elefante: uma mordida de cada vez”.

A abordagem shift-left abraça o conceito de mover um determinado aspecto para mais perto do início do que para o final de um ciclo de vida. Este conceito ganhou popularidade com o shift-left para testes, onde a fase de teste foi movida para uma parte do processo de desenvolvimento e não para um evento separado a ser concluído após o término do desenvolvimento.

Shift-left pode ser implementado de duas maneiras diferentes no gerenciamento de ATD:

• Shift-left para resiliência – identificando fontes que têm impacto na resiliência e, em seguida, corrigindo-as antes que se manifestem no desempenho.
• Shift-left para segurança — detecte e mitigue problemas de segurança durante o ciclo de vida de desenvolvimento.

Tal como acontece com a mudança para a esquerda para os testes, um foco prioritário na resiliência e na segurança durante a fase de desenvolvimento reduzirá o potencial de incidentes inesperados.

Observabilidade arquitetônica

A observabilidade arquitetônica dá às equipes de engenharia a capacidade de abordar de forma incremental os desvios arquitetônicos em seus serviços em um nível macro. Na verdade, o Wall Street Journal relatou o custo para corrigir a dívida técnica em US$ 1,52 trilhão no início deste ano no artigo “O problema invisível de US$ 1,52 trilhão: software antigo desajeitado”.

Para ter sucesso, a liderança em engenharia deve estar totalmente alinhada com os seguintes objetivos organizacionais:

• Resiliência — para recuperar rapidamente de incidentes inesperados.
• Escalabilidade — para escalar adequadamente com a demanda do cliente.
• Velocidade — para fornecer recursos e melhorias alinhados às expectativas do produto.
• Adequação à nuvem — transformando soluções legadas em ofertas eficientes de serviços nativos da nuvem.

Recentemente descobri a plataforma de observabilidade arquitetônica baseada em IA da vFunction , que se concentra nos seguintes resultados:

• Descubra a arquitetura real das soluções através de análises estáticas e dinâmicas.
• Evite desvios de arquitetura por meio de visualizações em tempo real de como os serviços estão evoluindo.
• Aumente a resiliência dos aplicativos por meio da eliminação de dependências desnecessárias e melhorias entre domínios de aplicativos e seus recursos associados.
• Gerencie e remedie dívidas tecnológicas por meio da observabilidade orientada por IA.

Além disso, a plataforma vFunction oferece o benefício colateral de fornecer um caminho de migração para transformar soluções monolíticas em soluções nativas da nuvem. Depois que as equipes modernizarem suas plataformas, elas poderão observá-las continuamente em busca de desvios contínuos. Se as empresas já possuem microsserviços, elas podem usar o vFunction para detectar complexidade em aplicações distribuídas e resolver dependências que afetam a resiliência e a escalabilidade. Em ambos os casos, uma vez implementado, as equipes de engenharia podem mitigar o ATD bem antes de atingir o ponto de ruptura.

Na ilustração acima, as equipes de engenharia são capazes de mitigar a dívida técnica como parte de cada versão, devido à implementação da plataforma vFunction e a uma abordagem subjacente de mudança para a esquerda.

Conclusão

Meus leitores devem se lembrar que me concentrei na seguinte declaração de missão, que acredito poder ser aplicada a qualquer profissional de TI:

“Concentre seu tempo em fornecer recursos/funcionalidades que ampliem o valor de sua propriedade intelectual. Aproveite estruturas, produtos e serviços para todo o resto.” - J. Vester

A plataforma vFunction segue minha declaração de missão, ajudando as equipes de engenharia a empregar uma abordagem de mudança para a esquerda para a resiliência e segurança de seus serviços em nível macro. Esta é uma distinção importante porque sem essas ferramentas, as equipes provavelmente mitigarão em um nível micro, resolvendo dívidas tecnológicas que realmente não importam do ponto de vista organizacional.

Quando penso naquele aplicativo que me fez perceber os desafios da dívida tecnológica, não posso deixar de pensar em como essa solução gerou mais problemas do que benefícios com cada recurso introduzido. Certamente, a utilização do deslocamento para a esquerda apenas para a resiliência teria ajudado a revelar problemas com a arquitectura subjacente num ponto em que o custo de considerar alternativas seria viável.

Se estiver interessado em aprender mais sobre a solução vFunction, você pode ler mais sobre ela aqui .

Tenha um ótimo dia!