ebXML - Creating a Single Global Electronic Market Part
The Story Behind...
Klaus-Dieter Naujok
Table of Contents
- Summary
- Introduction
- In search for the Next Generation of EDI/eCommerce
- The creation of the ebXML Initiative
- The ebXML Vision Ala UN/CEFACT
- Conclusion
Summary
This article outlines the reasons behind the creation of the ebXML initiative. The benefit to the reader will not only be an inside to story of ebXML but more important it will provide an understanding why the ebXML specifications are what they are. Further, it will help in putting ebXML in perspective to other efforts underway. The article will conclude with a value proposition for providing the SME solution that is required for ebXML to be successful.
Introduction
The success and failure of EDI (Electronic Data Interchange)
Over 25 years ago the idea was born to eliminate the use of paper documents for exchanging business data by linking computer systems together so that the data, normally on paper, could be sent from one system to the other. This concept became known as EDI, Electronic Data Interchange. The advantages are still valid today, no reentering of data and therefore fewer errors, if any. No dependency on postal services, cost savings per transaction from $75.00 to 50 cents, to mention just a few. However, looking at the statistics of who is currently utilizing EDI, one must wonder why it is not used by every business. In regard to the top 10,000 companies on the global scale (Fortune 1000 in the top 10 countries), almost every one is using EDI, 98% to be exact. However, for the rest of the world only 5% are EDI users. In other words, millions of companies are still using faxes and paper documents. Why?
The answer is well known; start up cost. EDI saves a lot of money, over time. But before that happens, companies must spend resources up front to identify their data requirements in order to map their in-house data to the EDI messages. For example, the UN/EDIFACT Purchase Order (PO) contains over 1,200 data elements. A paper PO contains about 40 different data fields (assuming a single item is ordered). Why does the EDI equivalent have 30 times as much data possibilities? The reason is that the PO contains more than just data related to an order being placed. When the standard was created, and maintained over time, it was the IT departments that sent their experts to participate in the work. Their knowledge was mostly based on "what" was in their corporate database. Because of that, they requested (demanded) that their data requirements be fulfilled in the EDI message. There was no analysis as to whether the corporate purchasing application (or any other one) actually "used" or "required" that data. The more the number of companies using the PO (or any other EDI message) increased, then the more that additional data elements were added. Because many of the EDI messages are used across many industries, this addition of data requirements grew and grew. To help to bring the real data requirements back to a manageable level, industry groups started to create Implementation Guides designed to limit the use of data elements to what the companies in that industry agreed to. The general rule is that this would result in an 80% reduction, resulting in 240 data elements in the case of the PO, still six times as many as a paper PO.
Individual companies overcame that problem by further limiting their implementation to a subset of the industry implementation guide to eliminate another 80%, resulting in 45-50 data elements, which is almost the same number as a paper-based PO. However, if one compares the POs of any two companies in the same industry, their data requirements are not identical. Further, even if a particular company is big enough to "dictate" their requirements to any other company, not every partner they trade with can deliver all the data they want, therefore resulting in different implementations. The net result is, that before one can engage in EDI with a particular partner, resources are required not only to identify the requirements for data to be exchanged, but also include mapping that data to the in-house data base and testing the exchange before going live. This process is required for each new partner one wants to exchange data with, and for each EDI message with that partner. Thus, a very costly effort that only the Fortune 1000 companies in each country can afford.
In order to reduce the cost so that the implementation becomes transparent, one would have to agree to a single data requirement for a particular EDI message. This would allow software vendors to create an EDI application that would have a large enough market to reduce the cost for small and medium sized companies to be able to afford. This will never happen. So what would it take for software companies to build software that is not tailored for each of the different EDI message implementations but will be able to adopt to the different data requirements for a particular customer and their trading partners?
The role of SMEs (Small and Medium Enterprises) in Business to Business (B2B)
In order for SMEs to benefit from next generation of eBusiness standards, those standards must contain all the information to allow software developers to create programs that can be purchased off-the-self (shrink-wrap-solutions). The question that now arises is, will the software industry deliver the "cheap" off-the-shelf shrink-wrapped solution for the SMEs? One would think so, however, many, if not all, of the software providers that are involved in the current efforts are after high margins ($$$) by delivering solutions for the Fortune 1000 companies.
The success of any new way to exchange data among businesses depends not only on the adoption by the Fortune 1000 companies of standard agreements, but on their adoption by the other 25,000,000 SMEs in the world. Without an economic incentive for the SMEs, any new method of accomplishing eBusiness is just another pointless effort. This article is an effort to help to achieve this goal.
In search for the Next Generation of EDI/eCommerce
Before describing the ebXML Specifications and their place in the new eBusiness world it is worthwhile to understand the history behind the work, the thoughts and ideas that served as the guiding light in forming the goal to define the next generation of electronic business data exchange without prior agreements - a goal that addresses not only large corporations, but also small and medium sized enterprises. This section is an account of the work that led to the creation of ebXML (electronic business XML).
Looking at new technology
In the late 1980's ISO/IEC/JTC1 created a special working group to research the idea of exchanging electronic data amongst organizations without prior agreement. This effort became known as "Open-edi". UN/ECE/WP.4 (predecessor to UN/CEFACT) participated in this work from the start in 1990 when the recommendation from the special working group was adopted by JTC1 to create a reference model. The Reference Model became an International Standard in 1997. However, the principal concept of that work was embraced by WP.4 long before in its efforts towards the "Next Generation" of EDI.
In 1995 UN/ECE/WP.4 created an ad-hoc committee (AC.1) to investigate the available technologies for creating the "Next Generation" for electronic information exchanges among business trading partners.
AC.1 reported that the most promising technology addressing the shortcomings of EDI was that of Business Process and Information Modeling (BPIM). By utilizing BPIM, standards would not have the problem of ambiguity; instead they would describe the complete processes and their information requirements, including constraints, options in execution, exceptions, etc. Further, AC.1 recommended that object technology should be used since it was not only the emerging star, but offered many, if not all, aspects required to describe the real world, which is made up from objects. In addition to identifying BPIM and Object Oriented Technology (OOT), AC.1 identified the failure of getting the SMEs to adopt (use) the current EDI standards.
AC.1 recognized that even with BPIM, the issue of businesses doing things differently would not go away, even if it is only in regard to external processes. AC.1 proposed that the next generation standards would be BPIMs for a particular business goal, such as "Catalog Ordering," that contained "all" the possible activities that could be part of that goal. In other words, the approved BPIM would be a super-model for a given business process. Since such models would have many ways of execution (paths through the model) each path would be identified as a scenario. Depending on their internal processes, one trading partner may be able to execute all the scenarios of a model, where another may only execute a certain number of them. For two trading partners to engage in the same business process, they must both be able to execute at least one scenario in common. In regard to the SMEs, it is envisioned that the software providers would create applications that implement BPIMs with their most popular scenarios.
During AC.1's research, one other path was explored, that of utilizing "intelligent agent" (IA) technology. Instead of "documenting" business interaction in BPIM, why not "discover" the capabilities of potential trading partners in order to determine if the internal processes would support interactions? AC.1 did not dismiss that possibility but concluded that the sole use of IA technology would currently be a costly effort only affordable to the "Fortune 1000" instead of the SMEs.
As WP.4 transitioned itself to the new organization, now known as UN/CEFACT, AC.1's BPIM recommendation became the foundation for the new work ahead. UN/CEFACT created the Techniques and Methodologies Working Group (TMWG) in order to continue the work of AC.1. Based on the original recommendation, UN/CEFACT also created the Business Process Analysis Working Group and encouraged UN/EDIFACT and other working groups to move towards adopting BPIM for its EDI standardization.
The TMWG continued by evaluating available modeling techniques started by AC.1. In 1998, the TMWG recommended that UML should be the modeling technique of choice for UN/CEFACT. This recommendation was adopted by UN/CEFACT. In order for UN/CEFACT as an organization to not only adopt UML for BPIM, but also to ensure that it's use was consistent for all UN/CEFACT working groups, enabling them to share their resources, TMWG was asked to develop a methodology. An effort to specify the UN/CEFACT Modeling Methodology (UMM) was started in 1999 by the TMWG. The work is based on the Rational Rose Unified Process. Since the start of the work, members of UN/CEFACT and/or TMWG, such as SWIFT, TM Forum and RosettaNet have not only participated in the work but also adopted it in part or expanded it.
Before providing the last events that let to the creation of ebXML a short description of the new technologies that were identified by TMWG (AC.1) to be utilized, will aid understanding of the new direction.
Open-edi
Open-edi is an ISO/IEC vision of future EDI. ISO/IEC 14662 provides a baseline for all levels of standards that are needed for the specification of Open-edi scenarios and their implementation. TMWG has explored and recommended various modeling techniques including UML for business modeling and information modeling.
Open-edi takes a generic approach. It enables organizations to establish short-term relationships quickly and cost effectively. Open-edi provides the opportunity to lower significantly the barriers to electronic data exchange by introducing standard business scenarios and the necessary services to support them. In principle, once a business scenario is agreed upon, and implementations conform to the Open-edi standards, there is no need for prior agreement among trading partners, other than the decision to engage in the Open-edi transaction in compliance with the business scenario.
The field of application of Open-edi is the electronic processing of business transactions among autonomous multiple organizations within and across sectors (e.g., public, private, industrial, geographic). It includes business transactions that involve multiple data types such as numbers, characters, images and sound. The Open-edi Reference Model provides the standards required for the inter-working of organizations, through interconnected information technology systems, and is independent of specific information technology (IT) implementations, business content or conventions, business activities and organizations.
The Open-edi Reference Model places existing EDI standards in perspective using two views to describe the relevant aspects of business transactions:
The BOV addresses the aspects of a) the semantics of business data in business transactions and associated data interchanges, and b) the rules for business transactions which apply to the business needs of Open-edi, including:
The FSV addresses the supporting services meeting the mechanistic needs of Open-edi. It focuses on the Information Technology aspects of functional capabilities, service interfaces, and protocols, including:
-
capability of initiating, operating and tracking the progress of Open-edi transactions,
-
protocols for inter working of information technology systems of different organizations,
Figure 1 sets out the relationship between the Open-edi reference model and these views. While the Model itself is developed as a standard, other standards are required. Standards are driven by, and must satisfy, the requirements identified within the Open-edi Reference Model.
Although TMWG's work must satisfy the overall requirements of the Model, the primary focus shall reside with the BOV and shall be independent of the supporting FSV solution. TMWG's assumption is that the FSV will be developed by commercial software vendors which enable distributed object computing environments, and ensure backward compatibility to traditional EDI messages. As such, the resultant BOV related standards will provide the business and object class models to construct Open-edi scenarios.
Interoperation among application programs requires that there be "common ground" in their exchange of information, so that there can be common understanding and agreement on the information being jointly processed. Common ground in this exchange of information is accomplished in current EDI methodology through a neutral, application independent syntax, i.e., typically for business data a translated UN/EDIFACT interchange file. All consideration of application programs, how to facilitate their interoperation, functionality variations, and the business practices behind them are deliberately ignored. Instead, the current EDI standardization process in UN/EDIFACT concentrates solely on the structure and content of the translated interchange file. The problems associated with UN/EDIFACT standards and the standard development process, are well documented and are not repeated here.
However, it is essential to understand that for Open-edi to overcome the current impediments to implementing EDI, a new paradigm must be envisioned that shifts the focus on EDI standards from the interchange file to the information contained in the business processes. While business practices from one business organization to another are highly variable, depending on competitive strategies, experience and management style, activities can be decomposed into business processes that are more generic to the type of business. This analysis through the modeling process will identify object classes and models that are likely candidates for standardization. TMWG looks for standard reusable components from which to construct information exchange software. Such a goal is a core concept of object technology.
Object Oriented Technology
Object Oriented Technology (OOT) is one of the most talked about concepts of recent years. It all comes down to organizing things in ways that echo how things are put together and relate in the real world.
Consider the children's toy, Lego™, small plastic building blocks in various colours and sizes. They have small round pegs on one side that fit into small round holes on other Lego™ pieces so that they fit together snugly to create larger shapes. With different Lego™ pieces (Lego™ wheels, Lego ™ engines, Lego™ hinges, and Lego ™ pulleys), it is possible to build castles, trailer tractors, giant robots that swallow cities, or just about anything else you can imagine. Each Lego™ piece is a small object that fits together with other small objects in predefined ways to create other larger objects. In turn, these fit together and form even larger objects. For example, a tractor and trailer will fit together to form a wagon.
As a second example suppose it is possible to walk into a computer store and, with a little background and often some help, assemble an entire personal computer system from various components: a motherboard, a CPU chip, a video card, a hard disk, a keyboard, and so on. Ideally, when all the various self-contained units have been assembled, the result is a system where all of its units work together to create a larger system that can solve the computational problems for which it was designed.
Internally, each of those components may be vastly complicated and engineered by different companies with different methods of design. But it is not important to know how the component works, what every chip on the board does, or how, when you press the A key, an "A" gets sent to the computer. As the assembler of the overall system, each component you use is a self-contained unit. The main interest is how the units interact with each other. Will this video card fit into the slots on the motherboard, will this monitor work with this video card, will each particular component convey the right commands to the other components it interacts with so that each part of the computer is understood by every other part, etc.? Once it is known what the interactions are between the components and one can match the various component's interactions, putting together the overall system is easy.
OOT works in exactly this same way. Using OOT, the overall design (model) is made up of lots of different self-contained components (objects), each of which has a specific role in the model and all of which can talk to each other in predefined ways.
Modeling
As TMWG identified the necessity to decompose business processes to their more generic components, it also concluded that a consistent methodology (modeling techniques) for conducting the analysis and design must be utilized. Thus, it is important to explore the benefits of using modeling techniques to identify the data requirements and data flows of a particular business process. These models assist in providing an interface specification that enables non-standard data, internal to a business process, to be mapped and translated to a representation of standardized data.
These models, which provide the interface specification, will constitute the new Electronic Business (eBusiness) standards, once they are certified as satisfying the business requirements. These new standards will be independent of the interchange data syntax, transport infrastructure, and server software.
TMWG's primary objective in this new focus on eBusiness standards was to make eBusiness technology widely available, non-obtrusive to the business process, and cost effective for all organizations, including SMEs. The requirements to make this objective a reality include:
-
Production of well-defined, consistent standards for interoperability, i.e., reduces the number of ways of doing things.
-
Development of off-the-shelf tools that are commercially available for analysis and implementation.
-
Separation of analysis from application design and programming.
-
Availability of training and reference sources (i.e., take advantage of a mainstream methodology for new projects in industry).
-
Provision for automatic generation of eBusiness interactions.
-
Separation of data definition and format from the transport layer.
Transporting and Packing the information
In looking towards the next generation of eBusiness standards it became clear that the best solution would be to separate the "how" from "what". Or more to the point, the Business process models defining the "what" should be independent of the transport mechanism, the "how". This way, the same models can be used to move the information using EDI messages, distributed object technology or what ever other technology may surface. This line of thinking was consistent with the Open-edi approach of looking at the world trough two views, the Business Operational View and Functional Service View. Where the BOV would be utilizing the modeling and the FSV would be the technology used for transporting the information. This is often called developing protocol neutral models.
Enter XML
In 1998 there were various moves outside UN/CEFACT towards XML as an EDI replacement. Towards the end of that year UN/EDIFACT users demanded that UN/CEFACT created an XML solution in order to protect is investment and leading role as the standards setter in electronic information exchange. This resulted in UN/CEFACT asking TMWG to research the feasibility of XML being utilized in the eBusiness information exchange (B2B). TMWG's recommendation was not to transform EDI messages into XML, but instead to use XML where appropriate in the BPIM and OO next generation effort. This led to the creation of ebXML.
The Result
So what is the answer to the question what would it take to build software that would help to address the SME issue? The answer is to "document" the business processes and associated information requirements for a particular business goal in an unambiguous way that can be processed by a computer program. Business Process modeling and Object Oriented Technology can achieve this objective. Instead of looking at the data requirements based on internal legacy data base records, business experts identify the collaborations with other parties in order to achieve a certain business goal. Those collaborations are documented in a model utilizing the Unified Modeling Language (a graphic rendering). Each activity will require information exchange. Instead of taking the data element approach, objects are used. (Since our real world is made up of objects it will be easier to identify objects that have attributes (data) and functions that can be performed on those attributes). The number of objects that are common to many business processes (goals), such as address, party, location, only to mention a few, are not that many. This concept is not rocket science. This article describes the latest efforts that followed this path of standardization called ebXML (Electronic Business with XML).
The creation of the ebXML Initiative
Part of TMWG's recommendation to create the ebXML initiative was for UN/CEFACT not to do this alone, but to find a partner that would bring in the XML community. The search was on to find the right partner that would ensure success of the effort.
Finding a Partner for ebXML
When the search started in the early summer of 1999, Microsoft was gaining momentum with its BizTalk initiative. Unless a viable alternative framework for using XML was developed, many vendors would be at risk of ceding yet another market to Microsoft. UN/CEFACT, on the other hand, was affected by somewhat different dynamics. Various industry groups associated with UN/EDIFACT were investigating ways to embrace XML. UN/CEFACT was at risk either of getting trampled into EC irrelevance in the XML stampede and losing the progress made in OO-edi, or of having a number of competing XML dialects emerge from among several groups associated with it (or possibly both!). To avoid these scenarios UN/CEFACT had to make a bold move to embrace XML. The choice for a partner came down to an organization that was a key player in the XML space. Two organizations came to mind. The first of the two being W3C. However, its main function was to develop base specifications that serve as foundation for specific implementations. The other organization was OASIS (Organization for the Advancement of Structured Information Standards), a non-profit, international consortium that advances electronic by promoting open, collaborative development of interoperability specifications. A perfect fit. Both were to benefit working together, creating synergy from their respective strengths - the EDI based e-business experience, user base, government support, and UN imprimatur of CEFACT and the XML expertise and vendor base of OASIS.
UN/CEFACT's B2B Goal
In summary, ebXML was created by UN/CEFACT's goal towards a B2B solution that would utilize BPIM, OOT, CBO, UML, UMM and XML.
UN/CEFAFT's vision for ebXML is as follows:
The initiative will develop a "framework" that utilizes BPIM, UML and Unified Modeling Methodology in such a way that any industry group or standards body, including UN/CEFACT, can create models that identify every possible activity to achieve a specific business goal. These models will be registered and stored in a global "virtual" repository. Users (trading partners - TP) will register "their" particular path/paths through the model (scenario(s)) so that others who want to engage with that TP can determine if they share at least one scenario. To ensure that the models not only follow the UMM but also are interoperable, the ebXML initiative will provide the most common objects (Common Business Objects - CBOs) that will be used by the modellers as they document a particular business process. In addition, ebXML will define the XML messaging format, packaging and routing and the metamodel for the repository.
A special note in regard to the view that ebXML should use registered "Super models" and scenarios rather than the process of discovering trading partner capabilities via intelligent agent technology. It is true that over the past few years this goal is achievable, but it still will require resources only available to the Fortune 1000 companies. The main goal for UN/CEFACT to create the ebXML initiative was to use XML since it would allow SMEs to engage in eBusiness via shrink-wrapped solutions. Yes, over time "intelligent agent" technology will become more affordable. Further, ebXML is extendable. Even now, TPs must register their capabilities in a global repository. The first use of IA technology should be to search the repository in order to identify who has the same capabilities in order to do business together. The next step would be to expand the use of IA by "adopting" internal processes to external scenarios which are almost "usable". And finally, one can expand IA technology by utilizing "internal" BPIM in order to engage in an automated "knowledge" exchange of a TP system, that also uses IA and BPIM, to identify, negotiate and agree to do business in a mutual way. But that is still some years away. ebXML can start the process in a way UN/CEFACT envisioned it, not only for the "big" guys, but also for the "small".
The ebXML Vision Ala UN/CEFACT
This chapter outlines the vision of exchanging business information without prior agreement among the parties involved in the exchange. This will include a brief description how ebXML enables large organization and small business alike and the benefits to SMEs.
Finding ebXML enabled parties
Before ebXML parties can engage with each other they need to find each other. In order to do so any business or organization that is ebXML capable will need to store in an ebXML registry information about its ebXML capabilities. This information will include which transport options are available, such as SMTP or http. Further, security features one can invoke, such as encryption, non-repudiation, digital signatures. Last but not least it will identify, which business activities are available for engagement. Is it just order placement, or the full supply chain? Are there various scenarios for the same business process? This registry will not be hosted by a single party but by many. Possible hosts could be industry user groups/consortiums, standard bodies, major market creators/enablers or software solution providers. However, regardless of who will host the registry they are all link together to create a single virtual registry.
Once the registry is setup anyone that is ebXML enabled can access the information in order to find businesses that offer the services one is looking for. This could be a search for a particular product, such as red women shoes, or a very specific item such as a Number 2 pencil, or less specific as any hardware vendor. The ebXML Trading Partner Profile Specification will allow parties to provide as much details as they are willing to publicly disclose. Some parties may provide a link to their complete product catalog where other will just provide a high level of product categories or services. However in order to engage in an ebXML business process, the parties will need to identify at least one business process model scenario they are capable of executing.
Selecting and engaging with the new found party
After a party has searched the registry for a list of businesses that can provide the product or service, the next step is, in addition to select a business that fits the requirement from the product and/or service point, to determine if the business processes available can be handled by ones own ebXML application/system. Depending on the software, this could be as simple as matching predefined processes against the available ones, or by performing a internal analysis in order tom determine if the system can dynamically adopt itself to any of them. Once the party wishing to engage with the selected party in one of the business scenarios a Trading Partner Agreement (TPA) will be send. The TPA will outline which options that were available will be utilized in this engagement. This includes the transport and security option and selected business scenario. The selected party will than either accept the TPA by sending a positive acknowledgement or reject it with a negative acknowledgement giving the reason why. After receiving a positive acknowledgment the selected business scenario will be started by the appropriate party sending the first business information message. Than depending on the result the rest of the scenario will be executed with the resulting messages being exchange. This could be the normal (positive) flow of information or exceptions as identified in the business process model. Regardless, sooner or later their will be a end to that particular engagement. To engage with that particular party again to start up a new exchange, a TPA will have to be send again.
The role of large companies/organizations/industries
The success of ebXML will depend on businesses registering and storing their business scenarios in the repository. Instead of each individual business modeling their view of how they think a particular business goal should be achieved, it is envision that standards organizations such as UN/CEFACT and user groups such as SWIFT create the models. These models would contain for a particular business goal all the possible activities that pertain to it. In other words if there is more than one way to achieve a certain step in the process they all are included. There is no prejudging on which way is the best.
As an example, figure 2 shows a UML use case diagram that outlines the high level activities that may be executed in a catalog order. Of all the activities shown only two a mandatory, the registration of Buyer Information and placement of an order. As to the other three they are optional. These are, getting a copy of the catalog, requesting a quote and enquiring about the order status. Because of this there are 5 possible scenarios available to execute this particular business process:
The first two of those are the minimum requirement for any party to be able to execute. Depending on its own internal system, some companies may register any or all of the other three scenarios.
This is a simple example. In a more complex business processes there maybe more than one way to place an order, in which case there would be more available scenarios.
How the SMEs will benefit
Before the SMEs can benefit from ebXML there needs to be content (Business Process and Information Models) developed on their behalf. SMEs don't have the resources to engage in standard development work. The value proposition is simple, if it is not as simple as the current fax solution they are using, than there will be no adoption of ebXML. In regard to the content work, UN/CEFACT has taken on that responsibility as part of phase 2 of ebXML. With the cooperation of all major industry groups UN/CEFACT will develop eBusiness content that includes SME scenarios within.
So what would it take to replace the current fax solution SMEs are using? Besides developing the process engine that can execute a business and information model, integration to existing SME solutions is needed. Most, if not all SMEs that use a computer in their business, are using an accounting and inventory package from such vendors as PeachTree, Intuit (Quickbooks) or Sage. It will be difficult, if not impossible, to get the SME to switch from those programs. Therefore there is no need to create new applications that requires and processes the data; instead an interface to their existing application is required. By integrating their current investment by providing a interface that implements ebXML automated data exchanges with their exiting application in a transparent and seamless way, the SME will have a solution that is better than the current fax. The benefit is the elimination of reentering of business date into his/her accounting and inventory system.
Conclusion
The question is will the current supplies of shrink-wrap solutions integrate ebXML into their offerings? For now these application vendors don't see the need for such an interface, or don't have the know-how to develop it. This opens the door for someone who knows the data interchange business to create the front end to those applications and to import a particular model in order to engage in the exchange with other partners that are ebXML compliant.
There are many opportunities for such software front-ends. In addition to being able to execute more than one (if not all) business model(s), the application could use agents to query on-line repositories to identify potential trading partners for a specific requirement (order). In addition to just being the front end to a popular business application, one could add the capability for the system to be configured to in-house applications that were custom developed. Further, the in-house business process could also be stored in a business process model allowing agents to not only identify potential customers based on a static in-house process, but possibly extending the number of potential partners by modifying (adopting) the internal processes based on the knowledge of both models. The technology is there, we have the know-how; all it takes is for us to harness it.
In closing, the success of any new way to exchange data among businesses depends not only on the adoption by the Fortune 1000 companies of standard agreements, but as well as on the utilization of the other 25,000,000 SMEs in the world. Without an economic incentive for the SMEs, any new method of accomplishing e-Business is just another pointless effort. ebXML is currently the global solution that uses business process and information modeling and object oriented technology to allow the software vendors to create the "volks data interchange" solution. The time is right for someone to do it, now.