System integration is like a commute, getting you from A to B. So why is there an overload of ERP integration tech options? Well, sometimes the destination is a system or an external business, and that determines the right integration technology choice. These options aren’t just programming languages but products of industry collaboration for interoperability. They may seem like business jargon to developers, but each plays a vital role.
The problem starts when companies blindly adopt these technologies without grasping their strengths and weaknesses. API or webhooks are classic examples. While they have made system integration easier, they might not be the best fit for every scenario. And let’s face it, dismissing a tech simply because it’s seen as “legacy” is like ditching radio for TV. So unless the enterprise technology is positioned as a clear successor, using something just for the “cool factor” might not be the wisest move.
Also, there are generally three layers in the architecture: web/UI, services, and database. Each integration technology option is optimized for one of these layers. For example, ETL’s design allows it to be efficient for quick and bulk movement of data, bypassing the business rules. But, newbies, listen up closely: bypassing business rules is a design choice but not always the best idea. Integration technologies optimized for web layers aren’t fit for every situation either. They have their own set of nuances, like UI layers may include additional presentation-centric logic only applicable to that layer. So how to select an appropriate option for your unique situation? Get a grip on the pros and cons of each tech option from the following list.
10. Natively built within ERP code/Custom-built and Externally Deployed
Most newbie ERP buyers mistakenly assume that business systems package unlimited bandwidth, oblivious to the fact that integrating additional code can strain system performance. ERP OEMs don’t typically plan for extra firepower in their core offering.
While minor customizations and some ERP integration logic can coexist within an ERP system, it’s not meant to cram ten passengers into a four-seater car. ERP Integration native to the platform comes in different forms: some people code it recklessly, bypassing security rules and tampering with the database directly, while others use add-ons or external components for deployment.
What’s it good for?
- For tightly integrated processes that touch master data, such as inventory. Customizations that seem inseparable from the core codebase.
- The code base is not likely to change. The state of code must not break because of invariability in inputs. The integration code requires frequent changes because of the changes in interfaces or inputs.
- The code base that the OEM must own regardless of technical or political drivers.
Myth
- Host the entire integration code inside the ERP to save costs. Don’t be fooled by this idea. You might pay much higher in the long term because of increased maintenance or slowed performance of systems.
- ERP integration logic can carry the additional workload. No, the planned capacity assumes that you must be running ERP with minimum customizations.
Best practices
- Host integration code inside the ERP that is tightly coupled with master data. Master data elements like inventory master or customer and vendor master.
- Host any native add-ons inside the ERP. The add-ons that are natively built for the embedded experience must be hosted inside the ERP.
- Don’t host the integration code inside the ERP that requires frequent changes or is prone to errors.
In short, don’t rush to host everything in the ERP. If your integration code simply moves data from A to B, it’s better off outside the legal and code boundaries of the ERP package.
9. Workflow Automation/RPA
Workflow Automation and RPA technologies are the newest entrants among integration technologies. While the flavors of workflow automation have been around, they weren’t as lean and efficient to automate user-driven processes embedded with system-driven. The tricky part is differentiating these technologies from iPaaS, which focuses on system-to-system integrations.
What’s it good for?
- Users and desktop-centric workflows and processes. Think of automating the responsibilities of a clerk performing monotonous tasks such as data entry or approvals.
- Good for tightening the processes of transactional systems. Such as ERP or eCommerce. Processes like improving the quality of master data: SKU numbering scheme or customer names.
- Good for ad-hoc processes. Think one time and not something that is part of your operational fabric.
Myth
- Replacement for other transactional technologies. It’s not meant to be better or worse than other technologies. They all have a role to play.
- Workflow automation and RPA are more cutting-edge. Everything is cutting-edge if you use it for the right use case.
- They are easier than other technologies, such as ERP. Every technology could be easy or hard, depending on how it’s being used.
Best practices
- Define the architecture and roles of the RPA and workflow technologies. Drawing architectural boundaries will help you clarify the roles and responsibilities of technologies.
- Analyze the admin effort first to ensure it’s not a symptom of broken processes. As well as to avoid automating broken processes.
- Don’t implement RPA and workflow tech just because they are cutting-edge.
In short, Workflow Automation and RPA technologies are great for ad-hoc and desktop-centric tasks, but they fall short when it comes to handling transactional, operational processes.
ERP Selection: The Ultimate Guide
This is an in-depth guide with over 80 pages and covers every topic as it pertains to ERP selection in sufficient detail to help you make an informed decision.
8. eCommerce and Marketplaces
You might be surprised to find eCommerce listed as an ERP integration technology. But believe it or not, eCommerce, EDI, or P2P could be substitute technologies and serve a similar role to integrating with sales channels, especially if the purpose of eCommerce is just to capture orders. The same applies to marketplaces. They have their own integration platform that could serve the role of integration layer.
What’s it good for?
- Smaller eCommerce brands that can’t afford expensive ERP integration just yet. Don’t fall for the temptation of point-to-point plug-and-play integration! While it may seem easy at first, you’ll end up with more reconciliation headaches downstream.
- Integrating with marketplaces that are a natural extension of that channel.
- Marketplaces and channels where segmentation of inventory for each channel is not as critical.
Myth
- Most channels must be routed through eCommerce, including punchouts. Based on the enterprise architecture and traceability needs, sales channels can be integrated through eCommerce or ERP.
- Pricing must belong to eCommerce. Depending upon the pricing segmentation and control required, it can belong to eCommerce or ERP.
- Bi-directional syncs are easy to implement through APIs. Without workflow design and control, bi-directional sync is likely to corrupt the data, challenging to reconcile.
Best practices
- Define the role of eCommerce, marketplaces, and channels. The clarity in roles will help you define your architecture.
- Define the traceability required for pricing and discounting and host in appropriate channels.
- Treat eCommerce as an order capture channel and then move to the central, downstream system to minimize the hops for reconciliation.
Use eCommerce and marketplace channels primarily for order capture. But for more complex scenarios, don’t forget to define your architecture, including reconciliation workflows, to ensure simplifying the front-end doesn’t lead to complicating the backend.
7. API
Most people misunderstand the role of APIs in ERP integration. The APIs hide the technical boilerplate of underlying technologies obeying the same security rules as the user interface. This prevents the tempering of databases directly and separates integration from core system concerns. Not meant to be plug-and-play, though often perceived, so designing architectural and reconciliation workflow is critical with APIs.
What’s it good for?
- To easily communicate with internal systems. Unified communication without worrying about translations and protocols required to communicate with each underlying technology.
- To integrate easily without tempering the state of the core system. Unified security and business rules layer across channels and integration points.
- To isolate core systems from the integration logic. Easier debugging and maintenance through clarity in the roles and responsibilities of the integration layer and logic
Myth
- APIs are replacements for architecture. APIs only provide easier access to data from applications implemented in different technologies, but how you want to mesh them together to achieve the desired outcome requires thoughtful design.
- As long as you have APIs, you can integrate anything. Yes, you can, as long as you have workflows and architecture vetted out.
- APIs are better than EDI. Not true at all. EDI allows external B2B communication where pre-agreed, industry-wide messaging is critical. Since most companies define their own standards for APIs, they don’t have the same canonical model as EDI.
Best practices
- Define security architecture before incorporating integration through APIs
- Isolate ERP integration code completely from the core system
- Define system interaction flows, and master data governance path with APIs
APIs have made ERP integration easier as they hide the underlying technical details and allow integration easily with wide-ranging technologies and systems. But they can’t create the integration flows themselves, and not meant to be plug-and-play.
6. P2P and Punchouts
Larger companies generally use a procurement system to streamline their procurement processes. The P2P systems may have a gateway built with eCommerce systems to communicate between the client’s P2P and the vendor’s eCommerce. They can share their catalog, complete transactions, and receive updates on their orders.
What’s it good for?
- The customer is too big to go to vendor’s websites to place orders. As big companies grow, they graduate from browsing vendor websites to place orders. The natural next steps? P2P or EDI
- Integrating with suppliers when you aim to consolidate and centrally govern your procurement processes.
Myth
- Punchouts and P2P systems are superior to ERP. P2P systems tend to decouple the downstream processes to expedite purchase flow but at the expense of workload for downstream systems.
- P2P systems are best for any procurement organization. Only good for larger companies who prefer to simplify their front-end processes at the expense of the backend.
- Punchout must go through the eCommerce channel. Depending upon the architecture, organizational structure, and traceability needs, integrate P2P systems with ERP or eCommerce.
Best practices
- Integrate with P2P if your large customers have mandated them. While integrating with it might not be optional, how you will integrate is your architectural decision.
- Define the roles and responsibilities of P2P vs. ERP vs. eCommerce. Identifying clear boundaries for each system will help define the architecture.
- Define the reconciliation and master data governance workflows for P2P, ERP, and eCommerce systems. To help decide: ease of use vs. increased overhead for downstream processes.
P2P and punchout integration are great when customers might mandate them to integrate with their systems. They might also be good for streamlining your vendor processes. But they are neither replacements for nor easier than any other integration technologies.
5. ISV Add-ons
Some ISV add-ons could provide the same capabilities as integration technologies, as well as augmenting business objects for improved traceability and collaboration with business partners. Despite their plug-and-play integration capabilities, analyzing architecture and reconciliation flows is still critical.
What’s it good for?
- Integrating with vendors that might not be able to afford other expensive integrations. Compared to P2P, EDI, or eCommerce, ISV add-ons could provide automated communication at a much lower cost.
- Providing additional granularity with the business objects and workflows.
- Hosting additional data that might not be relevant for the ERP and doesn’t need to be centralized.
Myth
- Enterprise architecture is not relevant to ISV add-ons. ISV add-ons are nothing but data siloes, and they should be treated just like any other systems in the architecture.
- Master data governance and reconciliation flows are not relevant for ISV add-ons. While they might be plug-and-play to integrate, the analysis of reconciliation workflows and master data governance is still critical.
- ISV add-ons are easier than ERP. Easier because they decouple the underlying systems but increase the admin efforts for downstream processes. It’s a design choice.
Best practices
- Use ISV Add-ons, but only if it makes sense architecturally.
- Where vendors or customers might not have any other means of integrating with your systems and are willing to communicate through the ISV add-ons.
- When underlying data make sense to augment in an add-on system than in the ERP.
ISV add-ons provide additional traceability and datasets that might be more expensive to build inside an ERP. They also provide cheaper ways of integrating than P2P, EDI, or eCommerce.
+ 
ERP Implementation Failure Recovery
Learn how Frederick Wildman struggled with Microsoft Dynamics 365 ERP implementation failure even after spending over $5M and what options they had for recovery.
4. WebHooks
WebHooks allow communicating with external systems as business objects advance. While they can support more intricate integration scenarios than APIs, they are also not meant to be plug-and-play. Not inherently providing transactional consistency or seamless communication, designing integration flows isn’t optional with them.
What’s it good for?
- Easier web-centric integrations that don’t require tight master data governance. If the integration is primarily to notify or log/report in the destination system, use WebHooks.
- Easier to use with web-centric technologies. Not as useful if there are any non-web channels involved in the architecture.
- Good for integration flows where tight security may not be of concern.
Myth
- Webhooks are easier than other integration technologies, such as EDI. Not meant to be replacements, Webhooks don’t support industry-adopted canonical messages like EDI.
- Webhooks are modern ways of integration. Despite allowing tighter embedding of web apps without tempering with the core, they are not better than any other integration technologies.
- The technologies that don’t support webhooks integration are legacy. What if legacy technologies don’t have a use case for Webhooks?
Best practices
- Use webhooks integration for commerce and web-centric technologies, especially where a tighter collaboration of web apps would make sense.
- Analyze the impact on omnichannel architecture if webhooks are still a good fit.
- Understand the security needs and master data governance before integrating it with Webhooks. Design, architecture, and reconciliation workflows are not optional, even with webhooks.
Webhooks are great for additional granularity that APIs might not support, as well as allowing tighter collaboration of web apps. But they are not meant to be a replacement for any other integration technologies.
+ 
ECommerce Supply Chain Transformation
Learn how LockNLube transformed its inventory and supply chain challenges by consolidating over 20 systems.
3. ETL
ETL is faster at bulk data movement, but it’s not the best choice always. It’s faster because you bypass the business rules to get quick access to raw data without impacting operational performance. It’s like using a service elevator while moving. But replacing passenger elevators with service ones is not the best choice.
What’s it good for?
- Bulk data transfer among databases. No other interactions at the UI and service layers through ETL.
- Nightly load to get data in a snapshot to perform analysis. Only when you need raw data for analysis, without touching operational workflow.
- Where faster processing at the database level is required. Think quick-moving without disrupting the passenger flow of an apartment building.
Myth
- ETL can cater to most integration scenarios. Calling the service layer and processing EDI transactions through the ETL layer is like exploiting your superpower.
- Even service and UI integration scenarios can be done through ETL. This would be very similar to accessing databases directly. APIs exist to prevent direct database access for unified security and business logic.
Best practices
- Use ETL only for the database-to-database integration. Using ETL for anything other than moving bulk raw data is an antipattern.
- Don’t use ETL where service layer integration may be a better fit. Just like the passenger elevator is perhaps the safest choice when in doubt, ETL access should be a privilege.
- Don’t use ETL for EDI or external integration with other businesses. This is like letting passengers go through the service elevator without security protocols or scrutiny.
Think of ETL as a special privilege allocated for one-off scenarios for bulk data transfer without impacting operational performance. So don’t let ETL touch other layers except for the database.
2. EDI
More than an integration technology, think of EDI as “electrical codes” designed for industry collaboration. Replacing EDI with API would be similar to leaving red vs. green for interpretation. Also, just because you prefer to swap out red with green in your home, it’s your personal choice. APIs are superior for personal choice, while EDI helps with regulated communication across industries.
What’s it good for?
- For B2B communication, where regulated communication is critical. Where each message is coded with the same standard without requiring interpretation.
- Where standardized messages are a requirement across all vendors, think of how terms such as receipt or profit could have different meanings in different contexts. EDI helps us prevent this confusion.
- Integrating with vendors that might already understand EDI or may have systems that are EDI-compliant.
Myth
- EDI is a legacy communication method. EDI is perhaps the most concise industry communication language ever designed. Get used to it!
- EDI should never be used. APIs are a better choice for integration. Using APIs where EDI would make more sense is like skipping electrical codes just because you don’t appreciate them. There will be consequences when you let an unlicensed electrician repair your home.
- EDI is slow and error-prone. Only when it’s being overly used and poorly designed.
Best practices
- Use EDI where systems might already be EDI-compliant.
- Implement EDI where standardized communication could reduce churn with vendor communication.
- Don’t use EDI for internal communication. Not designed for internal integration. APIs would be a better choice for that, or you will outgrow EDI codes.
Just like technology does not answer every question, EDI is a communication and collaboration language. Use EDI for externally regulated communication but avoid it for internal system integration.
+ 
ERP Optimization And Integration Architecture Development
Learn how Work Sharp fixed their broken ERP implementation that caused customer service issues and improved Supply Chain planning.
1. iPaaS/Middleware
iPaaS and middleware are probably one of the most overused terms. The role of iPaaS and middleware is to connect external wiring among different systems in the architecture. Not just that, though. Translation, transformation, and quarterbacking, when you might have systems that might operate at different speeds, would be other benefits.
What’s it good for?
- To implement integration logic. Integrating two or multiple systems through a variety of communication methods and technologies.
- To have room for load throttling. Cloud technologies don’t offer the same infrastructure control as was available in on-prem settings. The point-to-point connections assume that all systems can operate at the same speed, which might be OK at a smaller scale but not at a transactional inflection point when you need to decouple your workloads.
- To isolate integration logic from core systems. The separation helps with debugging, maintenance, and isolating issues.
Myth
- Unnecessary license fee. The additional license fee might come across as unnecessary, but keep the slower performance or increased fee due to the higher tier of your ERP infrastructure in mind.
- IT-centric systems are only relevant for large enterprises. Even smaller companies might use the baby version of iPaaS, such as Zapier. They might not be as capable as their larger peers.
Best practices
- Don’t host business rules and logic that must be hosted in the core system
- Keep only the integration and transformation logic inside the iPaaS layer
- Host only the workflows geared toward system-to-system communication. User-centric workflows might not be the best candidate for iPaaS. They are better suited to workflow-centric technologies.
Always use iPaaS in the architecture unless your needs are to use one system without requiring integration. But don’t assume that you have one system when you might be using a collection of apps underneath with the branding of one, like an ERP system.
Final Words
Just like attempting to “fly” to your neighbor’s house may not be the wisest move. It’s important to use integration technologies purposefully. Overusing them can lead to scalability and performance problems, even if they might be the trendiest tech around.
Moreover, integration isn’t just about moving data from point A to point B. That’s the easy part. The real challenge lies in tackling compliance issues and building an enterprise architecture that aligns with business and performance goals. So, if you’re new to the integration game, don’t get swayed by the latest technologies. Dig deep into their origins and intended use, and apply them wisely. Hopefully, this list can serve as a helpful 101 guide.
The 2024 Digital Transformation Report
Thinking of embarking on a ERP journey and looking for a digital transformation report? Want to learn the best practices of digital transformation? Then, you have come to the right place.
FAQs
Related Posts:
