Discussion

By James Harvey on Jun 20, 2011

Dear Bryan:

I enjoyed your article; excellent insight. I’d add that two success factors for printers to consider that I’ve learned from talking to printers, case studies and discussions at the Automate Solutions Network. Firstly, regardless of whether you’re using internal or external resources for integration, each printer will have to act as their own project manager. The simple truth is that any collection of supporting vendors is not likely to self-organize, regardless of their best intentions. Someone has to get them in to room together, set schedules, milestones and acceptance criteria, and ensure that any assumptions made about workflow align with your expectations and requirements. The second but most important factor is making sure that you have C-level support within your own company. When you automate you are not just replacing a piece of equipment with a better, newer model, you are changing how your company operates and its culture. If you are not the boss, you need the boss to have your back, both to ensure that the vision of where the company is going is consistent, and to thwart any staff or vendors who decide to resist and take their complaints to the boss. If you have those two things, then the rest gets a whole lot easier.

I also would offer a note of caution. You point out that using unstructured XML is popular, and in some areas, such as web-to-print, it’s used in the majority of cases. The motivation is that the cost and complexity of the initial installation can be lower, but this is a false savings. As you modify your system by extending your integration to more departments and devices or by adding features and function, you will find yourself paying over and over again to have work already completed modified or redone completely. That’s the fundamental value of JDF … the industry has gone through great effort and expense to define an interface language that can be applied to all devices and all workflows … so when you integrate device A and device B using JDF and JMF, you don’t have worry that when you add device C you are going to revise the work you’ve already done. Although partial integration has its ROI, the big payoff is when everything is integrated and you have the power to get direct job costing and status data, automatically construct estimates and reports, do job planning and scheduling all from one console and allowing one person to do the job of four. That’s were a lot of printers want to go, but you’ll find the road to be a long one if you use unstructured metadata.

-- Jim

By PATRICK CAHUET on Jun 21, 2011

I fully agree with Jim's comments.
I can add my personal experience on integration of a Web To Print solution with a MIS in order to manage digital and offset printing.
The starting point was a cheap XML development. After a couple of meetings with the MIS and the W2P vendors it became very clear that an XML development might lead to a dead end:
1- what would happen when the MIS or the W2P solution is ugraded?
2. what would happen when one of these 2 has to be changed,
3. who will manage the creation of new specifications ?
As a result, we all decided to go for a JDF Product Intent development.
There are plenty of avantages in this open solution:
1. W2P vendor can use this functionality to adress other MIS
2. MIS vendor can get datas from other W2P solutions
3. Development costs can be shared

As a conclusion, I would give this last advise:
Always use JDF when it's possible to link devices together. Home made developments will always be more complicated to set up and more expensive than what they seem. DO not try to invent languages that already exist!

By Chuck Gehman on Jun 21, 2011

Bryan, great piece. Good comments, too.

JDF is great and it becomes more and more valuable as contributors improve it and vendors and users implement it.

Let's not lose sight of the fact that it is an industry-specific XML specification. It's not for everything. There are many other valuable integration touch points inside and outside the plant that JDF can't address.

Important points to remember:

1) Non-JDF does not mean "home-made"

2) "Home-made" does not mean more complicated and expensive in every case. There are plenty of printing companies with great programmers and great project management on staff, who can implement solutions as well or better than vendors

3) JDF is not "plug-and-play" in many circumstances that I have seen, but it is can be relatively "easy"

4) Bryan didn't mention "unstructured XML", I went back and read his piece over again and I don't see that. He said "XML in general, from which JDF and JMF are derived", which means all non-JDF XML-- in other words, the whole world of XML that isn't narrowly focused on the printing industry's applications. "Other than JDF" does not mean unstructured.

Finally, few customers of printing companies use JDF, so there has to be another way to integrate with them. Some other "flavor of XML" may very well fit the bill.

By Bryan Yeager on Jun 21, 2011

Everyone, thanks for your comments. Jim, those are two great additional points you bring up regarding integration. Patrick, thanks for sharing your personal experience and advice.

Chuck, thanks for referencing my original comments. My experiences seem to mimic yours. When I speak with vendors and printers alike, the message I keep getting about JDF is that there are many "flavors" of JDF; the "plug-and-play" vision of JDF and JMF is what everyone should be aiming for, although I find it hard to find examples of where it actually happens.

Additionally, as printers diversify the services they offer, they need to manage information flows that may fall outside of print. That's really where XML comes into play. So long as there a defined schema that is adhered to within the organization, systems can be integrated and information can flow as seamlessly as need be.