Nicht lange nach der Gründung von Simacan haben wir die erste Version des Simacan Control Tower gebaut. Wir bauten ihn für einen einzelnen Einzelhändler, aber schon mit dem Gedanken, ihn in Zukunft auch für andere Einzelhändler zu verwenden. Dieser Einzelhändler arbeitete mit mehreren verschiedenen Transportunternehmen zusammen. Um die logistischen Abläufe überwachen zu können, mussten wir Verbindungen zu den Transportmanagementsystemen dieser Transportunternehmen herstellen.
Wir definierten ein XML-basiertes Datenformat, das wir mit den IT-Abteilungen dieser Verkehrsunternehmen teilten. Obwohl das Modell zu diesem Zeitpunkt nicht wirklich offen war, betrachten wir dies heute als die allererste Version von OpenTripModel.
Später, als mehr Kunden hinzukamen und wir mehr Integrationen vornehmen mussten, fragten uns einige Parteien: "Warum sollten wir uns an Ihr Datenmodell halten?" Eine berechtigte Frage, die uns zum Nachdenken brachte. Was wäre, wenn wir einen echten Standard als Datenformat verwenden würden? Dann würden wir diese Frage nicht oder zumindest seltener gestellt bekommen. Das war ungefähr zu der Zeit, als ich zu Simacan kam, und die Erstellung von OpenTripModel 4.0 war eines der ersten Projekte, an denen ich arbeitete. Obwohl die Version bereits bei 4.0 war, war dies die erste Version, die wirklich offen sein sollte.
Bevor wir uns Gedanken darüber machten, wie die Norm funktionieren sollte, legten wir einige Leitprinzipien fest. Wir beschlossen, dass die neue Norm einfach, flexibel und skalierbar sein sollte. Natürlich ist es unmöglich, maximale Flexibilität, Einfachheit und Skalierbarkeit gleichzeitig zu erreichen. Diese Abbildung verdeutlicht dies perfekt:
Also beschlossen wir, dass wir versuchen sollten, ein Gleichgewicht zwischen den drei Möglichkeiten zu finden. Bis dahin hatten wir ein ziemlich traditionelles, XML-basiertes, hierarchisches Datenmodell. Wenn Sie Erfahrung mit einem solchen Modell haben, wissen Sie, dass diese Modelle sicherlich nicht flexibel sind und dazu neigen, ziemlich schnell komplex zu werden. Also beschlossen wir, einen anderen Ansatz zu wählen.
Wir hatten mehrere Brainstorming-Sitzungen, und ich sprach mit verschiedenen Beteiligten. Es stellte sich heraus, dass der Bereich, den wir modellierten, eine Menge Ereignisse enthielt. Also beschlossen wir, nicht nur von XML auf JSON zu wechseln, sondern auch ein ereignisbasiertes Modell zu erstellen. Wir definierten eine kleine Gruppe von Entitäten und eine Menge von Ereignissen. Diese Ereignisse konnten sich auf eine einzelne Entität beziehen, aber viele Ereignisse waren assoziativ, d. h. sie verbanden zwei (oder mehr) Entitäten miteinander. Ein schönes Beispiel ist die Verladung einer Sendung in ein Fahrzeug. Dieses Ereignis assoziiert die Sendung mit dem Fahrzeug.
Das daraus resultierende Modell, das so genannte Open Trip Model 4.0, war sehr flexibel und - unserer damaligen Meinung nach - einfach genug.
Wir haben versucht, diese Anwendungsfälle zu berücksichtigen und einige weitere Extras hinzuzufügen. Dies führte zu den OTM-Versionen 4.1 und 4.2. Doch schon bald wurde uns klar, dass wir einige grundlegendere Änderungen an dem Modell vornehmen mussten, um ein besseres Gleichgewicht zwischen Flexibilität und Einfachheit zu finden. Genauer gesagt, um den Standard für die meisten Anwendungsfälle zu vereinfachen. Dies führte zur Entwicklung des Open Trip Model 5.0.
OTM 5 behält die JSON-Entitäten bei, bietet aber einfachere Möglichkeiten, Entitäten miteinander zu verknüpfen. Es ist jetzt möglich, bei Bedarf eine hierarchische Struktur zu erstellen, indem man Assoziationen verwendet. Es ist aber auch weiterhin möglich, einfache, nicht assoziierte Entitäten zu verwenden. Wir streben nach wie vor ein gutes Gleichgewicht zwischen Einfachheit, Flexibilität und Skalierbarkeit an. Aber wir haben zu unseren Zielen hinzugefügt, dass wir die einfachen Anwendungsfälle einfach halten wollen, während wir Raum für komplexe Anwendungsfälle lassen.
Da das Eigentum an OTM auf die SUTC übergeht, wird unter deren Verantwortung eine Arbeitsgruppe gebildet. Natürlich ist Simacan in der Arbeitsgruppe vertreten. Aber auch viele andere (niederländische) IT-Unternehmen und -Organisationen aus dem Logistik- und Transportbereich sind vertreten, wie TANS, FiLogic, U-turn, Rainbow Solutions, Prometheus, TLN und Evofenedex. Die SUTC-Arbeitsgruppe leitet den Prozess bis zur endgültigen Freigabe von OTM 5.0. Und es gibt bereits eine Liste von funktionalen Anwendungsfällen, die wir in zukünftigen Versionen von OTM ermöglichen wollen.
Bei Simacan setzen wir uns weiterhin für OTM ein. Wir glauben, dass ein offener Standard ein Gewinn für alle ist. Je mehr Unternehmen ihn implementieren, desto größer ist die Chance, dass eine Integration zwischen Unternehmen möglich ist, ohne ein neues Datenformat implementieren zu müssen. Es mag kontraintuitiv erscheinen, dass wir unsere Arbeit an OTM einer offenen Gemeinschaft zur Verfügung stellen. Wir verlieren die vollständige Kontrolle über den Standard, und es ist nicht unwahrscheinlich, dass Konkurrenten von dem Standard profitieren werden. Wir glauben, dass wir durch die Unterstützung eines offenen Standards dazu beitragen, einen größeren Kuchen zu schaffen, anstatt zu versuchen, unser Stück von einem kleineren Kuchen zu maximieren.
Simacan Leiter Produktentwicklung, Bart