Nesta mesa-redonda, realizada em Brasília, oito executivos de informática do setor público explicam: o legado nasce de uma ilusão. Quem mexe no legado em geral é um profissional mais velho, que conhece a empresa e o sistema, e que não se submete a firulas modernas, como escrever a documentação. Ele instala mudanças no legado depressa, a baixo custo, com baixo risco. Se a governança da empresa não for boa, ela vai sempre comparar o desempenho desse profissional mais velho com o desempenho de um profissional mais jovem, que não conhece nem a empresa e nem o legado direito, mas que se submete a todas as firulas modernas (como separar os componentes do sistema em camadas e escrever documentação de boa qualidade), e que portanto demora mais para entregar o que prometeu.

A mesa-redonda foi coordenada por Wilson Moherdaui, diretor editorial do Informática Hoje. Participaram: Alan do Nascimento Santos, assessor de TI do INSS; Ana Cristina Bittar de Oliveira, coordenadora de sistemas e TI da Secretaria do Tesouro Nacional; Antônio Bezerra de Albuquerque Neto, gerente de inovação e TI da Secretaria de Patrimônio da União; Gustavo Sanches, coordenador de sistemas do Supremo Tribunal Federal; Marcus Vinícius Vilela, coordenador de TI da Imprensa Nacional; Paulo Roberto de Almeida Mello, gerente de sistemas corporativos da Eletronorte; Rafael Almeida de Paula, secretário de TI do Tribunal Superior do Trabalho; e Rodrigo Evangelista de Castro, gerente nacional de arquitetura tecnológica da Caixa.

IH — É difícil renovar o legado ao trabalhar para instituições de governo?

Marcus — Talvez a Imprensa Nacional tenha um dos casos mais críticos de legado no governo federal. É uma indústria, que funciona 24 horas por dia, publica os famosos Diário Oficial da União e Diário de Justiça, e na qual tudo foi feito para funcionar de forma burocrática.
Em 2000 e 2001, 70% dos profissionais da Imprensa Oficial foram cedidos para outros órgãos, equipamentos foram doados ou jogados fora. Mas os dois diários tinham de sair todo dia. Eu sempre digo lá dentro: podemos dar qualquer explicação, desde que o jornal saia.
Os sistemas de informática não eram legados — mas largados. Não tinha documentação, nem código-fonte, mas os sistemas mais importantes não podiam parar.
Mas conseguimos reverter tudo isso em alguns anos. Fomos resolvendo problemas dos mais urgentes aos menos urgentes. Hoje temos um sistema de informática robusto, com redundância, um dos melhores entre órgãos de imprensa. Já não somos mais motivo de piada.
Integração de sistemas e SOA para nós eram uma coisa muito distante.
Muitas vezes, nem o próprio usuário tem a documentação de uma regra de negócio. Ele faz aquela tarefa daquele jeito há tantos anos que nem sabe mais por que faz daquele jeito.
Para mudar os sistemas, tivemos de fazer protótipos, mostrar a documentação e as telas para o usuário, fazê-lo assinar — e mesmo assim, às vezes o usuário dizia que não era bem assim.
Gustavo — Já tive a chance de participar da migração de uns 28 sistemas grandes — de Natural para Access, de Cobol para Clipper, de Mumps para VB, de Forms Imports para PHP... Mesmo assim, acho que vou levar uns 30 anos para entender mesmo como o negócio funciona. O real problema não é a tecnologia, mas a empresa: como ela se vê, como as pessoas trabalham dentro dela.
Para desenvolver um sistema, ou um aplicativo, preciso entender três grandes coisas: quais são os processos, qual é o negócio, quem são as pessoas.
Num tribunal, o que é longo prazo? É dois anos. A administração de um tribunal dura dois anos. Em dois anos, a gente está começando a entender o que deve ser feito. O que nós percebemos, depois de dez anos? Que a gente não errava no planejamento de longo prazo, mas errava no prazo. O longo prazo é curto mesmo. Então, se o nosso longo prazo é dois anos, o nosso planejamento tem que dar para dois anos.
Não digo isso no sentido negativo: a administração muda a cada dois anos, e muitas vezes muda para melhor — mas muda.
Então, adotamos SOA. Em vez de migrar um aplicativo, ou um sistema, estamos migrando serviços. Não significa que preciso ter, necessariamente, tecnologia nova de SOA.
A gente fez um teste no STF, e descobre que nossa página de Internet tinha 86 serviços. A gente sabia disso? Não sabia. A gente sabia de um monte de programas ASP, mais de 300 programas, mas não tinha a menor ideia de para quê eles serviam.
Quando identificamos esses 86 serviços, pasmem: em 82 deles as regras de negócios estavam na página ASP, que ficava no portal do STF. As regras estavam duplicadas em outros sistemas da casa.
Falo isso com o maior orgulho. Tem uma turma de acadêmicos lá que fala assim: não vamos falar de SOA, vamos falar de serviços. Começamos a redesenvolver os serviços, um por um.
Nosso legado, em termos de aplicativos, continua o mesmo. Mas, em termos de serviços, e de regras de negócio, mudou completamente. Usamos XML, uma linguagem padrão, muito conhecida.

IH — Vocês usam ferramentas de mercado para fazer isso?

Gustavo — Infelizmente, toda a gerência dos serviços é manual. Sentimos falta de ferramentas que controlem os serviços, e as regras de negócios.
A vantagem dos serviços é que, toda vez que tem uma mudança de regra de negócio, todos os sistemas que usam aquele serviço estão alterados automaticamente.
Ainda temos muitos legados para migrar, mas esbarramos nas pessoas. O cara usa um sistema e não sabe mais o porquê.
Rodrigo — Sim, o problema não é a tecnologia, mas os processos de negócio. Na Caixa, no planejamento de 2009 até 2015, conseguimos separar o que é responsabilidade da TI (instalar novas tecnologias) e o que é responsabilidade das áreas de negócio (otimizar processos). Todos temos nossas metas claras. Isso foi muito bom, porque tira dos ombros da TI a responsabilidade de discutir processos de negócio.
Gustavo — Na primeira revisão que nós fizemos, identificamos 11 ou 12 serviços que eram totalmente desnecessários, ninguém sabia o porquê nem para quê, e eles não foram redesenvolvidos. Não daria para mostrar isso ao usuário falando de sistema, que engloba tudo. Aí o usuário ia dizer que o sistema está com problemas.
Rafael — Existe o problema da gestão: se a TI se preocupa só com a excelência operacional, ela agrega muito pouco. É a mesma coisa ao tratar do legado: não podemos só tratar de questões técnicas; temos de trazer as pessoas para essa discussão.
E o primeiro passo é tratar o nosso funcionário de TI como legado: ele precisa de treinamento, de reciclagem, para se reinventar também.
E hoje o poder judiciário se preocupa com uma integração maior: de que adianta um tribunal funcionar muito bem, se o outro tribunal que vai julgar a sua causa funciona mal? Essa mudança de foco exige uma mudança nos sistemas, porque exige integração.
Hoje até pensamos numa numeração única para cada processo, justamente para gerar estatísticas mais corretas, mas que daria um reflexo pesado nos nossos sistemas.
Uma curiosidade: eu continuo tendo uma produtividade maior nos sistemas legados, e menor nos sistemas novos, com SOA. A equipe de legados está muito à frente da equipe de SOA. Estamos estudando o assunto ainda, para descobrir as causas.
Ana — Quando tratamos com tecnologia nova, a tendência é seguir todo o ritual: especificação, desenvolvimento, testes. Seguimos o passo a passo. Mas, quando tratamos com o legado, vai um técnico lá, faz a modificação, instala, e nos dá a modificação para homologar depois que ele já instalou... Vai ver, é isso.
Rafael — Acho que a questão é exatamente essa.
Rodrigo — A produtividade é maior com os sistemas legados, mas numa visão de curto prazo. O camarada instala a funcionalidade X num instante, mas o sistema não foi concebido para ser reutilizável. Com Java, por exemplo, o camarada vai ter de pensar em classe, bibliotecas, componentes. É mais difícil, porque esse pensamento pressupõe uma visão de longo prazo, pressupõe o reuso.
Gustavo — Cai naquela história de antes: conhecer o negócio é fundamental, e o sujeito especializado em legados em geral conhece o negócio.
Se você compara esse camarada com um jovem técnico, que recebe a ajuda de um usuário ruim, aí você compara quatro dias com 30 dias.
Antônio — É muito complexa essa questão de métricas, dos indicadores. Por exemplo: o camarada do legado faz uma modificação em quatro dias. Mas, como ele mexe com arquivos sequenciais no banco de dados, na verdade ele tem de mexer em 55 pontos diferentes do código. Vamos supor que ele acerte 51 pontos e erre quatro. Depois, bem mais tarde, quatro usuários vão abrir um chamado no help desk, e isso vai entrar na conta dos incidentes — mas não vai entrar na conta da produtividade do legado!
Marcus — A imagem perfeita de mexer no legado é a de mexer num prato de macarrão — se você puxa um fio de macarrão aqui, vai puxar outro ali.
Ana — O grande exemplo do Tesouro Nacional é o Siafi, um sistema legado de 20 anos, que automatiza todo o processo orçamentário e financeiro do governo federal, e se integra a vários outros sistemas. É um sistema com 60 mil usuários ativos, de 1987, feito com Natural e Adabas.
Ele começou com 17 transações e hoje tem mais de 600. É um frankenstein ambulante, que funciona muito bem.
No Siafi, as regras de negócio não são perenes: é o contrário, elas mudam constantemente. Às vezes, fico sabendo que preciso mudar o Siafi pelo Diário Oficial.
As pessoas são mesmo o fator crítico de sucesso: desde 2001 a gente faz concursos específicos para a área de TI, então hoje nós temos 50 analistas de TI mesmo. Precisamos de terceirizações de várias formas, por exemplo precisamos do Serpro, mas tem papéis que são indelegáveis.
E tem o principal: planejamento longo. Estamos evoluindo o Siafi, mas passei dois anos planejando o que migrar, o que mudar, como construir.

IH — Como são os legados no setor de energia?

Paulo — Por volta do ano 2000, muitas empresas de energia adotaram o ERP, inclusive a Eletronorte. Ainda existem usuários que esperam a TI resolver problemas, mas, com o ERP, os usuários cuidam de parametrizações, da criação de coisas dentro do ERP, e a área de TI só gerencia o ambiente.
Como a tecnologia melhorou, como elas se pulverizaram, surgiram nichos de TI: se a TI não me atende [diz o usuário], vou lá e eu mesmo faço. Assim, eu tenho legadinhos escritos em VB, legadinhos sem fonte, legadinhos escritos em Delphi por uma empresa terceirizada, contratada pelo Fulano sem o consentimento da área de TI. Mas a TI tem de cuidar desses monstrinhos.
Então, numa estatal grande como a Eletronorte, temos o ERP, temos os sistemas específicos para as tarefas de uma empresa de energia elétrica, e temos esses monstrinhos, alguns deles eu certamente nem conheço ainda.
Contudo, nós conseguimos parar a geração de sistemas novos sem a autorização de TI.

IH — Parou a geração espontânea de legados?

Paulo — Parou.
Rodrigo — Fui avaliar uma equipe de desenvolvimento uma vez, de oito pessoas, empregados antigos da Caixa. Um auditor tinha reclamado que eles não escreviam documentação. Cheguei, conversei com eles, e eles meio ressabiados comigo. Conclusão: a equipe é muito boa, e cuidava de um sistema legado importante para a Caixa. Mas eles escreviam documentação? Não. E eles escreveriam documentação? Sem chance. Então, nós colocamos uma equipe com viés de metodologia, com viés de documentação, entre essa equipe de programadores e os usuários. A equipe de metodologia levanta os requisitos e faz a documentação, antes de passar trabalho para os programadores, que vão fazer seu trabalho no menor tempo possível e com os menores riscos possíveis. Foi a única forma, pois não valeria a pena perder essa equipe de programadores.
Paulo — Quero só falar uma coisinha sobre software livre: eu uso OpenCMS, Microsoft SharePoint, Java, essa montoeira de coisas que fazem coisas parecidas. Aí aparece um software livre novo no mercado, você fica encantado com aquele negócio e cai na armadilha.
Antônio — Se fosse mais fácil usar os dados dentro do legado, se o legado me desse interoperabilidade, seria muito melhor. O problema do legado começa justamente porque ele surgiu numa época em que os dados eram trancados dentro dele.
A gente pode desenvolver vários sistemas com tecnologias bacanas, mas, no final das contas, temos que falar com os sistemas estruturadores do governo. Se esses sistemas estruturadores são legados fechados em si mesmos, fica difícil falar de interoperabilidade dentro do governo.
O legado gera uma sucessão de problemas. O cidadão, por exemplo, tem de recorrer a várias instâncias do governo para pegar certificados, pagar impostos. A produtividade dos funcionários fica mais baixa, por causa de papel, tramitação lenta. A equipe de TI que cuida de legados fica com o rótulo de equipe obsoleta, só porque está alocada para cuidar de tecnologias velhas.
É difícil mudar tudo isso. Em parte, porque é difícil tirar o pessoal de negócios do dia a dia, para que eles nos ajudem a descobrir as regras de negócio. O dia a dia tem prioridade sobre o futuro.
Ana — Outro problema: o TCU criou uma secretaria só para auditar as áreas de TI de órgãos do governo. É interessante isso, mas não existe contrapartida da instituição que abriga a área de TI — assim, a TI tem de se alinhar ao planejamento da instituição, mas a própria instituição não tem planejamento... Então, gastamos um tempo respondendo, explicando, justificando.
É mais um problema na lista de problemas a resolver para resolver o problema do legado.
Antônio — Como não existem leis que exijam a interoperabilidade dos sistemas, cada órgão se acomoda com os sistemas que tem, e os legados se proliferam.
Rodrigo — Para nós, na Caixa, legado é tudo o que já entrou em produção. Por esse conceito, nós todos aqui já somos legado. Então, o legado vai sempre existir. Outra coisa: o legado tende a crescer. E o legado sustenta os negócios. Na Caixa, estamos falando de 650 sistemas corporativos, fora os sistemas departamentais. Para sustentar esses 650 sistemas corporativos, recebemos por mês 2.200 demandas.
Por isso surgiram essas novas tecnologias como SOA, ETL, qualidade dos dados: para a gente reaproveitar, para não estar sempre substituindo.
Mas mexer no legado, mesmo modernizar o legado, gera batalhas internas dentro da empresa, brigas de poder. Mexer no legado mexe com a estrutura da empresa.
Alan — Também trabalhamos com o conceito de que legado é tudo o que já funciona.
Hoje nosso modelo de negócios é montar uma base cadastral, e pôr essa base à disposição das pessoas, para que elas corrijam as informações antes de precisar de um benefício. Passamos a criar canais de atendimento para diminuir o tempo de atendimento e os erros, as fraudes.
A primeira etapa desse novo modelo foi sincronizar os sistemas periféricos com o sistema central. Depois adaptamos os sistemas para permitir acesso pela Internet, e depois adaptamos os sistemas do call center, que já atendem três vezes mais gente do que nossos escritórios. E hoje estamos mudando os legados mais antigos.
Mas estamos chegando no limite da integração. Criamos n camadas de integração, com filtros e tudo o mais, que deixam o risco do sistema mais alto do que nós gostaríamos.
Trouxemos mais gente para os nossos serviços, com o acesso mais bem estruturado, e percebemos uma demanda reprimida.
Mas manter os sistemas legados significa manter os computadores e outros sistemas também; às vezes precisamos atualizar sistemas, em processos bem complexos. Outro dia, migramos um sistema, mas o sistema operacional de destino não aguentou. Num dia de indisponibilidade, deixamos de atender 200 mil pessoas; depois, precisamos remarcar encontros com essas 200 mil pessoas.
Como mexer no legado é complicado, precisamos de uma direção firme. A tentação de não mexer no legado, de investir nele um pouco mais, é muito grande, porque dá resultados a curto prazo.
Por exemplo: estamos migrando o Cadastro Nacional de Informações Sociais; são 15 bilhões de registros, 7 milhões de linhas de código. Estamos discutindo o cronograma dessa migração já faz cinco meses. Vamos aproveitar para juntar novas bases de dados, como a de direitos do trabalhador rural, do pescador, do silvícola. Não tínhamos antes essas bases estruturadas.
Outro problema é organizar as pessoas em torno desse projeto, até porque toda a execução técnica é feita pela Dataprev. A Dataprev fez concursos para se preparar, mas não tem conseguido manter a mão de obra. A idade média na Dataprev está em torno dos 47 anos.
Como solução, a Dataprev centralizou o desenvolvimento de software em cidades onde existe muita mão de obra mais jovem, como Rio, São Paulo e Brasília, e com isso melhorou a retenção de mão de obra. Mas, na produção, ainda existe o problema, até porque os centros de produção ficam em grandes cidades, e não dá para mudá-los de lugar fácil. [Os salários de profissionais na produção é maior, porque em média eles são mais velhos e mais difíceis de achar; então a Dataprev disputa esses profissionais com empresas privadas.]
Um complicador: tomamos a decisão de usar plataforma baixa [ou seja, servidores mais comuns, do tipo Intel]. Administrar sistemas críticos, com grandes volumes, em plataforma baixa é mais complicado.

IH — Vocês realmente têm controle sobre os sistemas legados?

Alan — Se você considerar o legado em toda a sua complexidade, vai facilmente chegar à conclusão de que é melhor não mexer nele. Mas isso vira um círculo vicioso.
Rodrigo — Quando a gente mexe num legado, mexe com cuidado, porque ali está o esforço de muitos anos. Se temos pouco tempo para substituí-lo ou atualizá-lo, então não temos tempo para investigá-lo com a acuidade desejável.
E as novas tecnologias, como já discutimos, nos ajudam no longo prazo; no curto prazo, paradoxalmente, elas não nos dão a flexibilidade que queremos.