Over the last few years, a tremendous number of information sites have emerged on the Internet, providing a variety of content, commerce, and collaboration services to individuals, businesses, social communities, and nonprofit organizations. Recently, driven by new business models, new kinds of commerce sites (e.g., private exchanges, e-marketplaces, and portals) have emerged on the Internet. These sites have many similarities to physical commercial marketplaces and financial markets, except that the boundaries are not restricted by physical space or proximity. Instead, the boundary limits are defined by the costs of participation, search and transaction overheads, integration overheads, computational resources, and other frictional issues. In spite of the overheads, the popularity of business-to-business (B2B) technologies is growing at a steady pace, and these technologies are being embraced by new and mature companies for efficiency in business transactions. The evidence is clear; companies completed more than $433 billion¹ of B2B commerce transactions on line (since launch) in the year 2000, and transactions are expected to have reached $900 billion in the year 2001.

We are currently witnessing a trend in the formation of medium- and large-scale B2B commerce sites providing services to diverse businesses over the Internet. Some of these sites are evolving from information portals to offering more complex commerce and collaborative environments in order to enable businesses to trade goods and services efficiently.^2-5 We are also witnessing an era of business transactions extending from the Internet into the intranets of businesses and connecting together the back-end “workhorses” such as enterprise resource planning (ERP) systems, logistics servers, and supply-chain systems, thereby improving the efficiency of order-capture, management, and fulfillment, resulting in improved production on the sell-side (sites for selling) and improved efficiency of purchasing on the buy-side (sites for buying).

In the next section we present some of the emerging business models for B2B commerce, which are the following: sell-side Web sites that promote sales over the Internet, procurement sites to enable low-cost purchasing for buyers, e-marketplaces that bring multiple buyers and sellers together for trading, and marketplaces that are owned privately (e.g., distributors, resellers, and seller consortia), where participation is limited to a few select buyers and sellers. We then discuss the architecture of our platform for B2B transactions targeted toward private exchanges, distributors, and large sellers. In the fourth section we discuss two IBM software offerings that serve as B2B platforms. One of them, WebSphere* Commerce Suite, Marketplace Edition (MPE), is targeted toward private exchanges and public marketplaces and is partly for distributors and brokers, whereas WebSphere Commerce Business Edition (BE), is targeted toward sellers who sell to other businesses. In this section, we also present some of the experiences gathered in deploying MPE. We conclude the paper with a summary.

B2B models and business scenarios

Our goal in designing and implementing the B2B platform was to support a wide variety of B2B business processes. Toward this goal, some of the underlying questions we addressed were the following: What are the core components to enable B2B transactions in various business and industrial scenarios? What are the relevant trading mechanisms? What are the access policies for private exchanges? What are the core business process flows? What are the required integration issues with business processes at the supplier or buyer back-end systems? In this section, we present some B2B business models and also describe some of the most common business scenarios employed by the B2B Web sites.

In recent years, public B2B e-marketplaces gained some popularity by allowing any business to register for a low fee and trade almost immediately. These sites initially were attractive to participants because they aggregated buyers and suppliers, reduced search costs, and promoted price discovery.² However, they face many challenges to generate revenue and survive. First, such marketplaces need a viable strategy to attract and sustain buyers and sellers at the marketplace. Since many of these buyers and sellers already have existing relationships, adding additional value that generates more revenue in the marketplace is challenging. Second, suppliers may risk their business by being exposed to more competition in a public marketplace where buyers could negotiate better delivery dates, payment terms, credit terms, and discounts on goods before purchasing. Suppliers may want to differentiate their products, whereas market makers want to describe products across suppliers in a common fashion to enable a better search and comparison. These compelling reasons and conflicts of interest caused most of these public marketplaces to become unattractive over time.

Very recently, market makers who have understood the industry structure have evolved to provide private marketplaces⁶ on the Internet that capture existing relationships among the buyers and sellers. Private marketplaces are attractive to suppliers because they protect their relationships with buyers. Business relationships in the form of contracts can be established between sellers and buyers at these private sites, and trading can be done based on those relationships. Some of these private marketplaces are owned by a buyer consortium in order to pool procurement functions or out-source procurement to an independent company.⁷ This creates greater buying power. Suppliers not willing to participate may be shut out of the market. To add value and bring in liquidity, private marketplaces based on an industry organized vertically can provide valuable information about the industry.³ In addition, the marketplace can provide better efficiencies and savings through Web-based deal-making for businesses. The marketplace can also act as a portal for communication between members of the industry.

Private trading exchanges are typically owned by large selling or buying organizations or by a consortium of buyers or sellers, by a reseller, or by a distributor. The company that owns a private exchange may have many suborganizations, each acting as its own purchasing agent. These individual buying organizations within the larger company may be dealing with many suppliers, sometimes the same suppliers. Private trading exchanges provide a one-stop shop for suborganizations within a company to pool their requirements and present an aggregated order to the suppliers, thereby increasing the purchasing power to negotiate for better terms and conditions. Again, this setup is favorable to the buying company but not for the suppliers. Other incentives need to be added to attract suppliers. If the company running the private exchange has enough market power, it can force the suppliers to participate. Otherwise a supplier may lose too much business. As an incentive to participate, some private exchanges have offered suppliers services, such as the ability to auction excess inventory on the site to other companies.

In Figure 1, we illustrate two models of private exchanges. In the buy-side private exchange, a buying consortium owns the exchange mainly for procurement functions. In a sell-side private exchange, the selling consortium owns the private exchange for sales. Both require a platform to support multiple buyers or multiple sellers, or both, and various forms of trading mechanisms such as requests for quotes (RFQs), contract negotiation, contract-based buying, catalog-based fixed-price⁸ buying, and auctions.

Figure 1

In a buy-side private exchange, the buyer can purchase through the catalog based on fixed prices, through an established contract on specific products, or through an RFQ-based negotiation process for one or more product items. For fixed-price purchasing, the buyer browses an aggregated catalog at the private exchange Web site. The buyer adds items to an interest list for current and future repeat purchasing. Once this is done, the buyer places an order and specifies the preferred shipping information. The order is sent to the private exchange Web site for processing, which captures the order,⁹ and routes it to the proper set of suppliers by disaggregating (splitting) the order.

In a sell-side private exchange, one or more sellers own and manage the marketplace. The sellers wish to use this exchange as a sales channel for primary and secondary goods. The exchange maintains an aggregated seller catalog and a collection of contracts between sellers and buyers. The sellers can sell their inventory via contracts, through fixed-price sales, or via auctions for sales of surplus goods. The trend recently has been toward large sellers and distributors, who manage a large¹⁰ catalog of products and wish to be connected to third-party supplier systems for quick order fulfillment.

Figure 2 illustrates a distributor model, where the Web site provides buyers with advanced purchasing capabilities. The distributor Web site connects to manufacturers and suppliers so that orders can be sent automatically to them for replenishment whenever inventory runs out. The buyer is able to see the distributor's price and available quantity information on products. In this model, buyers cannot transact¹¹ business directly with the manufacturers and suppliers. All orders go through the distributor and are processed manually or automatically. Distributors typically negotiate with manufacturers for better price discounts based on relationships and offer incentives for buyers to purchase through them. They also handle invoicing and logistics, which helps in reducing costs for the buyers.

Figure 2

Architecture

In this section, we provide a summary of the design criteria for building a B2B platform for marketplaces, private exchanges, and sell-side distributors.

Design criteria. There are many design criteria to consider when creating, developing, and deploying a B2B site. Some of the core criteria are as follows:

• Capturing member profiles and representing people and their roles in businesses are crucial requirements for B2B transactions.
• Catalog aggregation across multiple suppliers for private exchange and distributor models of commerce are necessary to provide one-stop shopping.
• Access control on the catalog and price information is required to limit what a buyer or a seller (or a person with a role) can do or view in the system. Access control plays a very important role in private exchanges. Access control on information and trading is crucial to allow only certain members to trade.
• Search on catalog: Search of product descriptions and product offerings that contain many attributes is complex. The search criteria include, among others, product identification (ID), many product attributes, and supplier ID.¹² A good parametric search engine, which empowers the buyers to quickly narrow the search to products of interest, is crucial for the success of the B2B site.
• Framework for trading: A platform for supporting private and public exchanges needs a flexible framework to instantiate auctions, reverse auctions, exchanges, and RFQs, and to enable multiattribute, multiround, and multistage negotiations.
• Order aggregation, order splitting, and order confirmation: Orders can be aggregated across multiple buyers, and the distributor can negotiate additional discounts for the buyers. Orders placed by buyers should contain items from one or more suppliers, and an order needs to be split among the suppliers. Similarly, responses have to be gathered from the suppliers and order confirmations sent to the buyers.
• Scalability: The issues of scalability are many. For example, the typical catalog sizes can be 1–50 million products in a large private exchange. Each product can have an average of 20 attributes, and the search on such a catalog needs to scale with the growing catalog size. Components such as auctions, RFQs, and orders should scale with the number of hardware nodes.
• Mobile e-business: With mobile commerce evolving at a rapid pace,¹³ some of the participants will use more than one device (including a Web browser) to access information from the commerce site and receive notifications on business transactions. For example, devices such as personal digital assistants (PDAs) and pocket PCs are inexpensive and computationally powerful.¹⁴ Support for these devices is of tremendous value for sales and purchasing people who are mobile and need the flexibility to handle simple business transactions and notifications such as order confirmations, order cancellations, and order statuses.
• Evaluation mechanisms and intelligence: Algorithms for bid evaluation and bid-ranking must be provided to help the buyer select among complex, combinatorial bids in multiattribute, multi-item RFQs, reverse auctions, and exchanges. Pricing algorithms play a very important role in B2B contracts, auctions, and double auctions. Reporting functionality is a crucial requirement for gathering intelligence, decision-making, negotiating new contracts, and evaluating past transactions.
• Integration to back-end systems such as ERP, logistics, inventory, and pricing servers: The requirements apply to sell-side and buy-side private exchanges, where orders are exported from the exchange to the supplier back end.

Architecture components. The architecture, shown in Figure 3, illustrates the various components in the platform. The platform shows the core middleware commerce components, on top of which are the various commerce application components for B2B transactions. In this subsection, we describe some of the components that are crucial to enabling transactions in B2B sites.

Figure 3

Membership. The success of any B2B site depends on how well it captures the structure and representation of businesses and the roles of people in the businesses involved in sales, purchasing, or approval. Representing roles of participating B2B organizations (buyers, sellers, administrators, and regulators) is a crucial requirement. Membership information is typically used for access control, ownership of documents and information created at the Web site, credit verification, order placement, approvals on purchases made by the buying organization, shipping information, and notification preferences. Membership structures can be mapped on standard Lightweight Directory Access Protocol (LDAP)¹⁵ or Universal Description, Directory, and Integration (UDDI)¹⁶-style models of representing organizations and people. In Figure 3, we show the membership component as being pervasive and universal across all the components in the platform.

Catalog. For purchasing and sales, a catalog is an integral part of the platform. The catalog in a private exchange should provide a unified view of the products traded, and the mechanisms for trade, to both buyers and sellers. In our design, the catalog logically separates the notion of items (i.e., the description of products) and their trading positions as expressed by the various parties in the marketplace. This concept is as follows: The product category and product template constitute the core catalog, and the trading mechanisms are linked to the catalog. The trades are initiated by identifying a product to be traded in the catalog, by selecting a trading mechanism, and by other parameters of bids and offers such as quantity being traded, price, payment or fulfillment terms, and period of validity of the trading position. In some special cases, such as an RFQ process, the buyer might create a new entry in the catalog and use the RFQ process to negotiate.

The platform defines the categories and product templates (i.e., the set of attributes for each product in the marketplace). Suppliers and catalog administrators can add their products (product descriptions) to the catalog by using the defined product templates. Suppliers are allowed to define their own product attributes from a dictionary provided by the platform. However, only catalog administrators can modify or add to the attribute dictionaries. Role-based access control on the catalog and other components is a crucial requirement and is part of the design, where certain members can modify or create entries in the catalog, and certain others can only view parts of the catalog.

Search and navigation. Catalog search is a crucial component in the B2B site. In a very large catalog with very many attribute types per product, a good search engine can provide the buyer access to products of interest. The catalog consists of product descriptions, which contain a large number of attributes, and the attributes could have single or multiple values.¹² In a typical business catalog for private exchanges, it is very common to see millions of catalog entries, and each product item in the catalog can have anywhere between 10–40 attributes describing the properties of the product and the offering information such as price(s), quantity available to promise, expected delivery time based on shipping location, and other relevant information. The platform supports a variety of search techniques ranging from simple text searches to more complex multiattribute searches, which help the buyer narrow the number of products based on attribute values.

Request for quote. RFQs are the most common mechanisms used for business procurement. RFQs are a form of reverse auction,¹⁷ allowing the buyer to negotiate price, product attributes, and terms and conditions, and to collaborate with suppliers on the specification of services and custom goods.^18-22 Therefore, they are the preferred mechanism for expensive items, custom goods, services, and direct goods (i.e., goods that are directly used in production).

A buyer can initiate an RFQ to solicit quotes for a specific set of goods and services. These goods could be defined in the catalog for which the buyer wishes to find a better price or negotiate a long-term contract, or a custom good or service could be defined for which the buyer wishes to collaborate with the seller for purchasing. In our design we have considered the issues of negotiation across multiple attributes, where the buyer can specify which product attributes are negotiable and which are not.

A buyer might want to send an RFQ to specific sellers instead of making the RFQ public. Our design takes into consideration a private RFQ model, where the suppliers are preselected and targeted by the buyer, and only those selected suppliers can respond to the RFQ. If the RFQ is public, then every registered supplier in the private exchange can respond to the request. RFQs could be sealed (only the RFQ creator sees responses) or open (all the participants can see all the bids, with possibly some information, such as identity of the suppliers, masked). Once the RFQ is evaluated, winning bids can be converted into a single, one-time order or a contract to support repeat purchases.

Contracts. Most B2B transactions in the physical world have been driven by short- and long-term contracts. A contract is a document with prenegotiated terms and conditions between two or more businesses to trade goods and services over a period of time. The terms and conditions include pricing, delivery, quality, payment, credit, and discounts. Contracts play a very important role today in B2B transactions over the Internet. A majority of transactions in most B2B sites are mainly driven by contracts. Private exchanges, through contract mechanisms, capture the existing business relationships between buyers and sellers. Our platform provides a mechanism for new contracts to be established and to renew or extend existing contracts.

Auctions. The platform provides a configurable forward auction component. Based on our study of auction methods deployed around the world,^18-26 we classify auctions using a few attributes or parameters such as interaction format, bid management policies, bid to price mapping policy, and auction closing rules. The implementation of the auction software is modularized according to these parameters, and each of these modules can usually be configured independently. This allows the auction component to support hundreds of distinct auction styles. Auction mechanisms are crucial for primary and secondary markets, as well as for sell-side private exchanges to sell excess inventory and ascertain the prices in the market. Lately, reverse auctions have become very popular for B2B in the area of procurement.

Exchanges (double auctions). There are many variants of the double auction or exchange mechanisms.²⁷ The different variants for exchanges are well-suited for different market conditions; for example, the continuous double auction is best if markets are liquid. Walrasian tatonnement can be used if it is important to clear all positions and set the opening price in financial and commodities markets.²⁵ The platform allows different goods or commodities to be traded simultaneously using different exchange mechanisms. Furthermore, different exchange mechanisms can be selected for a given commodity or trading post based on market conditions and other external events. Some of the financial markets open with a Walrasian tatonnement for establishing an opening market price (after the previous day's close) and then switch to a continuous double auction (CDA) during normal trading hours.

The double auction market has tremendous advantages for trading primary and secondary commodities over the Internet such as bandwidth, energy, and agricultural products (meat, corn, wheat, and others). In some of the sell-side models, trading using the double-auction mechanisms provides sellers with a channel to get rid of excess capacity by posting offers and obtaining matches in real time. The exchange does a match of the bids and offers, and orders are placed automatically to the sellers. The process can also be interrupted, and approvers could approve the orders before they are placed.

In B2B private exchanges, unlike the stock and commodities markets, the emphasis can be on multiattribute bids and offers. A bid can specify the price, quantity, quality constraints (e.g., quality > 5.0), delivery constraints (e.g., delivery date <= June 10, 2002), and so on. For such a bid to be matched with one or more offers, a matching algorithm that takes into account attributes and constraints is required. For the platform, we have developed “multiattribute” matching algorithms that scan the “closeness” of the bids and offers and match them. The advantages are in their application to trading of complex commodities such as petroleum, plastics, natural gas, and bandwidth, which typically contain multiple attributes for trading.

Flexible business flow. Business processes vary between companies, and a B2B e-commerce platform has to adapt to a wide variety of business models and processes. In our platform, a lightweight workflow engine, called FlexFlow, provides this flexibility. FlexFlow represents business processes as a set of state machines. It enhances the finite state machine model with some features borrowed from Unified Modeling Language (UML**) state transition diagrams. The business process can be restructured by simply modifying the state machine and ensuring that it is valid.

The FlexFlow engine uses the state-machine descriptions to directly control the execution of the business processes. It also generates controls for user interactions on Web pages based on the state-machine description. Different versions of an application can be generated by visually editing its FlexFlow description, with minimal incremental effort in rewriting application software or related Web pages. FlexFlow thus provides an efficient way to customize the platform to variations in business processes and to support different versions of business processes for different sets of organizations, users, or devices in the same e-commerce system.

Each process state machine has a set of states and a set of transitions between the states. States are symbolic representations of the condition of a business object such as an RFQ or a quote for an RFQ. Transitions are a tuple of <action, role>. An action corresponds to an atomic transaction, implemented as a command in the WebSphere Commerce Suite application framework. Role corresponds to the role of the party issuing the command, such as buyer, seller, or system.

When an event occurs in the context of a business process, FlexFlow uses the process state machine to start the appropriate action. An event can be a user action such as pressing a button on a Web form, a message from an external system, an event from an internal component such as the scheduler, or a coordination message from another business process. The FlexFlow engine checks whether in the given state of the process, the action corresponding to the event can be taken by the role of the originator of the event. If so, it executes the action and updates the state of the process; otherwise, it throws an exception. Once the action is correctly executed, the FlexFlow system informs the user interface of the next set of valid actions for that user's role, and this information is used to dynamically generate controls on the user interface. If the action fails, FlexFlow rolls back the state of the process.

Marketplace Edition and Business Edition

WebSphere Commerce Suite, Marketplace Edition (MPE)²⁸ was designed to provide a platform for private exchanges and public marketplaces in various industries. The WebSphere Commerce Business Edition (BE) is geared toward B2B sell-side operation. In this section we outline some of the differences in the two platforms and our experiences with deploying MPE.

In BE, buying is the only function provided to end users; the setup of sales or trade mechanisms is a complex process targeted for the sell-side site administrators. In marketplaces, end users are businesses that wish to buy or sell. MPE provides symmetric processes for all parties in a trade; for example, in MPE, the process for buying an item from the catalog has a corresponding similar process for offering an item for sale, and the process for requesting quotes for a purchase has a corresponding process for offering to sell. Order management in BE is much richer in function than in MPE. It provides order capture, order status, order cancel, repeat orders, order reject, back order, and a variety of functions such as analysis tools and collaboration tools, crucial for B2B transactions.

MPE uses a symmetric model of the catalog, where product descriptions defined by the catalog administrator are maintained. Both sellers and buyers could access the catalog and create requirements on what to buy and what to sell. Sellers can post offerings based on the product descriptions to the catalog and select the trading mechanism of choice. Likewise, buyers can post requirements in the catalog in the form of an RFQ, and also create contracts on one or more items in the catalog. In BE, the catalog does not aggregate products from multiple suppliers but separates them by stores.

BE supports a notion of a package, which is a collection of items that have an SKU, or stock keeping unit (the product identification), and packages are bought as a whole. It also supports a bundle, where the catalog items are loosely coupled, and buyers can place orders on one or more items in the bundle. These features are not supported in MPE. In both platforms, a parametric search is offered to buyers to narrow the number of catalog items of interest. This advanced search feature is based on ranking catalog items on attributes and value ranges.

Businesses use a variety of mechanisms to buy, sell, and trade goods and services. MPE supports most classes of these trading mechanisms. They include fixed price, contracted price, auctions, RFQs, reverse auctions, and exchanges. In BE, the trading mechanisms are restricted to the following: fixed-price and contract buying from the catalog, forward auctions, and single-supplier RFQs.

A novel distinguishing²⁹ feature of MPE has been the exchange component, which is a double-auction mechanism for trading commodities or any well-defined goods and services. The design was based on trading-post concepts from financial markets. The concepts were extended further to allow multiple matching and pricing algorithms to run simultaneously and support thousands of transactions simultaneously on the system.³⁰ For example, a private exchange for energy products could use the enhanced trading-post concept by trading oil on a different trading post from trading power or trading natural gas. Each trading post³¹ is configured with a different pricing and matching algorithm and could also be run physically on a different machine, thereby supporting scalability and speed.

In MPE, contracts are just one of the trading mechanisms enabled to determine prices, whereas in BE contracts play a central role in the architecture and operation. A contract has a number of terms and conditions that control the buyer's interactions and transactions with the seller. They govern the look and feel of doing business, the items in the catalog that the buyer can view, the prices that are shown, the shipping mechanism used, and the returns policy enforced. In MPE, contracts can be negotiated on line for one or more products or product categories, and any number of contracts can be established between buying organizations and selling organizations.

Experience with MPE. E-marketplaces support nearly all major types of B2B transactions, such as sales via catalogs, contracts, and auctions, procurement via reverse auctions and RFQs, and trading via exchanges. Therefore, a platform, such as MPE, that is made for public marketplaces can also be easily deployed for private exchanges, sell-side, and procurement. Our customers used MPE to create public and private marketplaces, sell-side and procurement sites, exchanges, and other variations on these. The companies included both established “brick and mortar” industries and “dotcom” startups.

Many dotcom startup customers tried to capitalize on the perceived novel potential of e-marketplaces to launch new businesses. The investment money available for dotcom businesses was drastically reduced in 2001. The problem was compounded by limited acceptance of open public marketplaces by suppliers. However, the technology for public marketplaces is also useful for private exchanges. Thus, many of these customers were able to switch from being marketplace owners to supplying private exchange and other B2B services to traditional businesses, while still being based on MPE. MPE has been deployed on single-tier and multitier configurations. The multitier configuration supports load-balancing of requests among the MPE servers running on multiple hardware nodes. Load-balancing is crucial for businesses running the private exchange in order to provide reasonable response times for the participants along with reliability.

The difference between public and private exchanges brought other challenges as well. Public marketplaces run by dotcom companies often had no existing infrastructure. Very little integration was required since no legacy order management or fulfillment systems existed. In contrast, private trading exchanges are usually run by mature companies with existing infrastructure. This requires the B2B platform to be offered on an expanded set of operating system and database platforms. It also requires better integration with existing customer systems and internal e-business systems (back-end systems). Integration can be in the form of a more robust set of messages to both front-end buy-side tools from procurement companies as well as messages for existing back-end systems for ERP. Thus, to meet these requirements better, BE has support for multiple hardware and operating systems and different databases. It also provides strong connectivity solutions.

Summary

We presented the architecture of a platform for B2B private exchanges and seller sites (sell-side) that support a wide variety of business functions such as membership, role-based access control, catalog, catalog search, purchasing, contracts, trading mechanisms for negotiation and price-discovery, order placement, and order-status tracking. We proposed a collection of core components for fostering business interactions and collaborations. Most of the components described in the platform were incorporated into two IBM products, MPE and BE, in order to address the requirements for private exchanges and seller models of e-business. MPE has been deployed at many sites and is currently being used for private and public marketplaces over the Internet. We have gathered sufficient experience from the deployments and a good understanding of the critical business needs. We plan to use the experience we gained to design the next generation of B2B platforms with advanced business intelligence and collaboration tools.

**Trademark or registered trademark of the Object Management Group.

Cited references and notes

Accepted for publication January 9, 2002.