Using a TMS and Business Logic to Complete the API Equation

“API” is one of those terms that get thrown around with abandon. While at a trade show recently, I talked to dozens of vendors and heard them say, “I have an API for that!” over and over. What’s upsetting is that most of them didn’t have a clue as to what an API is, other than a general understanding of something that happens on the internet! They seemed to think APIs (application programming interfaces) are like apps in Google Play or the Apple Store – you click a button and boom, it’s done.

Ahh, if it were only so simple.

APIs: An Entirely New Way of Connecting

I come from the commercial transportation management software (TMS) space, and one of the things a commercial TMS has to provide is connectivity. In fact, I’m not sure there’s another supply chain management system that has to communicate with so many different parties. A TMS has to deal with your ERP, order management systems (OMS), warehouse management systems (WMS) and finance — plus all of your trading partners, vendors, customers, third-party logistics providers (3PLs), carriers and more. There are also third-party data sources to consider like tariffs, rates, distance and tracking.   

APIs create a direct connection between parties for instant data exchange. For a TMS, this means managing freight while dealing with all of the other systems mentioned above, so it quickly becomes complex. While looking at data from current customers, many have orders that get touched by outside systems well over 100 times during the move. These API “touches” involve basic things like customer order changes or tendering to carriers, but also data validation, status updates, tracking, inbound/outbound notifications, customer queries, warehouse details, as well as the normal order-to-cash from the OMS/ERP through finance.

More Than Passing Data  

All of these systems have APIs and can pass data – but that’s only part of the story. A large part of the data that a TMS receives from other systems is inaccurate, unreliable or – most commonly – incomplete. With the amount of data your TMS deals with, there’s no physical way to manually operate a fully integrated process. To really maximize the point of APIs, your TMS needs to use business logic and process as much as possible – without requiring you to touch the data.

A TMS can use business logic to establish delivery windows, missing freight class, or running drive times based on service details, as a few examples. Remember: All of these systems use APIs, but the APIs only pass the data – you need a TMS with business logic to interpret and act on the data.

TMS: The “Rally Point”

Ten years ago, we would have used the term “Control Tower” to describe a TMS connected to so many systems. But the interesting fact is that most Tier 1 TMSs today have more connections than the Control Tower projects of just a few years ago! The old Control Tower projects easily cost millions of dollars and demanded extensive development and resources. Today, much of that logic is already built into a commercial TMS, enabling it to translate different systems’ output and act upon it intelligently. Rather than a Control Tower, the TMS becomes a “Rally Point” for combining different data sources, translating that data and then automating responses across vastly different data types while normalizing it into one home for advanced analytics.    

This is where a TMS can be the paladin of your data and help you differentiate your services, especially when it comes to e-commerce. Managing your digital aspects is now a core part of your operations and the ability to communicate information accurately and instantly is essential. Remember, customers don’t just ask “Where’s my freight?” – they expect to be told immediately when there are exceptions and need in-depth intelligence and analytics on service data to find ways to save money and build predictive analytics.

That’s why I smile when I hear people say “I have an API for that!” The problem isn’t setting up an API and passing the data. The problem is bringing all of that data – which is often incomplete data – to a rally point and making intelligent, automated processes. It’s where the rubber meets the road. 

Photo of JP Wiggins

JP Wiggins is Co-Founder & Vice President of Logistics at 3Gtms, where he manages channels and partnerships for the company. He was most recently at SAP where he was the solution principal focusing on SAP’s transportation, warehouse and event management offerings in North America and previously directed industry marketing for the company’s transportation and logistics business unit. Before SAP, he was senior vice president and general manager for Descartes Systems Group’s supply chain, transportation and logistics applications business, and also had been vice president of product management for the company. Previously, JP was co-founder and senior vice president of logistics for Global Logistics Technologies (G-Log); co-founder and vice president of product management at dx/dt; and vice president of logistics at Weseley Software. He holds degrees in transportation & logistics and marketing from The Ohio State University.