Integrating applications from multiple vendors, with data in multiple formats, possibly residing on a mixture of on-premise and cloud platforms, is no longer a complex problem. Integration has become easier, more economical and more flexible than it used to be.
(Editor note 27 Oct 2016: A better blog title would have been “Application Integration SHOULD no longer be a problem”. Unfortunately, for many organizations it still is. Most of the problems are avoidable though. Please read the follow up blog “The eight most common reasons integration projects fail“.)
The ease of integration means that the dominance of the integrated ERP software suite is coming to an end. Gone are the days that organizations had to buy all their application modules from the same vendor. They can now select and integrate best-of-breed applications and it is quite common to have, for example, CRM, eCommerce, PIM, WMS and Financial modules from multiple vendors, mixed with in-house developed applications.
A (simplified) view of history
The rise of integrated ERP suites started in the nineties when applications operated in silos. Integration solutions were still primitive and relied on data-duplication and batch synchronization processes.
Organizations that needed to integrate applications from multiple vendors developed their own ‘point-to-point’ solutions, which were typically hard-coded. It meant that an integration solution had to be redeveloped if the application at either end was upgraded. This became costly and unmanageable and resulted in organizations delaying their application upgrades. It also gave point-to-point integrations a bad name, although the problems were more caused by the hardcoded nature of the solutions, than by the fact they were point-to-point.
Around the late nineties service-based distributed systems started to become popular. Gartner recognized the trend and dubbed the term SOA (Service Oriented Architecture). The real momentum for SOA was created by web services around 2002, although not all SOA is based on web services. This was soon followed by ESB (Enterprise Service Bus) integration solutions, software that was meant to replace all direct point-to-point contact between applications on the bus, so that all communication would take place via the ESB. As it takes a while to setup the bus, ESB projects were typically hard to get from the ground.
Initially ESB vendors were given (and happy to take?) credit for many of the advantages that SOA and web services bring. Organizations even mistakenly believed that you needed an ESB to implement SOA and web services and for a while the three technologies became almost synonymous.
Eventually web services became very wide spread and organizations realized you didn’t need an ESB to implement them. ERP vendors, under pressure to open-up their applications, also embraced web services and they became the most commonly used technology in vendor delivered APIs (Application Programming Interface). Nowadays most ERP vendors offer, at a minimum, APIs to support what Gartner refers to as a postmodern ERP technology strategy, where operational and administrative ERP strategies can be different.
Today
The traditional ESB solutions have become too big and heavy to deal with the dynamic world of hybrid, cloud and on-premise systems. Organizations are gradually replacing their big, complex and expensive ESB systems with nimble, codeless and affordable Business Process Integration (BPI) platforms that can handle:
- Transportation — moving data between source and target.
- Transformation — mapping data between many different formats.
- Process Orchestration — sequential and conditional execution of process flow.
- Administration — auditing, error-handling, logging, security and system operations.
While it makes sense to avoid a patchwork of integration solutions and select a BPI platform with which you can create and manage multiple integration scenarios (e.g. web services, message services, XML, EDI, FTP, text, email, PDF, etcetera), there is no benefit to putting a bus in the middle at execution time.
The modern combination of cloud and on-premise systems requires a decentralized architecture and loosely coupled integrations. Point-to-point integrations are fine again.
Customer Examples – Best-of-Breed application integration
Eagle Systems, Inc. (ESI) a leader in intermodal transportation and container repair based in the USA, has recently implemented NetSuite Financials, a cloud-based solution, but will keep using its heavily customised ERP system to run its transportation management business. To synchronize and integrate the two disparate systems in this hybrid cloud environment, Eagle uses LANSA Composer and web services. The solution
- Keeps the customer master and other key files in synch
- Posts tens of thousands of ERP invoices and credit notes to NetSuite, and
- Lets Eagle’s on premise ERP system interrogate its cloud-based instance of NetSuite in real time to check customer account balance
Eagle is also using LANSA Composer to automate EDI and other transactions with its partners and to streamline the individual process flows and FTP transmissions with its container maintenance customers. Read more about Eagle’s project
Green’s General Foods, based in Australia, produces and distributes food products, such as baking and pancake mixes, crackers, cereals and popcorn. Green’s previously had over 150 modifications to its ERP system, mostly related to hard-coded integration with a Warehouse Management System (WMS) and EDI solution from another vendor. The modifications made it hard to upgrade the ERP system. By moving the transformation, transportation and orchestration outside the ERP, Green’s could wind back its many ERP modifications while continuing to use best-of-breed WMS and EDI solutions. Since the integration solution is code-free, custom processing is now managed by a business analyst, rather than a developer. Read the Green’s Case Study
Whitepaper: Choosing the right Business Process Integration solution
