By Jason Manosh and Chuck Gehman
Originally published in TAGA Proceedings 2002
Abstract
Supplier consolidation, budget cuts, and corporate e-procurement initiatives have emerged as a trend that even the smallest printer cannot afford to ignore. In order to remain competitive and continue to obtain business from both large and small corporations, printers must adopt new IT practices like Enterprise Application Integration (EAI.) EAI is a complex subject; there are dozens of books that address the need for EAI, and that discuss implementation strategies. This paper will focus on the small Print Shop (SPS) and its need for developing an EAI system to do business with corporate customers, despite the inherent challenges of a lack of IT resources at a typical SPS.
Definitions
We have defined the main terms used throughout this paper as follows:
EAI - "EAI is the unrestricted sharing of data and business processes throughout the networked applications or data sources in an organization." (eCRMguide.com, 2001)
SPS – Small Print Shop, an acronym we have created to use throughout this document, a sub $50m printing company.
BizTalk – A server-based software product from Microsoft Corporation that provides a low cost, accessible way for small business to implement EAI EDI - "Electronic Data Interchange (EDI) may be most easily understood as the replacement of paper-based purchase orders with electronic equivalents." (Clark, 1998)
XML – “The Extensible Markup Language (XML) is the universal format for structured documents and data on the Web.” (w3.org, 2002)
UN/EDIFACT (EDI for Administration Commerce and Transport) - “The only EDI standard that is truly accepted world-wide. EDIFACT provides standard formats for business documents and incorporates features that meet international requirements.” (SAA Consultants, 2000)
ANSI X12 – “The Accredited Standards Committee (ASC) X12 develops standards for cross-industry electronic exchange of business information.” (ASC X12, 2002)
*Printable Technologies, Inc.
Introduction
More than ever before, the systems at the SPS need to communicate, and integrate with, the systems of their corporate customers. Corporations who want to conduct substantially all of their purchasing via their own e-procurement systems, using software and services from e-procurement vendors (i.e., Ariba, SAP, PeopleSoft) are becoming more and more commonplace. These corporations are demanding that all of their vendors receive orders from these e-procurement systems, in lieu of the former practice of using faxed purchase orders and acknowledgements. This makes it critical for the SPS to obtain the ability to exchange the equivalent of these documents electronically with the corporate customer, or potentially lose the business to a more technically astute or larger competitor. This makes EAI a necessity for the SPS.
In addition, forward-looking SPS are now considering ways to leverage IT to create value-added services, increase their own profit margins, streamline order handling and decrease turnaround times. By using EAI, the SPS can work with their own suppliers more closely through information exchange, to communicate order information downstream to their distribution partners and shipping companies, and to seamlessly offer additional products and services (a very basic example would be promotional merchandise like Hats and Key Chains.)
Another trend that has started to become prevalent in the very large global corporation is the corporate document repository (i.e., Documentum,) which may contain tens of thousands of corporate documents. The SPS needs to interface seamlessly with these types of systems so they can perform functions like Print-On-Demand. The concept of printing “on-the-desk”, “down-the-hall”, or “down-the-street” has taken hold in corporate America, and these corporate customers want the flexibility of being able to choose output options and service providers with ease.
Finally, the same tools for EAI that provide for inter-enterprise data exchange, the most commonly addressed form of EAI, also provide interoperability between machines and other software systems within the SPS itself. For example, it is possible to use an EAI system to share JDF compliant documents from an ordering system (e.g., Printable) with a print management (or MIS) system (e.g., PrintCafe.)
The state of inter-enterprise document exchange today
For the most part, EAI has been out of reach for the average SPS to date. That does not mean that entrepreneurial small business owners have not found ways to accommodate requests from corporate customers for this type of functionality.
Some of the ways that small print shops have been solving these problems up until now has been a combination of EDI, and islands of web-based-systems. Neither EDI nor the web based systems in and of themselves accomplish the goal of implementing a flexible EAI system.
EDI is a powerful tool, and the introduction of the Society for Worldwide Interbank Financial Telecommunication (SWIFT) messaging system in 1973 was nothing short of revolutionary. SWIFT is responsible for “creating a shared worldwide data processing and communications link and a common language for international financial transactions.” (S.W.I.F.T., 2002) Since that historic initiative, most large corporations have required their major vendors to participate in their own or industry-sponsored EDI initiatives. However, EDI is a legacy technology, developed when many of the capabilities we have today were simply not possible.
Obviously, the interactive Web has also changed the way people do business. Nevertheless, these days, simply typing an order into a Web Site no longer fits the corporate customer’s idea of "integration". Closer integration and exchange of database information and documents is required. In addition, corporations require the ability to track, report and data mine the relevant data acquired with these exchanges.
The majority of SPS use off-the-shelf software to run their businesses. These applications perform tasks like simple estimating, accounting and shop floor management. Since most SPS do not have strong internal IT staff, developing custom systems to integrate with corporate EDI-based systems is out of reach for most SPS, both monetarily and because of skill sets.
XML and Interoperability
EDI overcame some major hurdles in the quest for inter-enterprise data exchange. However, EDI documents are based on a “punch card” like format, providing no flexibility for the new kinds of information that are being transmitted today, and the unknown but undoubtedly rich data formats of tomorrow. The computer and software industry is addressing these shortcomings by the development and widespread application of XML formats and technologies. Figure 1 is an example of an EDI document format, showing the limitations of the use of such formats.
Figure 1: This is an example of the X12-850 document format an EDI purchase order.
XML addresses many interoperability issues between disparate systems, but XML documents can also be very complicated. Both XML and EDI is machine generated. The big difference between EDI and XML is the explosion of support for XML standards, and specifications. There are also many tools widely available to create, read, and exchange XML compliant documents.
Figure 2: This is an example of an XML compliant document.
Integration Opportunities
It is surprising that today, with the level of general excitement in the computer and software industry about XML, the most prevalent format for inter-enterprise document exchange is still EDI, both in corporate America, and, in fact, worldwide. According to one source, “Ninety percent of U.S. Fortune 500 companies use UN/EDIFACT or X12 solutions, with similar adoption levels in Europe. Roughly only six percent of all other companies in the world are EDI enabled.” (Vasters, 2001) However, more modern e-procurement systems are making inroads. These are systems like Ariba, Commerce One, PeopleSoft, and SAP.
This underscores the opportunity for the SPS to develop a flexible EAI system. Not only are EAI systems an opportunity to increase revenue, but they will allow the SPS to remain competitive in the emerging technology-oriented corporate marketplace. More and more corporations will implement e-procurement systems to do their purchasing with both their large and small vendors. Without support for EAI, the SPS will be at huge disadvantage by not being able to “electronically” accept orders and exchange information with corporate customers.
Here are few examples of some relatively simple integration points:
§ Purchase Orders
§ Purchase Order Acknowledgement
§ Shipping Acknowledgement
These are the lowest common denominator of document types, which, corporate customers will seek to exchange electronically with vendors. This is the initial level of integration that the SPS should target. Being able to exchange this information electronically will allow the SPS to level the playing field with larger suppliers’ initiatives to serve corporate e-procurement needs.
Data Mapping
The information that needs to be exchanged is typically already stored in a database of some sort at the SPS (i.e., an inventory system, an accounting program, or a simple flat file database application like FileMakerPro,) and similarly, in an enterprise system at the corporate customer. The SPS could attempt to store their data in the same format as their large corporate customer, so they could provide their customer with, for example, updated shipping data using a technology like Open Database Connectivity (ODBC,) “A widely accepted application programming interface (API) for database access.” (Microsoft, 1999) This technique will not scale, however, because once the SPS obtains another large corporate customer who wants to do the same sort of inter-enterprise exchange, that customer will come with his or her own unique database structure and requirements. The SPS would then have to modify their existing database to meet the needs of their new customer, or worse yet, create a new database, and modify their online ordering system for the new corporate customer.
It is evident that this would be an unrealistic goal for the SPS, considering IT resources are most likely very limited. The SPS needs a way to translate data stored in their own ordering system to the multitude of e-procurement initiatives on the market today. This is called Data Mapping. Flexibility in Data Mapping is extremely important to consider when creating an EAI system.
Figure 3: Information from the SPS database needs to be entered into the corporate customer’s e-procurement system
By using Data Mapping in an EAI system, we are able to seamlessly and with minimal (or no) human intervention, transfer information from our database to our corporate customer’s database, and vice-versa.
Example
A corporate purchaser logs into an internal intranet purchasing system and places an order for business cards. The information (in the form of an electronic Purchase Order) is transmitted to the SPS’s online ordering system (along with the metadata for the business card), where the order goes into production.
Once the SPS accepts the order, an acknowledgement fires-off back to the corporate e-procurement system in an agreed-upon format (i.e., ANSI X12.)
Finally, after the order ships the SPS system sends a message (again, in an agreed-upon format) back to the corporate e-procurement system so that payment to the SPS can be processed.
Figure 4: Example of EAI in process: a corporate Intranet, showing Ariba catalog interface, and Printable catalog order in progress
This is made possible because the SPS in this case has implemented a flexible EAI system. Once the EAI system is in place, the SPS needs to work closely with their corporate customer’s IT department to arrive at a format that they can accept (in the previous example, cXML was used, because of the corporate user’s choice of the Ariba Network.) ANSI X12, a comma separated flat-file or XML may also be required; therefore, flexibility and support of multiple formats is key. Table 1 shows some of the common industry-standard document formats that SPS can use for communication with corporate customers using an EAI system.
| Document Format | Description | Used By |
| PIPs - RosettaNet Partner Interface Processes™ (PIPs®) | Defines business processes between trading partners. (2002, RosettaNet) | RosettaNet |
| cXML - Commerce XML | cXML is a streamlined protocol intended for consistent communication of business documents between procurement applications, e-commerce hubs, and suppliers. (2002, Commerce XML) | Ariba, Clarus, VerticalNet, others… |
| CBL - Common Business Library (a.k.a., xCBL) | A set of XML data tag definitions and schema language framework designed to extend the usability of XML in e-commerce. (2002, Commerce One) | Commerce One, SAP |
| JDF – Job Definition Format | JDF is a comprehensive XML-based file format/proposed industry standard for end-to-end job ticket specifications combined with a message description standard and message interchange protocol. (2002, CIP4)
| Hewlett Packard, Xerox, Heidelberger Druckmaschinen AG, others… |
| PrintTalk | PrintTalk defines the communication between print management systems and e-commerce applications. PrintTalk supports the JDF standard. | Printable Technologies, Heidelberg USA, others… |
| PML – PaperHub Markup Language | PML is a new protocol for Internet-based commerce between buyers and sellers of paper and printing products. (2001, XML.org/Zap Think) | Appleton Papers, others… |
| PDML – Product Data Markup Language | Product Data Markup Language (PDML) is an Extensible Markup Language (XML) vocabulary designed to support the interchange of product information among commercial systems (such as PDM systems) or government systems. (2001, XML.org/Zap Think) | Boeing, Lockheed Martin, General Motors, others… |
| CSV – Comma Separated Values | A record layout that separates data fields with a comma and usually surrounds character data with quotes. (2002, Atomica) | Microsoft Outlook, Excel, many others… |
| EDI FACT - EDI for Administration Commerce and Transport | The only EDI standard that is truly accepted worldwide. EDIFACT provides standard formats for business documents and incorporates features that meet international requirements.” (SAA Consultants, 2000) | SmartWorks, United Nations, many others… |
Table 1: Some common document formats for inter-enterprise exchange.
Messaging
Once the SPS configures the EAI system to map data to the corporate customer’s format, then the two companies need to agree on a messaging methodology. This requires technical specification of both how and when the SPS and corporate customer will exchange the data.
Using bidirectional messaging, either party could initiate a transaction. An example would be Ariba sending user validation information to the SPS online ordering system. The SPS EAI system would then send cXML to integrate with the Ariba shopping cart system.
It is possible that only one party will initiate transactions, and that information will travel in only one direction. For example, the SPS online ordering system sending their corporate customer a shipping acknowledgement in XML. It is important to note that with EDI, you typically have a precisely scheduled delivery time, or more specifically, an exact date and time. For example, a corporate customer may only allow exchange of X12 850 documents from SPS at 10:00 p.m. on the 28th of each month.
With legacy EDI systems, the aforementioned scheduled (or synchronous) document exchange was commonplace. Today the trend is toward the real-time asynchronous exchange of documents, so systems on both sides of the transaction have the most up-to-date information possible. Therefore, an EAI system implemented by the SPS needs to guarantee the delivery of all data in real-time. In addition, with the goal of no human intervention, this process should be automated using software that provides an Asynchronous Message Queue (i.e., MSMQ: Microsoft Messaging Queue.) Table 2 shows the most common communication protocols that the SPS EAI system should support
| Protocol | Description | Purpose | Suitability |
| FTP | File Transfer Protocol | Binary or ASCII file exchange | Good for Batch Transfers |
| HTTP | Hypertext Transfer Protocol | Internet Standard for non-secure transfer of Data | Basic exchange over the Web |
| HTTPS | Hypertext Transfer Protocol – Secure | Internet standard for secure transfer of data using encryption | Secure exchange over Web |
| SMTP | Simple Mail Transfer Protocol | Standard for sending email messages | Email Exchange |
Table 2: Common communication Protocols for EAI
Most IT professionals are familiar with these protocols and use them on a daily basis. The most important thing for the SPS to consider in selecting a messaging protocol for EAI is, “What does my corporate customer want me to use?” Therefore, we once again stress the utmost importance of flexibility.
Implementations
It is apparent that EAI is a very technical topic, but it does involve business development as well. To make EAI happen at the SPS, there has to be buy-in from upper management. That is because there are numerous costs involved in implementing such a system.
We have seen that the corporate customer typically drives EAI. Let us take for example, participation in the Ariba supplier network. In order for a SPS to receive orders from a corporate customer, using the Ariba network, the SPS needs to be certified “Ariba® Ready™.” Ariba® Ready™ is an “Ariba initiative to provide a special designation for suppliers who have demonstrated the ability to effectively transact with and provide content to organizations using Ariba® Buyer™ over Ariba® Supplier Network™.” (Ariba Inc., 2002) This will require high level interfacing between SPS management and Ariba’s staff.
The SPS will also need access to technical expertise in the EAI platform they are planning to use. For the purpose of this paper, we will use Microsoft BizTalk as an example of an EAI platform. Microsoft BizTalk is a good example because it represents a solution, which is relatively low cost, and suitable for use by the SPS. However, it may still be difficult to find expertise with this type of implementation, because this is an emerging technology.
Microsoft BizTalk Server 2000
The BizTalk platform costs a relatively small amount of money, and provides a lot of flexibility for the SPS to integrate with multiple e-procurement and other types of systems. In addition, it is possible to use BizTalk to support printing industry specific XML formats (i.e., CIP4, JDF, and PrintTalk.) Those specific implementations are beyond the scope of this paper.
BizTalk Server requires the aforementioned technical expertise to install, but is simpler than most other EAI products. For example, BizTalk provides the BizTalk Orchestration Designer “A design tool used to create drawings that describe long running, loosely coupled, executable business processes. The XLANG schedule drawing is compiled into an XLANG schedule that is used to execute the automated business process.” (Microsoft, 2002) The output of the BizTalk Orchestration Designer is XLANG, which according to Microsoft is “a language that describes the logical sequencing of business processes, as well as the implementation of the business process by using various application services.” (Microsoft, 2002)
Figure 5: An example of an XLANG Schedule Drawing created with BizTalk Orchestration Designer
There are also many third-party add-on software products for BizTalk available today, including special adapters, XML formats, and many other enhancements. There are numerous books available on the subject of BizTalk, which go far beyond the scope of this paper. To learn more about Microsoft BizTalk, visit www.biztalk.org. “The goal of BizTalk.org is to provide resources for learning about and using Extensible Markup Language (XML) for Enterprise Application Integration (EAI) and business-to-business (B2B) document exchange, both within the enterprise and over the Internet.” (Microsoft, 2002)
Case Study
ABC Print is a small privately owned SPS who recently established a relationship with a Fortune 500 company, XYZ Corporation. ABC Print agreed to provide stationary at a substantially lower price than the competitors did.
There was one big challenge in winning this account: although XYZ Corporation wanted to use ABC Print for their stationery, XYZ Corporation only purchased items using their own e-procurement system.
ABC Print decided to implement an EAI system that was powerful enough to handle this complex relationship, and flexible enough to open the door to new relationships with other Fortune 500 companies. After much thought, the IT department at ABC Print decided to implement the following workflow using an off-the-shelf EAI solution:
- When XYZ Corporation updates the design of their business cards, they populate the changes to their own e-procurement system and forward the changes on to ABC Print. After reviewing the updates to the business cards, ABC Print posts the new information on their online ordering system.
- When a purchasing agent from XYZ Corporation places an order for business cards, the e-procurement system externalizes the Purchase Order in X12-850 format, and places the EDI document in ABC Print’s FTP server.
Figure 6: Graphical Depiction of the Translation (mapping) of an XML document to an EDI document
- When ABC Print receives the X12-850 document in their inbox (scheduled delivery, every 2 hours), the document is converted from X12-850 to XML with their EAI system, and sent to their ordering system.
- ABC Print’s ordering system sends a response to the EAI system accepting the Purchase Order, which is then externalized in X12-855 format.
- Once ABC Print delivers the order, a notice is sent to ABC Print’s EAI system, which externalizes a document in X12-856 format and sends it to XYZ Corporation’s FTP server where it is processed by their e-procurement system.
Conclusion
There will come a time when small printing companies that do not have EAI capabilities will be left out of the corporate print spend. That time is fast approaching: with supplier consolidation, cost cutting, and layoffs prevalent in both the current economic downturn and the continued conservative spending likely to follow during an extended recover period, EAI with suppliers is high on the priority list of many corporations – not just for print, but for all procurement. Therefore, to remain competitive, EAI is a necessity for small and large printers alike. Fortunately, the range of affordable options and the ease of implementing these types of systems have never been better.
References
eCRMGuide.com: 2001, “The Definitive Source for Customer Relationship Management Technology”, www.ecrmguide.com
Microsoft Corporation:
2002, “Microsoft BizTalk Server 2000 - EAI Made Easy”,
http://www.microsoft.com/biztalk/evaluation/overview/
2002, “Getting Started with Microsoft BizTalk Server 2000”,
http://microsoft.com/technet/prodtechnol/biztalk/proddocs/btsdocs/
1999, “Microsoft Universal Data Access Web Site”,
http://www.microsoft.com/data/odbc/
Roger Clark: 1998, “Electronic Data Interchange (EDI): An Introduction”, www.anu.edu.au
SAA Consultants Ltd.: 2000, “EDI Resources”, www.reims.net
The Accredited Standards Committee (ASC) X12: 2002, “Developing Cross-Industry Standards”, www.x12.org
S.W.I.F.T.: 2002, “SWIFT History”, www.swift.com
World Wide Web Consortium: 2002, “Extensible Markup Language (XML)”, www.w3.org
Ariba Inc.: 2002, “Ariba Ready”, www.ariba.com
RosettaNet: 2002, “PIP FAQ”, www.rosettanet.org
Commerce XML: 2002, “cXML FAQ”, www.cxml.org
CIP4: 2002, “Information about JDF”, www.cip4.org
XML.org/ZapThink: 2001, “XML Standard Reports”, www.zapthink.com
Atomica: 2002, “One source for integrated answers on demand”, www.guru.net
