First, there was the internet, which let you publish information for your customers to read. If you were clever, it would let your customers interact with your databases without any special software beyond ordinary browsers. Then came the intranet, which let your own employees interact with your corporate applications without any special software, but kept others out. The next step was the extranet. The meaning of this word has evolved; it now refers to giving selected customers and suppliers restricted access to your applications.

Extranets are taking the supply chain by storm. They are the solution of choice with nearly all retail CEOs and IS managers. An extranet is an inexpensive way to do business. If you are already set up for internet, the extra costs are small. Compared to paper-based orders and telephone follow-ups as to the status, it is less expensive for both parties, because trading partners can interact directly with your corporate systems, thereby reducing both labour and possible errors. Compared to EDI solutions, the costs can also be much lower by avoiding expensive private networks and proprietary software. With an extranet, you need not convince your trading partners to invest in the correct client software, or in someone else's solution. You can give them, at no cost to them, a solution that suits your own needs, and proceed without time-consuming haggling on a common solution or set of standards.

An extranet is fine if you wish your trading partners to deal with you effectively, but this becomes a problem when you need to interact with them. What happens when each of your suppliers and customers has its own extranet? Each lets you reach into its corporate systems to do a number of useful things, but do you then have to learn how each works and what it can and can not do? In the paper-based world, the buyer owns the purchase order (PO), and that document contains the information useful to the buyer. In the extranet world, it's usually the sales order on the supplier's extranet that captures the information, so the supplier becomes the centre of the process. You lose some costs, and you lose some control. So who should design and host the PO and other documents?

There are three possible solutions to doing business on extranet. Each is deficient in some way. We have designed a fourth, called the Transnet. Let us first look at what exists. The first solution is to carry out transactions principally on the supplier's extranet, since the supplier knows most about what is being offered, with what attributes, at what price. A supplier catalog directly connected to the supplier's internal systems is more likely to be accurate than copies maintained on other sites. The supplier usually arranges shipment and has an interest in tracking the settlement.

The second solution is to carry out transactions principally on the buyer's extranet. The buyer has the more detailed requirements, and is paying the cost of the supply chain. It should be the buyer's prerogative to determine how expensive a solution is required, and the onus should be on the supplier to adapt catalog information to the requirements of the buyers, not the other way around. The purchasing document has a lifecycle on the buyer's site before and after the supplier has contact with it.

The third method is to use the format of a common intermediate or to set industry standards. That way, everyone has the same burden to conform to some common requirements. Depending on the compromises made, this can be a lowest common denominator, or a more demanding common denominator. But then it is entirely possible for two parties to support a particular feature that is not expressible in the common transaction language. If all your trading partners agree to a single standard, then your translation only has to be done once. But if there are more than one, your costs begin to multiply and you may be no better off.

When you adopt an extranet solution and/or move away from electronic data interchange (EDI), you are also moving away from most existing standards that have been hammered out over decades to handle transactions in a non-ambiguous and vendor-independent way, and to give them some legal framework. EDI transactions are recognized as legally binding contracts, but extranet forms are, by and large, not. There are good reasons for the expense of EDI, for instance when it comes to legal commitments and to settlement. So you might want to keep EDI for certain critical transactions.

In the longer term, several different initiatives are attempting to standardize extranet-extranet interaction. There are at least ten major standardization efforts going on, with no sign of widespread adherence to any of these beyond their pilot projects.

All these efforts have in common is that two types of standardization are required: catalog standards and transaction standards. The first determines data elements associated with a catalog entry as well as access methods, while the second determines how documents are created, signed, and transmitted.

Many of these standardization efforts are based on XML (extensible markup language). This is a richer language than the internet's usual language html (hypertext markup language). XML is in fact a meta-language, one that lets you define new language elements. For instance, rather than having a line item on an order defined as, say, "cells 2 through 6 of any line in the third table after the third line", in XML you can call it "LineItem", consisting of "ProductCode", "Description", "Quantity", "UnitOfMeasure", and "Price". Calculations, data validation, and other functions can be built into the definition of the document. The XML document contains more information than what is needed for display; it can encode the nature and purpose of the components.

While XML lets you define multi-purpose documents that are as expressive and unambiguous as they need to be, where the document itself enforces business rules, it may also exacerbate the extranet problems it is trying to solve. Every link in the supply chain can invent new languages that constrain its trading partners. An accepted standard based on XML has great opportunity, but different standards and variants can be very different from each other.

It doesn't seem that any given standard will be the winner any time soon (it took decades to develop X.12 EDI standards) or that adherence will be quick or easy. There is an immediate need, one that will last at least a decade, for solutions that allow buyers to deal with multiple supplier extranets and vice-versa.

We call the preferred solution a transnet. This is the connection between one extranet and another, with translation of content and transaction commands in between. A transnet supports interaction not only between browsers and the extranet, but between automated systems on two different sites as well.

Take, for instance, a function like the ability to be notified of specific changes to supplier catalogs. For this to work reliably, it is not enough to ask suppliers to keep a catalog up to date on any site but their own. You need to search their catalogs regularly or have a machine do it. On the other hand, the buyers want to consolidate notifications from all suppliers and set preferences globally. This is best done on the buyer's intranet where, ideally, all supplier catalogs are searchable in a common format, and extranet purchasing interacts with the buyer's internal acquisition or replenishment systems.

The RES transnet purchasing solution includes components that read supplier catalogs on their extranet sites in whatever format they happen to be, html or XML, whether they follow standards or not. All orders are recorded in a standard format in the buyer's database without requiring changes to the supplier sites, and the buyer's business rules are enforced, even when they are not incorporated into the supplier's extranet. The information is up-to-the-second accurate from the databases of the two partners, but the hard work of finding it and integrating it is taken care of by software.

The transnet solution has built-in intelligence to notice and exploit patterns in web documents; it can count table cells, it notices what content lines up, what applies to one line or to the entire page, and it can read and extract information from sentences. Some of this will one day be commonplace "-once everyone agrees to common sets of XML tags and elements, to common sets of ways to combine them into documents, and to common methods for using this information for transactions, -but that agreement may be a decade or more into the future."

In the meantime, the RES transnet initiative provides the best of both worlds. The leaders in extranet use can continue to make their sites easy to use for human beings, while satisfying specific requirements at low cost. On the other side, users of multiple extranets can set up environments that satisfy their own requirements, without forcing trading partners that already have a solution to convert to some other piece of software. Finally, the transnet will compensate for the fact that different partners have chosen different solutions. Its purpose is to insulate the buyer's workbench from the presentation and transaction details of multiple different sites, or the inability of some to support specific functions, and to present it all as a seamless whole.

Using the RES transnet solution, the buyer can select a list of suppliers whose extranet catalogs can be monitored. On a regular basis, these catalogs can be scanned and selected information about products can be extracted into a fast database on the buyer's intranet. The next day, the buyer can then do a global search of all supplier catalogs with a single database, and the information is no more than a few hours old. If the buyer wants more detailed information, it is retrieved from the supplier extranet in real time. The user interface may be the supplier's or the display can be re-formatted dynamically to a format that the buyer is more familiar with. For orders, all the fields in the PO document can reside on one site or the other by mutual agreement and be synchronized automatically. On the buyer's site, the order is a document residing in his database, and those fields that the supplier needs are transferred to the supplier's extranet using the supplier extranet's own screens and programs to write it to the supplier's database. Buyers need only interact with a single system on their own intranet, and take advantage of their suppliers' extranet without worrying about the details.

Dr. Martin Laplante