Nove em cada dez empresas pretendem ou estão com projetos de substituição dos seus sistemas legados por novos sistemas em novas tecnologias.
Obviamente, para as consultorias que prestam serviços de TI isso não é um problema, pelo contrário, é uma oportunidade de negócios que normalmente torna-se fonte incomparável de renda, em relação aos projetos commodities; mas este ainda não é o ponto principal.
A realidade aponta que muitas vezes o desejo de substituir o legado é apenas estético, como por exemplo, trocar a tecnologia usada por uma nova, com promessas de encontrar mais recursos no mercado, menos problemas com implementação (quem nunca ouviu “nosso legado possui muitos problemas, precisamos substitui-lo”), menos manutenções, uma interface mais agradável para o sistema, etc. Isso significa que, o desejo de evolução não passou pelo principal fator que motivaria tal investimento: o retorno.
Não, não sou avesso à evolução tecnológica de uma empresa, desde que esta seja feita no momento certo e com os pés no chão, essa troca pode trazer muitos benefícios; porém, simplesmente trocar o legado por uma tecnologia nova, não pode ser o fator principal de uma mudança.
Já vi casos de empresas que trocaram seus legados de dez, vinte anos por uma plataforma com quase quinze; também já presenciei situações onde os envolvidos, por não dominarem o negócio (ou talvez por pressão do cronograma), faziam com que o legado fosse apenas convertido em uma “nova” linguagem, independente de bugs e paradigmas; casos em que se gasta muito, perde-se muito tempo e no fim das contas, recebe-se um produto com qualidade inferior ao já existente, conseqüência de uma decisão equivocada.
Com base nestas indicações, podemos avaliar a necessidade de retomada do legado para algo novo, que justifique o orçamento investido nesse tipo de situação (que às vezes é o orçamento do ano todo para uma área) nos tópicos enumerados a seguir (lembrando que esta é a opinião do autor deste artigo e não deve ser levada com absoluta convicção, pois cada negócio é um caso diferente) - daqui para frente, denominaremos a evolução tecnológica ou substituição do legado por “projeto” e trataremos de uma conversa entre um consultor de tendências e você, CIO da sua companhia:
1. Sua empresa realmente precisa disso? O seu legado funciona, sua equipe não se importa em trabalhar com ele, seus usuários não se importam em continuar com ele, as integrações não são complexas.
O que motiva a mudar, portanto? Quais os ganhos serão obtidos em curto, médio e longo prazo?
2. Descubra todos os ângulos de valores envolvidos: atualizando seus sistemas agora, economicamente falando, onde você vai recuperar o gasto com software, hardware e mão de obra investida na construção do novo sistema?
Em quanto tempo? Quanto às falhas do legado geram de despesas para a empresa nos dias de hoje?
Quanto de suporte externo o legado gera de despesas? O novo projeto envolve a compra de um pacote fechado? Em quanto tempo o projeto “se paga”?
3. Menos é mais: Essa questão envolve pessoas e engenharia de software. Software é um ativo construído através de conhecimento, que é sua principal matéria prima.
Com base nesta afirmação, podemos dizer que não importa quantas pessoas estão desenvolvendo um software, isso não vai garantir que o mesmo será feito mais rapidamente.
Agora, quanto mais conhecimento concentrado em construir um software, as chances aumentam consideravelmente.
Software é código, códigos bons são duradouros, portanto, é muito melhor ter cinco bons desenvolvedores trabalhando em sinergia do que uma equipe de 100 pessoas com conhecimento inferior e gerenciamento precário. Investir no melhor sempre acaba saindo mais barato, se tratando de software, a frase "são nos menores frascos que contem as melhores essências" aplica-se perfeitamente.
4. Defina um modelo canônico para a companhia: é muito comum uma empresa de médio porte possuir inúmeros sistemas atendendo diversas áreas do seu negócio que se relacionam entre si, um exemplo disso é possuir mais de um sistema processando vendas, cada um da sua forma, quando na verdade, o que muda é apenas o canal pelo qual este é processado, por exemplo: o caixa possui sua forma de lidar com venda, o sistema de auto-atendimento outra, o aplicativo mobile outra, etc.
O problema é que uma mesma entidade está presente da mesma ou de diferentes formas entre os sistemas.
O modelo canônico é o desenho do negócio da empresa em estruturas definidas, essas estruturas devem servir como referencia a ser seguida– uma analogia, seria como se cada equipe possuísse a mesma marca e modelo de Lego para fazer sua montagem.
5. Avalie o que o mercado usa: O mercado dita as regras, ignora-lo e não fazer as devidas provas de conceito do que se pretende adotar é um risco que algumas empresas se aventuram em passar.
É interessante ser visionário, mas de preferencia, não inicie este processo pelo core business da sua companhia, siga o que o mercado está fazendo.
6. A importância da plataforma tecnológica e seu impacto no negócio: dependendo da arquitetura tecnológica definida, um novo sistema já pode nascer com sérios riscos que podem comprometê-lo ao longo do tempo.
O que acontece é que antigamente as tecnologias utilizadas para construírem o legado de hoje eram praticamente o que chamamos de full-stack, significando um pacote com banco de dados, linguagem de programação e interfaces.
Atualmente, a gama de tecnologias e opções para cada camada do software aumentou significativamente.
Apostar em uma arquitetura orientada a serviços (SOA) é uma boa opção, visto que o negócio está descrito dentro de um protocolo heterogêneo que pode servir N sistemas, facilmente de se escalar e alterar.
7. Não existe bala de prata: As empresas costumam criar uma RFP para comunicar aos players o interesse em um determinado sistema de informação, no nosso caso, o projeto de reconstrução do legado.
É muito comum que pacotes fechados (que prometem tudo e mais um pouco) sejam oferecidos a preços exorbitantes.
Não estou questionando a qualidade dos mesmos, até acredito que sejam úteis, porém, é necessário avaliar se sua empresa realmente precisa disso. Ora, talvez, um desenvolvimento pontual e focado no problema resolva de forma muito mais barata em valores e esforço.
8. Evolua modularmente: risque jargões como “virar a chave” do vocabulário da sua empresa.
Primeiro que você dificilmente vai conseguir construir todo seu novo sistema e substituí-lo de uma vez só, uma vez que enquanto se constrói um novo sistema, o próprio legado é mantido (i.e. atualizado, evoluído), é uma corrida em paralelo muito desleal. Identifique os módulos do seu sistema, priorize os mais estratégicos para o seu negócio, tenha antes aprendido com o desenho do modelo canônico para facilitar a modularização.
Entregue por módulos. Evite desperdícios.
9. Fazer software e falar sobre software: falar sobre software é muito fácil, mesmo. Escrever este artigo é fácil. Escrever um documento técnico é fácil.
Perder um ano inteiro escrevendo como será um software é fácil. O problema é que ainda não existe uma solução tecnológica para transformar texto livre em software e, como toda empresa que se preze, o seu negócio evolui relativamente em um ano, tornando documentos desatualizados.
Avalie questões como metodologias ágeis, entregas e implantação contínuas. Software é empírico, sua construção é baseada em conhecimento.
Conhecimento pode ser interpretado de diferentes formas por diferentes pessoas, chegar a um denominador comum da melhor forma de implementar um negócio pode significar mais de uma tentativa, mais de um desenho e mais de uma reescrita. Errar em software não é dos males o pior, devido a sua maleabilidade.
10. Construa o novo pensando no amanha: ou você quer passar por tudo isso novamente daqui cinco anos? Foque em plataformas solidas e horizontais.
Empresas fornecedoras de software deveriam, por si, seguir um bom percentual destas práticas, pois favorecer o cliente na melhor solução para o seu negócio é o estado da arte do que chamamos de consultoria.
Software é um mercado como qualquer outro, em que um produto com baixa qualidade pode significar uma mancha irrecuperável no nome da empresa.
Empresas que contratam TI, desconfiem de soluções milagrosas.
*Robson Vargas Farias É Especialista de TI na GetNet
