Tag System i

Padrões e Melhores Práticas para Integração ERP

Glenn Johnson – Senior Vice President – Magic Software Americas

Integração ERP pode ser definida como o processo de projetar, testar e implementar processos de negócios automatizados, orquestrando as conexões entre os sub-processos de um sistema de planejamento de recursos empresariais e os sub-processos de outros aplicativos de software corporativo, aplicações web, ferramentas de conteúdo, sistemas de e-mail/comunicação, mídias sociais e workflow humano.

Quando alguém aplica os princípios de integração ERP para um sistema ERP específico, isso pode se tornar conhecido como Integração SAP, Integração JD Edwards, Integração Peoplesoft, Integração Oracle eBusiness Suite (EBS), Integração Lawson, Integração Dynamics, Integração Sage, etc.

Melhores Práticas e Padrões de Integração durante a Implementação de Sistemas ERP

Plataforma agnóstica. Os sistemas ERP estão ligados a uma plataforma de aplicações ou ambiente específicos, tais como J2EE ou. NET e você também os executa em um sistema operacional específico. Sua integração de aplicações empresariais (EAI) e solução de gerenciamento de processos de negócios (BPM) deve ser capaz de trabalhar com todos os principais ambientes de computação e sistemas operacionais, incluindo Windows, Linux, UNIX e IBM i. Uma boa solução de integração ERP vai mesmo ser capaz de suportar os padrões de integração IBM i e padrões de integração de mainframe para aquelas organizações que executam aplicações nestes ambientes.

Modelagem e execução integradas. Muito freqüentemente, os analistas de negócio são forçados a modelar processos de negócios de alto nível usando uma ferramenta e executá-los usando soluções completamente diferentes, incluindo programação manual, pacotes de componentes java, ou soluções de EAI e BPM mal concebidas. Os gerentes de TI precisam ser muito cuidadosos aqui. Só porque a mesma marca, tais como IBM WebSphere ou Oracle Fusion Middleware, é aplicada a uma variedade de produtos diferentes utilizados para modelagem e integração pelos fornecedores, não significa que eles sejam integrados e projetados para trabalhar juntos. Ambas as marcas são conhecidas por ter usado uma estratégia de aquisições ao invés de uma estratégia de desenvolvimento unificado para ganhar mercado. Como resultado, suas ofertas para integração de aplicação e gerenciamento de processos de negócios são desconexas, confusas, sobrepostas e frustrantes para serem entendidas – e mais ainda para serem utilizadas.

Decisores de negócios devem ser extremamente cuidadosos com as recomendações que amarram sua integração ERP com estas soluções de integração desarticuladas e fraturadas de grandes marcas. Elas exigem numerosas compras de licenças de software e um exército de desenvolvedores e implementadores para realizar a integração. Não caia na “armadilha do mel”, método de vendas que convence que você precisa de apenas uma das muitas ferramentas de software avulsas oferecidas por estas marcas e, em seguida, prossegue com uma estratégia para vender mais e mais  produtos diferentes e desconexos que são agrupados sob a mesma marca, a fim de tentar forjar uma solução de trabalho.

Monitoramento e Design paralelos. Quando o monitor de integração utiliza a mesma interface visual que o estúdio de design de integração, fica muito mais fácil para seus gestores de TI monitorarem a execução de seus processos de negócios. Monitoramento e design paralelos significam que o fluxograma que você criou para seu projeto de integração é o mesmo que você utiliza para controlar sua execução. No estúdio de design você pode se aprofundar em qualquer componente para ver a sua configuração. No ambiente de monitoramento você pode se aprofundar em qualquer componente no fluxograma para acompanhar a sua execução.

Nenhuma Programação Manual. Há uma série de soluções de integração de aplicativos que destacam o fato de serem livres de código, ou que nenhuma programação manual é necessária. Isto só será útil se a solução o levar longe o suficiente na direção de seu objetivo final. Uma viagem gratuita de táxi que te deixa a vinte milhas de seu destino não tem nenhum valor. Uma solução de EAI que é livre de código, mas não pode adaptar-se à variedade de tecnologias em uso hoje, é igualmente de efeito muito limitado. Alguns vendedores podem mostrar uma demo estratégica de integração entre o JD Edwards EnterpriseOne e Salesforce.com, por exemplo. Mas eles realmente possuem os adaptadores de baixo nível necessários para integrar o JD Edwards World? Podem se integrar com aplicações legadas? Filas de mensagens? Fontes de texto não estruturadas? Eles podem funcionar com arrays multi-dimensionais? Será que eles possuem uma gama completa de operações lógicas incluídas em seus editores de expressão?

Equilíbrio entre Adaptadores de Alta Granularidade e Baixa Granularidade. É impossível para qualquer solução de integração de ERP ter adaptadores pré-construídos para todos os outros aplicativos que você pode possivelmente querer integrar. É por isso que é muito importante que a solução de integração ERP escolhida tenha os adaptadores tecnológicos necessários para realizar o trabalho. Isso significa muito mais do que ter suporte para bancos de dados e web services. Verifique atentamente para ver se a solução escolhida tem suporte para protocolos de comunicação, sistemas de arquivo, codificação / decodificação, redes e outras tecnologias de alta granularidade de baixo nível que te permitirão colocar em prática a integração necessária, sem recorrer à programação de interfaces para essas tecnologias. Qualquer analista de negócio que tenha experimentado a satisfação de realmente configurar uma solução de integração e não programá-la, entenderá este ponto muito claramente.

Aplicações compostas. Estas são as aplicações que são montadas utilizando tanto componentes de múltiplas aplicações existentes e adição de funcionalidades desenvolvidas especificamente, quanto serviços, tais como leitura de pedido do cliente, validação do status do cliente, cálculo do desconto ao cliente, ou aplicação de desconto ao pedido. Os componentes de uma aplicação composta são criados independentemente uns dos outros, sem o conhecimento ou análise dos diferentes modelos de informação que estão sendo usados. Na verdade, eles são independentes de plataforma, o que significa que o componente  que fornece algum serviço pode residir em qualquer plataforma capaz de fornecer tal serviço. Quando a integração ERP permite que o sistema ERP forneça serviços como parte de uma aplicação composta, você valoriza muito mais o seu investimento no ERP e começa a ver a recompensa prometida por fornecedores de ERP no início.

Arquitetura Fracamente Acoplada. Seu padrão de integração ERP deve incorporar arquitetura de baixo acoplamento com forte integração com o sistema ERP em si. Arquiteturas fortemente acopladas dependem umas das outras. Assim, alterações em qualquer componente podem (o que freqüentemente acontece) exigir mudanças em muitos outros componentes. Arquiteturas fracamente acopladas, em contrapartida, mantêm independentes os componentes que podem operar de forma independente. Uma arquitetura de baixo acoplamento permite substituir ou modificar componentes sem ter que fazer mudanças que refletem para os outros componentes. Desenvolvedores podem exigir a tecnologia correta para o trabalho sem ter que se preocupar com dependências técnicas. Na integração com ERP, você vai querer ter a certeza de que manterá os fontes do ERP e os destinos de terceiros separadamente (e vice-versa).

Componentes Stateless (sem estado). Os sistemas de ERP normalmente são capazes de múltiplas transações simultâneas. Isto é essencial para a escalabilidade da arquitetura. Quando um componente permite que mais de uma instância do componente esteja em uso simultaneamente e com estados separados, então ele é considerado um componente stateless. Isto tem a vantagem da escalabilidade e é vital para uma implementação robusta de arquitetura orientada a serviços e integração escalável de ERP.

Componentes Dinâmicos. Embora seja vantajoso ter componentes stateless em termos de dados de cada instância de execução, também é vantajoso ser capaz de configurar componentes de forma flexível para seu ambiente. Suponha que você está configurando a integração do Microsoft Dynamics CRM com o Oracle JD Edwards EnterpriseOne. Um sistema que utiliza componentes dinâmicos permitirá que você atualize a configuração do componente de forma a refletir quaisquer campos ou tabelas personalizados em uso nos ambientes de destino. O projeto de integração ERP é bastante simplificado quando os componentes utilizados podem ser passados em um pacote XML que configura a instância de execução. Um sistema de ERP que combina componentes sem estado e dinâmicos terá grandes vantagens, tanto no projeto concepção e execução.

Web Services. A Integração de ERP que utiliza Web Services pode vir a ter programação incrivelmente intensiva. Web Services programados manualmente também são difíceis de manter. Com Web Services nós estamos falando sobre o uso de protocolos padrão (como o WSDL, SOAP e UDDI) para “envolver”  serviços SOA, de forma que possam ser compartilhados com outras aplicações através da Internet. Este termo é freqüentemente usado como sinônimo de “SOA”, apesar de Web Services ser na realidade um mecanismo que permite SOA. Mas apenas porque estas tecnologias estão sendo utilizadas, isso não significa que você deve recorrer à programação delas. Uma boa solução de integração evitará completamente a necessidade de programar conexões para o seu sistema de ERP e outras aplicações, sistemas de comunicação e Web Services em seu ambiente.

Enterprise Service Bus. Um enterprise service bus é um mecanismo de mensageria distribuído baseado em XML, orientado a eventos – é um tipo de implementação de arquitetura orientada a serviços. É mais adequado para ambientes com servidor Wintel do que para ambientes de computação de médio porte, embora um sistema de médio porte possa certamente funcionar como um nó em uma implantação de enterprise service bus.

Sem um planejamento cuidadoso e a seleção de uma solução ágil de integração de processos de negócios orientada a eventos, a Integração ERP será cara, demorada e instável. Embora muitas empresas procurem evitar riscos, comprometendo-se com soluções de grandes marcas para integração, em vez disso eles estão expondo-se a maiores riscos e apenas evitando a culpa. É o fracasso destas grandes soluções para integração que inspirou a Magic Software a trazer a solução de integração iBOLT. Os wizards amigáveis ao usuário do iBOLT, as opções de arrastar e soltar, e as tabelas permitem criar conexões diretas com as aplicações corporativas implantadas em qualquer tecnologia de hardware, sistema operacional ou banco de dados. O resultado é uma arquitetura flexível e escalável que te permitirá fazer novas conexões, implementar mudanças e se adaptar rapidamente à necessidade sempre presente de mudanças em seu negócio.

A integração de aplicativos cloud com sistemas legados

David Akka

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.    

iBOLT acessando System i

  

– 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]