O foco nem é necessariamente atualizar tecnologia para usar coisas da moda ou algo assim, é realmente para reestruturar as coisas que foram feitas como MVP no início e estão lá até hoje. Revisitar o projeto para deixa-lo mais sólido. Não existe documentação ou registro das regras de negócios, o que deixa tudo mais complicado. "Isso deu erro porque o código ta errado? A regra escrita ta certa? O sistema faz o que esperam que ele faça?" Hoje temos dificuldade em manter e criar novas funcionalidades em cima da base caótica e isso pra mim também tem um custo. E acho que hoje é um custo invisível. Questionam o custo de planejar o ajuste de algo pronto, mas não consideram que uma base boa garante uma série de vantagens que economizam dinheiro e logo, refletem no bolso. Concordo com o que você falou sobre EMPRESA DE TECNOLOGIA, eu falei assim mais para deixar nos mesmos termos que eles mesmos dizem. E sobre refatorar ou refazer tudo, com certeza não é algo tratado dessa forma. A vida não vai parar pra gente refazer o que existe. hehehe Acho mesmo que o lance é mostrar o ganho financeiro que pode existir, mas como disse na resposta do outro comentário, a dúvida é se eu vou conseguir fazer isso. Sou dev, não estou acostumado a tratar de tecnologia nesse nível de gestão e tals... por isso uma das minhas críticas foi não ter uma liderança no setor.
É muito difícil mesmo, eu já passei (e ainda passo em alguns casos) as mesmas dores que você. Toda empresa quer que um projeto saia rápido e vem com o bordão (faz um MVP depois melhoramos) e no fim vende o MVP e fica por isso mesmo.
No meu caso sempre que tive sucesso em encaixar as soluções foi da seguinte forma. Entre uma tarefa e outra caso sobre um espaço tento melhorar algo que seja tangível, depois apresento para alguém que tenha o "poder" de autorizar a mudança o que foi feito e mostro o que agregou. Se gostarem é a hora que tento vender isso para o restante. Vou te dar um exemplo (sei que não é arquitetura de software mas uma situação que tive que tomar essa medida).
Exemplo que aconteceu comigo
Imagina um sistema que em uma determinada funcionalidade tenha um fluxo de trabalho com 5 telas, em uma dessas telas eu ia precisar fazer uma pequena implementação (vamos chamar aqui de tela 3).
Todas as telas eram lentas e feias, sendo assim estimei fazer a implementação com um pouco de tempo a mais para eu poder melhorar a beleza da tela 3 e sua velocidade.
Apresentei a tela 3 com sua beleza e velocidade para quem solicitou, e comparei com as outras telas (“O joaquim olha como essa tela está bem melhor seu layout e sua velocidade comparado com as outras”)
Joaquim observou e disse, “É mesmo”.
Esse foi o momento chave onde eu disse, “Então o sistema vai ficar estranho se uma etapa é muito lenta e com o layout feio e uma única tela dessa forma. Não posso aplicar isso nas outras, vou precisar de mais uma semana”.
E com sorte obtive o sim. Com essa abordagem consegui mostrar algo tangível e convencer de alterar o resto desse fluxo de trabalho.
Sei que nem sempre isso vai funcionar, mas nessa circunstância deu certo.