Can Information Exchange Standards Meet eBusiness Needs?

Summary

For years eBusiness information exchange standards and specifications, utilizing the latest thinking and technology, have been released with the promise that this latest solution can easily be implemented throughout the global business community. These solutions, however, generally have merit for only the larger corporations, and fundamentally fail to meet needs of Small and Medium-sized Enterprises (SMEs)[1]. Why? Generally, these solutions do not recognize the limited resources available to SMEs as well as the full scope of their business needs.

With rare exception, no SME will directly implement an eBusiness solution by applying the underlying standards and specifications directly. For an SME the only concern is a viable solution that enables a business process and offers them an opportunity to improve their chances of achieving profitable trading activities.

Thus, the solution for most enterprises must come from application solution providers, software developers, and others who provide either affordable commercial-off-the-shelf (COTS) applications or inexpensive supporting solutions which utilize the underlying information exchange standards. Thus, in order to incentivize providers, eBusiness standards ease of use and simplicity, not complexity, must be the fundamental premise for solutions that are fully interoperable, affordable, and easily and seamlessly implementable across the broader business community.

Unfortunately, we suggest that today’s new eBusiness standards and specifications are overwhelmingly complex—limiting implementation and posing a risk to the economics that lead to the availability and adoption of effective COTS solutions. However, efficient and affordable solutions are available to SMEs as well as to others already engaged in global eBusiness.

Setting the Stage

When firms like IBM, using their early computer systems, developed the first eBusiness capabilities in the 1960’s, it was embraced immediately by large enterprises and spread globally as the way to gain huge savings through the reduction or elimination of paper-based processes. Now, more than 40 years later the Internet and eBusiness have become key measures and enablers for electronic business success. However, while large companies continue to reap large savings from electronic business technologies, smaller companies have been unable to share in the benefits.

For many SMEs the investment in eBusiness capabilities is far too high, forcing the adoption of strategies requiring excessive time and effort devoted to manual and non-integrated processes. Larger organizations are better able to leverage investments to fully integrate their various processes, while maintaining both online and archived data to best meet their operating requirements. Clearly, smaller companies are not the priority here; instead they are effectively the targets for cost avoidance stratagems instead.

There are many who would like to see easier access to the economical use of electronic information exchanges. However, in many instances there are dynamics and marketplace forces at work that limit the penetration of true electronic commerce throughout the global economy. Strategically positioned organizations, regardless of industry, rely on the complexity of underlying eBusiness standards and specifications to ensure the control of critical mechanisms. And, many software solution providers essentially limit the open exchange process through the sale of solutions and services that foster a captive customer base rather than actively promoting solutions that provide choices.

Paradoxically, some lessons learned since those early days of eBusiness have also provided the means to achieve simplicity in common business information exchanges. Strategies were developed by some large international corporations in the 1980’s and 1990’s to reduce costs further by adopting minimalistic information exchanges. Unfortunately those efforts were derailed and discarded when powerful interests began promoting new technical solutions as the best alternatives. Unfortunately, those new “solutions” only brought added complexity to process.

Interestingly, many recent advances in open source technology combined with ubiquitous wireless network access and devices have emerged, providing the potential to tip the balance in the favor of small businesses interests and open collaboration processes. When combined with the serious economic issues in play today, we foresee a dramatically increasing interest in these alternatives as systems and mechanisms that can more favorably impact the global economy, regardless of the size of the participants.

Everyday Examples of Complexity

The issue does not exist in a limited domain. Rather, complexity, espoused in the name of simplicity, abounds in our everyday lives. Consider remote controls for our televisions, satellite or cable boxes, home entertainment centers, etc. Individually, these devices are numerous and represent different solutions to applications. But, collectively they are rarely easily implemented, and even more rarely interoperable. Enter the “solution”—the universal remote. Yes, it is generally quite affordable with numerous improvements embedded. But, implementation is not for the faint of heart or technologically challenged. Implementation inevitably takes time, is a complex and frustrating process, and frequently requires an understanding of the inner workings of the device to identify the “exceptions” necessary to meet your individual use needs.

Moving to the area of business software applications, frequently the product must balance affordability, meeting the needs of a wide user community, providing a rich set of features, and simplifying the ease of use. For example, consider any of the widely accepted (and unnamed) word processing applications. The market for any product must be sufficiently robust to justify product development and maintenance costs. And, with every new release there must also be enough new features, generally creating more complexity, to justify the product release. However, there is also a good case to suggest that the new features frequently include little perceived improvement in ease of use. In the majority of cases, users work only with the basic features that are well accepted and embedded within the product’s user interface. However, change the user interface with the intent of providing a “better product”, and you can easily introduce a broad set of negative implementation issues, including compatibility, interoperability, time to implement, ease of use, and cost that resonate across a broad spectrum of the business community.

Why then do so many solution providers fail to meet the users’ expectations for the product? Obviously, a reluctance to accept change is a natural human reaction. However, in many cases the products are designed with limited user involvement. Yes, beta testing involves users, but is frequently focused on identifying “bugs” rather than the underlying processes that directly impact product usability.

The eBusiness Environment

When one considers the early efforts to develop eBusiness information exchange standards, we can see a series of parallels. In the early days, electronic data interchange (EDI) was seen by many as the development of a mechanism that would simplify[2] information exchange. Most process participants were users, not vendors. One would have thought that this would have resulted in standards that were truly what users wanted.

However, the answer, as it turns out, is not that simple. Yes, early EDI standards reflect user requirements, but those early developers were fundamentally pressured into reflecting every user’s data requirements rather than coming to an agreement on an accepted, universal set of business processes. Thus, in an effort to obtain universality, an extraordinary increase in complexity resulted, missing the intended target of simplified interoperability.

To better understand the issue, consider the data requirement to exchange the “date for the delivery” of goods. One user may call it just that, but another may call it “drop-off date”. And, a third user may call it “arrival date”. Instead of taking the potentially difficult and controversial action of finding a common agreed name, all three date elements were included within the standard, begging the question of simplifying implementation across the business community. Apply this concept to the range of global information exchange requirements, and it is easy to extrapolate and see the extraordinarily complex issue of eBusiness implementation for SMEs. Consequently, the lack of standardized data and processes made it untenable for application developers to leverage these standards.

A Historical Perspective: Lessons from the First Attempts at Data Simplification

As an early international EDI standard, UN/EDIFACT experienced “complexity problems” from the start, but subsequently agreed to remove many of the existing duplications and redundancies from its data directory. Additionally, and again in the name of simplicity, the “cleanup” process replaced very specific data elements with more generic data element pairs, using a qualifier to provide the necessary specific user information.

The initial efforts made significant strides toward identifying common acceptable names for data elements. However, rather than continue process harmonization efforts, it soon became easier to fall back to merely adding a qualifier code for every variation of a data concept in the name of meeting user requirements. To that end, UN/EDIFACT (as well as the US equivalent standard, the American National Standards Institute’s ANSI ASC X12) has evolved to be extremely complex, with limited implementations throughout the predominant SME user community.

The process of sorting through the many qualifier values to map in-house data or trying to understand the subtle differences in usage among different trading partners makes implementation of the standard extremely complex and time consuming. The result is a major conundrum for software developers. Because the content of the standard is a user induced complexity and direct consequence of the flexibility that was inevitably built into the standard by the users, vendors are challenged to develop acceptable, cost effective COTS products that are easily implementable without process change at the user level.

An Often Forgotten Attempt at Simplification

We do not suggest that standards and technology have not brought with it opportunities for success–quite the contrary. In the late 1990’s Tom McGuffog, Nestlé UK’s Director of eBusiness, published a paper, “K.I.S.S.—Keep It Simple, Standard, Speedy and Certain”, introducing the concept of Simpl-EDI. The premise behind the paper dealt with the transfer of data in a fully automated environment, where supporting “master data” is available in a database and where the only data exchanged is simple transaction data. Recognizing the potential behind the concept, UN/CEFACT undertook an initiative to evaluate how the concept might be efficiently and effectively developed within UN/CEFACT’s structure.
The ultimate recommendation was the creation of a single, unique global electronic commerce repository. The core of this repository would contain UN/EDIFACT data elements and codes resulting from the work of the Simpl-EDI messages, but also including the work of other simplified message implementations.

On the surface this proposed solution seemed to point in the right direction, suggesting that the creation of simplified UN/EDIFACT messages could use the 80/20 concept, i.e. that 20% of the data from the existing message standards would enable 80% of global business relationships to function simply and automatically. Exceptions would require a more sophisticated use of the message standards.

At that point pressure to exploit new eXtensible Markup Language (XML) “simplifying technology” sidetracked the original effort. Development of the Simpl-EDI concept shifted to e-centre UK (now GS1 UK). Much later this work was transferred to UN/CEFACT with the intent that it would become a global standard for electronic business.

Regrettably, this work has not evolved to the level of an international standard. Instead the Simpl-EDI messages have become inputs to a new United Nations Economic Commission of Europe (UNECE) project, UNeDocs, which seeks to develop a superset of aligned documents in paper and electronic format—each containing a “class diagram”, the layout of the document based on the UN Layout Key, Web Form Box Completion Guidelines, XML specifications (i.e. schema, style sheet), and a UN/EDIFACT message implementation guide. Most of the current work is now directed towards the XML implementations and use of UN/CEFACT’s core component work.

Marketplace Dynamics Are Resistant to Technology

Although EDI was initially successfully implemented by 98% of the Fortune 1000 companies, it failed to gain broad acceptance by SMEs. High start up costs, complex and “cryptic” standards, and the lack of agreed processes were blamed on the standards community as the culprits that hindered implementation.

Not uncharacteristically, a new technical solution, the XML phenomenon, next arrived on the scene and seemed potentially to be the answer to traditional EDI problems. XML is a general-purpose specification for creating custom “markup languages”—giving a set of annotations to text that give instructions regarding the structure of text or how it is to be displayed. XML’s purpose is to aid information systems in sharing structured data, to encode documents, and to serialize data.

However, it soon became clear that regardless of the technology, the most significant shortcoming of EDI, XML, and business-to-business (B2B) exchanges in general, is the lack of agreement on structured data and the independence of syntax—the grammatical rules and structural patterns governing the ordered use and interpretation of information in a particular software application or programming language.

Information exchange standards are generally not implemented in the way they were published because of the overwhelming and confusing choice of available data elements. Instead, implementers are forced to utilize industry implementation guides which limit the number of data elements to be used. But even that has not been enough. Individual business partners further limit choices by negotiating the data elements to be used in exchanges. Frequently, studies found that as little as 3% of the data elements appearing in standards were actually included in exchange agreements among trading partners.

Irrespective of the technology solution, market “positional power” for any organization also complicates and limits the information exchange process. Frequently, the set of data exchanged between any two trading partners varies with the nature of the business process. Strategic positional leverage within a given business domain benefits the more powerful organizations by providing a degree of “dictated simplification” in defining the information to be exchanged. For the less powerful, the only alternative is adapting to multiple exchange agreements when dealing with its full range of trading partners.

Thus, we again see a series of dynamics that limit the ability of solution providers to develop broadly acceptable products that can reach the full spectrum of the business community—including the SME, the true future of eBusiness efficiency.

Enter Core Components

Early XML development work initially proposed creation of a business semantics element, a library of common business objects (CBOs) envisioned as the building blocks linked to a particular modeled business process. In turn, these CBOs would yield schemas for XML messages. This proposal, however, was rejected in favor of a document-centric solution and was based on long-reinforced experience that an individual piece of data might mean different things or have different component parts in different business contexts. As a result, this approach gave rise to a “core component” approach as the semantic foundation for XML business document exchanges.

Core components are reusable data elements found in business documents. They are semantically neutral objects; their actual meaning in business documents depends on their context, provided by the business domain and industry into which they are applied. Core components can be single elements or aggregates, defined as natural collections of core elements. The suggestion is, therefore, that as long as trading partners can relate their own terminology to neutral core components then businesses have a clear basis for achieving interoperability.

The concept behind the core component architecture is to address the lack of semantic interoperability by a combination of structured information and the use of context. The structure uses a series of layers, designed to consider commonality across industry business processes. Further, the structure is designed to support specialization based on the specific use of contexts, i.e., the description of the environment within which use will occur. Sadly, after numerous years of core component development efforts, the standard still does not meet expectations.

The concept of a core component library is quite good. However, like so many preceding initiatives, the component structure continues to evolve and mutate through its use in changes to the structure of the EDI messages, the development of UBL (universal business language), the basis for OAGi (open application groups), the development of Business Object Documents (BODs), and a number of similar industry-specific XML documents. Instead of being based on its business usage, the core component information structure is now based on harmonized semantic structures that are not only different from normalized data but are also dramatically different from lexical structures. This is contrary to the underlying objective of standardization.

The Underlying Complexity

In many quarters there is the thought that the resulting solutions of these different organizations can still be interoperable because they are based on the same semantic foundation of core components. However, we suggest that this is not the case. Although they share parts of the meta-level concepts defined in the core component technical specification (CCTS), each develops an individualized schema level concept. XML solutions based on core components are not better in ensuring interoperability than EDI. In fact, the opposite is true.

To illustrate this point consider UN/CEFACT’s XML schemas for the Cross Industry Invoice. It consists of 44 schemas. The linkage and cross-linkage of that many schemas unduly complicates the task of mapping any in-house data set to the Invoice. Historically, we have seen that for a simple paper-based invoice for a single line item, there are approximately 15 pieces of necessary information. Even considering the paper-based UN Layout Key (UNLK) invoice, there are only about 22 fields to choose from in mapping these 15 items of information compared to the UN/EDIFACT INVOIC message which consists of over 1,200 data elements. A recent listserv discussion highlighted that an industry version of the UBL Purchase Order, based on the UN/EDIFACT ORDERS message (and with mapping requirements similar to the basic data required in the UN/EDIFACT INVOIC), contained more than 830,000 different elements and more than 2 million attributes! Additionally, after consulting with members of the UNeDocs project team, we confirmed that the UN/CEFACT Cross Industry Invoice XML schema contains a similar number of elements and attributes as compared to the UBL Purchase Order. Instead of simplifying the mapping between the in-house data to the exchange structure, the development of core components has merely added to the complexity of the process—leaving users with even more issues to resolve before being able to implement the specification.

The Result—Lingering Implementation Issues

As originally suggested in our paper, for any eBusiness solution to be successful, SMEs must be able to have an available COTS application that integrates their in-house data and that is easily and efficiently interoperable with their trading partners.

Currently, there are no widely acceptable applications available that are based on either EDI or CC/XML. There are some prototype UBL based implementations with very limited scope. And, these initiatives reflect little appreciation for the economics involved in incentivizing an organization with existing EDI implementations to make the significant investment necessary to shift to an XML environment.

Further, because of the overwhelming requirement to process large numbers of XML schemas, and the millions of accompanying attributes, software developers are limited in their ability to economically provide COTS solutions that easily align standardized mappings between XML attributes and organizational in-house data. Consequently, the only available solutions to an SME would be to again deal with the costly and time consuming effort to map their in-house data to the overwhelming numbers of XML attributes that comply with an artificial naming convention that they rarely understand.

From our perspective, XML, CC/XML, and other proposed solutions do not solve the problems of interoperability. Just as with EDI, the underlying problem is that all of these alternatives are nothing more than syntaxes used to package information.

The continuing limitation to simplicity is a common solution to the information to be exchanged. Users keep asking for help in how to map, and implement their in-house data within a business process. The only good news here is that with the long history of EDI implementations, other users can quickly provide the answers, many times with a level of consistency that leads to a level of interoperability. Unfortunately, the same cannot be said for other solutions due to the limited levels of implementation.

And even with this assistance, few SME’s are able to implement an eBusiness environment among their trading partners without some sort of widely accepted and inexpensive solution.

So, What Is the Solution?

Interoperability through simplicity is the critical issue, and current challenge, to expanding eBusiness beyond large organizations to include SMEs.

To provide the necessary interoperability, a new standards concept is necessary. We must remove the complexity within the current standards that define only what is to be exchanged and how it is to be exchanged (data content & syntax). This type of standardization may have been acceptable 20 or more years ago when information was processed in batches. Instead, we must now move towards standards that define in simple terms how to document in a standard way what, when and why the information is required to be exchanged in real-time and in an acceptable electronic format.

The real requirement for these new eBusiness standards and specifications is to meet the needs of the application developers and to provide to the SMEs a COTS solution that replaces their current paper or fax solution. Such a solution must seamlessly and effortlessly, interface with their existing systems.

Current eBusiness standards development does not produce such standards and specifications. That is not to say there have not been honest efforts to develop such solutions. However, the projects were abandoned for a variety of reasons, including an inability to convince the “user community” that change is essentially required to simplify eBusiness.
We feel that it is time that eBusiness standards and specification developers recognize the fact that eBusiness simplification is the only way forward. Then, and only then, can software developers effectively deal with the environment. SMEs, unlike much of today’s “user communities”, are not interested in the underlying technologies. They simply want a solution that is simple, that works, and that is based on standards—something that ensures straight forward interoperability.

On a positive note, Illumonus, and other providers, are addressing these problems by applying a “best of breed” approach to providing a Simple-eBiz solution based on Simpl-EDI and other ISO standards which allow the simple transformation from EDI to XML by replacing the EDI syntax without changing the content structure. This permits the preservation of the link between the EDI standard not only in structure but also in retained experience and knowledge. By using, for example, ISO/TS 20625[3] current users can engage in XML exchanges without the need to replace existing back-end EDI translators. This is an essential element of any solution because it permits the creation of COTS applications that use XML in developing SME-targeted solutions which do not force large companies (hub-type organizations) to replace existing EDI applications. As such, the key dynamic in the current eBusiness marketplace will not be required to make significant investment and change. Instead, they will be positioned to gain additional savings by expanding their eBusiness base with only a minimal investment in the addition of a simple front-end XML-to-EDI/EDI-to-XML processor.

And what about SMEs? They are well positioned to acquire acceptable eBusiness solutions, join the global eBusiness community, and achieve the accompanying economic and business process improvements.