8.4. Altura Merchant Operating System

Catalog merchants have, over long years of trial and error, developed a very successful business strategy. They rent mailing lists, ship catalogs, take orders, get revenues, and then mail out more catalogs. It is a simple but elegant model that has proven itself over and over again.

But it is, as officials at Altura International realized in the mid 1990s, a strategy that entirely ignored the emerging world of the Web. Even in its infancy, the Web was turning the tables and creating an environment in which customers did not need to wait to receive a catalog to place an order. Indeed, the Web was clearly evolving into an environment in which a consumer could actively seek out, compare, and purchase products quickly—from the comfort of an armchair, the same location from which the customer might purchase an item from a catalog.

Altura officials could see that the Web presented some compelling opportunities for catalogers—and that catalogers themselves had not quite figured out how to make the most of those opportunities. Some catalogers had already developed Web sites to extend the reach of their paper publications, but no one had taken what, to Altura officials, was the real giant step—the creation of a Web site that would be for catalog shoppers what Amazon.com was for book shoppers, a single location on the Web where a shopper could access, browse, and order from thousands of catalogs.

For shoppers, such a site would offer unprecedented convenience, enabling them to find virtually anything that could be purchased via catalog. For individual catalogers, such a site would drive more business toward their individual offerings—particularly if the site were designed with cross-catalog search engines, organized by product lines and/or affinity groupings. A shopper searching for office furniture, for instance, might see catalogs they did not even know existed—and those catalogers might then have their wares presented to customers they never knew about.

So Altura officials took that giant step and began the development of CatalogCity.com, a single site that aggregated the best of the world's direct-mail catalogs. They even cataloged the catalogs themselves, organizing more than 17,000 publications into hierarchical categories—autos, books, beauty, clothes, electronics, and so on—with each high-level category branching into subcategories for further differentiation. By navigating the hierarchies, visitors could quickly access the catalogs of interest to them.

For catalogers, even those with existing Web sites, Altura's approach offered a significant value proposition. By affiliating with Altura, a catalog merchant could have its publication, and a link to its existing Web site (if one existed), included on CatalogCity.com. The more catalogers Altura officials could recruit, the better it would be for all catalogers, because the CatalogCity site would then gain the mass it needed to become known as the de facto standard for catalog shopping on the Web. In Altura's vision, consumers could shop across hundreds of catalogs with one sign-in, one set of privacy preferences, one password, one date reminder, one gift registry, and one easy-to-use navigational process.

Moreover, Altura was talking to catalogers about providing support for online purchasing through a sophisticated multivendor shopping cart—and for catalogers in particular, that discussion was very exciting. Even by 1997, it was clear that businesses accustomed to working face-to-face with customers had significant culture shock when working with customers on the Web, but catalogers were already accustomed to doing business with customers in other than a face-to-face mode. In fact, Altura's math made the Web appear to be even more efficient and more cost-effective than the traditional call-center approach to taking customer orders. A visitor to an Altura site would not even have to call the merchant to order from the catalog. With a few mouse clicks, an order would be in the fulfillment system as effectively as it would have been if an operator in a call center had taken the call. Yet no operator would take the call. No one on either side of the transaction would even pick up the telephone. Such orders would effectively be executed in a lights-out mode.

8.4.1. Constructing the Altura Merchant Operating System

Altura engineers began to construct the company's flagship site, CatalogCity.com, in October 1997, long before the J2EE specification was finalized. They selected a proprietary deployment environment that ran on top of Microsoft Windows NT 4.0, with Microsoft Internet Information Server providing Web-server support and Microsoft SQL Server providing database support.

Using these proprietary tools, Altura's developers began to build the core technology that would inform the company's sites—the ideas for which were quickly multiplying. This core technology soon became known as the Altura Merchant Operating System (AMOS). AMOS enables a wide range of unique features, prominent among which is a very sophisticated multivendor shopping cart, one that can hold virtually any item from any catalog on the site and one that can be pushed, as it were, from catalog to catalog, before the visitor pushes it to the checkout stand.

“We looked at hundreds of catalogs,” explains Vince Hunt, executive vice president of engineering at Altura, “and asked the question: 'Which products could potentially be in our database?' And the number of products—and the number of permutations—is huge. In our database, we have apparel products that have characteristics such as color and size. We also offer electronic items, and there you might have color or voltage as the important characteristics. We even offer products such as saws, where you can select the number of teeth on the saw. We took every product characteristic and shipping permutation into account and created a shopping cart that is completely flexible. It was designed to support any type of merchant and any type of product there is.”

Figure 8.1 shows the resulting Web site, CatalogCity.com, offering a variety of customer conveniences. With the AMOS shopping cart, a shopper can add any number of items from any number of merchants. The shopping cart also allows shoppers to change the quantity of items they have added and also to save items for later. The Save For Later feature allows shoppers to remember products, without having to shop again for items they may want to buy later. A shopper's AMOS shopping cart is persistent, too. The shopper can add a product on a Monday, log off, and come back two weeks later to find the shopping cart still intact.

Other AMOS features were just as compelling for catalogers.

• E-gifts provides a way for gift recipients to select the gift they want. Gift-givers can select categories of products and enable the recipients to choose from those categories.

• E-cards enable shoppers to send a customized electronic card to anyone with an e-mail address.

• Date reminders enable shoppers to build up a personalized calendar of reminders in advance of gift-giving events.

• Gift registry enables shoppers to identify items they would like to receive for wedding, anniversary, graduation, or other presents. They name their registry and then send e-mails inviting friends and family to shop in their registry.

• Multicurrency and multilanguage support enables AMOS to support merchants and buyers worldwide.

• Powerful search capabilities enable a visitor to search for products across virtually all the pages in a site. Shoppers can find merchants by name or description (that is, search by catalog), find products by name or description, and even search for items (by name or by SKU number) within a given catalog. Within the search results, shoppers can refine their search by selecting a price range or jumping directly into a category of products in which they may be interested. Also, to help refine a search even more, shoppers find related search words. These words are derived from tracking similar searches across the AMOS network.

• Personal shopping accounts provide facilities through which a shopper can enter shipping information and billing information once, store it securely, yet make it available to any merchant from whom the shopper is purchasing merchandise, through the use of a single password.

This combination of a well-organized collection of catalogs, a multivendor, multicurrency, multilanguage shopping cart, and the other rich features of AMOS opened up yet a new business opportunity for Altura: syndication. In addition to developing its own sites (in the United States, as well as regionalized sites in Europe and Asia), Altura began working closely with Web portals, such as Yahoo!, Excite, and Lycos, to deliver catalog-shopping sites specially packaged to cater to the shopping needs of those portals' members. The multivendor shopping cart fit neatly into portal owners' desires to deliver ease of use to their members, since the preponderance of shopping carts available at the time were geared to support a single vendor at a time. Altura's ability to order from multiple vendors with a single shopping cart was a clear advantage. Indeed, the AMOS shopping cart not only enables shoppers to add items from multiple catalogs on the CatalogCity.com site, but it also enables shoppers to add items from any Altura mall, even multiple Altura malls. The same cart stays with the shopper across all Altura-powered malls until checkout, so a shopper can add items from gifts.com, quixtar, ishopexcel, CatalogCity.com, and other malls (see Figure 8.2) and go through checkout with all these items from any of the AMOS-powered malls.

Yet these same advantages precipitated the complication that would eventually lead Altura officials to migrate many aspects of the site off their original architecture and on to an architecture that conforms to the J2EE specification.

8.4.2. Growing but not Scaling

From the beginning, traffic to Altura's site grew rapidly, thanks in large part to the strategic relationships it was forging with leading Internet portals. However, as traffic increased, IT managers at Altura began to notice some performance problems they were unable to overcome.

“There appeared to be flaws in the way our original deployment environment managed and completed threads,” says Hunt. “We could watch a thread going in, and then we'd notice that it took a long time to come out—but we had no way of knowing what was going on while that thread was inside the box. We simply had no insight into what was going on.”

Yet a far greater problem lay just around the corner. When quixtar.com opened its newly syndicated catalog shops to portal members in September 1999, Altura officials discovered they could not scale the site efficiently to meet demand. The original environment simply would not support more than 15 to 20 visitors on a given Web server. In order to accommodate the influx of traffic that these two newly affiliated portals unleashed, Altura had to expand its Web server farm from some 30 systems to more than 120.

Unfortunately for Altura, this vast expansion created more problems than it solved. The solution they were using offered no centralized services for managing multiple Web servers. Instead of one console that could manage the 120 servers, Altura had 120 consoles. Moreover, the original solution provided no failover, intersession, or intermachine communication mechanisms. If the Web application crashed, the user could not failover to another server, thus causing lost sales and lost customers. To compensate for this problem, Altura developers had to write more code to provide failover and user-data-caching mechanisms.

Beyond the challenges of avoiding potential data loss and managing multiple servers centrally, the expansion of Altura's original architecture created two other problems that Altura officials knew would have serious short- and long-term consequences. The first problem was that the crashes they experienced usually occurred in the Web-application layer, not at the Web-server layer, and the Web application itself provided no inherent mechanisms for reporting that an instance of the application had crashed. So 20 visitors might be stranded on a server, but Altura IT personnel had no notification that there was a problem. Indeed, because Internet Information Server was still running, the Web server and everything above it seemed to be functioning properly.

That fact gave rise to the second problem. Because Internet Information Server was still running but there appeared to be no IP traffic to or from that Web server, Cisco LocalDirector, which Altura had configured to provide load-balancing services across its 120 Web servers, perceived that that Web server could accept and handle more traffic. LocalDirector would consequently route new visitors right to the Web server on which the Web application was not running. Those visitors, of course, would get nothing but a blank screen. Compounding this problem was a sticky-bit feature Altura administrators needed to invoke in LocalDirector that automatically routed return visitors to the server on which they had held their last interactive session. Those visitors who were on the Web server when the Web application crashed often attempted to restart their session by leaving the site and quickly return—but as a consequence of this sticky bit, they would land right back on the original server with the dead application. Unless Altura IT personnel had discovered and restarted the dead application before they returned, the user would get nothing but a blank screen again. For those users, the entire site appeared to have died, even though it may have been only one Web server's application that was down.

“For an e-commerce site, this is a real problem,” notes Hunt. “People who land on dead servers get instantly frustrated and don't come back.”

Altura developers were eventually able to code (in C++) some monitoring tools that kept them apprised of the state of the application running on these 120 Web servers, which increased the speed with which IT officials could respond when the application had a problem. Yet even as they succeeded in putting a band-aid on those problems, Altura managers could see that their original architecture would be unable to provide a viable long-term solution. Without greater efficiencies in scalability and manageability, the original Web-application architecture would simply never provide a sufficient return on investment.

“The cost of adding a server to support 15 to 20 users was between $6,000 and $10,000,” says Hunt. “There was simply no way to justify that based on return-on-investment, considering we also had to write the management software, pay the monthly colocation and software maintenance fees, and pay a support staff to run it all.

“We knew we had to get through the 1999 holiday shopping season, though, and this approach would get us through. But we also knew we had to rearchitect our site. There was nowhere else to go, given the proven limitations of the proprietary solution we'd been using.”

8.4.3. Sourcing a Viable Solution

“Our original environment had not been a true application-development environment,” says Hunt, “but a scripted environment. Our Web application, including the multivendor shopping cart, relied on more than a million lines of script, and we really wanted to move all that into a true application-development environment. But what to use? And how were we going to get this script into the real world? We started to write a compiler to move all the script into C++, but the more we looked at where we expected to go and at the languages people were learning, the more C++ did not seem like a great option. We had some Java programming experience, but we also knew that as we grew we'd be recruiting a lot of new people—and increasing numbers of them would be coming out of UC Santa Cruz and UC Berkeley, where they learn the Java programming language as part of a computer science degree. We also wanted the flexibility to run our application on whatever platform would best suit our business needs. All this pointed us to Java technology. We were specifically interested in using Java Servlets, which were the new industry standard.”

Yet Java technology was only a part of the solution Altura officials knew they wanted. Given the problems in the existing environment with server-farm management, failover, fault tolerance, scalability, and performance, they decided to rearchitect around a J2EE platform-based application server. In January 2000, Altura officials set out to find a technology partner that could meet their needs. After considering and testing several vendor's solutions—including solutions from IBM, BEA, and SilverStream—Hunt and his IT team chose to rearchitect Altura's proprietary Web application around HP Bluestone Total-e-Server, an application-server infrastructure built entirely on J2EE technology.

“When we decided to go with Java technology, we got better development tools, better debuggers, and a better overall application platform for our site,” says Hunt. “Then we looked at what we would need to support that application optimally. J2EE technology was a prerequisite. We knew we wanted to do servlets, and we thought we wanted to do JSP. We also knew that Enterprise JavaBeans (EJBs) were something we'd like to explore in the future. So conforming to the J2EE specification was a hard and fast requirement. On top of that, we needed server-farm management, high reliability, support for load balancing, and of course, high performance.

“In the performance tests, we set up a system to mimic between 20 and 300 users hitting a Web server to see how our application-server candidates would scale,” Hunt continues. “Our old architecture supported around 20 concurrent users on a Web server, which is pretty poor. We had several hundred users on Total-e-Server without a significant performance impact—and these were the same Intel-based boxes we had been using all along. We even unplugged one of the HP Bluestone servers—and lost nothing. The user sessions continued, and the whole thing continued to work. And HP Bluestone Application Manager offered something else of critical importance—centralized server management. With HP Bluestone Application Manager we no longer had to manage each of our servers individually. We could manage them all from a central point.

“HP Bluestone also works with any JDBC compliant database. Our old application made calls to Microsoft SQL Server using ODBC, but SQL Server is also JDBC-compliant, so going with HP Bluestone meant that we did not have to change our database at all.

“Finally, the fact that HP Bluestone Application Server is based 100 percent on Java technology ensured that we would have full platform independence. We could run our systems on Sun Solaris, HP-UX AIX, Windows NT, even Linux—whatever we feel is best for our business. With our old solution, we had no choice but to deploy to Windows NT Server—with support for some UNIX platforms promised in the future. HP Bluestone and the Java technology give us options we did not have before.”