From Multi-Tentant to Malleability
Welcome to the 24th edition of The LogTech Letter, a weekly look at the impact technology is having on the world of global and domestic logistics. Last week, I examined the metric I believe will define the value of technology in the world of forwarding. This week, I’m taking a peek under the software hood to think about whether the structure of software deployment is a bit confusing for a buying market that’s in constant catch-up mode.
As a reminder, this is the place to turn on Fridays for quick reflection on a dynamic, software category, or specific company that’s on my mind. You’ll also find a collection of links to stories, videos and podcasts from me, my colleagues at the Journal of Commerce, and other analysis I find interesting.
For those that don’t know me, I’m Eric Johnson, senior technology editor at the Journal of Commerce and JOC.com. I can be reached at eric.johnson@ihsmarkit.com or on Twitter at @LogTechEric.
It’s too simplistic to say the logistics industry is behind the times when it comes to technology, because A) that implies the industry is a monolith, and B) it implies that the industry has only a couple of types of systems to consider. Neither is true, which clouds the picture of industry-wide adoption of cutting edge software.
It’s undeniable, to me, that everyone is aware of the challenge in front of them in terms of gravitating to newer, better tools. The rise of cloud-hosted, browser-based tools makes it easier to switch systems (not easy, but easier). But it also makes it harder to stop peering over your shoulder to see what else is out there. Ten years ago, if you committed to a six- or seven-figure multi-year logistics software engagement, you didn’t immediately start wondering what else was out there (in part, because there wasn’t a lot else out there). The ease of switchability cuts both ways.
This is all prologue for what I think has become a bigger issue in the minds of logistics software buyers - how quickly the underlying structure of software has changed in the last decade and what that means for buying decisions. Let me explain.
In 2010, the era of dotcom, cloud-based, software-as-a-service (SaaS) vendors in the logistics industry was about a decade old, but they had just reached the maturity stage where concerns about cloud-hosted software were easing. Where browser-based, subscription-based tools were being preferred to traditional on-premise, licensed products. That was a huge change.
Above all, it entailed logistics software buyers thinking about a new paradigm: the rise of the multi-tenant system. Multi-tenant systems are great in a lot of ways: all users benefit from an upgrade; a new wrinkle suggested by a set of customers is deployed to all customers; it incentivizes organizations to avoid over-customization of their products that can hamper future updates. In essence, when used in its optimally designed way, multi-tenant software removes much of the software maintenance and improvement burden from the user’s technical team and places it where it should logically reside: with the software provider.
But, and this is a big but, that means a user has to accede to the multi-tenant system as much as possible. The more its usage of the system diverges from the optimal design, the more it can stray away from the underlying benefits of multi-tenantism. Sometimes, this is fine, especially if the user has a strong technical team that understands the needs of the logistics team. Or if the logistics team uses a 3PL proficient in a particular system (this story comes to mind).
Whatever the case, the fact is that multi-tenant architecture has become the default setting for logistics software the past decade. But...the last three years have kinda changed the picture again. We’ve seen, in that time, the rise of solutions that are more malleable in nature, designed to meet software users on their terms, rather than being designed to force a user to migrate to a more rigid multi-tenant setup.
This is good! Malleable design means that software buyers don’t have to rip and replace, rip the band-aid off, and all the other “rip” cliches. System architecture, based on APIs and microservices, is designed to A) let users better leverage the systems they have already invested in (or are stuck with) and B) allow users to more readily connect to other systems.
But, and this is another big but, this is confusing...again. Logistics software buyers have spent the last decade coming to terms with a market where multi-tenant software is the baseline, and they’re now comfortable with buying decisions in that environment. Now, a new crop of vendors is saying...you don’t need to change everything, we’ll come to you and you can gradually evolve as your needs change and as users become more comfortable with change themselves.
To me, this suggests that buying cycles will become shorter, because the underlying architecture is changing so fast. It means that buyers in the market need to not only juggle features, functions, and ROI considerations, but also build adaptability into their thinking of how the software itself will be bought, deployed and (most crucially) adopted by users. We’ve entered the Fast and Furious era of #logtech software consumption. Buckle up.
Here’s a roundup of pieces on JOC.com the past two weeks from my colleagues and myself (note: there is a paywall):
Hardly a more important issue for ocean freight shippers to think about heading into ‘21 contracting season than how they strategize around container allocation. It involves carrier relationships, demand forecasting and a bit of pragmatism.
Let the Flexport diaspora in logistics commence. The former head of the forwarder’s LCL product line has started a new venture with two other Flexport vets to tackle the issue of product sourcing management in the apparel industry. Judging by outside interest in this story, they’ve hit upon something.
My colleague Cathy Roberson with an insightful look at how retailers are investing in fulfillment solutions.
And here are some recent discussions, reports, and analysis I found interesting:
It’s been a short, crazy-busy week, so I don’t have much here!
Carbon footprint calculation is a major issue that’s moved from pesky distraction to full-on corporate mandate. On Jan. 28 I’ll be moderating a panel with Nestle, CMA CGM, BuyCo and SeaRoutes to discuss how shippers can use technology to manage the sustainability of their logistics operations. It’s at 10 am CET, so that’s 4 am for the early birds on the US East Coast and 1 am for the night owls on the West Coast. The session is, of course, available on demand.
One more plug: I’m moderating a session with Henning Schleyerbach, COO of Digital Container Shipping Association (DCSA), Pascal Ollivier, chair of the IAPH Data Collaboration Committee, and Julian Abril Garcia, of the IMO, on the future of ship-to-shore data sharing at ports..
Weekly moving update: still not moving to Florida or Texas.
Weekly Keith Rabois update: comparing high tax rates and questionable housing policy to genocide. 🤷♂️
🚨 TPM21 registration is live, and so is the agenda. We’ll have two days of #LogTech focused programming Feb 25-26, ahead of the main program, which kicks off March 1. Each week until TPM, I’ll be highlighting a tech-focused session we’ll be hosting.
There’s an interesting question I have in mind that will serve as subtext for a panel with three venture capitalists focused on the supply chain and logistics space: how many $1 billion valuation software providers will there be in a decade? It’s not the most important near-term issue we’ll tackle in this 30-minute session with Julian Counihan, Flavia de la Fuente, and Santosh Sankar, but it underpins where the market is, and the extent to which VC as an equity class will have a marked impact on the trajectory of successful LogTech companies. If you want to really understand how clear-minded, pragmatic investors who understand logistics think about our industry, you don’t want to miss this one.
Disclaimer: This newsletter is in no way affiliated with The Journal of Commerce or IHS Markit, and any opinions are mine only.