Peeling The EDI Onion: Part 1

ESG is called by many an ‘EDI Company’.  This name misses our significant presence in the Retail Energy Billing and Wholesale marketplaces.   But for certain, we know energy EDI (Electronic Data Interchange).   More accurately, we know how to integrate systems from multiple companies and shops.  Among other skills, we have mastered EDI, both traditional and state-of-the-art, to serve this purpose.

For ESG, the EDI onion has many layers:  formatting, transaction structure, electronic exchange/transport, and best practices.   This series will explore these in detail.

Formatting

What people think most when they hear EDI is the formatting developed in the 1970’s to enable computer systems to exchange information with other computer systems.  We can all be honest:  it is a cryptic language that has fed many children of the people who have mastered that language.  We can also be honest and admit that that cryptic language is still used today to exchange BILLIONS of transactions daily.  It is compact and, once programmed, runs forever.

XML, now over ten years old, offers a strong alternative to traditional EDI formatting (key point:  XML is a formatting language only, just one layer of the EDI onion).  XML’s primary advantage is its human-readability.  A human can pick up an XML transaction and actually understand what data is in the document (the structure), where traditional EDI uses structural conventions stored outside of the transaction itself, normally in Word Implementation Guideline documents.  XML takes this a step further offering XML Schema documents, which provide the structure of the document in a format that both a human and a computer can read.

Structure

The non-XML EDI world wrestled with the structural side of electronic information exchange decades ago, the ANSI X12 standard representing one of the fruit.  X12 transaction standards set the high-level structure of an EDI document.  While not perfect, it does bring parties closer together when deciding to exchange electronic transactions.

In this respect, the XML world is a newb, the retail energy XML world even newbier.  There is no foundation of existing XML EDI (versus X12 EDI) transaction standards that a company can rely on having broad market support.  X12 has an XML initiative that attempts to morph their transaction standards into ‘XML-Ready’, but this has not been widely adopted.  Ontario has XML standards that at one time promised to be an industry standard, and ERCOT deployed retail energy XML transaction standards in 2001 that are barely used today.  Recently the Maryland gas energy marketplace developed XML transaction structural standards for their marketplace and essentially started from scratch.

Perhaps the greatest hope at this time for Retail Energy XML standards is the North American Energy Standards Board [NAESB].  This organization forged many standards in the Gas industry, and is the de facto keeper of retail energy standards at this time.  Their current body of work uses X12 EDI, but they have always correctly preached that formatting is separate from structure:  it would not take much to transform their structural transaction standards to XML EDI.  NAESB faces greater challenges in that hope, but that is a topic outside of the scope of this post.

There are other structural issues to consider.  XML brings the possibility of  using Web Services Description Language [WSDL] and Simple Object Access Protocol [SOAP].  These cross over into transport issues which we will cover in Part 2 of the series.  WSDL and SOAP still require parties to observe structural standards.  Without a body setting those structural standards, it becomes a free-for-all.

ESG helps energy companies master the free-for-all.  Our CTG framework normalizes every existing marketplace, including every existing transaction format and structure, into a single specification that can be easily deployed.   A company does not need to be worried about XML Schema’s, X12 asterisks, etc. because ESG presents the data in a common format.

Stay tuned for part 2 where we discuss transport and best-practices!

[Read "Peeling the EDI Onion:  Part 2"]

Leave a Reply