Während der letzten Monate, in denen  Mission Control immer mehr Gestalt annahm und sich bereits viele Partner unserer Vision angeschlossen haben, wurden wir immer wieder auf die Rolle von Zaikio in der Konnektivität im Allgemeinen und auch in Bezug auf JDF angesprochen. Bevor wir aber dazu kommen, erstmal ein kurzer Rückblick. 

Druckereien sind keine Inseln. Auch innerhalb einer Druckerei sind die verschiedenen Abteilungen und Menschen keine Inseln. Das war immer schon so und wird in Zukunft noch viel mehr so sein. Um erfolgreich zu sein, müssen Druckereien daher die interne und externe Zusammenarbeit  durch schlanke End-to-End Prozesse fördern, weil nunmal alles miteinander zusammenhängt.

Als wir vor sechs Jahren mit der Entwicklung von Keyline – unserem MIS-Produkt – begannen, haben wir es so aufgebaut, dass es sich über APIs mit anderen verbinden kann. Dies geschah mehr durch Zufall als durch strategische Planung. Die Entwicklungstools, die wir verwenden, die Entwicklungsphilosophie der wir folgen, und die Software-Umgebung, in der wir aufgewachsen sind, funktionieren einfach so. Wir waren sehr überrascht, dass es schwer war, Partner zu finden, mit denen wir uns einfach und mühelos verbinden konnten. Obwohl JDF existierte, gab es keine standardisierte Art des Informationsaustauschs.

Die bestehenden Standards für den Austausch entsprachen lediglich einer Dokumentation. Teile davon waren immer noch offen für Interpretationen, andere Teile wurden absichtlich für "kundenspezifische Dinge" offen gelassen. Die Semantik war detailliert, aber die Datenübertragung war es nicht. Hinzu kam, dass es keine einfache Möglichkeit gab, die Implementierung mit sofortigem Feedback gegen andere Systeme zu testen. 

Die meisten bestehenden Software auf dem Markt waren On-Premise Systeme. Das ist nichts Schlechtes, und wie ich schon oft gesagt habe, wird es immer Software geben, die lokal laufen muss. Aufgrund dieser Lokalität wurden jedoch Integrationsprojekte traditionell auch als "lokal" betrachtet. Bei einer Integration ging es immer um diese eine spezifische Installation, aber nie um die gesamte Branche auf einmal.

Dieser lokale Umfang führte auch zu der interessanten Situation, dass Integrationsprojekte vom Endkunden vorangetrieben wurden. Sie mussten Zeit, Ressourcen aller Art und offen gesagt eine enorme Menge an Kraft aufwenden, um sie zu realisieren. 

Diese Aufgabenverteilung klang für uns zunächst ein wenig bedenklich. Aber als wir genauer hinsahen, stellten wir fest, dass viele der Softwareprodukte ihre Aufgabe sehr gut machen. Wir sprachen auch mit vielen Maschinenherstellern, die in ihrem Aufgabengebiet alles unter Kontrolle hatten: Sensoren, Aktoren, Steuerungen und so weiter. Die meisten Anbieter verfügten auch über die notwendige IT-Infrastruktur für die Anbindung. Das einzig fehlende Stück war die Klammer, die alles zusammenhält. So sahen wir eine Chance, die Dinge zu verbessern und überlegten lange, wie eine Lösung für das "Konnektivitätsproblem" aussehen könnte. 

Im Hinblick auf JDF und die Gründe, warum es immer noch Probleme bei Integrationsprojekten gibt, mussten wir mehrere Sachen beachten und diese auch perfekt umsetzen:

Schließlich kamen wir zu dem Schluss, dass nur ein echtes Produkt die Lösung für diese Herausforderungen sein kann. Ein Produkt ist nicht nur eine Dokumentation über das Format der Daten (vergleichbar mit einem Standard wie JDF). Ein Produkt bietet:

Da diese Menschen von den Nutzern bezahlt werden, können Marktteilnehmer eine hohe Qualität erwarten. Gleichzeitig können sie mit einer sinnhaften und auf den Markt abgestimmten API und Semantik rechnen. Wäre das nicht der Fall, würde keiner dieses Produkt nutzen. 

Um es nochmals hervorzuheben: auch wenn eine zentrale Insatnz die API erstellt, was für die Geschwindigkeit und Konsistenz (im Gegensatz zu JDF) großartig wäre, kann diese Instanz nicht einfach ihr Ding machen und jemanden aussperren. Um kommerziell erfolgreich zu sein, müssen die API und das Datenformat so viele Parteien wie möglich ansprechen. Unserer Meinung nach ist dies ein ziemlich starker selbstkorrigierender Mechanismus und wird das Produkt sukzessiv verbessern. 

Unter Berücksichtigung des bereits beschriebenen haben wir bisher die Zaikio Plattform und den Mission Control-Datenaustausch als einen Service der Plattform aufgebaut. Mission Control macht genau das, was wir oben beschrieben haben. Jeder Anbieter hat seinen eigenen Mission Control-Arbeitsbereich. Über gut strukturierte APIs kann Software von Drittanbietern wie Shops, MIS/ERPs, Produktionsplaner und -steuerer, imposing software, Prepress-Workflows, usw., Daten austauschen. Zu diesen Daten gehören:

Wichtig ist zu verstehen, dass Mission Control keine dieser Daten selbstständig generiert. Es stellt einen zentralen Speicher zur Verfügung und sorgt dafür, dass die Daten an diejenigen weitergeleitet werden, die sie benötigen. Mission Control wird erst durch die Verbindungen mit weiterer Software lebendig. 

Um auf die Ausgangsfrage zurückzukommen, ob Mission Control JDF ersetzen wird – die Antwort ist ja und nein. Meiner Meinung nach ist Mission Control etwas völlig anderes als JDF. Das eine ist ein fertiges Softwareprodukt, wohingegen das andere ein Datenaustauschformat beschreibt. 

Mission Control definiert ebenfalls ein solches Format – hier überschneiden sich die beiden. Aber der Rest: ein Produkt zu sein, eine API zu sein, ist etwas ganz anderes und nicht vergleichbar. Daher glaube ich, dass es JDF noch lange geben wird, und dass es seine Aufgabe in der Verbindung von Maschinen gut erfüllen wird. Generell glaube ich aber, dass Plattformen die Zukunft sind, weil sie ein Gesamtpaket sind und damit die oben beschriebenen Probleme lösen. Probleme, die durch ein bloßes Datenaustauschformat allein nicht gelöst werden können.