It's incredible that the Internet age was in its infancy just a decade ago, back when Web browsers had been recently introduced and rapidly adopted, transforming the way business is conducted. In fact, the pressure to take advantage of B2B solutions to dynamically interface core systems with trading partners didn't really pick up steam until the mid to late 1990s. And now, the focus has stepped beyond the requirement to merely have a corporate Web site with dynamic, browser-based application interfaces. The latest stage of e-business involves XML/Web Services, marketplace integration, and Internet-based EDI solutions. This most recent evolution of e-business can reap tremendous benefits for those organizations able to implement these technologies, but there's typically a learning curve and some planning required to effectively integrate existing legacy application environments.
There are two distinct paths that today's IT manager must follow to keep an organization competitive and productive with the capabilities of the Internet, both now and in the near future. First, it's important that managers understand what is technically possible with XML and Web Services as well as EDI modernization solutions with EDI-INT. Designing (or selecting) an e-commerce framework that can tightly integrate to the back office while providing external interaction over various Internet channels--using Web browsers, XML, and EDI--is an essential step.
Second, depending upon the vertical industry focus of the business, there are likely standards bodies, e-marketplaces, global registries, government regulations, or e-partnership opportunities that will affect--and even drive--the implementation of this technology for an organization. In this article, we'll look at some examples of these, such as the UCCNet Global Registry, HIPAA in the healthcare industry, and the Covisint marketplace for automotive suppliers. If your business is being mandated to conform to or integrate with an entity or governing body such as these, then the Vertical Marketplace Integration discussion will be especially meaningful.
Understand the Technology Options
Anyone in IT these days without a basic understanding of XML may have just crawled out of a bomb shelter. XML has been defined and discussed and analyzed in just about every issue of every technology magazine--not to mention in presentations at conferences and user group meetings--for years now. (See the latest from MC Mag Online: "XML for Dummies, Idiots, and People Like Me Who Just Don't Know."
Most software vendors have incorporated XML into their products. Let's just say it's a way to describe data in a standardized, platform-independent way and should be the mechanism that you use to exchange transactional data with your trading partners in the future. In addition to the XML meta-language for data, there are some other components to learn, such as document type definition (DTD) or XML schemas, which describe the data definitions and relationships with an XML document, and Extensible Stylesheet Language (XSL), which transforms XML into another format, such as an EDI document, an HTML Web page, another XML document, or possibly a map to database records. For more information on XML, refer to www.xml.org.
The key point, for the purposes of this discussion, is that XML provides a common language so that you can use the Internet to exchange transactional data between your production systems and the systems of your trading partners. A number of organizations have implemented simple two-way XML solutions in which they exchange XML documents via one of the Internet protocols--HTTP (interactive Web), FTP (file transfer), or SMTP (email). When two entities decide to use XML to transact electronically with each other, they must agree upon specific transactions and the layout of the XML document; this can sometimes be a time-consuming effort. Many industries have formulated standard transactions and XML formats that you can use as a starting point. In XML lingo, this is often referred to as the "message payload." To see some of the standards that have been defined for various industries, check out www.xml.org and www.openapplications.org.
Ellett Brothers, for Example
Ellett Brothers is one of the nation's leading distributors of outdoor sporting goods, with annual sales of $150 million, primarily in the areas of hunting/shooting, archery, and camping equipment. They sell their goods through a number of different sales channels. Over 100 inside sales reps and 30,000 retail outlets carry Ellett products. In addition to selling through these traditional channels, Ellett does approximately 20% of their order count (1,100-1,200 orders daily) via e-commerce, with electronic transaction processing between various online retail outlets and their externally hosted ISP dealer site.
Because Ellett transacts electronically with a variety of different external entities (such as Outdoor Interactive, Eders, Gear Out, and TruServ), they have an e-commerce framework, using LANSA, that supports different formats. This e-commerce framework supports two-way, automated transaction processing over the Internet, using XML, EDI, flat files, XLS, and even Microsoft Access Database files (MDBs). All of the processing occurs on their iSeries with direct integration to their Daly.Commerce ERP system. Because Ellett was an early adopter of this technology, they have supported whatever format their partners have requested for B2B automation. However, going forward, they hope to standardize on XML. Figure 1 illustrates the Ellett solution.
Figure 1: The Ellett Brothers e-commerce framework supports two-way automated transaction processing.
This dynamic, system-to-system method of conducting business is quite profitable for Ellett Brothers, and they have plans to move forward very rapidly with the e-commerce side of their business. In the coming months, they will be extending their e-commerce framework to exchange product, order, and invoice information over the internet with GSI Commerce (which will include CBS Sports Line and 14 other Web sites), DoItBest, Ace, TruValue, and Gaylaan.
What About EDI?
Electronic data interchange (EDI), the original solution for paperless, electronic transaction processing between trading partners, has been around for almost 30 years, which is an extremely long time in computer years. A large number of organizations have implemented EDI, and it's predicted that approximately 20% of businesses are doing EDI with 20% of their partners. In some cases, large hubs such as WalMart have dictated that all of their suppliers do business using EDI. This demand has helped to securely position the technology.
There are two flavors of EDI--UN/EDIFACT, which is the primary standard internationally, and ANSI X.12, which is the North American standard. Standards organizations exist for both types, and the specifications for transactions have been well-documented and established, with a number of different versions released over the years. Translation software (to decipher the cryptic EDI documents) is required on each trading partner's system. EDI has historically been implemented as a batch processing solution, with batches of orders or invoices being sent to the trading partner once or twice a day. Also, typically a value-added network (VAN) intermediary has been used to transmit the orders between trading partners, which can be expensive for large-volume transactions. In the past, dedicated or dial-up lines to the VANs were set up. However, today, many VANs are providing Internet access as well.
Many industry analysts predict EDI's demise and its replacement with XML and Web Services solutions over time. No doubt this is where the world is going, but how quickly? I suspect that EDI will be around for a long time. There are too many installations in place that work very well, and there's too much time and money invested. Modernizing EDI solutions can be a good interim step to alleviate expensive VAN charges and to take advantage of the dynamic nature of the Internet to exchange EDI transactional data in real time.
The EDI-INT (Electronic Data Interchange--Internet Integration) specification is intended to address the need to exchange EDI documents over the Internet securely, using standard Internet protocols such as SMTP and HTTP. Specifically, the EDI-INT AS1 specification outlines how to use secured email via S/MIME over SMTP to send EDI attachments. EDI-INT AS2 outlines process-to-process (real-time) EDI based on secured HTTP using SSL (128 bit encryption). For more details, visit the Internet Engineering Task Force site. You can also look for Mike Faust's upcoming article on this topic.
The Next Generation: Web Services
Web Services have widespread industry support. From IBM, Sun, and Microsoft to the major ERP vendors to technology and e-commerce firms, essentially all the major vendors in the technology industry are basing their future product platforms around Web Services. Research firms have surveyed organizations, and statistics show that the majority of large corporations are committed to Web Services as the future for e-business.
The key specification for Web Services is Simple Object Access Protocol (SOAP), an XML-based messaging protocol with a number of components, such as the SOAP Message Structure, which includes specifications for an electronic envelope, header, and message payload (XML). Web Services also uses Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI) registries. Another key specification for Web Services, and an extension to SOAP, is ebXML (www.ebxml.org), which is under development by UN/CEFACT and OASIS and has already been selected by some industries as their standard e-commerce messaging protocol (more on this when we talk about Covisint).
It is not necessary to delve into the complexities of the SOAP specifications to understand what Web Services will do for your organization when your systems and the technology are ready. Some have likened Web Services to the next stage of evolution of both EDI and distributed application solutions. When Web Services are realized, the functionality and information on your external trading partners' systems will eventually be exposed as callable and accessible routines for your own applications (and vice versa). To understand the concept of the UDDI registry, think of it as an electronic Yellow Pages. Your application software can go to the UDDI to find out how to talk to your trading partners' computers. When this level of interoperability between systems can be achieved, many sophisticated applications and operational efficiencies, both with the supply chain and internally, will be possible. There should never be the need to re-enter details that have already been entered into a system (whether it is inside your organization or not), and this will result in less errors and far less data entry. Immediate access to information about order status, deliveries, finances, insurance eligibility, or whatever is fundamental to your business will be available regardless of the actual system it is housed on. Access to external modules, like tax calculators or currency conversion, will be accessible by external callable interfaces and may not need to be installed or coded on your system in the future.
Both IBM and Microsoft are already offering UDDI registries, which are synchronized daily. For more information, go to Microsoft's Business Registry Node page and IBM's UDDI Business Registry page.
Although this is undoubtedly the way of the future, most organizations will not be ready to deploy full-blown Web Services just yet; however, this should not stop you from taking advantage of the many benefits possible with B2B automation solutions. Your organization may want to move into e-commerce transaction processing by using two-way XML solutions as in the Ellett Brothers example. Or maybe you'd prefer to modernize EDI by processing over the Internet, with a plan for how this will eventually evolve into a Web Services solution.
Vertical Marketplace Integration
Depending on the business focus of your organization, there may be standards, marketplaces, portals, or registries that you will need to understand to exchange information electronically. Here are a couple of examples to give you an idea of how these mandates and initiatives are affecting organizations in different industries.
UCCnet
UCCnet is the Uniform Code Council's not-for-profit, tax-exempt subsidiary, providing e-commerce standards for the 23 industries served by the UCC. In partnership with EAN International, UCC has more than 1 million member companies and supports more than 5 billion scanning transactions per day. UCCnet is a global marketplace for registering any barcoded product for access by manufacturing, distribution, and retail organizations. The UCCnet's mission is standardization of item information and item identification, along with a central Internet registry for synchronization of product information--and all of it accessible by all trading partners. The food industry has been mandated to comply with UCCnet this year.
If your organization needs to register products with UCCnet or retrieve product information, you may submit your electronic transactions in either XML or EDI format. UCCnet provides specifications for the acceptable transactions and their format. In addition to enabling your systems to exchange these transactions electronically, providing the appropriate data (including GTIN--Global Trade ID Number, matching your item number) may be a challenge if your legacy system database does not contain all of the necessary item information. Products are available on the market to assist with UCCnet compliance, including both e-commerce transactional interfaces and item information.
HIPAA
Anyone in the healthcare industry will certainly know what HIPAA is. It stands for Health Insurance Portability and Accountability Act. Passed by Congress in 1996, it mandates many reforms in the healthcare industry, including the requirement to standardize on electronic transactions for exchange of patient information. The healthcare industry is actually the largest sector in the U.S. economy, representing $1 trillion in expenditures annually, so this government regulation affects many organizations. Even organizations that self-fund their employee benefit plans may be affected.
The original intent of this act was twofold: to protect the privacy of patient records and to save the healthcare industry literally billions of dollars by standardizing code sets and health identifiers, allowing the exchange of standard electronic transactions, and eventually eliminating expensive paper-based processing. The dates have been extended, and the current date by which all organizations must be HIPAA-compliant is October 2003, with testing by April 2003.
The standard put in place by the government is, surprisingly, not XML, but EDI ANSI X.12. Twelve-key transactions for exchanging patient inquiries on eligibility and claims status, as well as claims processing, enrollment, and premium payment, have been defined. Covered entities must use these transaction types when exchanging this type of information between external entities.
Because there are hefty fines for organizations not compliant by the due date, many are busy looking for solutions to enable e-transactions. Unfortunately, though, they are not all concerned with ensuring they achieve a level of improved operational efficiency in this first implementation. In order to achieve this, effective integration to their legacy systems environments is key. Use of the Internet to exchange this information is also an opportunity to save on transaction costs.
Covisint
The Covisint marketplace was originally conceived and funded by many of the big automakers, such as Ford, General Motors, Daimler Chrysler, Nissan, and Renault, who wanted to produce a single, global B2B supplier exchange for the automotive industry. The primary goal of this e-commerce initiative was to realize streamlined supply chain efficiencies, ultimately producing cost savings.
Since its beginnings in early 2000, Covisint has become an independent entity, offering a number of online services to the automotive industry, including auctions, product catalogs, quote manager, and portal services. Covisint was also intended to serve as a transactional portal to replace EDI with XML and Web Services for the automotive suppliers. Some of the big automakers are pushing their suppliers to transact electronically, using XML, with Covisint. Because the Auto Industry Action Group (AIAG) has sanctioned ebXML and OASIS (XML) as their standards for the industry, Covisint is now using these standards as its interchange strategy with suppliers and OEMs.
For many automotive suppliers, Covisint is just one new e-channel that they must conquer in their drive to streamline their business through effective use of e-commerce. Figure 2 illustrates the vision of one such automotive supplier who envisions exchanging both XML and EDI over the Internet with intermediaries such as Covisint as well as with suppliers and vendors directly.
Figure 2: This is an example of an automotive supplier with multiple e-channels.
Application Integration Considerations
In moving forward with any of these new technologies, a critical success factor will be how well you have designed the integration to your back-end legacy systems that are still the life and breath of your day-to-day business operations. For many of us, that means implementing these solutions with tight interaction to the iSeries, RPG or COBOL, and DB2/400-based application suites. With the press and so many vendors touting solutions that need to run on Windows and Unix servers, sometimes this can be confusing; however, all of these capabilities are available for the iSeries platform using both IBM and IBM iSeries Business Partners' software solutions. And it goes without saying that you will have a much easier job of accomplishing dynamic integration to your business applications suite if you implement your Internet solutions on the same platform. Maintenance, over time, will also be easier and less costly for your organization in this scenario.
Summary
The Internet and the rapid evolution of Internet technology has changed the way we must do business. It's crucial that we in IT stay abreast of these developments so that we can play the all-important role of assisting organizations in staying current and competitive in today's challenging marketplaces. The technical capabilities of XML, EDI-INT, and Web Services are important to understand for this current stage of e-commerce, but equally important are the movements and pressures within the vertical industry of your business. We've looked at a few examples--UCCnet, HIPAA, and Covisint--but there are many, many more, in just about every industry imaginable, that may be opportunities for your organization to move forward electronically.
Eden Watt is LANSA's Director of Professional Services for North America. She and her project teams have been involved in the management and design of some significant e-business deployments, including many of the early iSeries-based Web sites, wireless, and even Web Services solutions. Eden has written numerous articles for technology publications and is co-author of the new book Understanding e-Business Application Integration by MC Press. She is a regular presenter at COMMON and frequently speaks at conferences and user group meetings. She can be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it..
Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. 
LATEST COMMENTS
MC Press Online