NETTING IT OUT

While some tout services-oriented architecture (SOA) as a new architecture strategy, leading companies have been services based for years. In lieu of Web Services, these innovators have been realizing their architectures with a mix legacy, object-oriented, and messaging technologies.

This case study follows a quiet leader, L.L. Bean, in its quest to employ SOA in support of the company’s multichannel business strategy. We follow L.L. Bean from the late 1990s to current day as the company’s IT management and architects review their portfolios, make technology choices, deliver the architecture, and replace their most critical applications--those supporting customer sales and service.

L.L. Bean validated its technology choices--J2EE with message-based integration--in a proof of concept (POC) with IBM. Upon completion of the POC, an L.L. Bean architecture team was responsible for introducing the new technology and architecture strategy to the company’s mainframe-centric IT shop.

In devising its services strategy in early 2002, the team determined it was premature to adopt Web Services. However, they liked the underlying concepts from both SOAP and Web Services, and they applied those ideas to a design that would meet their heavy transaction loads and fast response time requirements.

As the architecture team was driving the technology rollout, a second team was developing and executing a migration plan for the customer sales and service applications. The teams would converge in a year’s time to decide on the best manner to procure services.

The procurement question was not easy to answer, and it required L.L. Bean to go out to market twice. The first RFP specified requirements for a multichannel customer sales and service application built on a services-based architecture. Not surprisingly, the responses were for traditional solutions with no mention of a services-based architecture. The second time, the RFP contained explicit requirements to procure business and infrastructure services along with a supporting environment to assemble services for various user experiences and business transaction flows.

After an extensive search, it became clear that the best provider for the job of delivering services to support the customer experience across channels was L.L. Bean itself. L.L. Bean took charge of developing the major services and mixing those services with user interface and business rules to produce channel-specific application assemblies. L.L. Bean still looks to the marketplace for supplemental services and development talent, but for the bulk of the effort, the company is blazing its own trail.

L.L. BEAN

Company Profile

L.L. Bean is a billion dollar multichannel retailer specializing in quality apparel, reliable outdoor equipment, and expert advice since 1912. L.L. Bean remains a privately held family-owned company. The numbers the company has published on 2003 business performance, combined with the retailer’s legendary customer service, provide a backdrop for the implicit requirements of service and durability expected in all of its IT solutions. Here are some statistics:

• L.L. Bean offers 19,000 different items.
• The 160,000 square foot flagship store draws close to 3 million visitors each year.
• Catalogs were distributed to customers in all 50 states and more than 140 countries.
• Over 14 million sales and service calls were answered in 2003, with 167,000 coming on the single busiest day.
• The Web site, www.llbean.com, is among the top-rated ecommerce sites in the industry.
• Over 56,000 orders were placed on the L.L. Bean Web site in a single day in December 2003.
• L.L. Bean shipped more than 14 million packages in 2003--200,000 on a single day.

The Late 1990s: an IT Shop at a Crossroads

In the late ’90s, in response to the company’s multichannel business plan to become a balanced multichannel retailer, L.L. Bean’s IT department took a hard look at the applications supporting customer sales and service (as L.L. Bean refers to it, its contact systems portfolio). For years, L.L. Bean had been a direct mail company with a flagship retail store and a handful of factory stores. The “catalog first” roots of the business were firmly entrenched in the systems portfolios. Achieving the goals of the business plan meant growing the existing retail and Web channels. The IT group knew some serious work was in order.

L.L. Bean’s direct mail contact systems--the applications used by call center representatives to capture and service orders--had been in place since the early ’80s. There were separate order-entry applications and databases for telephone and mail order processing. Supplementing both order-entry applications were a multitude of customer service applications including order inquiry, back order management, customer maintenance, financial adjustments, returns, gift registry, and fraud. Many of these service applications are hard-wired to the order-entry applications through screen flow, program linkage, and/or data store sharing. Over an almost-twenty-year period, additional business logic was shoehorned in to support L.L. Bean’s corporate sales business and the company’s entry into international markets. As a product of their time, the contact applications became a mix of mainframe-based technologies, starting in Ideal1 with Datacom databases, and later sprouting appendages in COBOL and CICS backed by data stores in both DB2 and VSAM. A 3270 scripting language created a fast path through the Ideal and CICS screens to match the workflow of seasoned call center representatives.

While it sounds a bit frightening, the good news was that the systems performed day in and day out, supporting the needs of the direct mail business and handling peak volumes, albeit under the watchful eyes of the technical services team. The bad news was that the systems were difficult and expensive to maintain, and they lacked extensibility to the Web and retail channels. L.L. Bean, like most multichannel retailers, had resorted to stovepiped applications for sales and service in each channel.

The flagship store in Freeport Maine and the factory stores ran an IBM point-of-sale (POS) system on the IBM 4690 cash register and controller architecture. The POS worked with a homegrown back office system hosted on an AS/400, which happened to be located down the road from the flagship store in the former home of L.L. Bean’s founder, Leon Leonwood Bean. The back office application and the mainframe (located in a data center) exchanged product and price information via nightly file transfers. The back office application created a price lookup file (PLU) for distribution to the POS over a token ring network. Sales, via a controller polling process, passed through the AS/400 for formatting prior to transport to the mainframe financial systems.

L.L. Bean was an early entrant to commerce on the Web, going live for order taking in November 1996 with the first production implementation of IBM’s Net.Commerce solution. The first release of Net.Commerce had a proprietary IBM architecture; the J2EE solution would not emerge until 2000. Similar to retail, the commerce installation and the mainframe exchanged information via batch feeds. Product, price, and inventory information went from the mainframe to commerce. Throughout the day (and night), Web orders were sent to the telephone order system for final order edits, credit authorization, and release to order filling. All orders--Web, phone, mail, and returns--traversed to a common orders database for order fulfillment. Illustration 1 depicts the L.L. Bean contact systems in the mid to late ’90s.

Proof of Concept Architecture

(Click on image to enlarge.)

Illustration 3. This architectural drawing shows the test cases with their resolution.

In contrast to the state of these front-end systems, L.L. Bean’s data architecture was strong. There were single sources, with agreed-upon definitions, for customer, order filling, inventory, and price. Additionally...