Editor’s Note: The following is an excerpt of a research report published recently titled “The DNA of Transportation Management Systems.” The research, conducted by Adelante SCM and commissioned by Manhattan Associates, highlights important building blocks of a modern transportation management system (TMS). Please visit the report page for more information about the research and to download the full report. Also, below is a recording of a recent LinkedIn Live event featuring Paula Natoli from Google Cloud, Tim Evans from Loadsmart, Robert Schaefer from Manhattan Associates, and our own Adrian Gonzalez discussing why rewriting the DNA of your logistics and transportation operations is important.
Transportation Management Systems (TMS) were among the very first enterprise applications to be offered in the software-as-a-service (SaaS) model, going back to the dotcom era of the late 90s and early 2000s. The SaaS model made it easier and less expensive for companies to deploy a TMS, especially small and midsized companies that typically lacked the IT budget and resources to implement a solution in-house.
Today, virtually all TMS solutions and deployments are in the cloud. However, the way these solutions are architected for cloud deployment has changed significantly over the past 20 years.
To provide some perspective, when the first software-as-a-service TMS were released, the iPhone and App Store did not exist yet (they were introduced in 2007 and 2008, respectively). Neither did Amazon AWS (2006), Google Cloud (2008), or Microsoft Azure (2010) cloud services. The emergence of smartphones, mobile apps, and cloud services — together with their underlying technologies — have influenced the way many enterprise applications are now designed and architected for cloud deployment.
For example, many enterprise applications, particularly those that have grown in size and complexity over the years (which includes transportation management systems), have migrated from a “monolithic” architecture to a “microservices” one. As defined by technology consultants James Lewis and Martin Fowler:
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms [such as APIs]. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Putting this in the context of a TMS, instead of being one big piece of software code, think of a TMS that is built using the software equivalent of Lego bricks. Each brick (microservice) is designed to perform a different TMS function, like rating or tendering. You can add new bricks, remove outdated ones, and connect them together in different ways to enable specific workflows.
Why the move to a microservices architecture? This quote by BigPicture.io founder and CEO Michael Frye highlights some of the main reasons:
“Previously, we developers built applications in a way that is now known as the monolith: The project starts off small, then we just add something here, bolt on a new feature there. Then fast-forward a year or two and you suddenly have this monster of a project where you change one thing and the whole system can break. Everything is interconnected. It’s also much harder to scale this type of system. It’s just one monster project, so you end up having to scale by throwing more servers at it, which ends up being very expensive.”
Lewis and Fowler add:
Monolithic applications can be successful, but increasingly people are feeling frustrations with them — especially as more applications are being deployed to the cloud. Change cycles are tied together — a change made to a small part of the application requires the entire monolith to be rebuilt and deployed. Over time it’s often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resources.
In short, a microservices architecture offers a variety of benefits related to scalability (i.e., the ability for an application to handle larger volumes of transactions and users) and how new functionality is added and updated. The latter includes the ability for users to create their own unique functionality to extend the capabilities of the application — that is, it enables users to customize a cloud application to meet their unique needs without affecting the rest of the codebase. It also enables users to add third-party extensions for additional functionality. These self-developed and third-party extensions are effectively “Lego bricks” that plug into the microservices framework of the application via APIs.
Admittedly, this whole discussion is very IT centric. So, why should this matter to a Vice President of Transportation?
It matters because the way a TMS is architected impacts how quickly and effectively it can keep pace with the changing needs and requirements of your transportation operations. And those needs and requirements are dictated by your customers and the ebbs and flows of the transportation market.
Considering the dynamic nature of transportation management, companies can no longer afford to wait a year or more for “the next version of the TMS” to be released in order to obtain new functionality that is needed now. Therefore, a TMS that is architected to always be current (“versionless”) is important, along with the ability to add new functionality via extensions as needed.
Scalability matters too, as many companies learned in 2020. While some companies experienced a reduction in shipping volume due to the pandemic, others experienced a large (and unexpected) surge in shipping volume. Therefore, the ability for a TMS to scale quickly and cost-effectively in response to growth in shipping volumes and processing needs is also important
For an overview of other important building blocks of a modern TMS, please download the research report, and watch the LinkedIn Live event below for an informative conversation on the topic.
