Mike Dietzen at the Brady Corporation started a discussion on LinkedIn regarding a new way to think about EDI. In the comment thread it moved in to a discussion of Canonical EDI, a concept that is near and dear to my heart.
Can we as professionals agree to a new way of doing EDI?
I would like to shift the thinking of how EDI maps are designed. If the receiving systems set the mapping specifications, then trading partners can ensure the documents load efficiently. This requires a change from the customer driven mapping specification of today. Though most maps can be grouped, wouldn’t it be nice to only have custom maps for outbound documents? This new method would allow companies to focus on one direction. Thanks
Mike Dietzen
EDI Specialist
Brady Corporation
EDI such as X12 was designed as a something-for-everyone-complex-instruction-set. The standard is quite huge and allows for nearly every possible permutation. As such, each Hub who sets out to use EDI creates an Implementation Guide: a subset of the standard. Each hub has one, and every one of them is different.
This leaves a huge burden on the trading partners to create a different map for every single hub they do business with. The irony is that the lowly hub needs much more complex mapping and translation software than the 800lb hub. Go figure.
To me, this is the single biggest obstacle to universal adoption of EDI for business to business documents. Since 1999 I have said that EDI will become ubiquitous when all hubs are spokes and all spokes are hubs.
The next generation of EDI hubs don’t have 10,000 or 40,000 trading partners, they have 500-1500 trading partners. And many of their trading partners are often bigger than them. There is no way they can dictate a proprietary implementation guide on their trading partners.
However, if there were a set of simple, standard and universally accepted implementation guides that they could adopt then they would not have to reinvent the wheel. These “mini-Hubs” could simply use a wheel that already fit on the car and ran on the same type of road. EDI Service Providers could easily ramp up new hubs in addition to all the spokes they have enabled.
How ECGridOS Approaches Canonical EDI
Think of it as a 99% solution like QuickBooks. CIGs will satisfy most of the normal business needs for 99% of the companies who currently do not use EDI. For them it wouldn’t be getting their customers to agree to canonical, it would be adopting them so that their EDI is plug in play with anyone who already has a mapping/translation in in place for the CIGs.
I’ve been working with Craig Dunham on a CIG for the 810 invoice; something simple and generic that most companies could easily adopt. Next we will work on and 850 and an 856. My goal is to create an “open source” type community to create simple CIGs.
With ECGridOS we plan to take the process one step further. As a web services API, ECGridOS depends heavily on class objects to send and receive data. In their SOAP format they are all XML. What we are doing with the X12 CIGs we are developing is to create a one-to-one relationship in our system with a class object.
For example the INVOICE Class Object would map directly into the CIG 810. The system itself would take care of all validations, mapping, etc. A developer would only need to read/write to the class object, and all the X12 would be taken care of behind the scenes.
The benefit of the X12 on the backend is that it would be 100% compatible with every VAN and every legacy EDI mapping/translation package in use.
The benefit of Web Services is that it has a one-to-one XML representation for those working at that level of abstraction.
The benefit of SOAP is that users of SDKs such as Visual Studio would be able to work with the data in a native class object model.
Canonical Implementation Guides (CIGs) are the future of EDI and what is necessary to move us from a stagnant market of about 300 major hubs to dynamic one of 10,000+ new mini-Hubs.
Todd Gould
President
Loren Data Corp.
