Best Practices and XML Content for Everywhere-to-Everywhereä Integration
OAGIS - A “Canonical” Business Language
Providing both Vertical and Horizontal Requirements
Open Applications Group, Incorporated
Document Number 20020429
Open Applications Group
The information contained in this document is subject to change without notice.
The material in this document is published by the Open Applications Group, Inc. for evaluation. Publication of this document does not represent a commitment to implement any portion of this specification in the products of the submitters.
While the information in this publication is believed to be accurate, open applications group, inc. makeS no warranty of any kind with REGARD to this material including but not limited to the implied warranties of merchant ability and fitness for a particular purpose. Open Applications Group, Inc. shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material.
This document contains proprietary information, which is protected by copyright. All Rights Reserved. No part of this work covered by copyright hereon may be reproduced or used in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems—without permission of the copyright owner.
Restricted Rights Legend. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.
Copyright ã 2002 by Open Applications Group, Incorporated
For more information, contact:
Open Applications Group, Inc.
1950 Spectrum Circle, Suite 400
Marietta, Georgia 30067 USA
Table of Contents
This document describes how the Open Applications Group’s Integration Specification (OAGIS) enables the requirements of horizontal as well as vertical industries to be provided for in a single specification. Through the use of something we call OAGIS Overlays, this can be accomplished without requiring industry vertical groups to give up their own terminology or enduring an exhaustive harmonization effort. While some harmonization is required to ensure a level of consistency and to identify the common aspects of interfaces, (both messages and business processes) in order to provide a road map for integration across vertical industries. It is not a requirement for an industry vertical or an individual company to abandon the terminology that has been built up over many years.
It is important to enable vertical industries to continue to use the terminology and business processes that they are familiar with as much as possible. It is also, important not to lose site of the ”end-in-mind,” that is to provide the information required to conduct business in the terminology of the participants. For example, if Ford Motor Company is buying Office Supplies from Staples or buying tires from Michelin, Ford should be able to issue the same Purchase Order ( with different data content) and have the Purchase Order be passed on to Staples or to Michelin in the format agreed to by each in their respective trading partner agreement. As such Staples receives the Purchase Order in their terminology and Michelin receives the Purchase Order in their terminology.
OAGIS Overlays allow the use of OAGIS Business Object Documents as the horizontally defined messages that are common within most industries, these include Purchase Orders, Invoices, Shipments, to name a few, that can then be extended by an industry vertical group to provide additional fields, compounds, components, nouns, additional constraints and additional context.
This document describes how industry groups (whether they are horizontal or vertical) can use OAGIS today to plug into a “canonical” message architecture in order to enable cross-industry integration.
“The great thing about standards is…there are so many to choose from.” Each industry vertical today has its on consortia (for some there are several) that define the standards to be used within that particular industry vertical. In large industries these are broken up into consortia for the different areas. While XML was designed so that multiple data formats can be optimized for different data exchange applications. A problem arises when these different vertical groups define their own message for common business documents independent of one another. For example: request for quotes, quotes, purchase orders, invoices, to name a few.
It is natural for us humans, to identify with those that we are most like and to work with them on common problems. However, it is important for us not to lose sight of the fact that we must provide the information needed to conduct business in a terminology that the parties on each side of the transaction understand. This is true whether we are doing business between companies (within or outside our industry vertical), as well as up and down the supply chain.
Today, what we see are point-to-point integrations by companies in each industry group, when they need to do business for a company in another industry group. Creating the mess shown in Figure 1.
Figure 1 - Companies create point-to-point integrations that do not scale at all when communicating to other companies integrating companies in different vertical industries makes this picture worse as often times the integrators do not recognize common constructs because they have different names.
While it is true that some aspects of a vertical industry are unique to that industry there are common components and business documents that really are the same or similar. What is needed is a common horizontal language that can be used as a basis for these common components and common business documents that allow these vertical industries to plug their additional content, constraints, and terminology into in order to pass information from business-to-business both inside and outside of a given industry vertical. See Figure 2.
Figure 2 - Companies need a Horizontal Business Language in which the additional content, terminology and requirements of vertical groups can be added to, but this is not enough.
It is very rare today when a company does business totally within only one industry vertical. For example Ford Motor Company buys tires from Michelin, but they also buy Gasoline from Exxon who is a petroleum company, they also buy office supplies from a retail company say Staples. Ford should be able to use one purchase order to communicate with all three companies, granted the content will be different but the XML structure should be the same.
While the purchase order for the petroleum industry may contain additional information or other terminology than the purchase order for office supplies the structure and the intent are the same to buy n- number of X product at Y cost.
If both the Petroleum industry and the Office Supply Retail industry used the same bases for a there purchase order, it would be possible for Ford to use the same purchase order business document to buy pencils and gasoline to both Staples and Exxon.
While a horizontal language that enables verticals to plug into a horizontal business language is a significant step forward from where we are today, it does not complete the picture. Because this flow of information cannot stop at the edges of the companies involved, the information must flow back into the business applications that drive these companies as well. See Figure 3.
Figure 3 - Ensuring communication of information between companies is pointless unless that information reaches the business applications inside of the company that drive the business.
Without this integration to the back end systems true “end-to-end” integration cannot be realized. Nor can the true potential “return-on-investment” that is promised by integrating supply chains.
At the same time in today’s economy companies need to be able to leverage their current investment in both standards and technology in order to enable the “end-to-end” flow of information. They must be sure that the “end-to-end” flow of information will not only work with today’s technologies but will also work with new technologies, as they are made available.
In order to provide the “End-in-Mind” of an “End-to-End” solution both of these requirements must be met:
ü Provide a mechanism in which an industry verticals unique information can be added to the horizontal without modifying the horizontal.
ü Provide a mechanism in which an industry verticals specific constraints can be applied.
ü Provide a mechanism in which an industry verticals terminology can be applied in context of the horizontal. This does not mean that the horizontal terminology is replaced, but rather they co-exist.
In order to do this what is needed is a canonical message architecture that vertical industries can “plug-in” their information including additional content, constraints and terminology in to a horizontal specification. While some degree of harmonization is necessary in order to provide a mapping from one vertical to another and so that common terms can be agreed to where appropriate. The complete purging of the terminology of a vertical industry is certainly NOT necessary nor is it practical. Only by doing this is it possible to achieve a “Canonical Business Language” for integration. See Figure 4.
Figure 4 - A Canonical Business Language must enable communication of information between companies as well as communicating information to the business applications inside of the company that drive the business. This must be done such that the terminology that has meaning in each vertical industry is preserved, otherwise the investment in industry standards has been lost and we start from square one.
Information must then be able to pass from Vertical-to-Vertical (V2V), Business-to-Business (B2B), Application-to-Application (A2A) as well as Application-to-Execution (A2E). Only by addressing all these areas is it possible to provide a Canonical Business Language.
What is needed is a horizontal business language that is open to working with vertical industries that does not require these industries to forgo the body of work that they have built over the years, that has a proven track record of delivering both B2B integration and A2A integrations.
OAGIS has a proven track record for B2B integrations as well as A2A integrations with companies such as Agilent, Lucent, Ford, Boeing, Lockheed-Martin, IBM, etc. using OAGIS for integrating both B2B and A2A. As well as having support in products (for example), from vendors such as Oracle, PeopleSoft, IBM, Mercator, HK Systems, J.D. Edwards, etc.
In moving to support XML Schema, OAGI recognized through the feedback of our members, that the key feature of OAGIS is its extensibility.
“Its reusability and extensibility, was crucial for us (Agilent) to adopt OAGIS as our canonical model.” – Paul Seabrook – Agilent
While OAGIS provides a good set of fields, compounds, and components needed for integration there is always going to be something that the designers of the specification did not consider. (No matter, how smart they are.) Likewise, a message can often be used in business scenarios or collaborations in ways that the designers never envisioned. Additionally, through our work with industry groups such Standards for Technology for Automotive Retail (STAR) and HR-XML, OAGI has learned that many times an industry vertical can reach consensus among its members to restrict certain values and certain collaborations can be made fixed or adhere to certain constraints within a given industry, however, when communicating across industries this does not hold true.
Because of these lessons learned, OAGIS 8.0 has been designed with the ability to “plug-in” industry vertical content, constraints, and terminology through the use of an OAGIS Overlay. By using OAGIS Overlays for Industry Verticals it is possible for OAGIS to be a “Canonical Business Language” as shown in Figure 5.
OAGI’s focus is on creating a Canonical Business Language enables the communication of the information required to do business in order to achieve the “end-in-mind.” As such, OAGI does not contain the in-depth knowledge of particular industries like Automotive, Human Resources, Pharmaceuticals, Finance, etc. that the industry groups that work in these areas do. Likewise, these vertical industry groups do not have in their charter to create “canonical business language” to enable businesses to do business across vertical boundaries.
Figure 5 - OAGIS 8.0 is a true Canonical Business Language that supports the ability for industry verticals to be “plugged-in” to OAGIS.
Because of this OAGI maintains an open policy and invites other industry groups to partner with the OAGI in order to create an Overlay of OAGIS that utilizes the terminology that already exists as well as the wealth of knowledge that each industry group has.
Only by working together can we create a true “canonical” business language.
A real example of this is the partnership that OAGI and HR-XML have.
Chuck Allen, Director of HR-XML - “Not Re-invented Here, … HR-XML to deploy SIDES specification as BODs.” - For more information see http://www.adtmag.com/print.asp?id=5885
As a result of this partnership HR-XML and OAGI have agreed to reference each other’s work. For example HR-XML will deploy their specifications in the OAGIS 8.0 Architecture making use of the Overlay capability of OAGIS 8.0. This allows the HR-XML community to take advantage of the BOD constructs to identify the intent of for example a TimeCard and adding the additional value of the BODs to identify the transactional differences of different verbs on the TimeCard, Noun. For example a Get transaction request information; a Show is the response to the Get that shows the information requested. The HR-XML community also can use business documents, OAGIS BODs that HR-XML does not have with in its charter to define with out worrying with different data formats and structures.
Benefits to the OAGI community are that OAGI does not have to define duplicate human resource BODs. And the OAGI community like the HR-XML community can use the HR-XML specifications without worrying with different data formats and structures.
Both organizations will reference each other’s work as appropriate.
Although, OAGI does have a few human resources BODs, they are not to the detail that HR-XML has defined and as such implementations using BODs today can use the specification of HR-XML just as they would use an OAGIS BOD in the future.
Another real example of this is the partnership between Standards for Technology in Automotive Retail (STAR) and OAGI. STAR has chosen OAGIS 8.0 as the basis for the STAR communities XML initiative. This XML initiative is designed to streamline the interactions between auto dealers, automotive manufacturers and other business partners in the automotive distribution value chain.
Through this partnership with OAGI, the STAR community has built new BODs that will be made available in a future release of OAGIS. By working through this process it has been possible to identify vertical aspects and horizontal aspects of several business messages. These have been captured at the appropriate level. OAGI has received more feedback on BODs that were being worked through to ensure that the meet everyone’s needs.
STAR is also able to focus on their core competency and that is creating standards for the automotive retail industry.
It is important to note that while OAGIS makes use of a flexible and extensible model, STAR has chosen to prohibit extension in the STAR overlay. OAGIS 8.0 enables this capability.
We have an opportunity to work together, The Open Applications Group with along with industry groups, to define a true Canonical Business Model, where each industry can maintain their independence while leveraging cross industry work to maximize interoperability while minimizing redandancy. The Open Applications Group issues this call for convergence to all industry groups to work together in a loosely coupled XML Alliance for the future.