David Akka – CEO – Magic Software UK
Em um artigo recente e muito bem escrito, intitulado “Cloud Computing: o que os CIOs precisam saber sobre Integração”, Kim Nash – CIO.com editor sênior – entrevistou CIO’s e CTO’s que estavam dispostos a compartilhar a sua experiência de computação em nuvem. 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.
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?
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.
Há todo um espectro de razões pelas quais isso poderia ser o caso, mas, essencialmente, é porque:
(A) Está sendo executado em uma plataforma cara (e muitas vezes obsoleta);
(B) É escrito em uma linguagem obsoleta;
(C) Não há mais ninguém na equipe que o compreenda.
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.
Motivadores de negócios para a modernização:
• A rápida evolução das necessidades do consumidor e dos modelos de negócios
• Tarefas manuais caras e demoradas devido à sub-processos semi manuais – o processo global não é racionalizado.
• Incapacidade para adicionar interações ricas (baseadas na web) e módulos móveis para aplicações legadas.
• Os usuários não estão satisfeitos
• Novos padrões/regulamentos/notificações não podem ser implementados/suportados em tempo.
• Integração manual de processos
• Fusão e Aquisição – necessidade de integrar processos de negócios
• Definição e monitoramento de workflow/processo
• Alto custo de manutenção de sistemas legados reduzindo o orçamento disponível
Motivadores de Tecnologia:
• Permitir o uso de Web Services
• Reutilização do código existente combinado com novos serviços/códigos
• Sincronização de dados entre legado e novas aplicações/processos
• Migração, substituição ou cenários mistos de plataforma e/ou banco de dados
• 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
• Construção de uma arquitetura SOA, incluindo aplicações legadas
• Manipulação de transações para processos que integram aplicações legadas
Opções com Legados
Tradicionalmente, há poucas opções quando uma organização procura lidar com um desafio do sistema legado. Geralmente, uma organização pode:
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:
• Alto custo inicial de desenvolvimento;
• Risco muito elevado;
• Dificuldade para adquirir o comportamento do sistema legado;
• Risco de criação de um sistema legado de segunda geração;
• Possibilidade de criação de um novo sistema, mais ágil.
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:
• Custo inicial de pequeno porte;
• Baixo risco;
• Ainda é necessário manter os sistemas legados;
• Não há aumento de agilidade no sistema legado.
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:
• Não há custo inicial;
• Não há redução no custo de manutenção ou na capacidade de aumentar as eficiências da operação;
• Não há aumento na agilidade.
Nesta situação, como o iBOLT tornaria a integração mais fácil?
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.
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.
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.
– 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
– Função embutida de abrir o arquivo de consulta – que permite a seleção e classificação de registros no System i
– 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.
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.
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.
[youtube=http://www.youtube.com/watch?v=VvThGAqQRUo]