Commentary & Analysis
Free Special: Print Management Focus: Definition of terms - Interface vs. Integration
Graph Expo next week will give us all an opportunity to look at a number of different management systems ranging from shop floor management to full enterprise information systems.
By Gail Nickel-Kailing
Published: October 4, 2002
Graph Expo next week will give us all an opportunity to look at a number of different management systems ranging from shop floor management to full enterprise information systems. In order to be fully prepared to discuss those management systems and how they work, now is a good time to look at the difference between application integration and application interfaces. They are indeed two different things.
After talking to a number of vendors, the consensus is that an interface is a clearly defined point where two applications transfer data from one to another, either in files or tables, while integrated applications share data in common databases.
The term we most often hear when discussing how applications communicate and work together is "integration." Integration involves an intimate knowledge of the applications that must work together because they must reach into the same database and share the same data. Most applications that are integrated are developed together, though a newly developed application may be integrated with a more mature application. More important is the depth of knowledge of the applications and a common shared data platform.
In most cases, the architecture involves a single relational database that houses all information about customers, jobs, and all activities in a common database structure. A truly integrated management system – whether it is end to end or a subset – passes information seamlessly through the whole system.
An interface is a point where data are transferred between applications and the data format is clearly defined. For example, if you are integrating a print management system from one vendor and an estimating system from another, the data are exported from the estimating system in a file format that would be consistent with the order entry system.
Those file structures can be flat files, comma-delimited files, or database tables. The data also generally go through a verification or certification step before they are loaded into the subsequent application to insure their usability by that application.
Interfacing with Third-Party Applications
The applications with which print management systems interface range across a number of solutions:
- Ariba and CommerceOne offer generic "buy side" applications to manage corporate procurement of all kinds of goods and services
- Major ERP systems such as those offered by Peoplesoft, Lawson, Oracle, and JD Edwards
- Ancillary systems such as shipping and tax calculation
- Payroll packages offered by Abbra, ADP and Ceridian
- Data collection systems from new, advanced presses
Data can be passed from one application to another in a number of different formats, however the critical issue is to insure that the data coming into the print management system is good data and will not cause anything to affect operational processes. Print management system vendors cannot risk bringing down their systems because of bad data.
An additional step needs to take place, because data cannot simply be taken from one application and automatically "fed" into another without being verified or qualified. Data can be extracted and verified on a transaction basis, on a timed batch basis, or based on an event. When dealing with legacy systems, installing a new application often involves a onetime transfer of data from the legacy system to help set up the new system.
In order to transfer information, the data must be fed in the same format needed by the subsequent application. For example, formats can include ASCII text-based flat files, comma-delimited files, database tables, EDI, ODBC, and others. One vendor I spoke to described 10 data formats that could be implemented "out of the box;" others described custom implementations depending on the formats in use at the customer’s site.
Challenges of Standards
Print management system vendors are chasing a moving target as JDF evolves. A number of the large database applications such as IBM RDBMS and Oracle have been adding XML capabilities for several years.
Because the final JDF standard has not yet been solidified, a number of vendors are taking two alternatives. One alternative is to implement the information transfer standards used by customers and prospects. The second is to simply wait until JDF is finally implemented and see what information everyone is going to expect as the norm.
One of the biggest challenges is not to develop standards, but to get them accepted and put into practice. Without standards, the vendor, the customer and any third party application provider must work through the semantics very carefully and thoroughly understand data elements and how they will be used by all applications.
Vendors must be willing to work together to interface and integrate applications, and open standards will facilitate that.
Enjoy Graph Expo next week. There are a number of print management information systems providers who will be exhibiting, including but not limited to those listed below.
Thanks to the folks representing the following companies for providing input for this piece: CRC Information Systems, Primac, Printable Technologies, Printcafe Software, Prism-USA, Radius Solutions, and unit inc.