The bright future of OpenTripModel
Simacan initiated the development of the open standard OpenTripModel (OTM) several years ago. In this article, I’ll explain why this was such an important step and why OTM will play an important role in further optimizing and automating logistics processes. I’ll also explain why I think we’ll see more and more parties implementing OTM in their product in the near future. But let’s start with a very short history of OTM.
The beginning of OpenTripModel
Not long after Simacan was founded, we built the first version of the Simacan Control Tower. We built it for a single retailer, but already with the idea in mind to use it for other retailers as well in the future. That retailer worked with several different transportation companies. To be able to monitor the logistics operation, we had to make connections to the Transport Management Systems of those transportation companies.
We defined an XML-based data format that we shared with the IT departments of those transportation companies. Although the model wasn’t exactly open at that time, we now consider this the very first version of OpenTripModel.
Later, when more customers came and we had to make more integrations, some parties asked us: “why should we adhere to your data model?” A fair question, that made us think. What if we used a real standard as data format? Then we wouldn’t get that question, or at least less often. This was around the time that I joined Simacan and creating OpenTripModel 4.0 was one of the first projects I worked on. Although the version was already at 4.0, this was the first version that was to be really open.
Before we started to think about how the standard should work, we set out some guiding principles. We decided the new standard should be simple, flexible and scalable. Of course, it is impossible to have maximum flexibility, simplicity and scalability at the same time. This is perfectly illustrated by this figure:
So we decided we should try to balance between the three. Until then, we had a fairly traditional, XML based, hierarchical data model. If you have experience with such a model, you know that those are certainly not flexible and tend to get complex pretty quickly. So we decided to go for another approach.
We had several brainstorming sessions, and I spoke to various stakeholders. It turned out that the domain we were modelling had a lot of events in it. So, apart from changing from XML to JSON, we decided to create an event based model. We defined a small set of entities and a lot of events. Those events could happen on a single entity, but a lot of events were associative, that means they associated two (or more) entities with each other. A nice example is the loading of a shipment into a vehicle. That event associates the shipment with the vehicle.
The resulting model, called OpenTripModel 4.0 was very flexible and -in our opinion at that moment- simple enough.
Transfer of ownership
Another thing we realised when we started with OpenTripModel 4.0, was that for it to become a real standard, we had to relinquish the ownership of the standard. We didn’t want anyone to be held back of using OpenTripModel, because it was owned by a commercial company, that might e.g. be a competitor of them. So we sought for a solution and found Stichting Uniforme Transportcode (SUTC). They already took care of some relevant standards in the transportation domain. And they were more than happy to take ownership of OpenTripModel. On July 4th, 2018, ownership of OpenTripModel was transferred to SUTC. But our involvement with the standard didn’t stop there.
While we were eating our own dogfood and were implementing OTM 4 on our platform, more and more clients and partners of ours were starting to work with it. Among them were early adopters TANS and FiLogic. We got a lot of feedback. We discovered that, while we thought OTM 4 was ‘simple enough’, some parties had a hard time implementing it. Main reason was that many IT systems that were already around for some time, weren’t suited to use an event based standard. For example, planning systems typically work batch oriented. They calculate the planning for a specific day, and when the planning changes, they just send a complete new planning again. Furthermore, we ourselves also experienced that we needed better ways to model the reality. It turns out that some things belong together in reality, that we weren’t able to group together in the model.
We tried to accommodate for these use cases and added some more extras. This lead to OTM versions 4.1 and 4.2. But soon we realized that we needed to make some more fundamental changes to the model, to find a better balance between flexibility and simplicity. More specific, to make the standard simpler for the majority of use cases. This is what lead to the creation of OpenTripModel 5.0.
At the moment of this writing, OTM 5 is still in bèta. Most structural changes are decided on, but a lot of details have to be worked out. OTM 5 keeps the JSON entities, but has easier ways to associate entities with each other. It is now possible to create a hierarchical structure when needed, by using associations. But it’s also still possible to use simple, unassociated entities. We still aim to get a good balance between simplicity, flexibility and scalability. But we have added to our goals that we want to keep the simple use cases simple, while leaving room for complex use cases.
Beyond OTM 5.0
Since the ownership of OTM is transferred to SUTC, a working group is formed under their responsibility. Of course, Simacan is represented in the working group. But many other IT companies and organisations from the logistics and transportation domain are represented as well, such as TANS, FiLogic, U-turn, Rainbow Solutions, Prometheus, TLN and Evofenedex. The SUTC working group is leading the process towards the final release of OTM 5.0. And there’s already a list of functional use cases we want to make possible in future versions of OTM.
At Simacan, we are still committed to OTM. We believe that an open standard is a win for everyone. The more companies implement it, the higher the chance that you can make an integration between companies without having to implement a new data format. It might seem counterintuitive that we donate our work on OTM to an open community. We lose total control of the standard and it is not unlikely that competitors will benefit from the standard. We believe that by supporting an open standard, we help in creating a bigger cake, instead of trying to maximize our piece of a smaller cake.
In conclusion: OTM has grown towards an open standard, that is flexible and easy to implement. Ownership and governance is in good hands at SUTC and there is a growing community of organisations supporting further development.
Manager Product Engineering @ Simacan