The Promised Land

Agent technology may be the key to delivering the full business value of participation in e-marketplaces

By Eric Adams

E-marketplaces have emerged only recently, but they're already beginning to change how business is done by giving the enterprise a more dynamic, finely grained mechanism for procuring goods and services. Consequently, many suppliers that are not the sole sources of specific goods may soon encounter increased competition because of more liquid markets. But at the same time, they will also see more opportunities for innovation, which may take the form of new business models, manufacturing processes, or social networking. That's the whole idea behind a market-driven economy: that competition drives innovation.

The evolution of the information economy will generate many new such e-marketplaces, and along with those markets, more opportunities. If you think "outside the box" for a moment, you'll soon realize that a few new markets may go beyond raw materials. What if you could trade in blank CD-ROM futures, or perhaps concrete futures? What about an e-marketplace that gave you the ability to efficiently access the global market, optimizing across many dimensions - for example, to find a provider with a net cost to your enterprise that was significantly lower when shipping, taxes, tariffs, quality of product, and time to delivery were all taken into account?

Clearly, e-marketplaces have many interesting implications. But before they can reach their full potential, they will have to integrate with enterprise resource planning (ERP) systems in an automated fashion - which is where electronic agent technology plays a potentially important role.

Enterprise Integration With Markets

As we all know, marketplaces are networks where goods and services are contracted for purchase and sale. Today, most business-to-business (B2B) e-marketplaces are driven by the ERP systems that many medium and large organizations implemented in the last decade. ERP systems encouraged supply chain integration and vice versa; however, supply chain integration requires that the chain itself be fixed and long lived. Consequently, because of the lack of standards at the product level, each integration effort was time-consuming, expensive, and required custom coding between each participating enterprise.

The touch points between ERP systems and e-marketplaces are the requirements lists on the demand side and sales forecasts on the supply side. The agent-mediated integration of these touch points is where agent technology can play a crucial role. By speaking a "common language" independent of both industry verticals and horizontals, these agents will ease integration.

An example would be an automobile manufacturing company that needs to procure both office supplies and outsourced automotive components. These procurements involve very different products, but they may share the same descriptive qualities and follow the same general purchasing processes at an abstract level. Agents can buy and sell across organizations in a similar fashion, leveraging relationships that are more web-like than hierarchical.

In this approach, buyers or analysts will still need to manually validate, and if necessary, correct requirements lists that are generated by ERP or supply chain management (SCM) systems. However, after validation and correction, the entire requirements list is sent to a coordinating agent (CA), which "knows" which markets offer which types of goods for sale. If multiple markets support the same goods, the CA will send requests to agents in each market to work on its behalf. Agents sitting on "general markets" may receive all lists of goods, while agents at specialized markets may receive only specific types of goods to look for. The CA then chooses recommended transactions to fulfill a forecast and alerts the human trader to confirm the transaction. If the trader confirms a transaction, the CA updates the ERP system, and the cycle can continue. With this more efficient mechanism in place, companies can lower costs by consolidating work and making more informed purchasing decisions, letting employees focus on more productive, rewarding work.

As you may have noticed, the key to integrating ERP and e-marketplace touch points is the trader, who can modify the information sent to the agents. That capability gives traders the power to manipulate the perception of their enterprises within a market. Consequently, agents could be used to suggest that fewer goods be offered for sale in order to maximize short-term pricing or to avoid flooding a market. (For example, if the world's entire diamond inventory were available for sale, the cash price would plummet.)

Distributing Functional Power

The greatest impact of agent technology on markets is on where the analysis and decision making take place. For example, participating in markets such as the New York Stock Exchange requires that only brokers in the market fill orders. Brokers can't process enough information to handle realtime analysis and execute trades at the same time; doing both jobs would require an inordinate number of brokers on the trading floor.

Similarly, e-marketplaces will eventually require that buyers and sellers have software agents "living" inside the market. Meeting this goal will require overcoming additional concerns such as security (of code) and confidence in these agents. Today, stock exchanges and option exchanges use brokers (agents) to negotiate price, and in noncommodity markets, brokers provide additional value-added services (such as quality verification). In the new generation of e-marketplaces, companies and institutions will have electronic agents that similarly trade on their behalf.

Based on these developments, several regulatory scenarios may evolve. The Federal Trade Commission or Securities Exchange Commission may step in and require that electronic agents function on hardware separate from that which the market is conducted on in order to minimize monopolization of markets by deviant or "misbehaving" agents. An alternate regulatory step may be the approval of agent code by a certifying agency or the market itself so that it is protected from outside manipulation.

From a technological standpoint, a key factor in performance optimization is the locality of the data to the function operating on the data. With higher speed networks this problem becomes less of an issue; however, it still poses an interesting question: Where should the functionality physically reside?

In one approach, "smart" market agents would receive the cleansed requirements list output of an ERP system, observe market trends, do technical analysis, and then communicate back to the coordinating agent when an item of interest meets its own, self-selected criteria, based on its input and environment. These market agents would then recommend specific purchases. A coordinating agent would reconcile trends across markets and forward the consolidated recommendations back to the human trader. (See Figure 1.)

Smart market agents work on the premise that the market-supplied information will be more expensive to obtain than the enterprise information. For example, consider the dedicated network that provides realtime stock quotes to brokers and day traders: These organizations must subscribe to a service that provides the information, while the analytic results from within the organization are relatively free. Issues that arise in this situation include questions about security: Participants may have agents that run on the same CPUs as other participants, on the same CPUs as the market, or on separate, more loosely connected machines.

In a more traditional marketplace, market agents are very simple and work as a base filter for information to be sent back to the CA. (See Figure 2.) In this scenario, the CA sends price-point alert registrations to market agents, which send price points and volumes back to the CA. The latter then analyzes these price points and decides whether it would be appropriate to buy the good(s) at the current time. The CA would then send a recommendation to the trader who could then consider executing a trade.

One technical advantage to using agents is that they obviate "function shipping," or worrying about the locality of data. If pricing information is changing continuously, it is cheaper, easier, and less computationally intensive to ship forecasting data from the enterprise to the agent at the market, rather than having a system at the enterprise continuously monitor a stream of data.

How Will It Work?

Platform independence is a key factor in agent development. Consequently, Java will continue to be a primary technology here because whenever the potential exists for code to run outside the enterprise, you cannot assume the requirements of the hardware it will need to run on.

Agent frameworks - sets of standard processes and procedures that constrain the behaviors of agents - will also need to develop in order to support market agents and provide a seamless interface to the e-marketplace itself. Financial frameworks will also be useful in this arena so that relationships with additional enterprises can develop smoothly, efficiently, and with a minimum of IT overhead. Security concerns and the need to ensure that only "well-behaved" agents participate in markets will also require development of agent behavioral monitoring systems.

CAs and market agents will probably communicate via extensible markup language (XML), although depending on the volume of data being transmitted, this communication may require the use of abbreviated schemas.

The Issues

Trade laws already restrict how brokers interact with a market. However, the creation of purely electronic markets offers new challenges for governing bodies. For example, can enterprise agents legally run inside an external market? If so, is their interaction limited? What are the security and confidence factors required? Does the actual CPU that the agent is running on matter? Which side of the market-enterprise boundary can it live on? Is a "market-close" agent only smart enough to look at realtime data and trigger alerts back to the CA, or can it do more?

Furthermore, in liquid markets, agents let us reconsider the rationale behind long-term contracts. If many suppliers are available for goods, why does an enterprise need to lock in a long-term vendor? Will the market resolve issues involving risk and stability? Agents can also be used to address highly specific terms on bids such as supply guarantees, delivery times, and quality guarantees.

In such markets, there is high volume and the opportunity to continuously change direction. Consider the implications for just-in-time inventory: Companies such as Dell Computer Corp. use it to their advantage in the technology sector where parts and technology change frequently. If interface standards exist in e-marketplaces, agents can help determine at which point vendors can be changed out quickly and efficiently.

The Future

I've only scratched the surface in terms of the synergy between agent technology and e-marketplaces. For example, we may even see the emergence of agent markets with which companies integrate to analyze and compare offerings from various markets or metamarkets. These agents could be leased based on computational and data requirements. This approach may be a way around the legal requirements for smart agents participating directly in a market on behalf of an enterprise.

Another place where the automation and integration of markets with enterprises may play a role is in aggregated buying and selling among multiple enterprises. Groups of companies would work together in order to maximize purchasing power. This type of arrangement could be fronted by a SCM solution - such as I2 Technologies Inc.'s Rhythm - integrated with a market, where the SCM solution optimizes across multiple enterprises rather than within just one.

Agent Watch

Although many companies put intelligent agents high on their list of things that are relevant to their enterprise, real-world applications of such agents won't be common for some time. However, if you lean more toward the common definition of agents, this technology is right around the corner. Using these technologies is just one part of an overall enterprise-market architecture.

Sidebar:

WHAT IS AN AGENT?

To understand how agent technology applies to e-marketplaces, we must first understand what agents are in a business context as well as a software context.

Merriam Webster defines an agent as "one who is authorized to act for or in the place of another: as in a business representative (as of an athlete or entertainer)." In a business context, the entity referred to as "one" in this definition is a person or organization. In fact, people, organizations, and agents share many qualities: According to the MIT Media Lab, software agents are long-lived, semi-autonomous, proactive, and adaptive. These qualities make them somewhat different from conventional software, which is session-based, user or systemically stimulated, and lacking a framework for self-extensibility.

Software agents have existed for some time in the telecommunications industry. You may think of the Internet infrastructure of routers and switches as a network of cooperating agents. These agents as a whole produce an emergent, complex behavior. The end user of this network of agents asks only one agent to send a message to a computer on the other side of the globe. Routers then examine routing tables, quality of service metrics, and metadata to ensure that the packet of data is delivered.

While this process occurs, the router network may notice high volumes of data moving and adapt to optimize the traffic flow from one point to another, possibly increasing bandwidth for a short time or establishing a virtual circuit. In this example, a group of agents that follow relatively simple rules accomplishes a relatively complex task in a very short period.

Interestingly, networks of markets also serve the same purpose of buying or selling goods by an enterprise - but at the business layer of the Open System Interconnection (OSI) stack rather than where routing occurs.

Eric Adams (eadams@lante.com) is chief database architect for Lante Corp.