It's the data that matters, not how it looks

This blog could also be entitled the triumph of substance over style.

We had a new customer sign with us last week, not in itself unusual, but that fact that we were replacing an alternative solution, and at the same time becoming the partner of choice for another software house is worth mentioning. At a more technical level it gave me an insight in to the limitations of some of the older methods for EDI integration.

The client concerned required a particularly rapid turn around of one specific trading relationship and asked if we could move faster than our standard Service Level Agreement (SLA). We had a quick look at the data, the format required by the recipient and the how the missing data could be deduced. We then said yes.

However, the reason for the rush was that this particular Trading Partner (a customer of our customer) had been waiting for over six months. The reason was that whilst the previous EDI vendor had claimed that their tool was flexible and did not need rigid formats. The truth was more like "we have several different formats that we can use, but outside of these formats we will struggle or it will be a an expensive consultancy exercise".

I have a problem with this approach. I do see the benefit of standard data formats being developed, in fact I really admire the business analysis that has gone in to the development of standards such as UN EDIFACT. However these standards are rarely rigidly adhered to and that is both the problem and the beauty. Different businesses have different data requirements, sometimes based around restrictions in the ERP system, sometimes around the business process. Therefore, your EDI solutions must have the flexibility to change as the business requirements or you or your partner changes, this may involve merging data from various sources, using a message intended for one purpose to provide the data for a different message, splitting or concatenating data to provide different data and the use of look-up tables or catalogues. Sometimes we are even asked to use one message between trading partners to add data to another message between the same partners. Obviously, because our service is Software as a Service (SaaS), the idea of such data merging is easier than for software deployed at the end user site, especially when like us you can be using industry catalogues that are shared amongst many users.

One thing is certain, the format of the data (XML, EDI, csv, Fixed Width or even MS Excel) is irrelevant as long as the data that is required by the recipient is either present or can be deduced. You see the style of the message is not as important as the substance (aka content) of the message.