Introdução
Todas as empresas desejam manter seus ativos de hardwares e softwares atualizados. No entanto, esbarram em custos significativos de atualizações de licenças, complexidade dos legados e ‘dívidas técnicas’ dos ativos de software.
Com a adoção de microsserviços (pelos motivos corretos ou não), muitas empresas verificaram que os ativos de software se multiplicarem (Como “Gremlins” quando são submetidos a água transformando-se em monstrinhos descontrolados e grandes causadores de pânico e tragédias, que aterrorizam todos a sua volta).
Não somos imunes ao “Efeito Gremlins”. Empresas tem centenas de “bichinhos” ativos e precisamos manter eles controlados e comportados. Devido a dinâmica do mercado acaba-se criando um ambiente propício para “água” e os benditos “gremlins” se multiplicam de forma impressionante! Cabe aos times estruturantes (Arquitetura/infraestrutura/segurança/etc.) manter o controle do fator de multiplicação destes adoráveis bichinhos, uma vez que é inevitável seu crescimento.
Vivemos hoje em mundo muito mais “acelerado”. As mudanças de comportamento e necessidades cada vez mais crescente dos nossos clientes, exige do mercado de tecnologia da informação um avanço constante em atualizações. Novas atualizações de frameworks, atualizações de segurança e pacotes de terceiros vem se tornando um grande problema para as empresas. Novas soluções mais performáticas com menores custo e maiores recursos parecem fazer parte desta equação que não “bate”.
As áreas de TI das empresas precisam movimentar seus ativos de software para estas atualizações. Algumas das justificativas para este movimento podem ser: Garantir a atualização de segurança contra falhas conhecidas, manter-se atualizado com novas funcionalidades, habilitar novos recursos de tecnologia para inovação e oportunidades de negócio. Este tipo de “dor” é uma atividade que muitas empresas já endereçam, porém na maioria das vezes, focadas em softwares prontos de terceiros e sistemas operacionais.
“Software Currency” é uma expressão que significa de quão atual tal Software será mantido em relação à emissão de atualizações, upgrades, novos lançamentos e novas versões do licenciante aplicável de ou para tal Software.
Os times de arquitetura corporativa deveriam expandir suas atividade para “Software Currency”, principalmente microsserviços e suas dependências (pacotes próprios ou de terceiros) , fazendo com que esta atividade faça parte do “software life cycle”, sendo um requisito para todas as atividades de evolução.
As Leis de Lehman
Um software é concebido para atender a um proposito. Um propósito evolui em sua necessidade, ou mesmo perde a relevância ao longo do tempo. A evolução do software trata do desenvolvimento contínuo após sua concepção e visa atender às mudanças dos requisitos de negócios (em constante mudança), corrigir defeitos e integrar-se a outros sistemas. Meir Lehman e László Bélády, foram 2 cientistas e pesquisadores na área da computação, que na década de 70 analisaram, formularam e aprimoraram diversos fenômeno da evolução do software que são conhecidas como as “Leis de Lehman”. Destaco 3 destas “leis” para nosso ensaio e proponho juntos, fazemos algumas reflexões:
Mudança contínua : “Um software deve ser continuamente adaptado, senão torna-se aos poucos, cada vez menos satisfatório. A cada alteração no ambiente em que ele roda que exija nele melhorias, não fazê-las o tornarão progressivamente menos satisfatório naquilo para o que foi construído.” (Meir Lehman e László Bélády)
Durante a evolução do seu software, é esperado que haja mudanças. Não atender as mudanças torna o software obsoleto, mas ao fazê-lo é exigido melhorias, mas quais? Não basta apenas entregar novas funcionalidades em seu software, cada uma dessas evoluções afeta progressivamente a deterioração de sua arquitetura e/ou parâmetros de qualidade, faz sentido para você? Antes mesmo de você parar para responder e refletir, gostaria de apresentar outra “lei” complementar:
Depreciação da Qualidade : “Os softwares desenvolvidos para resolver problemas do mundo real se depreciam progressivamente se eles não receberem as mudanças necessárias para adaptar-se ao que acontece em seu ambiente operacional durante todo o tempo de seu ciclo de vida útil.” (Meir Lehman e László Bélády)
Voltando então a reflexão, além das alterações do próprio código afetar a qualidade e arquitetura do software, elementos do seu ambiente operacional (ecossistema talvez fosse mais adequado) influenciam em depreciar o seu software… Isso começa a fazer sentido quando se fala que um software passar a ser um legado desde o primeiro momento que é colocado em produção. Faz sentido também para você? As reflexões compartilhadas até aqui nos levar a acreditar que: Ampliar o escopo de alterações contínuas nos ativos de software, observando os impactos na arquitetura, parâmetros de qualidade e ambiente operacional irão mitigar alguns fenômenos da evolução do software. Vamos agora, agregar a esta reflexão a “última” “lei” que destaquei para esta provocação:
Complexidade crescente : ”Se não forem tomadas medidas para reduzir ou manter a complexidade de um software, conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.”(Meir Lehman e László Bélády)
O mantra “Complexidade é custo” é fácil de compreender e aceitar, porém nem sempre é fácil reduzir, ou mesmo remove em casos específicos (exemplo: regulatórios de mercado). Discutir a teoria de complexidade nos levaria a perder o foco desta provocação específica, então em uma reflexão mais “rasa” poderíamos dizer:
Quando não reservamos um esforço para reduzir a complexidade final de um sistema as equipes e times que desenvolvem e mantem um software estarão fadadas a entregarem resultados cada vez mais complexos com maior tempo e esforço para manter seus ativos, afetando gradualmente e negativamente os resultados desejados, distanciando-se do propósito para o qual foram concebidos.
Novamente…Faz sentido para você?
“Software Currency” para microsserviços
As reflexões compartilhas até aqui podem servir de referência endereçar outra “dor”. Com adoção de microsserviços pela área de tecnologia das empresas, a quantidade de ativos de softwares está se tornando bem mais significativa (“Efeito Gremlins”). Para os ativos QUE ESTÃO recebendo estímulos de atualizações, manter atualizado os frameworks e dependências é uma questão manter a visibilidade do quanto está desatualizado, planejar as atualizações e manter constante e atualizado a comunicação com os times envolvidos. Para os ativos que NÃO ESTÃO recebendo estímulos de atualizações? O que fazer com aqueles ativos que foram para produção e estão “estáveis” e sem atualizações? Fazem parte do grupo “deixa quieto – time que tá ganhando não se mexe”?
Outras provocações
Independente dos estímulos, já se perguntou como fazer (Em tempos de migração cloud, inovações, e novos demandas que exigem mais recursos e menor custo ou a gestão otimizada) para mover os ativos para tecnologias mais recentes (seja por motivos estratégicos ou de custos)? Como movimentar centenas de microsserviços e/ou manter eles atualizados e mitigando riscos de vulnerabilidades conhecidos? Em sua empresa existe o controle de quantos microsserviços estão realmente ativos e dos ativos quais versões de frameworks e suas dependências estão desatualizados e/ou sem suporte? O quão rápido sua área de TI é capaz de mover seus ativos críticos para versões mais performáticas com menor custo?
Então…Bem-vindo ao mundo onde os “gremlins” fazem parte da realidade e segue algumas recomendações :
- Devemos manter um controle dos principais artefatos que produzimos por meio de processos automatizados de entrega com o inventário de todos nossos adoráveis “gremlins”, suas versões, seus frameworks, suas dependências e a versões utilizadas.
- Os controles devem ser automático e transparente para todos
- Os produto também será capaz de manter regras de versões não desejadas, frameworks desatualizados e afins.
- As informações serão compartilhadas com todos os envolvidos e de forma dinâmica já nas fases de criação nos diversos ambientes de desenvolvimento.
- Todos os nossos “gremlins” já estão ganhando uma “coleira de identificação única” de forma automática (Amem devops!). Vai nos ajuda a entender “o que comem”, ‘como vivem”, “como se reproduzem”.
- A cada 6/8 meses todos os microsserviços e/ou produtos de softwares que estão sem receber nenhuma atualização deverão passar por uma análise por parte dos times responsáveis, com base nas nossas ferramentas, e apresentar um plano de ação de atualização ou remoção para os próximos 6/8 meses quando for aplicável.
- A cada 6/8 meses todos os microsserviços e/ou produtos de softwares que estão recebendo atualizações devem passar por uma análise por parte dos times responsáveis, com base nas nossas ferramentas, e apresentar um plano de ação de atualização/redução de complexidade para os próximos 6/8 meses quando for aplicável.
Pacotes internos
Sobre a ótica de “Software Currency”, não existe diferença entre um pacote que um time cria para uso em seus microsserviços de um microsserviço em si que implementa um negócio.
- Ambos podem possuir dependências de outros pacotes
- Ambos têm evoluções independentes e complexidades distintas
- Ambos são influenciados pelas “Leis de Lehman”
Seguindo este entendimento, um ponto de atenção que costumo repassar para todos os times é cautela na criação de pacotes, pois para cada pacote criado o seu time terá que manter a evolução, sendo outro ativo que deve merecer a mesma atenção que o ativo do seu negócio, mesmo porque, na evolução de seu microsserviço (que utiliza este pacote) poderá não evoluir na velocidade desejada caso seus pacotes não estejam compatíveis com a evolução dos ambientes atual/desejado.
Conclusão
Para as empresas que querem manter-se competitivas, não dá mais para ignorar o “Efeito Gremlins” na produção e evolução dos softwares. Os Times de negócio e técnicos precisam tomar consciência que o ciclo de vida e esforço para entregar uma funcionalidade, melhoria ou um novo produto não se encerra quando ele é colocado em produção, na realidade é justamente o contrário. Uma vez que ele passa a existir, precisa ser mantido, reservando e planejado esforços para ele continuar atendendo seu propósito até não fazer mais sentido seu uso ou propósito.
“Software Currency” é tão importante quanto o produto que se entrega. Sem uma visão mais crítica sobre este assunto as empresas estarão fadadas a se tornarem cada vez mais “engessadas’ criando fatores limitantes para suas atividades, competividade e sucesso. Se você passar a escutar com mais frequência do seu time técnico que será mais rápido “reescrever” aquela aplicação, talvez seja a hora de repensar como você trata este tema internamente.
Finalizando deixo o registro de uma frase que me veio à mente enquanto escrevia este artigo. Utilizo para minha vida e para com quem me relaciono e resume de forma espetacular a essência de tudo que foi dito:
“Tu te tornas eternamente responsável por aquilo que cativas.” (ou cria/mantem…) Pequeno Príncipe – Antoine de Saint-Exupéry
Referências
Software Currency
https://www.linkedin.com/pulse/software-currency-gary-robinson/
https://itforum.com.br/noticias/a-dura-verdade-sobre-o-gerenciamento-do-ciclo-de-vida
Leis de Lehman
https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution
Rules and Tools for Software Evolution Planning and Management
http://www.doc.ic.ac.uk/research/technicalreports/2000/DTR00-14.pdf
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.
