Trading Partner Coordination

Business Challenge

One of the most costly business processes for an enterprise is establishing a new trading relationship. First, the enterprise has to locate a suitable trading partner. Then the enterprise has to negotiate the parameters of the relationship, including the time-consuming process of exploring whether the partner has a compatible business model. Finally, the enterprise must attempt to make the trading process efficient by collaborating with the partner on automation projects.

It would be nice if enterprises could reduce costs and uncertainty by automating this entire process. Unfortunately, the barrier to entry is very high. Each enterprise must first have a publishable model of its business so it can test partner business models for compatibility. Each partner must also use the same negotiation framework. Lastly, each partner must have compatible business messaging software that can execute the negotiated process. Even with all these pieces in place, the enterprise must have a way to mediate all the internal interactions with both human users and software applications necessary to support the trading relationship.

It is possible for large enterprises to custom-develop systems with most of these capabilities. Because potential partners must have the same custom software, this type of automated negotiation could take place only for extensions of existing relationships. Moreover, the complexity of the software involved makes such an undertaking costly to implement and maintain.

XML Benefit

XML can certainly address the last issue of supporting human and software actors. Standard components of the enterprise desktop such as e-mail clients and Web browsers have gained XML capabilities. Therefore, human actors can use these familiar desktop applications as their interface to the workflow system, decreasing learning and ownership costs. XML has also gained acceptance as an integration technology. Later in the chapter, we'll look at the use of XML for application integration. Therefore, XML-based trading partner coordination can easily connect with internal applications.

XML also addresses the problem of having publishable and machine interpretable trading policies. As discussed earlier in the workforce automation section of this chapter, XML documents can drive process execution. So enterprises can encode rules for negotiating agreements and their possible trading processes in XML. Then both human and software actors at other enterprises can evaluate them for compatibility.

XML-based standards make all these features cost-effective . Undertakings like ebXML seek to provide standard frameworks for process negotiation and execution. This standardization lowers costs by opening the way for third-party vendors to amortize the solution costs across enterprises and increases the chances of other enterprises having compatible software.

A side benefit of using XML both to define and to execute trading relationships is the applicability of other XML- related technologies to the resulting business data. For example, Scalable Vector Graphics (SVG) is an XML-based standard for interactive diagrams. It is perfect for business data visualization. You could use the internal and external process descriptions plus accumulated business documents to create an SVG-based system for visualizing various aspects of process flow over time. Because SVG also relies on XML, it is easy to generate such visualizations from data in XML documents.

Architecture

As Figure 7-3 shows, a trading partner coordination system has separate elements for each enterprise that participates. A conductor facilitates the communication of internal actors with other enterprises. This facilitation may include human and software actors. Human actors usually access the system through e-mail clients or Web browsers. In some cases, e-mail clients or browsers may need special plug-ins or other extensions so that they can operate on work products. Digital signatures are a good example of a feature that requires such extensions. Software actors interact with the system either through native XML interfaces or mediated through XML-based integration tools.

Figure 7-3. Trading Partner Coordination Architecture

To establish a trading relationship, the two conductors exchange information about the types of business processes they support. If their associated enterprises can cooperate in one or more areas, they initiate the negotiation process. They present their respective internal actors with the possible trading models and the parameters to negotiate. Software actors may automatically assess the costs of various proposals, but human actors make the final decision. If negotiations are successful, the two conductors confirm the relationship by exchanging the external process description they will both use and move on to the execution phase.

For each type of business document a conductor can exchange with another enterprise, it has a map of internal work products involved in producing that business document. For each work product, it has an internal process description that generates that work product. As the external process description and associated interaction with trading partners brings about the need for an internal work product, it calls up the appropriate process description and facilitates the necessary exchanges among internal human and software actors.

Key Features

The most prominent feature of trading partner coordination systems is the automated negotiation of the trading relationship itself. The coordination of the operational exchanges between enterprises is identical to that of business process orchestration, and the standardization of exchanges of applications within the enterprise is identical to that of application integration. Automating the negotiation itself adds a new dimension of increased efficiency and decreased time-to-market .

Development Process

The first step in the development process is to select, install, and configure trading partner coordination components from appropriate vendors. The complexity of the external coordination and internal integration usually makes it most cost-effective to buy most of the system. You may need multiple components, including a B2B conductor component, an XML application integration component, and a process modeling tool. In rare cases where the potential efficiency to your organization is enormous , you may decide to build some of these components from scratch.

Once you have installed the conductor, you must configure it to manage each internal and external business process. The first step is defining the work products that the conductor can assemble using internal business processes. Each work product consists of one or more schemas. The next step is defining the human and software actors necessary to populate each work product. For human actors, you may have to define XSL stylesheets to control the presentation of each work product. For software actors, you may have to integrate them with your application integration solution. The last step is defining paths among the actors and the allowable actions at each step. Software actors may automatically initiate and populate most of a purchase order once inventory falls below a certain level. But if the purchase order amount exceeds a given amount, it may route it to a human actor for approval.

After you can assemble the necessary work products, you must configure the conductor so that it can negotiate and execute trading exchanges. This process is equivalent to specifying the CPPs and the allowable rules for constructing CPAs discussed in the ebXML section of Chapter 4. The opportunity for automation absolutely relies on the use of a standard B2B framework and associated tools to support it.

Schema Source

Because business processes differ greatly from enterprise to enterprise, it might seem as if an enterprise would have to define its schemas from scratch. However, the emergence of B2B standards like BizTalk and ebXML means that there are standard schemas for most common interactions. ebXML especially strives to provide a complete framework for such interactions. An emerging area of innovation from ebXML comes in the form of automating the trading negotiation process. In the near future, this process should be standardized. While people still have to provide substantial input and final authorization, there will be schemas for automatic mediation of the process.

To define the internal processes and the parameters for allowable external processes, business analysts will use modeling tools. These modeling tools will generate process descriptions that follow a standard vocabulary. BPML, WSFL, or XLANG provide the most benefit for coordinating internal processes. ebXML's BPSS may soon offer a practical means for coordinating processes between partners.

For common business processes, the B2B standards provide standard document schemas that should be sufficient. Within your industry, there may be additional schemas that support the unique characteristics of that industry. In some case, you may want to customize these schemas or create completely new ones to account for your unique competitive advantage. You should use this option judiciously because it naturally decreases the ability of potential trading partners to accept them automatically.

Document Life Cycle

As with the process documents described for workforce automation, humans create them and machines consume them. They evolve with respect to changes in business polices. However, the internal policies governing the performance of job task and the external policies governing trading relationships are substantially different. Trading relationships naturally evolve much faster. Changing business conditions constantly spark the need for new and improved trading processes. Moreover, these processes must cross enterprise boundaries, so the evolution of trading process descriptions can often resemble collaborative authoring: Representatives from different companies work together to optimize the flow of trade constantly. As with workforce automation, these documents provide critical operational data, so they probably will require a native XML store or data server to achieve the necessary scalability.

In addition to the process descriptions, there are external and internal business documents. External exchanges occur between the conductors of two enterprises, whereas internal exchanges occur between the conductor and the internal applications of a single enterprise. External business documents represent implicit business agreements and authorizations to take action. Internal business documents represent only the internal marshalling of resources to satisfy these business agreements and perform these authorized actions. Therefore, it is important to maintain persistent versions of external documents, but internal documents may be transient. Because process documents require a native XML store or data server anyway, it probably makes sense to use the same type of mechanism to store external documents.