During the last couple of months, as the work on Mission Control takes shape and many partners already have joined us in our efforts, and we’ve been asked repeatedly about Zaikio’s role in connectivity in general and also in regards to JDF.

But before we get to that, let’s start with a piece of history.

Print shops aren’t islands. And inside a single print shop, all the different departments and people aren’t islands either. This truth will become even more pronounced in the future. Printers will have to foster internal and external collaboration, team work, and streamlined, meaningful end-to-end processes to be successful.

When we started Keyline - our MIS product - six years ago, we build it in such a way that it connects to others through APIs. We did this more by accident than by strategic planning. The development tools we are using, the coding philosophies we follow and the software environment we grew up in, simply work that way. And we were rather surprised that it was pretty hard to find partners with whom we could easily and effortlessly connect. Even though JDF existed, there was no generalised way of information exchange.

The existing information exchange standards were documentation-only. Parts were open to interpretation, other parts were intentionally left open for “custom stuff”. Semantics were detailed, but data transmission was not. And there was no easy way to test your implementation with immediate feedback against other systems.

On top of that, all existing data exchange standards were super complex.

The scope of most existing software was on-premise deployments. This is nothing bad, and as I already said many times, there will always be software that has to run locally. However because of this locality, integration projects were also traditionally considered to be “local”. Integration was always about that one specific installation, but never for the whole industry at once.

This local scope also lead to the interesting situation that integration projects were driven by the end-customer. They had to apply time, resources ($$$) and frankly a huge amount of energy, to make it happen.

At first, this sounded a bit dire to us. But as we looked closer, we found many of the software products to be pretty good at their job. We also talked to a lot of machine vendors who had everything in their domain well under control: sensors, actors, controllers and so on. Also many suppliers had the IT infrastructure required to connect. The only missing piece was that clip that holds everything together. Thus we saw an opportunity to improve things and thought long and hard how a solution to the “connectivity problem” could look like.

Considering the reasons why JDF didn’t get widespread adoption, we assumed a successful approach would need to do the following, and really do it well:

Finally we figured that only a real product can be the solution for these challenges. A product is not a mere documentation of how data needs to be formatted (as opposed to a standard like JDF). A product provides you with documentation, well-defined semantics that have been created by a single authority, APIs that give you direct feedback if the data you send makes sense and most importantly: people that provide support and help for developers. And since those people are paid for what they do by the people who want to connect, you can expect them to perform well. You can also expect them to design an API and semantics that make sense. Because otherwise nobody is using the product and they’ll fail. So even though a central authority is now building the API which is great for speed and consistency (as opposed to JDF), that authority can’t just do their thing and lock someone out. In order to succeed commercially the API and data format must appeal to as many parties as possible. In our opinion this is a pretty strong self-correcting mechanism.

Taking all this into account we have so far build the Zaikio platform and the Mission Control data exchange as a service of the platform. Mission Control does exactly what we described above. Every printer has their own Mission Control workspace, and through well structured APIs third party software like shops, MIS/ERPs, production planners and schedulers, imposing software, prepress workflows and so on can exchange data. That data includes product specifications, meta data about print assets, commercial data like orders and payment, logistics information, calculations, shop floor data like jobs, tasks, required materials, schedules and so on. The important thing is that Mission Control doesn’t generate any of that data. It provides a central storage for it, and makes sure data is forwarded to whoever needs it, but it doesn’t create data by itself. It only becomes alive through the connections that other software makes to it.

Coming back to initial question, will Mission Control replace JDF? The answer is yes and no. In my opinion Mission Control is something completely different than JDF. One is a software product ready to use and the other one describes a data exchange format. Mission Control also defines such a format and that’s where the two overlap. But the rest of it: being a product, being an API, is something very different and not comparable. Thus I believe JDF will be around for a long time, and will perform it’s job in machine-to-machine connectivity quite well. Generally speaking however I believe platforms are the future, because they are a more complete package, and thus solve the problems outlined above. Problems that cannot be solved by a mere data exchange format alone.