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 Open Trip Model 4.0 was very flexible and -in our opinion at that moment- simple enough.
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 Open Trip Model 5.0.
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.
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 (Dutch) 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.
Simacan Manager Product Engineering, Bart