It is often questioned whether EDI has a future. It was created in the early 70s to simplify B2B communication and enable trading partners to quickly and securely exchange information with each other and reduce or completely eliminate paper-based communication and of course, technology has moved on in the years since. These days many commentators talk of EDI in historic terms and offer API technologies as the new way forward.
So what is the reality?
“…an interface that provides programmatic access to service functionality and data within an application or a database. It can be used as a building block for the development of new interactions with humans, other applications or smart devices. Companies use APIs to serve the needs of a digital transformation or an ecosystem, and start a platform business model.”
In simple terms this means that an API is a interface that allows two different systems (say, a buyer’s system and a supplier’s system) applications to talk to each other and exchange data without the need for either system to understand the complexities around what the data that is exchanged (or the message) will be used for, or how the other system will do what it then goes on to do. A good practical example of how an API works might be you, ordering a Thai takeaway meal for a party you are holding. You go online, you read the menu (the API) and place your order. The restaurant has no idea who is attending your party or indeed what you are celebrating. You equally have no idea necessarily where the restaurant is precisely, what specific ingredients they will use or who will cook it and how…and neither of you need to know. You place your order, you pay your money , the interface between you and the restaurant makes sure that they receive your order and the money, you receive your food , at your address, hopefully on time.
If you think about API’s in the context of connecting different, discrete business applications, they ideally act as reusable building blocks (which is why you will sometimes see them compared to the famous Danish toy Lego bricks) that allow developers to more quickly create links between applications; in fact it is the communications mechanism, or code, that will link the two apps together. Think of a price comparison website for, say, insurance quotes. The site could keep a series of spreadsheets with the costs of each of the insurance companies fees, but they would have to keep this spreadsheet updated continually, real-time…and would have to do it for every insurance company they covered. If, however, the comparison site develop and publish an API that can be used by any insurance company to allow each one to create a query handling capability, and similarly every insurance company involved develop and publishes their own API to enable a return quotation,(and presumably other API’s to handle contracts, sales and payments online) then business is accelerated, you can get a quote and buy the best deal, real-time (without knowing any of the ‘how it is done’) and new insurers, new services , new offers all can be added speedy and easily.
So where does that leave us today?
Contrary to many predictions, and in the face of what we have just said about API growth, EDI continues to thrive – in fact estimates suggest that the overall EDI market will grow at 12% CAGR 2022-2027 (EMR: Global Electronic Data Interchange (EDI) Market Outlook). Whilst EDI was supposed to standardize B2B communication, the reality turned out to be not quite so simple. In Europe, companies use EDIFACT, while in the USA and Asia, ANSI X12 is the most widely used standard. That said, EDI, as a general model, is well established, has been around for a long time and is based on solid standards.
This means, of course, that there are pro’s and con’s to using EDI: one person’s standardisation and therefore clear ease of use is another person’s inflexibility and strict external ‘control by the dominating players in a particular industry’.
In summary thepro’s of EDI can be said to be:
Well documented and standardised so ‘everyone knows the rules’, and these ‘rules’ are regularly tested so that new entrants can immediately begin operations knowing exactly what frameworks they need to work within and with the security of knowing that these will not change with any frequency.
Many years of thinking, planning and standardised use, including signing and encryption along with secure non-repudiation (ie no-one can change a document without it being clear and obvious that they have done so) have meant that EDI messaging is highly secure, accessible only by those with the right permissions and the integrity of the data contained is absolute.
Long established messaging protocols mean that if anything does go wrong there are clear and addressable workflow trails that allow rapid identification and resolution of issues.
This doesn’t mean that EDI doesn’t have its drawbacks in certain business environments and generally , the development of API’s has tried to address some of these limitations.
Simply by being faster and more flexible to develop, the deployment of API’s allows businesses to respond to new opportunities that are not catered for by common EDI standards far more rapidly, cheaply and independent of the over-arching ‘controls’ and timescales of large dominant players or industry bodies.
API’s are very well suited to developing integrations that allow more than just message sharing. They can facilitate the connection of databases and applications in a more agile and resource-lite manner, especially connections to mobile devices and applications.
With the evolution of new technologies and tools, API development has become easier, cheaper and the availability and cost of the specialist development staff you will need is generally much lower than trying to ‘develop’ new functionality within EDI ecosystems.
The emergence of these new, funky API technologies created a groundswell of opinion that EDI had had its day and that it would be completely replaced by APIs. However, respected analyst Gartner concluded that:
“APIs complement, rather than replace, traditional B2B technologies such as electronic data interchange and managed file transfer. Application leaders should use API capabilities to add new channels, enable automation and optimize their business ecosystem for digital business.”
“Use APIs to Modernize EDI for B2B Ecosystem Integration” Mark O’Neill and William McNeill, 11/06/2019
Why does this debate matter and what part should it play in your planning process?
Neither EDI nor APIs offer a perfect solution to all situations but they do provide significant benefits to users. We have discussed some of the limitations of EDI and the benefits of APIs above so it is only right that we offer the mirror view and summarise the benefits of EDI and some of the downsides of APIs as well.
EDI offers many advantages over APIs but carries some downsides
The disadvantage of the long-established EDI formats are that they can be complex to work with and if you do need to make adaptations then finding specialists with the skills and experience can be challenging and expensive
If you have set up to use what is ‘on offer’ but then find you need to add complementary services you may find that you are ill-equipped to deal with the challenge
As new opportunities arise and you want to move quickly, and with a focus on mobile compute platforms you will struggle to adapt an EDI platform quickly
APIs on the other hand whilst often being quicker and cheaper ways of adding functionality have their own drawbacks
They do carry a level of technological complexity that requires investment in skilled staff
Security risks can be reduced if you develop point-to-point connections but this can be time-consuming and costly
You will be responsible for the creation of your own audit trail capability, to both protect against data integrity breaches and to ensure that you can trace back to where issues arose or changes that were made
Whilst API development moves on at pace it remains the case that there is no over-arching body that sets standards, tests compliance or underwrites interconnectivity
This is the design philosophy that is informing the direction of Omnizon’s platform development. API and EDI are complementary and can be deployed in tandem to great success using the solution developed by Omnizon. Disadvantages associated with EDI technology can arise with the vast majority of solutions, but by using our Omnizon’s iPaaS EDI platform, the user has the tools in their hands to easily overcome these issues with the possibility of transforming document types and data fields with quick implementation whilst retaining the opportunity to use APIs for certain integrations when it proves to be a simpler, faster and cheaper solution, especially in terms of connections with some of the standard applications, such as common ERP systems or mobile applications.
At Omnizon, we understand the scope of our abilities and we plan carefully and with discipline to ensure that we never over-extend our capacities. We don’t try to be a universal API connectivity platform but instead we focus on particular market sectors and user segments. An example of this is our focus on Odoo modules. If you are an Odoo user then in all probability you will be operating in the SMB sector. If so, you will have critical investment decisions to make as to which skills you can afford to invest in and what areas of operation represent core business activity for you. By developing Odoo-specific connectivity Omnizon is able to offer you a tailored solution that recognises your focus of needs and delivers significant ‘fast track’ business benefits whilst allowing you to concentrate on running your business operations knowing that your interconnectivity needs have been well-catered for.
Omnizon Odoo modules
To give you a clearer picture of the kind of things we focus on, let’s take a closer look at what we have done in the Odoo space. Omnizon has developed a couple of Odoo modules that enable simple integration of the Odoo ERP system with Omnizon’s iPaaS EDI platform.
Firstly we have what we call a Base Module that gives the possibility to enter GLNs for the company and delivery points and GTINs for the products. This provides a solid foundation upon which to develop full functionality. The second module is designed for users who play the role of buyer in the business process, whilst the third module has been developed for those in the role of supplier.
In most cases, if you use Omnizon’s iPaaS EDI Platform, you will need both Odoo modules.
With these Odoo modules, you have the possibility to integrate your Odoo ERP system with partners using Odoo or other ERP systems and also partners who are non-digital players and who are still using emails or other messaging to communicate in just a few clicks. For partners where the connection is ERP to ERP integration is achieved using the Enterprise EDI option. For those not using any ERP system or where there are some other business or technical reasons, then integration is achieved through use of the Supplier or Customer Portals, which themselves are integral modules of the Omnizon iPaaS EDI platform.
Because of both the comprehensive capability of the Omnizon iPaaS platform combined with the Odoo modules, you are in a position to meet the challenges of B2B integration related to the entire procurement and sales process, quickly and simply without having non-digitised suppliers or customers potentially ‘excluded’ from your digital eco-system.
The simplicity of implementation and the completeness of integration that Omnizon Odoo modules brings, increases your competitive advantage and delivers all the benefits of digitizing your business processes in a quick and simple way.
We see development of these kinds of modules as a practical demonstration of our vision that digital transformation should be accessible to everyone and should neither be complex nor time-consuming and is a proof-point for the development path we are committed to following.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics and Hubspot to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!