OMP Talks

A story of innovation: OMP's software journey

• Patrick Van Cauteren

Share episode

Dive into the evolution of OMP’s supply chain software with Software Architect Patrick Van Cauteren, who’s been with the company since the very start. From the first mathematical optimizer application to the full-blown Unison Planning platform, discover the challenges and driving forces behind this transformative journey.

Hello and welcome to OMP Talks, a podcast about supply chain planning challenges, Ways to solve them, and the people behind the technology. My name is Flo, Senior Business Development Consultant, here at OMP, and your host for this episode. Today's talk is the first episode in a series called 'How to build software'. And in this series we'll take you on a journey so you understand how to build functional software and also which steps you need to take to bring your idea to the market. And in this first episode particularly, we're going to talk about why OMP’s software is so successful. And we'll do that with our very own Patrick Van Cauteren, who has actually been with OMP from the very start. He's a Senior Software Architect here, so he's going to tell us all about the success behind OMP. Thank you so much for being here today, Patrick. It's great to have you and I suggest we dive right into it. What was the reason for you to start working at OMP? Well, I was fresh from university. It was 1988. There was no Amazon, no Google, no Facebook. So choices were really limited. And actually you had to choose between banks or small software companies. At that time, banks worked mainly with mainframes. So yeah, smaller companies got more of my attention, especially OMP, because they had more modern hardware like workstations. Okay. And were the workstations the only reason that you chose to start working at OMP or was there more? No, we had a very nice integrated development environment. Brand new out-of-the-box with version management, build systems, source code analyzers, performance profilers... So lots of new things to try out, to experiment with and there were no libraries that existed at the time. So we had to do a lot of experiments, do some research, and it really taught us a lot about how to think about reusable software and making flexible designs. So to recap, you could say that you had to build the software basically from scratch, and by testing and playing around, you really understood what it takes to design flexible software and reusable software. Can you maybe give an example? Yeah, my first assignment was to modernize the user interface of the optimizer. It was still character-based, we had no Windows at the time, but we supported multiple platforms. So we had to support not only PC, like we have now, but also OS/2, VAX/VMS and Unix operating systems. So we had to design a user interface library, still character-based, that worked on top of all these platforms. So we had to do quite some experiments and come up with a flexible and good design so that it worked on all these platforms. Yeah. So you mentioned it was character-based. Does that mean that there were no graphical applications available yet at that time? No. We started with graphical applications when Windows 3.0 became popular. That was somewhere in the early nineties. And we realized that the future is with graphical applications. So we investigated some portable graphical libraries, because we still supported different platforms. We found one and we made a prototype with that, and we created an application that visualized the output of the optimizer in a Gantt chart. Okay. And that was actually a very important key moment in the history of OMP, because that was the step towards a full scheduling application. Yeah. Interesting. And if you would have to define the main challenges in designing this application, what would these challenges have been? Well, we had no experience with supply chain applications then, so we really had to do lots of investigations, experiments, try out what the users would want from our applications. So it really gave us the opportunity to try out lots of things, and gave developers the opportunity to give their input on what they thought the application should look like. Okay great. And OMP of course today is a full planning software. But I heard that the Planner application actually only came a few years later, is that correct? Yeah, that's true. We first had the scheduling application with the Gantt chart, and then a few years later we had the planning application, which was made together with the University of Galway in Ireland. And so at that time, we worked together with universities, which was not very new because our founder, Georges Schepens, was already a professor at the university, and one of his colleagues, Francois Louveaux also helped in optimizing the optimizer algorithms. Yeah, that's amazing that you guys already worked with universities so early on. Before, you mentioned that there were two applications, right, Planner and Scheduler. Wasn't it complicated to have two applications at the same time? Yeah, we didn't want to make two separate applications with no shared codebase. Okay. So we really wanted to make good tools, good components, that could be reused in both applications, which means that you also need to think about 'What is a good design, how do you make your code reusable and flexible so it can be used in two applications?'. Yeah. And is that flexibility also visible from outside the application? Yeah, that's true. We also made a very dynamic and extensible data model, allowing our applications to be used in different industries. That wasn't the case from the start because the first versions of our scheduling applications were really customer-specific. For every customer we had a different executable that we wrote. But after one or two years, we really learned how to make a flexible design with configuration possibilities, so it could be used for multiple customers. Yeah. So basically you learned by doing and then you found out that there was a need for flexible software that could be customized to your customers needs, right? Is that correct? Yeah. And has this flexibility helped you in making these customer- tailored solutions? Yes, because our applications are not customer-specific anymore, they're standard applications. But the solution is customer-specific, which means that, as a software designer, as a software architect, we need to make our software configurable in such a way that our applications can be used in lots of different industries, regardless of whether you make haircare products, diapers, metals, wires or medicines. So eventually both applications were replaced by one single application called OMP Plus. Why did you decide to do that? At that time all of our competitors had separate planning and scheduling applications, but we realized that it would be much better for users to have one integrated application where you could have as well both planning functionality and scheduling functionality in one application. And of course, going from 2 to 1 is quite the challenge, I imagine. What were the main challenges for your team when doing that? Yeah, well the challenges were that you had two applications with two different data models and you had to integrate them into one data model. Same with the algorithms. You had specific algorithms for scheduling, specific algorithms for planning, and you had to merge them into one application, so that in OMP Plus users could have both functionalities. Yeah, So that's quite the evolution, right? OMP basically went from being a mathematical optimization tool to a fully integrated supply chain planning software. So what was your role in that evolution? For me, it was a whole journey. When I started in 1988, I was the ICT department, but that was much easier than today. There was no internet, so no firewalls, no virus scanners, just making sure the computers ran. But when we started with the graphical applications, and more specifically OMP Scheduler, I became the main architect for the supply chain scheduling application. And I really worked closely together with functional people and consultants because they know what the customer wants, and I know what what we can technically do. So we really cooperated very closely together to come up with the best solution. Yeah. So as a Software Architect, your job was, and of course still is, to serve the customer's needs that are being represented by the consultants, but at all while guarding the flexible and pragmatic character of the software. In the beginning you mentioned that OMP was using modern technologies and was very innovative, way more ahead of time than other companies. Is that still the case today? Yeah, that's still the case, but there's always a risk. You should not jump into the latest hype. Who still remembers things like CORBA, and SOAP, and Distributed COM, and so on? Those things, well, they might exist today but they're less popular than they were. So you need to use mature technologies. You need to do some investigations and research to see what is a mature technology. And on top of that, use some abstractions to hide these technological things behind some facade in your application. So if technology changes, it becomes easy to change the technical implementation behind your facade. Yeah. So I think, Patrick, we can conclude that there are a couple of main reasons why OMP's software has been so successful. I think you guys trying and testing a lot of new things was one of them. In addition to that, also the need for a flexible approach and a pragmatic approach, you mentioned that a couple of times. But also that we need to make sure that we understand our customer's needs, and that we work in close collaboration with consultants, with third parties, with universities, that can help us improve the software. But I think last but not least, Patrick, I think it's very important also to have such passionate software architects and developers to make it all work. Thank you so much for joining us today, Patrick. And I would also, of course, like to thank all listeners for tuning in, for listening to this podcast episode. Make sure to stay tuned for the other episodes in how to make software or how to build software. And we will be taking you on a journey where you learn how to build functional software, but also what are the steps you need to take to bring your idea to the market. Thank you very much.