As businesses look at the API Economy, the discussion covers a variety of
business drivers and use case types. While most initial API projects are targeted at internal audiences the strategy often expands to include a partner ecosystem that can drive tremendous additional value and revenue. But, there are already many partner integration models that have been implemented including EDI, files, and more. Are Business APIs going to replace these prior mechanisms? Should they? The short answer is – sometimes yes and sometimes no.
I addressed a related topic about two years ago in a blog titled, “
I Already Have Partners Accessing My Services. Why Should I Use APIs?”. I’m still satisfied with this, so do not intend to repeat too much here. Please look at this first if you need a refresh.
As businesses create partnerships there is a need to exchange data or invoke transactions to communicate between the partner companies. For example, a retail store may need to reorder inventory from a product manufacturer. Distinct B2B interactions have different requirements. Here are a few examples:
- Reordering inventory does not need to be done every time an individual item is sold, assuming there are more items still in stock. However, an out of stock situation may not want to wait for another weekly cycle to replenish the supply.
- Checking on the delivery date for a specific item to promise delivery to a customer needs immediate response.
- Providing an invoice may need an immediate acknowledgment of a receipt of the transaction with further activity to follow.
What is EDI?
From
EDI Basics, “Electronic Data Interchange (EDI) is the computer-to-computer exchange of business documents in a standard electronic format between business partners.”
While the business documents exchanged in EDI have a standard electronic format, there is more work involved than each partner implementing the standard. First, there are multiple standards - ANSI ASC X12, UN/EDIFACT, and Tradacoms to name a few, and then there are versions for each standard. In addition, while the standards define the format of the fields, they do not necessarily define the meaning of the data that is in each field. Typically, there is a translation done to create an EDI document and to read it on the other side of the transmission to map/transform the fields appropriately into each company’s business systems. So, as businesses become partners, there is significant set up work to on board a partner using EDI.
Traditionally EDI has been used between companies that do quite a bit of business together. The investment in setting up an EDI communication is non-trivial and not easily justified without many transactions. Also, historically EDI has been primarily “batch” oriented. The typical EDI document contains many records, perhaps weekly invoices with many line items and detail, an order for replenishment of stock with many products, etc. This tends to lead to very large files. While it is possible to do EDI asynchronous request/response transactions for individual items, many companies with a long history of using EDI still choose to batch transactions into a single EDI transaction.
This is far from a complete definition of EDI, but enough to do the positioning with APIs.
Contrasting EDI and APIs
It is possible to do similar types of transactions with APIs – send an invoice, order stock replenishment, etc. However, APIs are typically synchronous (request/response) and have small payloads. Setup to use an API is focused on simplicity. The API exposes a simple to consume transaction (if done well) focused on what the API consumer needs to provide to execute the transaction. The technology, typically
REST, is a well understood architectural style that is very familiar and easy to use by programmers. API industry standards for B2B transactions are starting to form in some industries (see my
blog). However, this is not universal. So, like EDI there is some mapping done to the consuming business systems. However, because APIs are typically fine grained for a specific purpose, the number of parameters involved may be far less than EDI which is more general purpose.
So, Will APIs replace EDI?I said in the opening paragraph that the answer is sometimes yes and sometimes no. Let’s look at a few scenarios to see when it makes sense and when it does not.
- Businesses are major trading partners that have already implemented EDI“If it isn’t broken, don’t fix it”. If you already have an EDI implementation and it is working for you, why change it? Today APIs are not well suited to asynchronous transactions or bulk data. This may change over time and perhaps the recommendation may be reconsidered. However, do consider subsidizing the current EDI implementation with APIs for additional real-time interactions. If for some reason EDI costs became excessive then replacing with an alternate approach (i.e. APIs) might be considered.
- Businesses are not major trading partners (or maybe not even partners yet) and there is no existing EDI implementation between the parties. This scenario includes trying to reach new markets perhaps via on-boarding new partners and partnerships where there are not many transactions.More frequently businesses are moving to real-time synchronous transaction models. APIs are a better fit for this scenario. The setup time and costs are far less. Also, this allows for smaller partners in larger quantities.
IBM has products that support both API Management and EDI and many businesses currently using EDI are probably considering adding APIs to their B2B tool kit. The same DataPower gateway (with the B2B module) can act as the gateway for both APIs and EDI.
Partnering and
reaching new markets or new customers are some of the most common use case categories and business drivers for API initiatives. It is natural to question whether APIs are a replacement for prior techniques to implement these scenarios. In most cases APIs are additions to the capabilities you are already using with existing partners to provide new capability and on board new partners.
To understand more about IBM’s thoughts on the API Economy visit the IBM
API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the
API Connect website. And you can also experience a
trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter
@Arglick to continue the disc