Com Daniel Darlen*

As experiências do Governo Federal, retratadas no Guia Livre[1], revelam a existência dos mais variados métodos e modelos de migração para software livre. Entretanto, pouco se comenta na esfera pública, sobre as experiências de insucesso enfrentadas no desenrolar de processos de migração, sejam das instituições destacadas no Guia ou das demais experiências que ainda não foram tornadas públicas. Se por um lado já existem boas referências das mais variadas estratégias para se iniciar uma migração, por outro, ainda há escassez de informações sobre os caminhos a serem evitados.

O paradoxo em questão não se propõe a criar um arcabouço de mitos, dúvidas ou inconvenientes técnicos para migração, mas, ao contrário, facilitar, acelerar e fortalecer as atividades e tarefas dos que estão começando ou enfrentando processos de migração.

Na prática, qualquer processo de migração executado ou em execução na Administração Pública convive com três aspectos gerais:

• i) os casos de sucesso e as ?boas práticas?, na maioria das vezes, não se aplicam em outros ambientes;
• ii) os casos de insucesso técnico não estão devidamente documentados; e /li>
• iii) existe um desconhecimento da totalidade do ambiente de TI em boa parte das instituições.

Além dos poucos relatos de insucesso, o cenário atual aponta para os percalços de se aplicar uma experiência bem sucedida em outra instituição. Isso ocorre em função de duas condições: os ambientes computacionais internos de cada organização são muito heterogêneos; e essa heterogeneidade dificulta a replicação das experiências nas organizações, em decorrência da pouca ou nenhuma similaridade entre os ambientes. Dessa forma, dificilmente uma prática de migração será adequada por completo para replicação, em especial pelo que se identifica dentro do universo dos sistemas legados.

Os sistemas legados

Logicamente, os desafios para uma transição tecnológica bem sucedida consideram fatores culturais, motivacionais, técnicos e gerenciais. O domínio amplo do ambiente de TI da instituição é um fator de sucesso em qualquer processo de migração. Dentre as diversas variáveis ambientais, uma se destaca por apresentar um aparente domínio institucional, mas do qual, efetivamente, se tem pouco controle: os sistemas legados.

Os legados são sistemas informatizados em operação que durante uma transição tecnológica precisam ser mantidos em sua plenitude. Isto significa que, quando se decide utilizar uma determinada tecnologia alternativa ou emergente, não se deve gerar perdas aos usuários, aos sistemas e ao ambiente.

Em função das dificuldades encontradas no trato com os sistemas legados e das inúmeras rotas de migração possíveis[2], existe uma fase de extrema importância, anterior à própria migração: a elaboração de um plano (ou projeto) de migração.

Um dos pontos de ataque dos planos de migração é o mapeamento da estrutura de informática e dos serviços existentes[3]. Nesta etapa é possível dimensionar corretamente um método de migração que não cause transtornos para o dia-a-dia dos usuários, contemple espaços estratégicos para o aprimoramento técnico e estabeleça o tratamento efetivo para os sistemas legados.

É importante reforçar que, ao falarmos sobre os sistemas legados, tratamos somente de um dos enfrentamentos existentes nos processos de migração. O aprendizado com a aplicação de planos de migração demonstrou que os sistemas legados se tornaram o maior problema do ponto de vista técnico na fase operacional da migração[4] e, por isto, é fundamental que se tornem objeto de análise nas organizações.

Classificações

Ao verificar a abordagem dos sistemas legados nos processos de migração para software livre, existem três classificações centrais a considerar. Cada uma delas deve ser prevista pelos gestores e técnicos antes de iniciar a migração. Considerá-las na fase preparatória do plano significa buscar as formas ideais para conhecê-las dentro do ambiente e prever adequadamente a interferência técnica a ser realizada.

A primeira classificação é facilmente reconhecida dentro das estruturas organizacionais, pois se referem aos sistemas legados de domínio institucional. Estes são sistemas em produção que convivem com algum nível de controle e acompanhamento nas organizações. Existem ainda duas categorias menos comentadas, ou pouco controladas, que são o ambiente caótico e os nós de migração.

O ambiente caótico normalmente é composto por sistemas que funcionam na arquitetura da plataforma baixa (microinformática) e foram desenvolvidos com pouco ou nenhum acompanhamento dos gestores de TI, sendo, muitas vezes, construídos pelos usuários. Já os nós de migração são qualificações que se referem ao grau de complexidade e abrangência de um determinado sistema dentro do ambiente em transição tecnológica. Em função do número de usuários, de soluções e de máquinas atingidas, um sistema pode se tornar um nó de migração.

Todas as instituições que começaram suas migrações desde 1999, tais como a Dataprev e a Marinha, ainda convivem com o desafio de superar o entrave dos sistemas legados de domínio institucional. Isso também se repete nos órgãos que começaram sua migração no primeiro mandato do atual governo, tais como o Serpro, a Embrapa, o ITI, os Correios, a Caixa Econômica, o Banco do Brasil e diversos Ministérios. Esses sistemas são relativos às soluções corporativas desenvolvidas há bastante tempo, em ambiente proprietário, com padrões fechados e com elevado grau de maturidade, tanto na utilização dos usuários como em sua manutenção. Embora exista um maior domínio institucional dos sistemas, estes, em sua maioria, são mais complexos e custosos para serem migrados.

O ambiente caótico da microinformática advém dos ?ambientes desconhecidos? pelos técnicos e gestores de TI. A disseminação do uso de estações de trabalho com processamento local, ferramentas de automação de escritório e redes locais permitiu que os usuários desenvolvessem em larga escala sistemas próprios, para atender demandas específicas, sem nenhum tipo de controle nem aderência aos padrões de desenvolvimento, ao uso adequado de recursos de rede ou às metodologias já consagradas no ambiente de TI. Essas soluções isoladas geralmente só chegam ao conhecimento da área técnica quando algum problema no ambiente é detectado, sendo necessário acionar suporte especializado. Estes sistemas, em função do grau de desconhecimento institucional, geram entraves técnicos e dificultam fortemente a migração.

Os nós de migração são mais complexos de serem detectados, tanto pela dificuldade de identificarmos onde se encontram, quanto pela necessidade técnica de sua devida qualificação e mensuração. Tratam-se de soluções com funcionalidades específicas que não são percebidas inicialmente pelo corpo técnico responsável pela migração, mas que se tornam essenciais aos usuários e/ou sistemas, como por exemplo: um sistema corporativo (domínio institucional), que em determinado momento faz exportação automática em planilhas eletrônicas proprietárias (ambiente caótico ou domínio institucional) e os usuários, com essa planilha em mãos geram um banco de dados proprietário para cada setor (ambiente caótico). Neste exemplo, dependendo da quantidade de usuários ou máquinas que a solução atinja e do seu grau de complexidade para análise e reprogramação, esse sistema pode ser classificado como um nó de migração.

Justamente para os casos do ambiente caótico da plataforma baixa e dos nós de migração, e embora seja trabalhoso, o diagnóstico e o mapeamento auxiliam no reconhecimento do ambiente de TI. Este trabalho, inclusive, pode ser aproveitado para futuras padronizações do ambiente, revisões de sistemas de informação e identificação das soluções existentes. Os aliados de ?primeira hora?, nesta etapa de levantamento, são as ferramentas de inventário de hardware e software[5]. O uso dessas ferramentas pode auxiliar no adequado mapeamento do ambiente com rapidez e confiabilidade.

Experiência

O panorama encontrado na Administração Pública Federal, no contexto da elaboração de planos de migração para tratamento dos legados, aponta os seguintes passos como as ações mais adequadas para a realização de migração dos sistemas proprietários para software livre:

• i) Estabelecer um ciclo de diagnóstico onde se realiza um mapeamento dos sistemas legados utilizados pelo usuário, tanto os sistemas internos quanto os adquiridos externamente;
• ii) Consolidar as informações coletadas no mapeamento (em planilhas ou banco de dados), ordenando os usuários e sistemas segundo aptidão para realizar determinada rota de migração: estações, servidores, serviços e sistemas;
• iii) Classificar os sistemas de acordo com os seguintes itens: grau de complexidade, domínio institucional, recursos envolvidos para migração e se os mesmos se tratam de um nó de migração;
• iv) Identificar as possibilidades de migração de acordo com critérios técnicos pré-estabelecidos para o ambiente: aplicativos proprietários com similar livre sem perda de funcionalidades básicas, menor quantidade de aplicativos proprietários ativos, menor micro-legado, menor macro-legado, menor quantidade de nós de migração, etc.[6].
• v) Estabelecer os estágios tecnológicos que serão alcançados por cada sistema: adoção de padrões abertos, operação multiplataforma, interoperabilidade, parte de funcionalidades em software livre, migração parcial ou total.
• vi) Definir o cronograma de execução das ações de migração, conjugando os critérios pré-estabelecidos com os estágios tecnológicos descritos acima, bem como a preparação técnica da equipe.

Alguns órgãos do Governo Federal tomaram a iniciativa de elaborar um sólido planejamento com base em técnicas de gestão de projetos, utilizando ferramentas livres de gerenciamento e produzindo documentação agregada dos resultados. Essas iniciativas podem servir de referência para elaboração de planos adequados a cada instituição e também, dentro de um curto espaço de tempo, aperfeiçoar as reflexões sobre os processos de migração e tratar concretamente os sistemas legados.

Conclusão

Já se percebe que os Planos de Migração ajudaram a estruturar as condições para migrar adequadamente os ambientes do Governo Federal, mas é importante reforçar que não bastam bons planos. Muitas vezes um documento bem estruturado serve como alento e contemplação. Os apoios gerenciais consistentes, os coordenadores e técnicos capazes, o enfrentamento técnico dos sistemas legados e o registro de êxitos e fracassos são fundamentais para não deixar um belo plano no papel. Entretanto, os sistemas legados, especificamente, serão migrados somente com o adequado reconhecimento do ambiente de TI e muita ?mão na massa?.

(1) Guia Livre – Referência de migração para Software Livre do Governo Federal (em PDF).

(2) O conceito de rota de migração é explorado na Parte IV, no Capítulo 12, do Guia Livre, onde são descritos os exemplos das rotas de migração para software livre que podem ser adotadas.

(3) Existem diversos exemplos de Plano de Migração, um deles é o do Ministério do Planejamento (em PDF).

(4) A pesquisa foi realizada em setembro de 2005 com mais de 150 técnicos do governo, durante a I Oficina Técnica de Migração para Software Livre do Governo Federal, quando 63% dos participantes da pesquisa identificaram como o maior problema de migração o tratamento dos sistemas legados.

(5) O governo federal disponibiliza como Software Público o sistema de inventário CACIC ? Configurador Automático e Coletor de Informações Computacionais, desenvolvido e disponibilizado pela Dataprev: www.governoeletronico.gov.br/cacic

(6) Os critérios são alterados de acordo com cada diagnóstico. Como explorado no próprio texto os ambientes são heterogêneos, existe pouca similaridade entre os sistemas legados nas instituições e nota-se uma realidade técnica em cada estrutura.

* Daniel Darlen, co-autor deste artigo, é Coordenador de Infra-Estrutura na Coordenação Geral de Informática do Ministério do Trabalho e Emprego.

Publicado na Revista LinuxMagazine de março de 2007, n. 28, Linux New Media do Brasil Editora Ltda.

.

Corinto Meffe

Corinto Meffe (corinto.meffe@planejamento.gov.br) é assessor da presidência do Serpro.