From the moment when we stop managing our jewelry store on paper and start using a system, the question of integrating it with third-party systems becomes unavoidable in order to move data back and forth between those systems and ours.
There are many examples for what platforms your jewelry store or manufacturing management system might need: Rapnet, GIA, QuickBooks, pulling market prices for metals, exchange rates for currency, communicating with your shipping providers, customer relationship management system, your website or other websites like Shopify or Etsy, or different payment gateway integrations.
Why are these integrations necessary?
First of all, this can help automate many of your manual processes; and second, because having all your data and information centralized will provide a huge advantage. Since all the information will be stored and managed in one single system you won’t have to deal with copying and transferring data repeatedly from one system to the next.
Just think about shipping labels being generated and the orders being inserted into the system automatically, and you will see how an integration like that can help so that you never have to do it manually again.
So the question is not even whether integrating with other systems is useful, but how these integrations are actually done.
Integrations can be done fundamentally by three methods:
1. Direct integration
2. EDI integration
3. API integration
1. Direct integration
Direct integration is when you get the two systems to talk to each other by mixing their code – basically, an application will communicate with another application like if it’s part of the same program, on the code level. This can be actual application code or database code, but the result is the same - data flows seamlessly and quickly, in real time, from one application to another.
Direct integration is usually very time-consuming to implement as you need to have a deep, code-level understanding of both systems, and know exactly how to format the data – also you need to make sure that all your data is transferred without errors, or write extensive error-checking and validation rules. So because of this, direct integrations are rare and are only done when there is no other option, such as EDI or API.
2. EDI (Electronic Data Interchange)
EDI is a communication technology used to transmit data from one system to another. EDI was born in the 1940s and refined in the 1970s. While most technologies have become significantly more sophisticated over the past 45 years, EDI has not been modernized as the Internet’s capabilities have grown. While it might seem like the must-have communication tool in the jewelry industry, especially if you work with older retail systems, but newer and more innovative options like APIs (Application Program Interfaces) are quickly replacing it as they are quicker and provide more flexibility.
As such, communication through EDI these days is considered slow, one-way communication – comparing EDI to APIs is like comparing dial-up internet to cable.
The basic way how EDI works is that the data is stored in a certain format depending on the information that is to be transferred, such as a purchase order or an invoice, then forwarded without confirmation, much like a fax machine. The storage delay can slow down the process and the data transfer gaps can result in decision-making based on information that may have changed already. Also, because the data is not real time, proactive decisions cannot be made using information that may be outdated.
Now, the fact that EDI is still being used can be explained with the high costs that come with switching to a new system. For example, larger retail chains still use EDI because their supply chain is mainly based on this technology.
However, in my opinion, switching over to using API is only a matter of time for them too – the costs of not having up-to-date information and tight integrations with suppliers is becoming more and more pressing for them too.
3. API (Application program interface)
The increased use of APIs is a step towards modernization – in fact, Forbes once called it the “digital glue” as it links together systems in a neat, tight way.
Whether you know it or not, you interact with APIs on the Web on a daily basis. Essentially, APIs are what make it possible to move data between programs quickly and in real-time. Have you ever wondered how you can use your Facebook ID to log in to websites you’ve never been to before? Yes, you can thank that to the Facebook API.
Should I use EDI or API?
So since direct integration is less common due to the inflexibility of the integration and the time-consuming development, the question remains: should we use EDI or API as our integration and connection method?
Naturally, we would say API, considering that it’s the technology of the future, but at this point, it is worth noting that EDI technology is still being used quite often due to its popularity and the need for integrating with older, large-scale systems.
The newer the system, the more likely it is that it has an API that we can work with, but replacing EDI-based systems will not happen for another few years to come, to say the least. There is an estimation that 90% of the global supply chain still relies on legacy EDI models, at least in part of their operations.
So once you decided to integrate with another system, what difficulties will you be facing during integration? Some of the issues are for example:
1. Who will do the integration work? If there is no API method already developed, then will the vendor develop one? If not, do they at least have EDI ready to go? If that is not an option either, is it worth to do a direct integration?
2. Every integration project is different – for example, a webpage integration cannot be standardized because usually, every jewelry company will have different styles and components and different ways for defining their components and their attributes. Because of this, it is impossible to avoid having some custom programming during integration to be able to get this data in a way that both systems understand, sort of creating a common “data” denominator. So in most cases, there is no integration solution that works at the push of a button – some programming is still required.
3. Third-party providers can decide to change their APIs at any time – if this happens, the communication may break between the integrated systems and part or all of the integration may need to be redone again.
4. Poor data quality from legacy systems – data hasn’t been completely filled in or has been entered incorrectly; also, with users changing throughout the years, every generation of users may have entered different data that needs to be cleaned first before an integration
5. Two systems don’t always match in structure. For example, one system may have an e-mail field for employees, while the other does not. As you can guess, this sometimes requires entering the data manually into the other system to make sure that all the necessary data is in sync between the two systems.
6. Integration that connects both EDI and API – sometimes it is necessary to use both EDI and API to interface between systems – you may use bridge software – also called a middleware – that reads and writes EDI but supplies API functionality to other systems – this is usually done when one older system has to be connected to several newer systems, and the old system only “talks” EDI but all the new systems only “talk” via API. This can save time and money on the integration as you only have to integrate with the EDI platform once, and not individually for every new system – you can use API for those, as well as for any other, future system to be integrated later.
Another important thing to consider is that transferring files from one system to another using CSV files or Excel spreadsheets is also sometimes considered integration. Now, some vendors offer these options for “interchanging” data between systems, but they don’t make it clear to their clients that their solution is not automation and certainly not real-time integration like an API-based solution. So when it comes to integration, you really need to understand what integration options are available and use API based integrations whenever possible.