Ecommerce Solution - Assemble

Fueled by the ubiquity of Web access, the land grab of the Long Tail, the realization that the internet is a social destination and the new rich internet applications (RIA), there is a revolution in ecommerce. Along with media, and Internet-based companies, retail is a leading vertical in this revolution. This is somewhat of a new position for retail, to be an online trend-setter. But retail is innovating and pushing Web technologies. The generic Web storefront – the left hand and top navigation, search, product catalog, product details, cart and checkout have become a standard, but have also become mundane, ho-hum. There are several ecommerce platforms available, but many mandate uniformity of form and function. This uniformity comes at the cost of innovation for the retailer.

Current retail trends such as social shopping and RIA suggest that some innovation needs to happen. I am not talking about wholesale and fundamental changes to a customer’s experience. I am talking about allowing some basic innovation to allow a retailer to introduce some new retail concepts. The out-of-the-box ecommerce solutions are typically late to the party on these innovations because the innovations are yet to be uniformly defined, therefore they are not standardized, and non-standard solutions upset an ecommerce product manager’s goals. And then there is the problem of choice.

How can best-of-breed online functionality be selected by a retailer? Most of the popular ecommerce platforms are integration solutions. Service Oriented Architecture (SOA) and Software as a Service (SaaS) are the most promising ecommerce retail architectures because they do allow retailers to separate commodity services that should be outsourced from innovative services that should be kept in-house.

SOA and SaaS also allow for the selection of best-of-breed components. This is what is meant by assembled architectures – one that is assembled from best-of-breed packages and services. But SOA and SaaS are relatively new, and most packages do not yet embrace them. SOA, SaaS services and the various opens source solutions and commercial offerings are what comprise the assembled ecommerce solution. SOA is responsible for uniformly integrating services. Ideally these services are from a SaaS provider so the infrastructure does not have to be maintained by the retailer.

Services such as PayPal for payment processing and Scene7 for image viewing are examples of ecommerce-related SaaS services that can be integrated via SOA. The basic idea is to extend this same idea to as many retail services as possible. Then the collection of services that hang off an SOA bus are then fronted by a custom user interface framework to provide the retailer with complete control of the storefront look-and-feel. And other storefronts can be created that reuse the collection of services. Finally the collection of services are unified under a common administrative toolset. This final point is important because we do not want a different administrative interface for the business users for each service. Ideally we would like a unified suite of tools the merchants and marketers can use to manage the ecommerce storefront. An assembled ecommerce solution:

• Allows retails to select best-of-breed components
• Allows an evolutionary migration strategy
• Allows the outsourcing of commodity services via SaaS while at the same time supports the construction of in-house services for innovative services
• Is agile, so it supports change as the business evolves
• Allows retailers to fully manage their brand by owning the user interface tier and thus completely owning the interactions with their customers
• Has a unified set of merchandising tools: product management, content management, image management, pricing and promotions, etc.
• Allows several storefronts, including concept storefronts, to be put up quickly because the same services are reused in the backed.

The major ecommerce components to be assembled can be broken down this way:
Back-office packages – These are systems such as shipping & receiving, warehouse management, financials, etc. These packages are mature because they solve fairly well-defined problems. They solve significant issues, but they are also well-known. Many of these features predate ecommerce. There is no need to look for a set of services for these capabilities, there are mature packages available and there is little reason to assemble here because the features are commodity for most retailers. We will need a good API to integrate via SOA, but the major back-end packages do support the assembled ecommerce platform very well.

Pre-componentized solutions – These are offerings that are already componentized such as: payment processing, personalization, content management, image management, search, analytics, etc. These are components that can be purchased or harvested from open source, and are ready for assembly. These components are already built as services and will readily integrate into SOA, and many also support SaaS. There is opportunity for innovation in these services, and the competition will help the best-of-breed selection. We will need to bind these solutions under a common business tool suite, otherwise these components are also ready for ecommerce platform assembly.

Ecommerce storefront functionality – These are baseline ecommerce capabilities such as the shopping cart, checkout, product catalog, product detail and quick view. These present the biggest challenge to the assembled solution. Most of the major solutions here are tightly integrated solutions. The retailer would like complete control of the user interface and would prefer opportunities for service innovation and best-of-breed selection at this level, but most of the existing vendors don’t corporate. The offerings here are bundled into packages where we would prefer to have independent services to consume. There is momentum for these vendors to offer their capabilities as discrete services. Amazon is a leader here, as it is beginning to offer its ecommerce capabilities that can be consumed as discrete services running as SaaS components that can be integrated via SOA.

Once the ecommerce architecture is assembled, the next hurdle is to make the architecture that was assembled from various packages and services operate as if they were one. The primary issue here is how the various components are administered. Retailers do not want multiple merchant applications and tools, so the component parts need to be integrated from an administrative point-of-view so a single, integrated set of administrative tools can work like an umbrella over the various components. This can be done with some work through administrative APIs.

We may not be able to get down to a single merchant tool, but we want to make merchandising cross-channel as simple as possible. The assembled architecture is often performed evolutionary, not revolutionary. Services can be consumed at the pace that is comfortable for the retailer, and can be integrated with legacy systems to reduce risk. In this way new services can be brought online at a comfortable pace at an acceptable risk for the retailer. This is only possible in an assembled architecture, and is another major reason why it is the preferred method to either enhance existing ecommerce capabilities or for an entire replatforming.