If you found this article, chances are you already know why you need a solid eCommerce and ERP integration. After all, ERP is kinda of the backbone of any online shop; a master system, if you like, that allows you to effectively handle sales orders and order fulfillments, manage your supply chain and B2B partners, and keep track of the inventory, especially if you sell on multiple channels.
So instead of going through what an ERP system is or the benefits of its integration with eCommerce (which you undoubtedly already know, otherwise you wouldn’t be searching for how to enable this integration), let’s go over the available options, potential obstacles, and different approaches.
Part 1: Two approaches to ERP eCommerce integration
In case of ERP eCommerce integration – as well as in any application integration in general – all integration approaches can be divided into two categories: point-to-point integration (P2P) and middleware integration tools. I’m going to go on a hunch that you already know what each of these means, so let’s examine in which cases one is better than the other.
Point-to-point integration
The benefit of this approach is that when you have just a handful of applications to connect, it is a relatively simple and cost-effective way to do so. Oftentimes you will have to familiarize yourself with new APIs (if an API is how a respective application allows you to “talk to it”), but if an API is well-designed and documented, it shouldn’t pose a lot of challenges. However, this approach needs to be treated with caution.
First of all, while this approach works well when you have just 2-3 applications to connect, it can quickly grow unmanageable when more applications join the party. According to the n*(n-1) connections rule (also referred to as the n-squared problem), if four disparate systems need to communicate with each other bidirectionally, pushing and pulling data, the total number of point-to-point connections can be up to 12. If it’s six business solutions (for example: CRM, ERP, online shop, product information management (PIM), marketing automation and accounting), this number jumps up to 30.
This is quite a lot of connections to build, maintain and keep up-to-date. Especially the latter eats into financial and scarce development resources, because some vendors continuously update and improve their APIs.
THE CONCLUSION: Before you embark on P2P integration, consult with e.g. a business development executive what the company’s strategy with respect to their eCommerce presence is. Are there more applications to come in the foreseeable future? More selling channels to address? Maybe, marketing should be shaped more tightly around the customers’ purchase behaviour? If that’s the case, it might be better to turn to using an integration middleware.
Integration Middleware
Middleware is rather a generic term that refers to software or applications that sit between two or more business solutions or data sources. Middleware integration is superior to P2P integration in the way that once a connection to, say, a CRM application is established, it can be reused for connecting it to a number of other applications instead of having to pair applications with each other from scratch.
There are several architectural patterns to approach a middleware architecture, with Hub and Spoke vs ESB being the ones that are most often cited on the Internet.
To be entirely honest, no one could explain to me what the clear difference between the two is. Yes, the baseline architecture is different as you can see on the pictures above and below, but the core function is largely the same. Both have a central mechanism that removes the necessity of applications to talk to each other directly: a message broker in Hub and Spoke vs message bus in ESB. Both enable data transformation and routing between the core business applications.
The only notable difference is probably that message transformation and routing are present in different layers – connectors vs. hub. A side note: After additionally researching the difference of Hub and Spoke vs ESB and sifting through about 20-30 different sources, this was the one I found more insightful than the rest.
More enlightening is the intended scope of use for these architectural designs. Due to its centralized architecture, Hub and Spoke is generally considered to be less scalable than ESB as well as offering less performance. It is also seen as less flexible in its implementation and usage scenarios, considering that its architecture is monolithic and the provided services are not standard-based. On the other hand, ESB implementation is generally more complex to manage when the environment grows and is seen to be rather unfit for resource-strapped IT teams.
And what about iPaaS?
While we’re on the topic of integration middleware, let’s not forget to mention iPaaS. Integration platform as a service (iPaaS) is not a middleware design pattern per se but rather a middleware product, but it’s worth mentioning nonetheless.
Strictly speaking, iPaaS works on the same principle as ESB, especially considering that many ESB products of today are more lightweight and cloud-friendly than their predecessors. However, due to its architectural design and legacy, even the modern ESB solutions are considered to be best suited for older, on-premises, and mostly internal applications. In some cases, iPaaS can offer better value for money, more scalability and connectivity to external sources (for example, in B2B eCommerce ERP integration) but on the other hand, struggle to handle legacy software solutions.
Generally, though, with the middleware approach, you have more visibility and transparency into your integration endpoints. Additionally, modern tools usually come with solid monitoring and logging functionalities, which help pinpoint and fix bugs more quickly than in the case of P2P integration.
THE CONCLUSION: If you’re thinking about implementing an integration middleware, you’ll need to take an inventory of systems to connect, noting where most of them reside (on-premises or in the cloud), and whether you’ll need to connect to your B2B partners’ business software solutions on top of it. Clarifying such questions as the desired scalability and performance of integrations is also imperative. If most of the systems are in the cloud and high scalability is of great importance, then iPaaS is probably the right choice; if it’s largely on-premises business software solutions that you want to connect, you might want to go for Hub and Spoke or ESB.
Part 2: How to get started with ERP eCommerce integration
Understanding the common data integration patterns for ERP and eCommerce
First things first, these patterns are not reserved to ERP eCommerce integration per se; these are general data integration patterns that apply to ANY system. But since we are now reviewing specifically the ERP eCommerce integration, let’s review them from this perspective.
There are various needs that ERP eCommerce integration can address. It’s not only about processes automation, better resources planning and effective inventory management, but also about availability of the most up-to-date customer, product and accounting data across the entire organization in order to optimize business processes and operations.
These five patterns for ERP eCommerce integration are able to address most (if not all) of these needs.
- Migration
- Broadcast
- Aggregation
- Bi-directional sync
- Correlation
ERP eCommerce data migration
Data migration is about shifting a specified set of data from one system to another. This pattern can be useful for several reasons: For example, if you transfer data from a legacy ERP system to a new one, or when you need to combine data from several ERP or eCommerce applications. Data migration helps manage large amounts of data and process many data records typically in batches.
ERP eCommerce data broadcast
This pattern helps transfer data from a single source system (for example, your ERP) to several destination systems in real- or near real time. Broadcasting data is transactional and designed to process data records as soon as possible, which ensures that data is kept up-to-date across multiple business software solutions.
This pattern can address probably the most common time-sensitive integration use cases such as triggering order shipment, stock updates on the store’s frontend, or sales order update in your eCommerce platform once an order was marked as shipped in your ERP. Typically, data broadcast is triggered by a push notification from the source system or is scheduled, which makes the aspect of reliability of your solution for data integration (P2P vs middleware) even more important.
Data aggregation
This pattern does the opposite of data broadcast. In this case, data from multiple systems is automatically copied or moved into a single system, which reduces the concerns of data accuracy and timely synchronization.
Data aggregation might be useful when you want to pull and combine product data from several sources to create a single format or collect missing product information. In such a scenario ERP rarely acts as the destination system but rather one of the source systems, alongside your eCommerce platform, product information management (PIM) and product content management (PCM) solutions. Your destination could be your home-grown composite API that collects data from several systems and processes them into a single response, or a business analytics platform. The former strategy is, by the way, often used when there are mission-critical legacy business software solutions that need to be “modernized” to meet the requirements of a modern business.
Data collection, formatting and transformation as well as merging several datasets are all important considerations in such a scenario. Choosing the strategy that fits your specific ERP eCommerce integration is also key: Should your destination point rather listen for signals from other business software solutions and aggregate datasets in real time, or should this be triggered through a specific event?
Bi-directional sync
Bi-directional synchronization is most useful when different systems must perform different functions on the same dataset. In our concrete example with respect to ERP and eCommerce, customer information can be updated in at least two ways: a customer logs into his profile on your online store and updates his, e.g. shipping information themselves. Or your support service received a request from a customer to update this information and did this in your ERP platform. In both cases, ideally both systems need to have the up-to-date shipping address.
With the by-directional sync pattern, you will need to first understand how many systems need to exchange information both ways. If it’s just two, a simple point-to-point connection (not to confuse with point-to-point integration!) might be enough. With more systems at work, you might need to set up a more sophisticated routing mechanism such as a pub/sub or queue routing.
ERP eCommerce data correlation
The correlation pattern is similar to bi-directional synchronization in the way that they both help share datasets between two or more business applications, but with one major difference. If new records are present in one system but not in the other, the bi-directional sync will result in creation of new records. The correlation pattern, on the contrary, will try to identify the intersection points of two datasets and synchronize them only if they are already available in both systems.
This pattern is useful when you have two business applications that need to share only the datasets such as product items or customer data that are present in both of them. For example, your organization wants to launch joint marketing campaigns with your B2B partner, addressing the customers who bought both of your products. Obviously, you will be asked to synchronize these customer data for more accuracy but you don’t want to send ALL your customer contacts to your company’s B2B partner.
Identifying the next steps checklist
There are undoubtedly many more factors to consider when embarking on integration ERP with eCommerce. But for now, let’s recap the most important points of this already long article and maybe add just a few more to get you started.
1. Decide who is going to be in charge
This might seem straightforward but it’s worth mentioning nonetheless: You’ll need to make a decision whether you are in full charge of the entire integration project or your company goes for a third party. For example, many ERP and eCommerce vendors provide integrations, either native or through their own B2B partners, to most common business software applications. In theory, this sounds great: Such integrations are easy to kick off, the price is often quite moderate, and the endpoints maintenance might be handled by the respective provider.
What is often forgotten, though, is that two ERP installations are rarely the same because each installation usually requires at least some level of customization to meet the needs of a business organization with its specific demands and business workflows. This means also that such a unique ERP setup will most likely require an equally unique integration with your eCommerce platform and other business software solutions.
This is bad news for pre-built integrations because they address only the standard processes such as order flow from eCommerce to ERP, customer import from ERP to eCommerce, or stock import from a custom CSV file to eCommerce.
2. Choose your approach
If you decided to embark on this project without the help from a third-party, is it going to be P2P or a middleware approach? This depends on the size of your company and hence your IT resources, on the number of business software applications you need to connect with each other in addition to your ERP and eCommerce platform, and such things as potential need for scalability, flexibility, performance as well as real-time responsiveness.
3. Map out the applications ecosystem
It often starts with integration ERP with eCommerce but it rarely ends there. This is why it is imperative to create a clear picture of all the applications and systems that rely on the data stored in these two. How about automating customer relationship management? Or improving inventory management by connecting to your warehouse management system (WMS) should your company have one? And what about the supply chain management and integrating with your B2B partners – is this something that might become part of the agenda, too?
4. List all ERP eCommerce processes
Create a logical map of the workflows and business processes between your ERP and the eCommerce platform. Customer data updates, creation of new customers, inventory updates, new product creation – the list is long. Talk to your sales, marketing and accounting, show them the list and ask if there is anything else they’ll need.
Yes, this seems like a lot of work and it will be, but this way you can ensure that this ERP eCommerce integration brings the promised benefits to your company: better inventory visibility and inventory management, improved customer experience, smooth B2B partner collaboration, reduction of manual entry, costs savings, and more.
Want to see an example of ERP eCommerce integration with iPaaS? Check out this sample integration pair following the button below.
Shopify to Netsuite integration pair
Alternatively, we encourage you to contact us to discuss how elastic.io can help you with your ERP eCommerce integration.
