Understanding Integration: Web to Print

Home / Web to Print / Understanding Integration: Web to Print

Understanding Integration: Web to Print

Integration might be the most overused and misunderstood word in technology today. There is a gigantic gap between what we want integration to mean (two systems acting as one) and what integration is in reality (sometimes as little as a few pieces of data passed in one direction at scheduled intervals).

Please don’t see a check box in a feature list that says, Yes we integrate and think your due diligence is complete. You have to dig a bit deeper, assume nothing, ask the questions provided below, and make sure you and the vendor are defining integration the same.

How can a better understanding of the topic of “integration” help you with your online print business and the connections between order entry, production management, and financial systems?

Lets skip over the technical jargon for now and talk about what you want to accomplish using a variety of technology solutions like web to print, pre-press management, production workflow, MIS, and financial systems. You might be saying, why isn’t there one system that just does it all so we don’t have to be bothered by the integration mess? The software industry has tried that and failed, bigger systems aren’t necessarily better and the larger the software system the more inflexible it tends to be.

I consider the business process of print along two parallel paths – one is all about production, the other is all about the business. The production path captures assets (files, graphics, fonts, etc…) and job instructions. While the business path tracks the use of supplies, labor, pricing, inventory, and everything about the financial transaction between the printer and the customer.

Web to print begins the workflow and captures a bit of information for both these paths – this makes the web to print system critical because it has to accurately capture the information and potentially pass it to multiple systems on the backend (if its deployed in a fully integrated workflow).

Remember data capture for the backend systems is the SECONDARY priority for web to print; the #1 priority for web to print is to provide a self service order entry tool for your customers. I’ve seen systems that are excellent at the data capture, excellent at the pass off to multiple systems, but they fail in the PRIMARY priority – customer’s tool for order entry. If your customers don’t use your web to print system, because it’s too hard or too complicated, nothing about the integration matters.

Integration is a connection between two systems, the systems will exchange data. The first question I ask in an integration setting is which system is the “master” and which system is the “subscriber” to that data? This is a common misperception with the Apple’s iTunes, iPod platform. Nearly every non-technical person in my life thought if they lost their iPod they lost all their music because they didn’t understand that the iTunes Library on the computer is the master and the iPod is merely a subscriber to that master.

In a print environment that has a functioning MIS system, I believe the MIS should be the master in virtually every case. The MIS system collects orders from everywhere (not just the web), therefore it makes sense that the MIS system would be the master and the web to print would push data into that system and subscribe to data stored and managed in that system (e.g. pricing). This is challenging for vendors because the web to print system and the MIS system are typically provided by different vendors.

Web to print is one of many inputs into a printer’s business and production workflow. You want web to print to serve its primary purpose – capture more orders, in a more efficient manner, and be a source of competitive advantage for your sales staff. The web to print system should then gracefully hand off to the production management systems and the financial systems so that an order from web to print is treated like any other order once it’s in production.

Here are some really good questions to ask about any integration project:

  1. What data needs to be shared between systems?
  2. Do both systems define the data the same? If not can you map the data between systems?
  3. How often is that data sharing required (from real-time all the way to monthly)?
  4. Does the data need to be one-direction or bi-directional?
  5. What is the preferred method or tool set (e.g. web services)?
  6. Does either system have a well defined API for this type of transfer?

Asking these questions and answering them honestly will help you control the scope of integration projects. Very few systems require real-time, bi-directional integration which happens to be the most complex and expensive. Don’t overlook the power of scheduled exports and imports – they frequently provide sufficient functionality and are almost free in most cases!


  1. Mike Caruso on September 3, 2010 at 11:26 am

    I think one more question to add to the list would be: “Is there an existing integration already completed or what have you previously integrated with before?”

    Nice job!

    Mike Caruso

  2. Jennifer Matt on September 7, 2010 at 12:25 pm


    I agree but I would just be careful to accept “yes” we integrate with that system. Don’t just ask that question because then you can get surprised by what the two vendors agreed upon was “integration”? An existing integration needs to be evaluated with the same scrutiny. What data, when, how, one direction or bi-directional.


Leave a Comment