API and EDI: Finding the best from both Worlds

What are APIs?

We have discussed EDI , what it is and how it works in previous blogs.But what are APIs?Gartner’s Technical Glossary describes an API as“…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 APIs 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 APIs 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.  The origins of the API can be found in work done around 2000 by researchers trying to develop new ways of allowing greater collaboration between apps across the web that ate less bandwidth and therefore involved less code. Over time,  the development of JavaScript Object Notation (JSON)  opened up the opportunity to develop this work and create applications that offered excellent browser connectivity to low-density applications. This progress was  further enhanced as new programming languages like Python, Ruby, PHP and of course Java enabled new programming to be quicker (because they were developer-friendly) more flexible (because they were highly scalable) and cheaper (because of the reasons mentioned and the fact that they were platform-independent.) As the IT industry got on board with the concept of API development, and data gathering giants like Google,  Facebook ..and all the others you can think of… led the way, the use of APIs exploded. Now all of the common social media, content consumption, online services, data & content sharing and even government services delivery platforms rely on APIs. The explosion of ‘mobile’ computing has been a huge accelerator and there is every reason to expect that the evolution of IoT and the massive growth in interconnectivity that this will bring will drive the next step-change in API evolution and use. In short, they are everywhere ..and are here to stay.

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 the pro’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 APIs has tried to address some of these limitations.These include:Simply by being faster and more flexible to develop, the deployment of APIs 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.APIs 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 downsidesThe 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 quicklyAPIs on the other hand whilst often being quicker and cheaper ways of adding functionality have their own drawbacksThey 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

So how can you get the best from both worlds?

In order to be able to work with both  technologies, an integration solution based on an integration platform is needed. This enables the sharing and use of data between EDI and API and getting the most out of B2B or/and A2A integration and the data being exchanged. It can also be beneficial to have the opportunity to discuss your business processes with experts in EDI , who can identify where you can ‘fast track’ to adopt existing formats and protocols for the quickest and easiest implementation and equally recommend the areas where APIs may offer a better option.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.Omnizom will continue to address the needs of users in key SMB sectors, so stay tuned for further updates as we bring new modules to market.