SOA for B-to-B commerce

We live in an era of "virtual" corporations, rapid product lifecycles, and ever-changing alliances between businesses. These trends put increasing pressure on companies to find flexible, innovative ways to connect with their partners, customers, and suppliers--known in IT circles as business-to-business (B-to-B) commerce. However, while the Internet has proven a boon to some aspects of B-to-B commerce, many critical B-to-B operations remained mired in the rigid and costly territory of traditional enterprise architectures. In general, IT connections between businesses are difficult to maintain and complex to change.

With their inherent flexibility and vendor neutrality, Web services and the SOA (service-oriented architecture) provide a method by which modern B-to-B commerce can be implemented in a flexible and economical manner. Web services and the SOA enable more dynamic and cost effective B-to-B commerce, and this article examines ways in which they make this happen.

Before we get started, I want to start you thinking in terms of the interplay between business process and IT. After all, most IT exists because a business or organization requires it. In general, IT supports business processes. Too often, business strategies are hostage to the rigid IT infrastructure that has developed over the years, failing to take into account that the whole reason IT exists in the first place is to make the business itself more competitive. This article deals with the ways in which IT can be made to support business processes as they evolve.

When two companies become partners, their respective enterprise architectures become partners, too. In customer-supplier relationships such as manufacturing supply-chain management and partner relationships such as airlines and car rental firms or auto manufacturers and dealers, traditional enterprise architectures have proven inflexible and problematic. The systems and their interfaces cannot keep pace with the changes in these relationships. Web services can enable these systems to connect with greater agility.

Example: Managing the supply chain

Supply-chain management is one area of B-to-B commerce that provides some fertile opportunities for an SOA. To see how the SOA can improve B-to-B commerce in this area, let's examine a simplified example of a manufacturing company with two plants. The business process for supply-chain management at this company dictates that if one plant runs out of a particular part, then its ERP (enterprise resource planning) system sends a message to a computer at headquarters (HQ), which then automatically queries the ERP system situated at the other plant to see if it has that item in stock. If the other plant does not have the item, then the HQ computer sends an electronic order to the supplier's ERP system.

To support the company's inventory query and supply ordering, the enterprise architecture requires that four systems be connected using three proprietary interfaces. The mainframe at the first plant connects to the Windows-based servers at headquarters, which in turn connects with the minicomputer at the second plant and the Sun box at the supplier. As we have seen, this tightly coupled integration can prove to be inflexible as well as costly to modify and maintain. For instance, in the current architecture, the addition of new suppliers, competitive bidding on supplier contracts, and the like would be complex and expensive to implement.

Converting to an SOA opens up a number of new possibilities for conducting B-to-B commerce without significant reworking of the underlying systems. In addition to eliminating the proprietary interfaces, the SOA makes it easily possible for the first plant to check directly with the second plant and place orders without going through the HQ computer, as it is now configured. Of course, it would be possible to make that change to the architecture in the traditional method of modifying the interfaces, but that would be a far more complex and time-consuming task. The HQ system can now monitor the transaction flow passively using its own Web service, which can digest the SOAP messages that travel back and forth between the second plant and the supplier.

The manufacturer now wants to institute an electronic competitive bidding system for its orders. The suppliers who want to bid on the opportunity to win business from the manufacturer can connect to the bidding system through a Web service. Once again, this is certainly possible to do with traditional distributed computing technology, but at a much greater cost. The costs are so high, in fact, that such systems are rarely built, and, when built, rarely change without considerable pain. With the advent of the SOA, however, this kind of B-to-B commerce can easily take shape. The manufacturer gains the ability to manage its suppliers and costs more effectively, and the suppliers gain the ability to win new business. Further, when suppliers are replaced or new suppliers added, IT can now respond quickly and inexpensively to the business decisions.

The UDDI (Universal Description, Discovery, and Integration) and WSDL (Web Services Description Language) features of Web services make the new SOA paradigm that much simpler to implement as well. If a supplier wants to become part of the bidding system, its software developers can access the specifications of the manufacturer's bidding Web service using the manufacturer's registry of available services. The supplier's software developers can process the WSDL document and derive the correct policy information that will be required to interoperate with the Web services--based bidding system. The UDDI and WSDL gives these SOA features the ability to scale rapidly. If 10,000 suppliers need to sign on to the bidding system, they can do it largely without disturbing anyone at the manufacturer. Now, in reality, developers will call each other to exchange information and make sure they are working correctly, but in terms of relatively effortless scaling, the SOA enables improvement an order of magnitude greater than the architectures based on proprietary interoperability.

Example: Building hubs

One trend in corporate IT that the SOA is encouraging is the development of various corporate "hubs." A hub is a Web service--based center through which distributed services can be managed and secured in a central manner. Internally, hubs become the center for provisioning and management of services for the enterprise. Externally, hubs enable communication with an array of suppliers, dealers, clients, and so on. For example, in the automotive industry, thousands of dealerships must regularly receive and transmit sales information to the manufacturer.

The business process behind the automotive hub is a process of sales and market information sharing that has gone on for many years. On a regular basis, the dealerships report sales data to the manufacturer. At the same time, the manufacturer collects market research data from research firms. The manufacturer then combines the information and publishes it back to the dealerships. This was originally done in print, and then on the Web. However, the process was always slow and prone to errors. With the Web services--based hub and SOA, it is now possible to share information in near "real time" with a large number of dealers.

Partner-to-partner: Airline and car rental

The necessity for communication between companies that work in partnership with one another creates a strong potential demand for SOAs. For example, car rental companies and airlines often work together. The car rental company usually wants to know when a traveler's flight is arriving so it can best plan its operations. If someone is arriving late, or if their flight has been canceled, then the car rental company can plan accordingly.

Traditionally, if a car rental company wanted to be informed automatically of a flight time, its software developers would have to create a custom interface to tap into the airline's computer. Even if the airline provided a "kit" for doing this, as many large companies do, the work involved might still be significant. And then, the car rental company would still face that great cost center of traditional enterprise architectures: change management.

An SOA can simplify the software integration challenges in the airline-to-car-rental-company connection. A Web service exposed on the airline's mainframe can be accessed by any number of car rental companies, regardless of their hardware or software architectures. Change management on both ends becomes infinitely easier. If the airline modifies its flight arrival software, then the car rental companies can modify their Web service consumer software without having to program to the airline's specific software standard.

Perhaps the most important benefit that the SOA brings to B-to-B commerce, however, is the flexibility that it confers on business processes. In Figure 5, the business process is relatively simple: 1) The car rental company requests a flight arrival time from the airline, 2) the airline responds with a flight time, and 3) the car rental company receives the flight time. Now let's suppose the car rental company wants to make a special offer; for example, it tells its customers, "If your flight is going to be very late, we find out which hotels are available in the area in case you need a place to spend the night."

To realize the special offer, the car rental IT department has to implement the automated version of the following business process:

Steps 1--3: The car rental company requests and receives a flight arrival time

Step 4: The car rental company checks to see if the flight is late enough to qualify for the special offer

Step 5: If the flight is late, the car rental company creates a list of nearby hotels that have vacancies

The car rental company uses a Web service consumer program to poll participating hotels, which themselves use a Web service to respond.

As with the other examples, it is of course possible to accomplish this type of integration using traditional means. However, given the effort and expense involved, it is unlikely that a car rental company and half a dozen hotel chains would make the commitment to such a concept. Why is that? The answer is that many new business ideas, especially various marketing alliances, are essentially experimental. If the idea doesn't work, then the partners drop it. The result is that most companies will not invest in trying new ideas if they bear a high IT cost burden to implement.

The SOA gives the car rental company the flexibility to experiment with new marketing ideas more cost-effectively than it could do before. While not free, it is far cheaper for the car rental company to connect with half a dozen hotels through an SOA than it would be to custom-integrate with each one.

Eric Pulier is a pioneer in the software and digital interactive industries. A frequent public speaker at technology conferences around the world, Pulier has helped establish cutting-edge technology companies in media management, professional services, voice systems, and peer-to-peer networking.

Hugh Taylor is an SOA marketing executive who writes, teaches, and promotes the business value of SOA and Web services to major companies.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about ADVENTEdge TechnologyEvolveInterplayParadigmPioneerUDDI

Show Comments