Having worked as a tech lead for more than 6 years in a project, involving automation of supply-chain complexities, I would like to share my tryst with EDI files. Enterprises have long relied on EDI (Electronic Data Exchange) for automating transactions and as a medium to improve productivity by automating intense manual processes and minimizing associated overheads.
With the emergence of XML, enterprises are increasingly contemplating the viability of XML as an alternative to EDI that offers many- to-many connectivity and its transactional capabilities. Before arriving at a conclusion as to which is the best medium, let us make the field even for both EDI and XML. General guidelines one should follow while contemplating EDI or XML platform or any other platforms for that matter are: ROI on Investment? Whether to leverage existing set up or start building a new one right from scratch? Performance criteria? Does it subscribe to pay as you go model? Security, reliability and scalability and Feature extendibility concerns ? End user adoption?… and so and so forth.
These guidelines can help us make an even comparison between XML and EDI and which of the two makes a compelling force to adopt.
EDI – A Protocol while XML is a Data Format
Let us begin. Though an oft-debated comparison, when it comes to communication between two systems, EDI and XML are two separate concepts. XML is a data format, not a protocol or an application, on the other hand EDI is. Though both are used to parse documents without manual intervention, it is important to understand their importance in respective context.
An EDI files or document transmission can take any one route among Serial Communications, Internet, Peer-to-peer, Value Added Networks (VAN) and gets translated via FTP or AS2 protocol. What this means is EDI renders solid security due to its stringent protocol something, which makes XML less so. further, there are lots of tried, tested and proven off the shelves EDI tools in the market that eases the hazzles of developing an application right from scratch which is most likely the case with XML.
On the flip-side, XML is gaining grounds due to proliferation of e-commerce sites and portals, which requires many-to-one transactional capabilities. XML makes more sense for small and mid-size companies that does not have to follow a standard format and whose transactional needs are less intense. On the other hand as EDI is best suited for one-to-one, point-to-point connectivity, it is a viable option for two big companies with millions of transactions happening per day between them, through a standardized protocol. Since, the volume of data managed will be high; investing in value added networks (VAN) is worth the buck spent.
Finding EDI experts
It can be downright frustrating if you have to build an EDI set up at ground level if you do not have the expertise and business domain knowledge. Unlike, XML, which is in a way human readable, EDI is complex and is meant for two systems to communicate. I can tell from my experience in a project spanning 6 years, EDI programming can appear complex and daunting to a novice and can results companies spending in millions and getting nowhere. In addition, there are several industry levels EDI standards that need to be adhered that requires a lot of expertise. As an experienced EDI programmer, I have to pay extra attention to the tiniest details while developing translation maps between two systems. in the next Blog post I will share some real-life examples of complexities involved in EDI processing.