00:00:07 Importance of software design in modern supply chains.
00:01:22 Common software design problems in supply chain management.
00:02:37 Challenges of real-time software systems in supply chains.
00:04:55 How complex operations can impact real-time systems.
00:07:13 Real-time systems clogged by non real-time operations.
00:09:13 Importance of design choices and time scale in supply chain software.
00:12:31 Differences between single tenant and multi tenant software.
00:14:11 Challenges with multiple versions of software in single tenant applications.
00:15:33 Advantages of multi tenant software and the shift towards SaaS models.
00:17:56 Importance of understanding core assumptions in software design for supply chain practitioners.
00:19:18 Core design assumptions of Lokad, including batch processing mode and multi-tenancy.
00:21:35 Concluding thoughts on understanding choices in software and their impact on future operations.
00:23:36 Closing thoughts.
Summary
In an interview with Joannes Vermorel, founder of Lokad, the impact of software design on supply chain optimization is discussed. Challenges often arise from design problems rather than bugs or crashes, which can make the software slow, non-intuitive, and difficult to configure. Real-time data handling is a key feature that can impact operations. However, focusing on swift, simple operations can hinder complex processes like forecasting or network-wide analyses. It’s crucial to understand software design assumptions to prevent issues from arising due to mismatches between the software’s design and a company’s intended use.
Extended Summary
In this interview, host Kieran Chandler discusses with Joannes Vermorel, the founder of Lokad, the impact of software design on company operations, particularly within the context of supply chain optimization. Vermorel highlights the importance of software design in modern supply chains, which rely on multiple layers of software, such as ERPs, MRPs, WMSs, OMSs, and EDIs, to function efficiently.
The challenges faced by Lokad’s clients often stem from issues with their software’s design, rather than obvious bugs or crashes. These design problems can make the software sluggish, non-intuitive, slow, and difficult to configure. As Vermorel explains, these problems often result from a mismatch between the core design decisions made for the software and the actual reality of the supply chain they are intended to serve.
One of the key features of software architecture that can impact supply chain operations is its ability to handle real-time data. Vermorel points out that while true real-time data processing is not possible due to the finite speed of light, many supply chain software systems are designed to approximate real-time data processing. For example, when an item is picked from a shelf, the software decrements the stock level immediately. This real-time approach, however, can have unintended consequences.
When software is designed for swift, simple operations, it becomes challenging to execute more complex operations, such as forecasting or network-wide analyses. These complex operations require a more sophisticated level of data processing, which may not be feasible within a system optimized for real-time, small-scale updates.
Joannes Vermorel emphasizes the critical importance of software design in supply chain optimization. The challenges faced by Lokad’s clients often stem from design problems that make the software slow, non-intuitive, and difficult to configure, resulting from a mismatch between the software’s core design decisions and the actual reality of the supply chain. The ability to handle real-time data is one key feature of software architecture that can impact supply chain operations. However, when software is designed for swift, simple operations, it becomes challenging to execute more complex operations, such as forecasting or network-wide analyses, which require a more sophisticated level of data processing.
Vermorel explains that the issues faced by supply chain practitioners using such software are not always obvious, as they often manifest as a slow accumulation of problems, which he refers to as “death by a thousand cuts.”
One key issue is the need for real-time functionality in certain scenarios, such as scanning items on a high-speed conveyor belt. When non real-time operations are introduced into the system, the overall performance may be negatively impacted, resulting in slowdowns and delays. This can lead to increased frustration among users and reduced efficiency.
Vermorel highlights the importance of making the right core design choices, which should be deeply aligned with the problems the software is trying to solve. In the context of supply chain software, various core assumptions are made, and if these are not met, problems may arise down the line.
The timescale on which the software operates is a crucial consideration. Vermorel describes the different types of software needed for various timescales, ranging from sub-millisecond response times for driving conveyor belts, to longer-term planning involving factory placement decisions spanning years or even decades. Each order of magnitude increase in timescale necessitates a different type of software with unique capabilities.
At Lokad, the focus is typically on timescales from one day to one year, which requires a different approach to software design. Vermorel also touches on the differences between single tenant and multi-tenant software, which is a critical consideration for software developers, although less familiar to most companies.
They discuss the differences between multi-tenant and single-tenant software, the advantages of the SaaS model, and the core assumptions that have guided Lokad’s software design.
Vermorel explains that multi-tenant software serves multiple clients using the same piece of software, while single-tenant software involves giving each client their own customized version. Lokad is multi-tenant, with one code base updated on a weekly basis. This approach has several advantages, including simplified versioning and less security problems. Vermorel contrasts this with single-tenant software, which allows for per-client customization but requires managing multiple versions, leading to operational challenges.
He observes that, over the past decade, many serious software companies have moved towards multi-tenancy. For web apps like Lokad, being multi-tenant is fairly straightforward, but for software that operates on client machines, it can be more complicated. One solution to this problem is the “evergreen” strategy, as exemplified by Google Chrome and Microsoft Office 365. These applications update automatically, without user intervention, thus mitigating the issues of having multiple versions of the same software.
When discussing Lokad’s software design, Vermorel emphasizes the importance of understanding a vendor’s core assumptions. He warns against vendors who claim their software can do everything and stresses that design is about trade-offs, with both positive and negative aspects. He encourages potential clients to ask software vendors about their core assumptions, and to be cautious of those who only provide vague, positive answers.
Lokad’s core design assumptions include batch processing mode, which Vermorel explains is chosen because it allows for better optimization and resource management.
One key principle is prioritizing smart calculations over speed. Lokad prefers to have accurate and detailed computations even if it takes longer, as opposed to faster, less precise calculations. The software is designed for batch processing rather than real-time, allowing for greater expressiveness and power in analysis.
Another core assumption is the importance of multi-tenancy and embracing the capabilities offered by cloud computing. Lokad aims to use scale-out capabilities rather than scale-up, meaning they utilize multiple smaller machines for processing large amounts of data rather than relying on a single, powerful supercomputer.
Vermorel emphasizes the importance of supply chain practitioners understanding the core design assumptions of their software. This understanding helps to prevent issues arising from a mismatch between the software’s design and the company’s intended use. Vendors may claim their software is versatile and suitable for various situations, but in reality, certain design limitations may hinder its effectiveness in some applications.
Full Transcript
Kieran Chandler: Today, we’re going to understand how these decisions can actually end up pigeonholing a company and also understand some of the core assumptions that lie behind them. So, Joannes, we’re talking a bit about how poor software design can actually impact a company. What are some of the challenges you see?
Joannes Vermorel: The first challenge is that software design is critically important for supply chains. Modern supply chains run on software. You have trucks, machines, conveyor belts, but also large chunks of software like your ERP, MRP, WMS, OMS, EDI, and so many layers. Modern supply chains don’t run without software in large quantities. When I discuss with clients of Lokad, they frequently struggle against the applicative landscape of the supply chain. There are a lot of software-related problems, but they’re not necessarily bugs or crashes. Design problems are much more pervasive; they make things sluggish, not intuitive, slow, and it takes forever to configure the system. When you try to do a root cause analysis, you frequently witness that the problems are actually software design problems where the core fundamental decisions were made about the design of the software, and it just completely mismatched the actual reality of the given supply chain of interest.
Kieran Chandler: So, what are some features of the software’s architecture that can be so important? What are some of the challenges that you’ve seen with your clients?
Joannes Vermorel: Let’s say, for example, real-time. Many supply chain software nowadays are geared toward real-time operations. By real-time, I mean that if you decide to pick one unit on the shelf, it’s going to decrement the stock level immediately. It looks like a very reasonable thing. However, as soon as you have this kind of software that is designed for real-time, any sophisticated calculation is going to be a big pain to operate in the software. The reason is because if your software is designed to be super fast for super simple operations, having a complex operation, like a forecast or a network-wide analysis, is going to be a struggle. This is because your software is designed for very swift, small operations, and when you need to process a moderately complex amount of data, it’s going to be difficult.
Kieran Chandler: And if you have a big granular version, it’s going to slow down everyone, including things that should be super fast, like just scanning a barcode and doing beep. I have scanned, you can proceed to the next item. How obvious are some of these challenges? You’ve got to sympathize with a supply chain practitioner. I mean, there’s a lot going on, and with a lot of time with this software, there’s a hell of a lot going on under the hood. So how obvious is it that some of these challenges are out there?
Joannes Vermorel: It’s not obvious because usually, it’s not an obvious bug where your system crashes. It’s more like death by a thousand cuts. Let me illustrate: you have this system that is supposed to be real-time. When something is scanned on a high-speed conveyor belt, you should be able to beep items three items per second, or something. You should be able to be really fast and have milliseconds response time.
Now, what is happening if, once in a while, you have a calculation that just takes a few seconds instead of taking milliseconds? If you just have one operation, once in a while, that takes a few seconds, and your real-time system is nicely designed, probably most of the other operations will stay super fast, so it doesn’t hurt that much. Except, if you’re not lucky, and at the same point in time, you have like ten different operations that take multiple seconds to compute. That just absorbs, at this specific point in time, all the computing resources.
So, what will happen is that the system that was supposed to be able to scan and give you feedback in milliseconds suddenly takes one second. It’s not ideal, but you can live with it. However, once in a while, you have this thing where you were expecting something lightning fast, but suddenly it’s two or three seconds of delay. By the way, you can see that sometimes even in local supermarkets. You have a point of sale and the beeping of items is very fluid, but at some point, they just beep something and three seconds happen, and then beep.
Here, you have a real-time system that was kind of clogged into a non-real-time operation. I don’t know what it was, maybe a Windows Update or some sort of weird stuff that happens that slow down the machine. But in a real-time system, you’re not allowed to do anything smart or complex because that’s going to degrade the superfast operations you want to carry out.
When I say death by a thousand cuts, it’s because the first time you do a non-real-time thing in a real-time system, probably nothing bad will really happen. It’s rare, so you’re kind of okay. But the problem is that you pile up more and more non-real-time stuff, and suddenly those problems that were very infrequent start to become more frequent and more frequent, until they become super frequent. Then people are just going nuts, saying, “Why is this conveyor belt not working faster? It could.”
The answer is because there’s a machine that is supposed to scan the barcode, and we need to wait for the system to answer. I have seen situations where it was taking half a minute for the system to answer back after scanning a barcode. It was about printing something to put on the box, but the conveyor was limited by the speed at which the system could deliver the order to the printer to print something on the box. They had people just waiting for the printer to print.
You have plenty of design choices that need to get the core choices very right, in ways that are deeply aligned with the problems you’re trying to solve.
Kieran Chandler: What are the key core assumptions that are being made in supply chain software, and which ones have you observed are not really working?
Joannes Vermorel: There are many ways to approach this. First, consider the time scale you want to operate in. We have things that need to operate from sub-millisecond response time, which is what you need to literally drive a conveyor belt, to decisions where you need to think a decade ahead, like the placement of factories. Every time you add an order of magnitude, you change the software fundamentally.
Kieran Chandler: Can you give some examples of different time scales and the corresponding types of software?
Joannes Vermorel: Sure. Sub-millisecond is one type of software; from 1 to 10 milliseconds, it’s going to be another type of software; from 10 to 100 milliseconds, it’s going to be another type, which is typically ERP software with response times from 10 to 100 milliseconds. From 100 milliseconds to 1 second, you get the sort of things that you can find in a web app. Then, if you start thinking from 1 minute to 10 minutes ahead, you’re not in real-time anymore, but you can start doing fancy calculations. For example, a navigation app like Waze needs to provide a route within half a minute but doesn’t need to be real-time.
If you are optimizing a route for truck deliveries, you can typically take multiple minutes to get the results, as it doesn’t need to be real-time. At Lokad, we are typically more focused on timeframes from 1 day to 1 year. This is the sweet spot for us, and it means that we can pretty much ignore everything before that. If we go beyond one year, we enter the realm of supply chain design, which is more map-centric and changes the problem.
Kieran Chandler: Let’s talk more about the implementation of software. What are the key differences between single tenant and multi-tenant software?
Joannes Vermorel: The difference between single tenant and multi-tenant is how many clients you serve with the same piece of software. If you are multi-tenant, like Lokad, it’s the same software serving all our clients. We have only one version deployed online at any given time, and we update this software on a weekly basis. The other way, which was more common before the advent of SaaS, is single tenant. This approach involves giving each client their own copy of the software, which often results in customization for large clients.
Producing the software means that suddenly you end up with many variants of your software that just happen to be running at the same time, which is a big operational problem because it means that if there’s a bug that happened in one version, you have to fix this version, but you have to make sure that the bug is also fixed in all of your other versions. By the way, this is a problem where, for software companies, you have like anti-economies of scale. The bigger you are, the more problems you have with your versioning. By the way, this problem is very severely impacting Oracle, for example, with the Oracle database. They have plenty of heavily customized versions that are optimized for performance. I have no secret insider information, but from just public information, you can see that literally, in some multiple engineering divisions at Oracle, they are struggling with the fact that they have many variants of the software out there. Obviously, Oracle has tons of engineering capabilities, but nonetheless, it remains a big challenge. So, single-tenant gives you the option of per-client customization, but then you have to deal with per-client overhead. Multi-tenant gives you the fact that you have one code base for everyone, no customization, but in exchange, you can evolve much faster and also have much fewer security problems.
Kieran Chandler: When you say that the marketplace is very much moving towards that kind of SaaS model, why is it that this model is so much better? Does it give a greater degree of flexibility for the company?
Joannes Vermorel: Yes, over the last decade, pretty much all the serious software vendors have moved toward multi-tenancy, even classical traditional desktop applications. Because obviously, if you’re a web app like Lokad, being multi-tenant is fairly straightforward. You redeploy the stuff on your own systems, and it’s done. Obviously, when you have software that operates on client machines, like let’s say your browser, for example, Internet Explorer or Google Chrome, it’s more complicated because you don’t have control of your client machines. But guess what software vendors have done? They have switched to the evergreen strategy. For example, Google Chrome doesn’t ask you anymore about updating the browser. When Google decides that your Chrome version is outdated and needs to be replaced, Google updates your browser at a distance. Obviously, the next time you connect to the internet and whatnot, they can’t magically update your software if you don’t have internet connectivity. But assuming that you have internet connectivity and you’ve not done any specific shenanigans with your machine to prevent the upgrade, the upgrade will happen, basically without your intervention. And when you look at what Microsoft is doing with Office 365, it’s the same thing. In the past, you had a series of Microsoft Office versions when you were moving from one Excel version to the next. Nowadays, it’s on-demand, and Microsoft takes care of the upgrade. You have a subscription, the software is installed on your machine, but it can just upgrade itself to the next version. And if you just let it, unless you deactivate your upgrade options, Microsoft is just upgrading all the desktop apps precisely to mitigate the problem of having many versions of the same software.
Kieran Chandler: Let’s talk a bit about Lokad then. You said that there were certain core assumptions that have to be made in software design that can really impact future operations. So, what were the core assumptions that you made here at Lokad?
Joannes Vermorel: There are tons of them, but before I go into the core assumptions, I would like to have a note. If you meet a software vendor that
Kieran Chandler: That tells you all my software, you know. We are capable of everything we didn’t make. You know, so software assumption. If they give you only, can I suggest, you know, when you met a software vendor for your supply chain, ask them what are the core assumptions? And if they tell you something vague like, “we are designed for security,” great. “We are designed for speed,” yeah, me too. “We are designed for cost efficiency,” yeah. You know, these are sort of our super vague, absolutely positive things. But when we discuss design, a design standpoint is a trade-off. It’s something that has positive aspects and negative aspects. So, if you can discuss with the software vendor, and all they can give you are the positive aspects, it’s probably that they don’t even understand the nature of software design in the first place. So, Joannes, what are the core design assumptions that you built into Lokad?
Joannes Vermorel: The first was a batch processing mode. So, what does that mean? That means that what we want is to be able to crunch tons of big data and to do very smart calculations. Obviously, because we want to, we prefer to be very smart as opposed to be very, very fast, which means that we, for us, having calculations that are typically executed within minutes, but the fact that they can be executed within seconds is kind of a bonus. But if we can’t, it’s not such a big deal. We prefer to have better numbers even if it takes a bit of time. By the way, it’s not because there is our parts that look at that our wheel time, it’s just a presentation of the results. So, maybe you will need like half an hour to do a massive calculation, but when you want to access those results, then it needs to be real-time, but it’s pre-computed. So, you see that was a core design assumption. No real-time, or it’s batch. And the reason is that we want to be able to be very expressive and very powerful and thus be as smart as we can for, I would say, net worldwide analysis. So, that’s one core assumption. Another one was we wanted to have multi-tenancy. Obviously, nowadays, most people are doing that, but there are still companies that are, especially in the enterprise space, lagging behind. And I would say multi-tenancy done with all.
Kieran Chandler: Can you explain the difference between scalable and scale out?
Joannes Vermorel: The capabilities offered by the cloud mean that we want to have scale out capabilities rather than scale up. The question is, if you want to process terabytes of data, can you do that by piling up tons of small machines or do you need a supercomputer to do it?
Kieran Chandler: So what’s our main conclusion here today?
Joannes Vermorel: Our main conclusion is that in terms of the data we have out there and in terms of making choices about software, it can very much pigeonhole what you do in the future. So you need to fully understand the choices that you’re making.
Kieran Chandler: Can you elaborate on that?
Joannes Vermorel: My suggestion would be for supply chain practitioners to be more aware of the core design assumptions that are characterizing their own applicative landscape. They have many apps, and can they give me half a dozen of critical code assumptions that explain the ins and outs of the product. It might sound super technical, but if you don’t understand those core design assumptions, you are going to suffer a lot when you realize that you’re attempting to do something where by design this is not going to be a good product for that. Frequently, I have seen many companies where literally their problems are emerging from a mismatch between the design of the software and what they are trying to do with it.
Kieran Chandler: Can you give an example?
Joannes Vermorel: Vendors try to be very confident, you know, as a vendor, you’re trying to sell your software. You want to act confident and tell the client that your piece of supply chain software is going to be nice in all situations, and we got you covered. But the reality is that if a client is going to use your piece of software for something that is outside your design capabilities, you can’t just duct tape the thing. You can’t just add a feature. The software engineers on the back end are going to tell you, “Boss, sorry, we can’t do it. It’s going to be hell.”
Kieran Chandler: Alright, let’s wrap it up. Thank you, Joannes. That’s everything for this week. Thanks very much for tuning in, and we’ll see you again next time. Bye for now.
