Here at Get Elastic, we’ve spent a fair amount of time exploring the importance of having a broad, consistent multichannel customer experience. Typically, we look at things from the consumer perspective, focusing on best practices in areas such as mobile optimization, usability and social marketing. But just as important as what you should be doing in these channels is how you should be doing it.

One of the hallmarks of today’s most successful online enterprises is that their customer-facing services reach far beyond traditional desktop websites to encompass everything from mobile apps and standalone hardware devices to purchasing features embedded within other pieces of software such as games and social networks. Labels such as agile commerce, multichannel 2.0, and the “internet of things” have been variously used to describe a new reality, where companies are expected to offer their customers a consistent, unified relationship experience while allowing them to conduct business and transactions seamlessly across a multitude of touchpoints. Anyone with IT experience will appreciate that this is a daunting scenario, but the ideal solution has actually been incubating for quite some time.

For many years now, good software architects have promoted the use of service oriented architecture (SOA), where building blocks of back-end functionality (such as catalog or cart features) are individually packaged and exposed for consumption by the delivery mechanisms that need to use them. But in the old multichannel paradigm, where revenue was attributed solely to “store, catalog, and web”, the idea of moving to a model designed to sell things across dozens of channels was usually a tough sell. For most organizations, it would have been difficult even three years ago to envision a plausible scenario where potential revenue from alternative channels might offset the cost and effort of migrating from a legacy system to service-oriented software.

Then smartphones, tablets, connected televisions, app stores, and Facebook happened. The explosion of potential customer touchpoints, along with the disruptive business models that often come with them, have once again propelled the SOA concept to the forefront of ecommerce thinking. Supported by technical advances in the design of REST web services that make it easier for potential channels to “plug in” and consume complex functionality, the notion of decoupling ecommerce functionality from a website and distributing it everywhere via a full-featured shopping API is finally an idea whose time has come.

Want to learn more about the next generation of shopping APIs, and how they can help future-proof your business? Join our guest speaker Brian Walker, Forrester Research Vice President and Principal Analyst, and Sal Visca, Elastic Path Software Chief Technology Officer, for a live one-hour discussion Shopping APIs and How They Future-proof Your Business on August 2, 2011, at 9:00AM PDT/12:00PM EDT.

Customers seek out and prefer sites with ratings and reviews. They want to advanced search capabilities and product features. They want to ship to store, check in-store availability, choose from multiple payment options, and even browse your site and purchase from a mobile phone.

At the same time, growing retailers launch new storefronts for international customers or to serve new market segments. Or, multi-store retailers like the Gap experiment with merging sister brands into one checkout.

But for many retailers, it’s not that easy to evolve as fast as they’d like…

Roadblocks to “Next Generation Ecommerce” – Legacy Architecture

Legacy architecture can prevent online retailers from implementing the cutting edge usability, customer service and functionality of the online shopping experience that customers are quickly coming to expect.

For example, an online retailer who began 10 years ago with a home-grown ecommerce platform has updated its systems several times over the last decade – each time patching new functionality on top of what’s already built. Retailers end up “stuck” with hacked integrations and patch-overs on systems that are difficult to replace or even extend. Order management, the storefront(s), content management system, call center etc. rely on the legacy systems, the data warehouse, financial system, inventory and warehouse management, payment verification systems and so on. Everything is so tightly coupled that it’s near impossible to switch one system out for another without affecting other systems.

Other problems include duplicated data (no consistency or master point of data) and cross-organization chimneys (e.g. the brick and mortar store runs different systems than the online store).

Sometimes cross system replacement and re-architecture is simply too expensive for a retailer, there are limited operational resources or business critical legacy processes are too difficult to replicate or replace.

Even if resources exist, the time to market for the new solution could take years, while competitors forge ahead.

But there is a better way…SOA – Service Oriented Architecture.

What is Service Oriented Architecture?

SOA or Service Oriented Architecture takes various areas (like your content, catalog and checkout services), opens them up and exposes them so they can be consumed by delivery channels that need to use them (like storefronts, email software and the call center). It also provides a consistent set of tools to channel management – store administration, promotions and content management.

Legacy Architecture

Click for larger image.

SOA Reference Architecture

Click for larger image.

Benefits of SOA

1. SOA provides the foundation to get back end systems working together. Components can be easily swapped in and swapped out without impacting operational integrity, one at a time if necessary.
2. Eases migration to a new ecommerce platform.
3. Brand defining or business specific services can be developed in house (you can innovate!).
4. Commoditized services (e.g. payment processing, customer reviews) can be outsourced.
5. Reduces time to market for new ecommerce functionality. The business and marketing department may demand certain functionality be implemented by IT, but IT does not have to deliver anything, the services already exist. It’s just a matter of consuming and using them. For example, a mobile storefront can re-use the systems the online storefront relies on.

An example of how SOA can drastically reduce time to market comes from an Elastic Path customer, Aeroplan, the frequent flier rewards program for Air Canada. Aeroplan has a number of partnerships from hotels to credit card companies, and requires a complex infrastructure that enables loyalty program members to redeem points for goods and services across partners. You can read the technical details in this Baseline Magazine article.

More recently, Aeroplan launched an new e-store where plan members can earn rewards points on products from retailers like ToysRUs, the Apple Store and Overstock — not just flights. Thanks to its existing SOA (single sign on, fulfillment, reporting etc), the new store went live in 8 weeks.

How to Get Started With Service Oriented Architecture?

1. Review your existing ecommerce infrastructure. Know your architectural constraints and scalability requirements.
2. Identify business objectives for next generation stores – what features and functionality do you need to deliver best-practice user experience and customer service?
3. Align IT strategy with business objectives – understand your SOA vision.
4. Introduce new services in a phased approach. Don’t do everything at once (replace CRM and ERP systems in one project, for example). When you piece-meal projects, they have quicker time to market and higher success rate.
5. Leverage existing legacy components where possible

For more information, please check out the on-demand version of our recent webinar with Oracle: Delivering an Integrated Ecommerce Experience for Empowered Customers.

Carr’s report, “Improving Ties to Business Partners” explains Aeroplan’s modus operandi, “Aeroplan “sells” mileage credits to partners, such as credit card issuers—who then offer them as rewards to customers. These customers can trade credits for air travel, car rentals and merchandise. SOA enables Aeroplan and its partners to exchange customer and other data in legacy systems to make the rewards program work.”

Last year, we published a case study about Aeroplan‘s implementation of Elastic Path and, in the process of writing the report, I learned a lot about the wide-ranging possibilities within ecommerce. While examining Aeroplan’s project, I focused my attention on the community building aspects of ecommerce – or the art of selling based on relationships.

What I mean is … ecommerce “stores” are easily viewed as virtual representations of their brick and mortar colleagues. Somewhere, (one could assume) the storeowner has an inventory of stuff taking up space and awaiting a situation in which to put on racks and deliver to the customer. However, Aeroplan is an ecommerce storefront indirectly selling non-physical and physical products using a virtual “currency” at a virtual storefront.

As such, the challenges Aeroplan face are rather different than a (dare I say traditional?) “vanilla” retailer. Rather than the primary mission being getting people to the site, then presenting them with the goods they seek, and finally, providing a barrier-free(ish) path to checkout, Aeroplan’s challenge is to educate (both existing and new) members about the myriad ways to spend their accumulated currency then present the choices in a compelling manner so members redeem their points/miles/ducats for services and goods which will please them and maintain their loyalty for future purchases from an increasing kaleidoscope of partners.

It seems Aeroplan’s challenge is to tactfully and efficiently facilitate these “cashless” transactions for the mutual benefit of all parties. No big deal right? No inventory means no warehousing, no frantic calls to suppliers for shipping tracking numbers and no annoyed customers who “were counting on that item for their Mom’s birthday.”Instead, Aeroplan embraces the challenge of managing these multi-party relationships tactfully and artfully. These varied relationships exist with the Members collecting points (with varying levels of passion from incidental to traders), the “Point Vendor” partners who offer points (AKA miles) as an incentive and include financial institutions, retailers, real estate agents, movers, parking lots and car rentals and, oh yeah, … airlines, as well as “Point Spending” partners who include hotels, retailers of every stripe plus indulgences like personal chefs or the aforementioned spa experiences.

In this case, Aeroplan needed to do something to reduce the points customers were holding onto and this was the mandate when they spun off from parent Air Canada.

Carr explains this situation thusly,

“As member account balances swelled, Aeroplan needed to provide alternative ways of allowing members to use mileage credits beyond the limited number of flights available from Air Canada. Otherwise, there would be too many miles chasing too few seats—a common complaint about frequent-flier programs —and way too many frustrated members. Hence, it established loyalty-reward partnerships.”

OK enough background already! How’d they do it? It doesn’t sound easy, in fact it sounds rather complex, especially when interacting with many disparate partners and not-necessarily-cutting-edge travel industry legacy systems.

Carr quotes André Hébert, Aeroplan’s vice president of technology and e-business, “If you look at the Aeroplan Web site today, it’s like a combination of Expedia and a retail store Web site so it’s very complex.”

In short, Aeroplan sorted out the complexity by making a significant transition from existing systems to a Service Oriented Architecture using Open Source technologies including Linux, Apache (web server), My SQL (database) and Elastic Path (ecommerce) and using XML (eXtensible markup language) to pass data from system to system including the existing mainframes.

From Carr: Technologically, this required an evolution from the mainframe-based system Air Canada had created, designed solely to handle flight rewards, to a new architecture that retained the mainframe as a back-end transaction engine but layered on capabilities for interacting with business partners and consumers more flexibly.

Indeed, with the re-engineering, Aeroplan found themselves on the forefront of a fundamental shift in thinking about enterprise technology ecosystems – moving away from the “one systems does it all” idea towards web services approach of assembling a collection of components which understand each other and have the ability to exchange data using accepted standards.

Carr explains, “… the standard way of accomplishing that, using Internet technologies, is with Web services—the family of standards and specifications for invoking functions on remote computers with messages formatted in XML.”

With a plan in mind, Aeroplan needed a way to get products to sell and provide a way to sell them. This started with a relationship with a employee-incentive product vendor who managed sales Aeroplan’s members – for starters.

From Carr: When the system went live in early 2004, Aeroplan wanted to offer non-travel rewards but didn’t have its own catalog of merchandise to offer. … To drive more of that business through its own Web site {instead of third-party product vendor Maritz’s}, Aeroplan needed a more capable Web site and a more sophisticated level of Web services integration with its partners.

More capable, more sophisticated? Enter Elastic Path.

Carr and Aeroplan’s Lafrance break down the some primary advantages succinctly saying,

E-commerce software vendor Elastic Path provided software to manage the catalog of merchandise Aeroplan would be offering as an alternative to flight rewards. Lafrance says he was attracted to the product because of its emphasis on leveraging open-source technologies, which Aeroplan wanted to use where practical to hold down expenses.

Although Elastic Path itself is not open source in the sense of making its source code freely available, it shares source code with its clients under a commercial license, and it incorporates a variety of open-source technologies such as the Apache Lucene search engine. Aeroplan also takes advantage of Elastic Path’s support for the open-source MySQL database to store catalog content.

Bringing it all together required the many pieces to “get along” reliably plus be robust enough to manage a high volume of transactions efficiently. For this, Aeroplan stuck to their strategy of, “small pieces loosely joined” (my words, not theirs) by finding specialized tools to perform specific functions – without getting tied down with proprietary systems, stifling licensing costs and recurring subscription fees.

Carr’s article quotes Hébert on the economic advantages as well as the technical benefits of their strategy.

“We would probably end up paying a few million more in software licenses if not for our use of open source,” Hébert says. Aeroplan also takes advantage of Apache Tomcat to execute Java code running on its Web servers, rather than use a commercial application server on the Web front end. Heavy-duty processing for Java applications, including the Elastic Path and OpenJaw software, is managed within the integration framework provided by BEA Systems’ WebLogic platform.

Works well and cost-efficient equals “Great Success!”

Now, they’ve found other hospitality companies heading in a similar direction – something Aeroplan is ready to leverage – easily.

In January 2007, Best Western became the first hotel chain to support that direct-connect XML interface to its reservations systems, and Lafrance hopes other hotel partners will follow. “For us to add another hotel is no big deal, and most hotels are implementing the OTA standards anyway,” he says, referring to the OpenTravel Alliance, an industry standards group.

Any enterprise, no matter whether the goods are physical or virtual, can follow this strategy of using specialized and open components to reliably pass data between partners, members and vendors to produce a highly scalable, infinitely customizable and cost-effective architecture.

Carr sums up Aeroplan’s strategy saying, “Aeroplan’s experience shows the value to any business of the SOA approach, now widely embraced as a more flexible and adaptable way to build complex enterprise systems.”

Indeed, bundle specialized tools for efficiency and profit – leaving more time for fun.

More from Baseline:

Aeroplan Takes off – architecture diagram

SOA: What You Need to Know

The SOA Payoff

Calculator: Reaping Benefits From SOA