Arquitetura Corporativa para Todos

Artigo / Post

Dívidas Técnicas: um risco corporativo que cresce silenciosamente

É necesssário  evolução do pensamento crítico sobre as dívidas técnicas para uma proposta sustentável de dívidas corporativas.

Dívidas Técnicas: um risco corporativo além do código

Dívidas técnicas NÃO SÃO apenas um problema de projeto de software, são um RISCO CORPORATIVO. Uma dívida técnica, devido a sua natureza, só tende a aumentar pela constância da evolução e inovação. Ela se manifestam em diversas camadas:

  • ✅ Código ineficiente
  • ✅ Testes ausentes
  • ✅ Falta de conhecimento técnico
  • ✅ Adoção de IA sem governança
  • ✅ Segurança negligenciada desde a concepção
  • ✅ Prazo curtos e/ou irrealistas
  • ✅ Falta de recursos técnicos e/ou humanos

 

Uma postura mais holística (O todo é mais que a simples soma das partes) sugere a ambidestria como ponto de partida a ser considerado nas decisões, equilibrando a eficiência operacional com constante atualização dos sistemas, respeitando-se suas limitações. Diante das rápidas mudanças tecnológicas, é ingênuo pensar que tudo pode ser atualizado ao estado mais recente ou que sistemas antigos estarão prontos para a próxima inovação.

Quando adquiridas de forma CONSIENTE , podem alavancar oportunidades:

  • Acelerar a entrada em novos mercados
  • Responder rapidamente a mudanças
  • Adaptar-se as restrições impostas por clientes, parceiros e mercado.

Abordar apenas problemas técnicos durante os períodos do ciclo de entrega pode dar aos líderes uma falsa sensação de progresso, porem isso só alimenta o ciclo continuo das dívidas.


Métricas da arquitetura corporativa

Quando as dívidas técnicas se tornam transparente e instrumentos de baixa fricção, frente aos desafios das mudanças para o negócio no presente,  permite explorar o futuro para as oportunidades de crescimento e inovação. As dívidas técnicas deve ser um dos objetos de análise da arquitetura corporativa para uma evolução sustentável, discutida em seus desdobramentos, transformando-se em dívidas corporativas de interesse de todos.


No âmbito de arquitetura corporativa, não somente deve ser discutido o mapeamento e soluções das dívidas técnicas como também os apetites de riscos como fatores para as decisões.


Na observância das dívidas corporativas é que se encontra a compreensão do estado atual e as soluções para o estado futuro, revelando oportunidades de alto impacto para problemas recorrentes como desempenho, conectividade, resiliência , estabilidade , satisfação dos clientes e responsabilidades tecnológicas sustentáveis a longo prazo.


Tenham um excelente dia! Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável.

Compatilhe

0 0 votos
Avaliação Global
0 Comentários
Categorias

Sobre o Autor

Picture of Fernando Cerqueira

Fernando Cerqueira

Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.

Outros Posts

Categorias

IA : Uma sociedade colocada em xeque. “Governando IA para o bem e para todos”

A motivação deste artigo “nasceu” da reflexão sobre o vídeo abaixo (Um robô bípede sendo chutado empurrado em um evento na Ásia). Vídeo : https://www.youtube.com/watch?v=nJoVl-og42M Você sente algum sentimento de desconforto assistindo o vídeo? Por quê ?  Convido você a me acompanhar nesta pequena jornada de reflexão , tomando como

Adotar classes seladas em .NET por padrão é uma ótima escolha

Adotar classes seladas em .NET por padrão é uma ótima escolha. Saiba por que! Em .net todas as classes que são criadas por padrão (template), permitem herança. Esta opção padrão deixa mais flexível qualquer implementação por herança, mas sendo sincero, acredito não ser esta a melhor opção : Uma classe

Singleton: Anti-pattern ou apenas mal interpretado?

O padrão de projeto Singleton garante que apenas uma instância de uma classe exista durante a execução de um programa, fornecendo um ponto de acesso global a essa instância. Admito que já o classifiquei imprudentemente como um anti-pattern, mas estou aqui para me redimir. O Singleton resolve um problema recorrente

"devolver um http status-code diferente de (2xx a 3xx) para um liveness só faz sentido quando a aplicação não é mais capaz de responder a nenhuma requisição porque está travada ou se encontra um estado de conflito."

Fernando Cerqueira | Arquiteto Corporativo

Sua Reflexão

0
Adoraria saber sua opinião, comente.x