EDI is System to System not B2B

October 27 2016

2 comments 0
b2b edi

90% of everything is moved around the world in containers across countries and continents. The containerization of cargo is a highly efficient and open standard of transport. It’s efficient because the same physical container can be easily handled by a super sophisticated automated terminal in Rotterdam as well as the more basic terminals across Africa and Asia. It’s a simple structure that can easily flow through and between businesses and it’s easy to work with agnostically.

However, the data that often accompanies these containers are crippled by manual protocols and difficult to adapt (or adopt) archaic structures. Most container terminals and their business partners use EDIFACT or ANSI standards. This is an interindustry standard of Electronic Data Interchange (), but as a standard, it’s pretty cumbersome to deal with.

EDI Message Structure

Understanding should be ambiguous

To give you an idea of what these messages look like take a look at the following EDIFACT message:

  • Try and understand what the EDI message is for
  • Then look through and determine what are the key pieces of information
  • What percentage of the information did you understand?
  • How long did it take you to read through it and answer the above questions?

UNA:+.? ‘

UNB+IATB:1+6XPPC+LHPPC+940101:0950+1′

UNH+1+PAORES:93:1:IA’

MSG+1:45′

IFT+3+XYZCOMPANY AVAILABILITY’

ERC+A7V:1:AMD’

IFT+3+NO MORE FLIGHTS’

ODI’

TVL+240493:1000::1220+FRA+JFK+DL+400+C’

PDI++C:3+Y::3+F::1′

APD+74C:0:::6++++++6X’

TVL+240493:1740::2030+JFK+MIA+DL+081+C’

PDI++C:4′

APD+EM2:0:1630::6+++++++DA’

UNT+13+1′

UNZ+1+1′


Many people would understand that this is a message related to flight bookings; it’s actually the EDI and integration between an OTA (Online Travel Agent) and a flight booking system. You may be able to decipher some of the airport acronyms. However, like me most will answer that they understood at most 20% of the message and if you tried hard it probably took around 5-6 mins and a lot of head scratching. Theses edi-based interactions are common, and many are significantly larger and more complicated.

Can you imagine now building a modern day iPhone or Android app and asking a whiz kid developer to deal with messages like the above? The likelihood would be that:

  1. You end up having to supplement your UX developer with an EDI expert
  2. You then supplement your two developers with a domain expert on flight bookings
  3. You end up with three times the cost and delivering your project two times slower.

Imagine you now need to change some of the underlying systems and the messages. Who would you need to be involved to make sure the change does not impact the end UI your customers see? How quickly could you make that change?

I imagine at this point – you’re thinking “I really wish I didn’t have to deal with EDI” and you’re not alone. Many modern day systems end up using parsers to get the data in a more human readable format before processing them, but when working with multiple systems, you may just end up with the same mess you were trying to avoid – a single format for exchanging information.

Transmission

Communication should be transparent

Unfortunately, things now get worse.  The UI developer likely has to deal with much more than the message and its structure but also how to deal with the way these messages are passed around. In a shipping terminal the likelihood is that you may get this data from various channels:

  • Flat file from an FTP server that needs to be batch processed
  • An attachment to an email that needs cleaning up
  • Maybe the odd Webservice
  • In an advance terminal maybe JMS

All of these different methods creates a burden on your developer to consume EDI transactions. They have to invest time in doing more point-to-point integrations to fetch/receive EDI messages and also send/respond to messages. This continues to slow down your UI developer’s goal – which is to create a new user-friendly app on the latest smartphones.

Once again you may “fast track” this by adding another expert to deal with the communication protocol, but this adds cost, time and complexity; once again creating technical debt that if one of the underlying systems change you are hindered to adapt quickly.

How do developers traditionally deal with the issue?

Agnostically working with data

The reason why your UI developer has issues is that their sphere of influence is their app; building in all the components to deal with different message types and transmission protocols is typically done within their application. They will likely need to master this,  which, although it may speed up the next project,  also means they may continue to build upon this constrained and fragile model creating more point-to-point solutions. Relying solely on an EDI between applications perpetuates technical dept by incorporating the processing and transmission logic within an application.

The unintended consequences of EDI

Silos of data

Great value can be found in analyzing and harvesting data for traditional businesses in the transport & logistics, manufacturing and healthcare industries; exposing these digital assets can greatly improve their revenue and costs:

  • Providing visibility as a value added service to customers
  • Sharing information to support other links in the supply chain for just in time (JIT) manufacturing
  • Predictive analytics supporting better process optimization

Will industries change?

Absolutely, and it’s already started! More modern day systems already use various types of parsers to convert data back into a more usable formats such as XML. Larger EDI community systems have already begun discussions with partners on leveraging a better data transmission format based on XML. Destin8 (MCP PLC), a UK-based port community system already offers XML-based formats for several types of messages and this trend will likely continue as their customers modernize systems often built on much more modern technologies.

Where EDI excels

EDI is here to stay, and after decades of use across many different industries, it is well established as the defacto standard for communicating between systems and therefore B2B communication

EDI provides a common structure and language to communicate with common standards. Although these standards are often interpreted differently, the overall structure remains the same. EDI is very effective at being a dense medium to transmit information due to its highly abbreviated formats.

Therefore EDI is something that we need to work with, but working with it in a smart way and ensuring that it does not hinder future innovation is key.

The best of both worlds

Legacy modernization

For those with legacy systems, adding a wrapper to modernize their interactions with other systems is far more cost effective (and efficient) than re-implementing mission critical systems. This enables developers to quickly consume data without having to understand EDI; this also unlocks data to look then how to innovate with it to provide value-added services and visibility to their customers, or using the data to optimize their business processes.

API-led connectivity

The alternative (or next step) is to have connectivity at the heart of the business and IT landscape, ensuring that the application network is structured in a way that:

  • Data is easy to access and discoverable
  • Information can be easily aggregated from multiple systems
  • Developers are insulated from back end systems allowing them to focus on innovation
  • Legacy systems can be replaced in a controlled way
  • New systems can be added to the Application landscape without the need for deep experts in back-end systems
  • In essence creating a composable layer of APIs that are agile to the business’ needs

Take a look how some businesses are adopting an API-led approach to connectivity and innovating on top of EDI, improving their business agility and creating new and valuable experiences for their customers and stakeholders.



We'd love to hear your opinion on this post

2 Responses to “EDI is System to System not B2B”

  1. Interesting article Sanket,
    An important point to remember is that whoever as part of an organisation using traditional EDI there are two main types of connection; suppliers and buyers. When it comes to buyers the customer is king you just have to accept whatever standard they give you lest you upset them. So EDI is certainly here to stay in that respect. Also many suppliers simply don’t have the resources to change their messaging, its very very pain full.
    As an EDI consultant one of the most successful strategies I have seen is to transform the EDIFACT or whatever to and from an intermediate XML form so if you have 50 customers orders you will undoubtedly have 50 variants but at the end of the day one universal message to work from as you expand from the old style P2P to other value added services.

    Agree(1)Disagree(0)Comment
    • Thanks Paul. EDI has become the a standard ‘language’ and I agree that based on the nature of the organisation who typically use EDI standards and the industries that they were initially designed for, EDI is here to stay. However, many of these industries are being disrupted by competition or are diversifying their customer base and offerings. This has led them to (as you said) use a new ‘intermediate’ language which helps them to hide the complexities of EDI and extract information to then place in to other systems for the purposes of BI, Self Services, Reporting, Mobile etc. Some are taking it one step further and allowing multiple paths to communicate; including EDI but also web service based APIs.

      I’ve come from a background transforming Port Logistics and many of my customers have focused their efforts on unlocking the information out of EDI (and backend systems). They’ve harnessed this elsewhere, to drive other business interactions. The key integration challenges they face are:

      1) How do they encapsulate EDI complexity
      2) Enable a larger development community to innovate
      3) Govern and secure the data (without hindering #2)
      4) Unlock the capabilities of the data by making it discoverable and self service (breaking silos)

      I’ve certainly seen EDI consultants (like yourself) helping their customers with the above integration challenges. Those customers who succeed in releasing the potential of their data and systems, are often the most successful in driving businesses interactions and innovations. The business looks for a language that is more business centric and in the meantime having an integration layer that enables that is important – EDI plays a role in transmitting data, the integration layer plays the role of unlocking the information.

      Agree(1)Disagree(0)Comment