De zonnige toekomst van het OpenTripModel

Een aantal jaar geleden is Simacan gestart met het ontwikkelen van de open standaard OpenTripModel (OTM). In dit artikel leg ik je uit waarom dit een belangrijke stap was en waarom OTM een belangrijke rol zal spelen in het verder optimaliseren en automatiseren van logistieke processen. Ik leg ook uit waarom ik denk dat meer partijen in de nabije toekomst OTM zullen implementeren in hun product. Maar laten we beginnen met een korte geschiedenis van OTM.

De begindagen van OpenTripModel

Niet lang na de oprichting van Simacan bouwden we de eerste versie van de Simacan Control Tower. We bouwden het voor één winkelketen, maar hielden er al rekening mee dat we het voor meerdere winkelketens zouden kunnen gebruiken in de toekomst. Die winkelketen werkte met verschillende transportbedrijven. Om hun logistieke proces te kunnen monitoren, moesten we de Transport Management Systemen van al die transportbedrijven aansluiten.

We definieerden een XML-dataformaat en deelden dat met de IT-afdelingen van die transportbedrijven. We beschouwen dit als de eerste versie van OpenTripModel, ook al was het model op dat moment nog niet echt “open”.

Toen we, in een later stadium, meer en meer klanten kregen en er dus meer integraties gemaakt moesten worden, kregen we de vraag: “waarom zouden we ons moeten conformeren aan jullie datamodel?”. Een terechte vraag, die ons aan het denken zette. Stel nou dat we een echte standaard zouden gebruiken als dataformaat? Dan hadden we die vraag niet gehad. Ongeveer op dat moment kwam ik bij Simacan werken. Het maken van OpenTripModel 4.0 was een van de eerste projecten waar ik aan werkte. Hoewel het versienummer dus al 4.0 was, was dit de eerste versie die echt open was.
Voordat we gingen nadenken over hoe de standaard in elkaar moest zitten, stelden we een aantal basisprincipes op. We besloten dat de nieuwe standaard eenvoudig, flexibel en schaalbaar moet zijn. Het is natuurlijk onmogelijk om tegelijkertijd zo flexibel, eenvoudig en schaalbaar mogelijk te zijn. Dit wordt duidelijk weergegeven in dit diagram:

We besloten te zoeken naar een balans tussen deze drie. Tot dan toe hadden we een tamelijk traditioneel, hiërarchisch XML-datamodel. Als je wel eens met zo’n soort model gewerkt hebt, weet je dat dit soort modellen zeker niet flexibel zijn en al snel complex worden. Dus kozen we een andere benadering.

We hielden brainstormsessies en spraken met belanghebbenden. Het bleek dat het domein dat we gingen modelleren veel events bevatte. Daarom besloten we niet alleen XML te verruilen voor JSON, maar ook om een event-gebaseerd model te maken. We definieerden een aantal entities en events. De events konden op een enkele entity plaatsvinden. Maar veel events waren associatief, wat betekent dat ze twee (of meer) entities met elkaar verbinden. Een mooi voorbeeld is het laden van een zending in een voertuig. Dat event associeert de zending met het voertuig.
Dit alles resulteerde in OpenTripModel 4.0, dat heel flexibel was en - in onze ogen op dat moment - simpel genoeg.

Overdracht van eigenaarschap

Toen we begonnen met OpenTripModel 4.0, realiseerden we ons ook wat anders: om te zorgen dat het een echte standaard zou worden, moesten we het eigenaarschap van de standaard loslaten. We wilden voorkomen dat men terughoudend zou zijn met het adopteren van OpenTripModel, omdat het eigendom was van een commercieel bedrijf, dat misschien wel als concurrent gezien kon worden. We vonden de Stichting Uniforme Transportcode (SUTC) bereid om het eigenaarschap van OpenTripModel op zich te nemen. SUTC had al enkele relevante standaarden rondom transport in beheer en OpenTripModel paste daar goed bij. Op 4 juli 2018 werd het eigenaarschap van OpenTripModel officieel overgedragen aan SUTC. Maar onze betrokkenheid bij de standaard stopte daarmee natuurlijk niet.

OTM 5.0

Uiteraard gingen we zelf ook aan de slag met het implementeren van OTM 4 op ons platform. En daardoor kwamen meer en meer van onze klanten en partners er ook mee in aanraking; onder wie early adopters TANS en FiLogic. We kregen veel feedback. We ontdekten dat, hoewel wij dachten dat OTM 4 ‘eenvoudig genoeg’ was, veel partijen het lastig vonden om te implementeren. De belangrijkste reden daarvoor was dat veel IT-systemen die ze al in gebruik hadden, niet geschikt waren om een event-based standaard te gebruiken. Planningsystemen werken bijvoorbeeld vaak batch-gewijs, ze berekenen de planning voor een bepaalde dag. Als deze planning wijzigt, sturen ze simpelweg een compleet nieuwe planning op. 
Daarnaast ontdekten we zelf ook dat we betere manieren nodig hadden om de werkelijkheid te modelleren. Het bleek dat sommige zaken die in de werkelijkheid bij elkaar horen, moeilijk te groeperen waren in het model.
We probeerden de standaard aan te passen voor deze gevallen en voegden ook hier en daar extra zaken toe. Zodoende ontstonden OTM versies 4.1 en 4.2. Maar al snel realiseerden we ons dat we een aantal meer fundamentele wijzigingen moesten gaan doorvoeren in het model, om een betere balans te kunnen vinden tussen flexibiliteit en eenvoud. We wilden de standaard eenvoudiger maken voor het merendeel van de use cases. Zo ontstond de noodzaak om OpenTripModel 5.0 te gaan ontwikkelen.
Op het moment van schrijven is OTM 5 nog in de bèta-fase. De meeste structurele wijzigingen hebben al vorm gekregen, maar veel details moeten nog worden uitgewerkt. De JSON-entities zijn behouden in OTM 5, maar het is makkelijker geworden om associaties te maken tussen die entities. Het is nu mogelijk om een hiërarchische structuur te maken als dat nodig is, door gebruik te maken van associaties. Maar je kan ook nog steeds niet-geassocieerde entities gebruiken. We mikken nog steeds op een goede balans tussen eenvoud, flexibiliteit en schaalbaarheid. Maar we hebben nu als doel toegevoegd om simpele casussen zo simpel mogelijk te kunnen modelleren, terwijl er ruimte blijft voor het modelleren van complexere casussen.

Wat komt er na OTM 5.0?

Na de overdracht van de standaard aan SUTC, hebben zij een werkgroep samengesteld. Uiteraard is Simacan ook vertegenwoordigd in die werkgroep. Daarnaast zijn verschillende bedrijven en organisaties uit de wereld van logistiek en transport vertegenwoordigd, zoals TANS, FiLogic, U-turn, Rainbow Solutions, Prometheus, TLN en Evofenedex. De SUTC-werkgroep leidt het proces om tot een definitieve versie van OTM 5.0 te komen. En er is ook al een lijst gemaakt van use cases die de werkgroep in volgende versies van OTM mogelijk wil maken.
Bij Simacan staan we nog steeds vierkant achter OTM. We geloven dat een open standaard een win-win situatie creëert. Hoe meer bedrijven het implementeren, hoe groter de kans dat je een integratie kunt maken tussen bedrijven zonder een nieuw dataformaat te hoeven implementeren. Na al het werk dat we eraan gehad hebben, lijkt het misschien onlogisch dat we OTM doneren aan de gemeenschap. We hebben geen controle meer over de standaard en het is niet ondenkbaar dat concurrenten voordeel kunnen ondervinden van de standaard. Maar wij geloven dat we hierdoor helpen met het maken van een grotere taart, in plaats van te proberen ons stukje van een kleinere taart te maximaliseren.

Concluderend: OTM is gegroeid tot een open standaard, die flexibel is en gemakkelijk te implementeren. De standaard is bij de SUTC in goede handen. Een groeiende groep bedrijven en organisaties ondersteunt de verdere ontwikkeling.

Bart Kummel
Manager Product Engineering @ Simacan