Multichannel commerce poses new systems-integration challenges
By Ernie Schell
It wasn't long ago that most directcommerce companies were catalog businesses, with orders coming in by mail and phone. These orders were entered into a comprehensive catalog management system that handled customers, inventory and orders. Fulfillment was driven by the catalog management application.
While this paradigm still applies in some facilities, it's more complicated for most of today's direct-commerce businesses. E-commerce Web sites are the primary source of complication. Kiosks in retail stores are another. A growing number of companies have found that a warehouse management system (WMS) is more effective in handling fulfillment than a catalog management system.
All of these facts pose serious systems-integration challenges.
There is no such thing as plug-and-play in the systems-integration world. Horror stories of integration failures are legion.
Perhaps the biggest disasters among direct-commerce companies have been in trying to integrate order-processing and warehouse management systems. Several years ago, a very large and eminently successful (award-winning) multi-title catalog company, which had experienced a decade of solid growth, implemented a WMS from a reputable third-party software vendor to manage a new and enlarged warehouse facility.
Unfortunately, the business rules the WMS used were inconsistent with the business rules driving the home-grown—and quite massive—order-processing platform. The full extent of the mismatch wasn't evident until tens of thousands of orders went unshipped during the fall holiday season. Only heroic efforts and a faithful customer base kept the company from going under.
If that kind of disaster can happen to a thriving company, it can happen to anyone. In fact, one of the largest catalog companies in the country abandoned a multi-year systems-integration project partly because the difficulty of integrating multiple systems had been grossly underestimated.
Prompting multiple systems to interoperate is difficult, even if they're all written in the same language, run on the same databases and operate on the same platform. Most integration projects don't fit such an artificial best-case scenario. In the real world, the integration challenge often is severe. Connecting multiple systems effectively to create a unified enterprise resource requires near-obsessive planning and careful execution.
Integration strategies can be described as either loosely coupled or tightly coupled. In the former, the systems pass data between them without regard to the specific methods each uses to manage that data (I'm over-simplifying these descriptions for the sake of clarity). As long as each system knows what the data represents, it can function effectively, and the integrated applications can perform coordinated functions as required. While a system may need data from another system to produce the desired results, the systems still can function independently.
In a tightly coupled environment, systems are linked so that each system requires functionality from the other system to get its job done. It will begin a process, pass data to another system, wait for the other system to process that data and return an answer or an update (or request data from another system to complete its function), and then complete its original process.
Typically, tightly coupled systems depend on remote-procedure calls to support the inter-system relationships. And loosely coupled systems often rely on a bridge system like IBM's Websphere MQ, which passes data in the form of messages (hence the name "message-oriented middle-ware").
Both tightly coupled and loosely coupled systems also can rely on application programming interfaces to pass data. These are pre-programmed doorways, or "sockets," into a system that permits entry of data according to predefined protocols.
The Impact of the Web
As with everything else, the Web has had an impact on systems integration—in fact, it has profoundly changed the concept of what systems integration means. No longer is systems integration seen simply as sharing data among a group of systems within a single enterprise, or among enterprises linked by a proprietary network. The future of systems integration is to link any system to any other system using protocols designed to support business process integration (BPI).
Most of these protocols rely on eXtensible Markup Language (XML). With XML, tags travel with the data—not unlike a dog-tag or license plate—to identify what the shared data represents.
Most of the heavy lifting in BPI is done by application servers such as WebLogic Server from BEA. These servers are a collection of software programs that provide a link between the Web and the back-end, or legacy applications, that need to talk to one another, as well as offer security, load-balancing and other services.
Finally, there are Web services such as Microsoft's .NET that facilitate inter-system communications via the Internet on a secure permission basis. Such services could, for example, automatically search a supplier exchange to place an order for goods, negotiate a price and request authorization to confirm the order (or go ahead and place it with preset pricing parameters), based on pre-defined business rules.
As an example of what can be done, W.W. Grainger uses WebMethods, an XML-based application server, to connect its two business-to-business marketplaces—Grainger.com and OrderZone.com—to the company's SAP R/3 ERP application, which it uses for inventory management to support real-time information on pricing and availability of products. WebMethods also connects Grainger to other b-to-b marketplaces as a supplier.
Catalog Systems Options
A number of vendors of catalog- management systems have included modules in their applications suite that accomplish similar goals. CommercialWare (www.commercialware.com) makes good use of IBM's Websphere, while Ecometry (www.ecometry.com) has developed its own, universal data interchange component written in C and C++ that uses a proprietary talker/listener methodology to exchange data between the order management core and modules for e-commerce, campaign management, merchandise forecasting and database analysis. There also is some support for XML and Java interfaces for data exchange with external applications.
An independent vendor, Marketing Concepts (marketingconcepts.com), developed a middleware module in C++ and C# for Ecometry that provides a more open, fully enabled XML interface on an SQL Server platform to link Ecometry to any XML-enabled or SQL-compliant application.
One of the most elaborate integration modules is from Page's synaro catalog management system (www.synaro.com). The synaro Integrator uses Java and XML to support both tightly and loosely coupled integration platforms.
These integration-support modules can tie a variety of systems together—linking order management with a best-way shipping calculator or a sales tax module, for example, even if those services are Web-based and externally managed. But they also can be used for more straightforward challenges such as linking a Web site, an order management system and a WMS.
Either way, be sure to scope out the time and expense of setting it all up properly. The results may well be worth it. Carefully planned integration can streamline business operations, improve customer satisfaction, and accelerate systems ROI. Isn't that what systems are supposed to be all about?
Ernie Schell is author of "The Guide to Catalog Management Software" and president of Marketing Systems Analysis Inc. He can be reached at firstname.lastname@example.org or (215) 396-0660.