EDI is System to System not B2B

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 EDI standards. This is an interindustry standard of Electronic Data Interchange (EDI), 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?

Many people would understand that this is a message related to flight bookings; it’s actually the EDI and B2B 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 B2B 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.