The key purpose of Enterprise Resource Planning (ERP) systems is to digitalize and facilitate the automation of business processes to increase productivity and provide better visibility of the overall business landscape. ERP systems cannot live in isolation; as nowadays business processes often expand over several enterprise systems and even organizations. Consequently, business data must seamlessly flow between internal and external systems. Enterprise Application Integration(EAI) has traditionally been used to implement an integration solution when a company had to automate business processes and data flows internally. Whereas Business to Business (B2B) integration has focused more on process automation and data flows between different organizations. Until very recently it was a challenge to cover both EAI and B2B integrations with one solution, but with the emergence of cloud-based iPaaS solutions, this is now a reality.
Below are three secrets that may help to ease the pain of ERP integration using iPaaS:
At first this may seem like a trivial issue; however, it is not. Usually, companies do not want to provide a direct inbound connection from a public network, such as the cloud, to their ERP systems via their firewall. Granting direct access would be too hazardous. You might be able to tackle security issues, for instance by using a combination of SSL/TLS and client certificate authentication. Nevertheless, usually these kind of security measures are not supported by the ERP or there’s nobody with the required know-how to set it up.
To tackle the challenge mentioned above, the most advanced iPaaS architectures support distributed deployments which allow small-footprint adapters or agents to be installed on-premise behind a firewall. From there they can provide the required ERP system integration functionalities for the integration logic running in the iPaaS in the cloud.
To facilitate flexible and yet secure integrations between the ERP and the iPaaS:
To solve the security threats described above, larger companies have implemented their own intra-company middleware solutions, such as Enterprise Service Bus (ESB) or EAI. This helps to decouple the ERP system and other backend enterprise systems from direct connections to other systems. This indicates that all the requests to ERP need to go through the middleware regardless of whether they are coming from the internal or external network. For receiving these requests, middleware usually exposes its own interface that differs from ERP’s native interface in terms of technology and message standards.
Additionally, several studies have shown that more than 75% of ERP implementations are more-or-less customized even when companies have not deployed any middleware. One might expect this since each company is keen to optimize their ERPs and other enterprise systems to serve their own business processes as efficiently as possible. It's rare that the internal business processes between the companies are the same. In customized ERP environments, the system itself does not behave according to the standard way. To make things more complicated, customization is also reflected in the interfaces of the ERP; there might be heavily-customized APIs setup, or the exported and imported data structures do not meet the ERP vendor’s standards specifications anymore.
This may lead to a situation where product-specific ERP adapters - which many suppliers offer as an easy solution to a complex problem, and which are based on each ERP products' standard interfaces - will no longer work. Product-specific adapters speed up the integration development in cases where you have a vanilla ERP deployment, with no customization, and there is no internal middleware layer in between, but they will run very soon out of options when they are faced with customizations from the ERP side.
A better alternative for gaining the needed adaptability is not to tie your hands by sticking with product-specific ERP adapters, but to understand the technology the ERP interface has been built on and use very simple technology adapters to achieve required integrations. For example, with using XML files, REST or Web Services, today you can integrate with almost any modern ERP system.
One of the pitfalls that product-specific ERP adapters may also introduce is that they try to understand ERP semantics too deeply and thus they become too coupled to certain ERP versions. Once the ERP is updated, the adapter may get confused and the integrations will stop working. In the worst-case scenario, IT support needs to log into the on-premise server machine hosting the adapter and possibly upgrade the adapter installation to fix the problem. All this may take several days and during that time your business-critical ERP integrations may be out of service.
When using a cloud-based iPaaS keeping more sophisticated integration intelligence, such as semantical and structural validations, transformations and routing, and using adapters just as simple integration gateways to gain access to the ERP data, gives you more flexibility in terms of ERP version updates. It also provides more elasticity in terms of how you can design your integration solutions, and allows you to change the integration logic afterward without the need to do any and changes to adapters installed on-premise.
Despite the challenges, iPaaS is the ultimate tool for integrated ERP system as it facilitates fast development of the customized solution and allows you to make modifications simultaneously as your business logic is changing.