Um dos problemas comuns que todos eles descreveram foi a questão da integração dos sistemas legados com aplicações em nuvem. Lorraine Lawson refere-se a esta questão como o calcanhar de Aquiles do Cloud Computing em Os únicos e não-tão-únicos desafios da Integração. A pergunta é: por que um dos passos fundamentais para funcionar eficazmente na nuvem é tão difícil? Existe uma maneira de tirar essa dor? A resposta é sim, pura e simplesmente, e chama-se iBOLT.<br /><br />Se tomarmos o exemplo do artigo de Nash, podemos ver qual é o problema. Nash entrevistou Stuart Appley, CIO na Shorestin Properties. Eles usaram “uma versão hospedada de um sistema chave de gestão, da Yardi Systems, sendo que o Yardi é executado em um servidor IBM (IBM) AS/400. Quando ele quis versões em nuvem de outras aplicações para troca de dados com o software Yardi, nenhum fornecedor dos aplicativos nem a Yardi tinha um utilitário escrito especificamente para ligar seus sistemas. A equipe da Appley tinha que escrever interfaces em RPG, a linguagem de programação que a IBM usa no AS/400. Isto pode parecer uma solução simples para um problema pequeno, mas aqueles que tentarem saberão que escrever uma interface entre duas aplicações não é rápido nem simples e o que será, se você tem dezenas de aplicações?<br /><br />A manutenção e modernização de sistemas legados tornaram-se um dos obstáculos mais visíveis enfrentados pelos departamentos de TI de muitas organizações. Um sistema que tornou-se legado pode ser simplesmente definido como qualquer sistema que seja difícil e caro de manter.<br /><br />Há todo um espectro de razões pelas quais isso poderia ser o caso, mas, essencialmente, é porque:<br />(A) Está sendo executado em uma plataforma cara (e muitas vezes obsoleta);<br />(B) É escrito em uma linguagem obsoleta;<br />(C) Não há mais ninguém na equipe que o compreenda. <br /><br /> Estas questões compartilham o mesmo resultado: um sistema legado não tem a agilidade que a maioria das empresas precisa para apoiar as mudanças nos seus processos, além de que está custando muito mais para manter.<br /><br />Motivadores de negócios para a modernização: <br /><br />• A rápida evolução das necessidades do consumidor e dos modelos de negócios<br />• Tarefas manuais caras e demoradas devido à sub-processos semi manuais – o processo global não é racionalizado.<br />• Incapacidade para adicionar interações ricas (baseadas na web) e módulos móveis para aplicações legadas.<br />• Os usuários não estão satisfeitos<br />• Novos padrões/regulamentos/notificações não podem ser implementados/suportados em tempo.<br />• Integração manual de processos<br />• Fusão e Aquisição – necessidade de integrar processos de negócios<br />• Definição e monitoramento de workflow/processo<br />• Alto custo de manutenção de sistemas legados reduzindo o orçamento disponível<br /><br />Motivadores de Tecnologia: <br /><br />• Permitir o uso de Web Services<br />• Reutilização do código existente combinado com novos serviços/códigos<br />• Sincronização de dados entre legado e novas aplicações/processos<br />• Migração, substituição ou cenários mistos de plataforma e/ou banco de dados<br />• Conectividade de aplicações legadas e outras aplicações diretamente ou através de sistemas de mensagens (JMS, MS MQ e Websphere MQ); substituindo interfaces proprietárias com plataforma de integração escalável<br />• Construção de uma arquitetura SOA, incluindo aplicações legadas<br />• Manipulação de transações para processos que integram aplicações legadas<br /><br /> Opções com Legados<br /><br />Tradicionalmente, há poucas opções quando uma organização procura lidar com um desafio do sistema legado. Geralmente, uma organização pode:<br /><br />Substituí-lo: Criar um novo sistema que substitui a funcionalidade completa do sistema antigo. Este é a opção mais difícil, mais dispendiosa e arriscada, mas é a única que oferece uma solução de longo prazo e, possivelmente, fornece um sistema que seja ágil o suficiente para responder às novas necessidades do negócio. Questões a considerar incluem:<br />• Alto custo inicial de desenvolvimento;<br />• Risco muito elevado;<br />• Dificuldade para adquirir o comportamento do sistema legado;<br />• Risco de criação de um sistema legado de segunda geração;<br />• Possibilidade de criação de um novo sistema, mais ágil.<br /><br />Envolvê-lo: Trata-se de envolver a aplicação do legado existente em interfaces mais modernas e atraentes. Essas interfaces permitem o uso de abordagem mais flexível de arquitetura orientada a serviços. Isso realmente não ajuda a tornar o sistema mais flexível e mais fácil de manter. Mas, contudo, permite maior acesso ao sistema legado por outros sistemas. Esta abordagem pode permitir que o sistema legado seja modularizado e, assim, parte dele pode ser substituído em uma base fragmentada. As considerações incluem:<br />• Custo inicial de pequeno porte;<br />• Baixo risco;<br />• Ainda é necessário manter os sistemas legados;<br />• Não há aumento de agilidade no sistema legado.<br /><br />Viver com ele: Tendo em conta as possíveis repercussões das alternativas, esta é uma opção popular que não surpreende. Além do risco envolvido ser quase zero, infelizmente isso não oferece nenhuma esperança para o alívio do problema do legado e fornece apenas estagnação. Com esta opção, as principais características são:<br />• Não há custo inicial;<br />• Não há redução no custo de manutenção ou na capacidade de aumentar as eficiências da operação;<br />• Não há aumento na agilidade.<br /><br />Nesta situação, como o iBOLT tornaria a integração mais fácil?<br /><br />Com o iBOLT você teria que usar simplesmente uma única ferramenta para se conectar às suas aplicações legadas, então Appley e seus colegas poderiam utilizar um conector do iBOLT for System i/AS400 para integrar rapidamente o AS400 e o sistema Yardi sem necessidade de qualquer codificação local. O iBOLT é uma plataforma de integração livre de código. Abaixo está uma imagem do iBOLT que mostra apenas uma coleção de componentes que servem a diferentes tecnologias.<br /><br />Por exemplo, usando uma ferramenta para conectar de/para sua aplicações legadas para permitir compartilhamento de dados e processos com outras aplicações. Ou um produto que tem um suporte embutido para diferentes ambientes e plataformas e pode fornecer a ponte entre eles.<br /><br />Aqui está um exemplo de como acessar os serviços do sistema System i – com recuperação de listas de objetos, valores do sistema, entradas do arquivo de spool, e arquivos do diretório IFS. <br /><br />iBOLT acessando System i <br /><br />- Integração / Exposição dos elementos do System i – que podem chamar processos externos em qualquer outra plataforma de programas OS/400 RPG/CL/Cobol via API requisitada pelo iBOLT;<br />- Função embutida de abrir o arquivo de consulta – que permite a seleção e classificação de registros no System i;<br />- Runtime de gerenciamento de ambiente – com acompanhamento do projeto em tempo real e o iBOLT pode ser usado para permitir que sistemas legados facilmente se conectem e consumam serviços recém-criados da web. O iBOLT trata automaticamente cada chamada e resposta de webservice de cada mensagem de acordo com o protocolo padrão SOAP e HTTP. Você pode efetivamente integrar aplicações legadas e aplicações baseadas na nuvem, incluindo as locais e as remotas. <br /><br />O que é mais prova de um bom futuro, do que você poder se concentrar no desenvolvimento de processos de negócio independente da tecnologia utilizada.Você, portanto, mantém todo o controle dos processos de negócios da sua empresa melhor do que qualquer fornecedor conseguiria. <br /><br />Para obter uma representação visual do iBOLT em ação, dê uma olhada no vídeo abaixo sobre o iBOLT e a integração SAP, mas lembre-se que poderia ser qualquer coisa, desde algo escrito em casa , até algo escrito em RPG.<br /><br />(*) CEO – Magic Software UK<br /></p>
