Logistics Software Technology - some new, a lot old

Logistics Software Technology – some new, a lot old

So much of our world is controlled by logistics software running in every manufacturer, warehouse, trucking company, ocean carrier, etc. As consumers, we see our packages arrive promptly at our doorstep and are pleased with how quick and efficient the process is. How convenient it is to go to the UPS or FedEx site and track our packages. Isn’t technology wonderful!

The package at your doorstep is the last link of a very long and complex supply chain that involves a multitude of companies, often using very antiquated software. For example, consider how information is exchanged between these companies.

Data is commonly exchanged using EDI (electronic data interchange) with a format called X12. This data format was created in the 1960s and standardized in the 1970s. It is still the primary means of communication between many companies in the supply chain. Here is a sample status message (EDI 214) from a trucking company:

ISA*00*         *00*         *02*FXFE           *ZZ*114874527P     *260125*0835*U*00401*000031132*0*P*:~
GS*QM*FXFE*MYCA*20260125*0835*42718*X*004010~
ST*214*427180003~
B10*6283467433**FXFE~
L11*8368-AL9XXXXXX*PO~
K1*PP~
N1*SH*MY CABLE~
N3*55 ELM ST~
N4*CAROL STREAM*IL*601889415~
N1*CN*THE ELECTRIC COMPANY~
N3*33 MAIN STREET~
N4*WOODSVILLE*NH*037851006~
LX*1~
AT7*AV*AO***20260125*0923*LT~
MS1*BERLIN*VT*US~

Pretty ugly.

Again, we are faced with the same conundrum we saw with the old COBOL programs. This data interchange format is 50 years old and still the primary method we use today. Why hasn’t it been displaced long ago by better technology? The answer is the same as with COBOL programs – it’s too hard and costs too much time and money. It’s not even clear if the new technology is better or worse than the old.

Nobody would argue that the EDI format above is hard to read, hard to produce and hard to debug. We have replaced this data format with better representations, first by XML, and more recently by JSON. And while these data formats are easier to read and write, the process of using them has gotten much harder. This is for two reasons:

1. Lack of standards. EDI was standardized. And while each company may stray a bit, the basic structure, data types and codes were consistent. There are no such standards for XML and JSON. The NMFTA is starting to create some standards for LTL (less than truckload) integrations, but it is a drop in the bucket.
   
   
2. Lack of documentation. You can criticize EDI all you want, but you cannot argue that there is extensive documentation for every message, every field and every value. XML at least had some. One format used WSDL (Web Services Definition Language). Another used XSDs (XML Scheme Definition). While these were not nearly as extensive as EDI documentation, at least it defined data types and possible values. JSON has even less.

So, has this technology change from EDI files sent between companies, to XML or JSON sent over an API (Application Programming Interface) an improvement in terms of cost and efficiency? While the new technology may yield better performance in exchanging messages, from a programming perspective the answer is NO. Building a modern-day API integration is far more work than using 50-year-old EDI technology.

FAILURE #2:

We continually change technology in terms of languages, data storage and data transfer, but this does not move the needle in making us more efficient. The changes may even be a step backwards in terms of building better applications quicker.

We see backwards steps when going from EDI to XML to JSON. EDI was very well documented, and standardized. XML was not standardized but at least has some documentation. JSON has neither. Programmers will argue that JSON has documentation that is automatically generated from the code with tools like Swagger. This auto-generated documentation only tells you the names of the fields, not the possible values, how the field is used, or any other information that would be useful to someone integrating with your system.

In hindsight, maybe we should have kept the old EDI standards, stuck a converter in front of all our systems to convert EDI to JSON, and called it a day.

Unlike almost every other industry, software development does not build on the work of the past. Rather, the next generation invents some new thing and blindly throws out the old, without truly understanding the thoughts and decisions that went into it. This leads to either constantly reinventing the wheel or often taking one step forward and two steps back.

In the next chapter I’ll discuss how this pattern is not only in the underlying technology, but in the actual logistics applications themselves.

Next chapter – “Logistics Applications – another legacy problem”