In search for the next generation of EDI
This posting outlines the efforts by UNECE in defining the next generation of EDI. The benefit to the reader will not only be an inside to story but more important it will provide an understanding why UN/CEFACT is where it is today. Further, it will help in putting WP.4/CEFACT’s work in perspective to other efforts underway.
The goal for the new generation of EDI was that in order for small Businesses (SMEs) to benefit these new eBusiness standards must contain all the information to allow software solution providers to create programs that can be purchased off-the-self (shrink-wrap-solutions).
At the same time it was recognized that 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.
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 was based on the Rational Rose Unified Process. From 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.
Below are short descriptions of the new technologies that were identified by TMWG in 1999 (AC.1) that could be applied in achieving the goal of CEFACT to simplify eBusiness.
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 Business Operational View (BOV) and;
- the Functional Service View (FSV).
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:
- operational conventions,
- agreements,
- mutual obligations.
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,
- user application interface,
- transfer infrastructure interface,
- security mechanism handling,
- protocols for inter working of information technology systems of different organizations,
- translation mechanisms
Figure 1. Open-edi environment
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 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, and 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 forward direction was 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 colors 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 whatever 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, but more on that in a future posting.
The Result
So what was the answer to the question what would it take to build software that would help to address the SME issue? The answer was (still 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. All of TMWG’s work and recommendations not only resulted in the creation of a new standardization initiative called ebXML (Electronic Business with XML), but are still guiding today’s work within UN/CEFACT. The real question that still is to be answered did it result in the simplification to allow software solution providers to create programs that can be purchased as off-the-self products(shrink-wrap-solutions)? Stay tuned for more on that topic.
