I have seen great evolution in programming languages and productivity in last 10 years. I started with assembly language. I cannot imagine writing present day complex applications using such languages. However, when it comes to EDI processing, we still do the complex mapping and talk segments and elements. There must be a better way to handle/process EDI documents.
WE WANT TO CHANGE THE WAY WE PROCESS EDI DOCUEMNTS. WE WANT TO BE THE CATALYSTS FOR THIS CHANGE!
MAPPING – WHY WHY WHY?
The following picture summarizes everything I want to say in this post.
(Image taken from the book:BizTalk 2010 EDI for Health Care)
I still remember my shift from C/Assembly language to C++. I was very excited with all the good and powerful things OOP/OOD brought to the table. It helped to model complex software better and increasing the productivity by multiple folds.
I have been working with EDI documents for quite sometime now. Most of the EDI processing solutions still talk in terms segments, loops, separators etc.. IMO, there is a big scope for taking this concept to the next level (just like we moved from ASSEMBLY->C++). Once this happens, productivity will shoot up.
Our new solution will attempt to bring the same level of power and productivity as that of OOP brought to the software world. When an application developer working on a EDI, for example purchase order (850), he/she should not in terms of segments/loops, instead talk about business terms such as Product.Color (this product’s color), Product.Weight (weight of the product) etc. This brings more meaning to the business process (and that’s how it SHOULD be).
We are looking for all sorts of channels to market this idea/product. If you think you can make a difference, let me know and contact me at email@example.com
BTW, in addition to bringing new way of looking at EDI documents, our EDI processing platform is designed for scale (bring it on!), fault tolerance, friendly operations.