BMS - Primeiros projetos

A BMS, e, em certo sentido, todo o grupo Belgo-Mineira, tinha evoluído de um ambiente baseado em mainframes para um ambiente totalmente distribuído, baseado em servidores Intel rodando Windows. Era uma mudança radical, de um sistema totalmente centralizado para um sistema totalmente descentralizado. Em alguns momentos, isso até gerava uma certa nostalgia em alguns funcionários mais antigos. Eu me lembro bem do meu chefe, o Fernando, dizendo que o sonho dele era voltar para um ambiente de mainframe: ter uma única máquina bem controlada e que funcionasse 100 por cento do tempo. A Belgo usava o sistema SAP, o que talvez fosse uma espécie de meio-termo entre os dois modelos, por ser bem mais centralizado do que os sistemas mais comuns baseados em Windows.

Passei a fazer parte de um time que foi apelidado de Netforce. Era o time que cuidava basicamente da parte de redes e segurança. A rede era totalmente baseada em equipamentos Cisco, bastante padronizada, e seguia uma topologia em estrela, com o centro sendo a BMS em Belo Horizonte e as pontas sendo as usinas e escritórios da Belgo. Eu passei a ser o especialista em segurança desse time e gerenciava sistemas como antivírus e firewalls, também da Cisco. Aprendi bastante sobre administração de redes e gerenciamento de ambientes corporativos de missão crítica durante esse período.

Uma das atividades de segurança mais importantes que tínhamos era a atualização dos servidores Windows, feita sempre aos domingos, uma vez por mês. Esse era o dia em que a gente precisava trabalhar no fim de semana e conectar aos servidores, um por um, para atualizar e garantir que não havia nenhum problema de segurança conhecido. Depois de um tempo, começamos a perceber que algumas das atualizações publicadas pela Microsoft podiam causar problemas em certos servidores. Com isso, tivemos que estabelecer um protocolo escalonado de atualizações, em que começávamos atualizando poucos servidores e íamos aumentando esse grupo aos poucos. Nessa época, praticamente todas as empresas começaram a adotar esse tipo de prática, porque estava ficando muito arriscado simplesmente aplicar atualizações sem nenhum teste prévio. Isso não mudou o fato de que, uma vez por mês, precisávamos ir ao escritório trabalhar no domingo.

Além de aprender muito sobre operações — ou seja, basicamente manter os sistemas funcionando — a BMS também tinha projetos interessantes de tempos em tempos. Um desses projetos foi o desenvolvimento de um sistema que permitisse aos vendedores de uma empresa cliente levarem a campo um equipamento do tipo Palm Pilot para registrar os pedidos que recebessem. PDAs eram uma grande novidade na época, e esse foi um projeto que nos permitiu ter acesso a tecnologias bastante recentes. Eu participei pouco desse projeto, mas, em determinado momento, precisaram de alguém com mais conhecimento na área de criptografia, e eu fui chamado. O grande problema era como criptografar os dados armazenados no dispositivo de forma rápida e eficiente, já que esses equipamentos tinham capacidades bastante limitadas de processamento e memória. Junto com o Arnon, testamos alguns algoritmos de criptografia, mas todos se mostravam lentos demais. A solução encontrada foi reduzir o nível de segurança dos algoritmos, diminuindo o número padrão de etapas (rounds). Isso reduzia a segurança, mas tornava o algoritmo mais rápido. Não era a solução mais segura, mas foi a solução possível naquele momento para aquele tipo de equipamento.

A BMS tinha uma grande capacitação na área de SAP e fazia muitos projetos para outras empresas. Um desses projetos foi o desenvolvimento de alguns módulos específicos para uma indústria química em São Paulo, e eu fui alocado como responsável por garantir a conectividade de rede entre a BMS e o cliente. Fiz algumas visitas a São Paulo por conta desse projeto, para conversar com o cliente sobre as possibilidades de interconexão entre o time de desenvolvimento e a infraestrutura do cliente. Nenhuma das duas empresas estava preparada para fazer uma conexão direta de rede para rede, que seria a solução mais indicada nesse caso. A BMS tinha cerca de 30 desenvolvedores em Belo Horizonte que precisavam acessar os sistemas do cliente em São Paulo, e a única forma que o cliente encontrou para permitir esse acesso foi uma conexão discada via modem, de Belo Horizonte para São Paulo. Como era a única solução possível naquele momento, foi isso que implementamos.

Depois de algum tempo, o time de desenvolvimento começou a reclamar que a conexão via modem era muito ruim. A conexão começava com uma velocidade razoável, mas depois ia ficando cada vez mais lenta até cair, o que estava atrapalhando bastante o trabalho. Após várias visitas ao cliente e muitos testes, acabamos concluindo que o problema estava na fiação telefônica do prédio, que era muito antiga e introduzia muito ruído na ligação. A única solução definitiva seria trocar essa fiação, o que não era viável. Com isso, tivemos que voltar a negociar com o cliente uma conexão do tipo VPN remota via internet, para que o trabalho pudesse fluir melhor. Eventualmente, o time de desenvolvimento mudou de prédio, e a situação melhorou um pouco, mas nunca tivemos a oportunidade de implementar uma solução realmente adequada, até porque se tratava de um projeto temporário. O problema acabou se arrastando, com pequenas melhoras e pioras, até que o projeto foi concluído.

A empresa ainda tinha muitas pessoas com grande conhecimento em sistemas de mainframe, e isso levou a outro projeto interessante. Eu participei muito pouco desse projeto, mas ele ficou marcado na minha memória por ter sido conceitualmente muito elegante. Sistemas de mainframe são tradicionalmente orientados a telas. Os terminais são baseados em texto, com dimensões bem definidas, normalmente 24 linhas por 80 colunas, e os sistemas costumam definir uma espécie de formulário que ocupa toda a tela. Nesse formulário, o usuário pode inserir informações ou ler os dados fornecidos pelo sistema. A grande sacada foi perceber que, como a web é baseada em páginas, existia uma correspondência quase direta entre uma página web e uma tela de um sistema de mainframe. Alguém então desenvolveu um software capaz de se conectar ao mainframe, receber a informação correspondente a uma tela e transformá-la em uma página web. A navegação entre telas no mainframe normalmente é feita por meio de teclas de função, como F1, F2 e assim por diante, cada uma associada a uma operação disponível naquela tela, como salvar, apagar, avançar ou voltar. Isso podia ser facilmente representado como um menu no topo da página web. Era um sistema conceitualmente simples, que unia tecnologias de épocas completamente diferentes e permitia que sistemas antigos se integrassem a tecnologias mais modernas.

A gente teve outros projetos bem interessantes também, mas esses eu vou deixar para o próximo capítulo.