The Multichannel Retailing Reference Architecture

NOTE: I've updated this to include the Decision Support function, see the MCR-RA Updated post

For a while now, I've been pondering over what the ideal Multichannel IT architecture might look like or for want of a better term, the Multichannel Retailing Reference Architecture.

At the very highest level it might look something similar to my diagram below.

Whilst very high-level, I have attempted to address the business functions for a retail organisation rather than cross-cutting IT concerns, such as security, systems management and monitoring, etc.

The key element to this diagram is the horizontal 'Business Interaction Services' layer that separates the vertical business systems from the 'Sales & Fulfilment Channels'. By decoupling the multiple channels from the underlying business applications through a single consistent set of interactions, customers, employees, suppliers or business partners can interact with the business across any channel consistently. What I'll now attempt to do is give an overview of each element.

• Sales & Fulfilment Channels - these are the selling channels to the customer, such as Web, Phone, In-store POS, Mobile, etc. However, I have also placed fulfilment channels here too, the idea being that 3rd parties providing dropship fulfilment services, build-to-order services or logistics will interact with the retail organisation preferably through a subset of the Business Interaction Services. It also gives the opportunity for a flexible fulfilment network.


• Business Interaction Services - this horizontal layer provides a common data/services model for the whole enterprise and in a manner that can be easily expressed to non-IT people during the design phase of applications. A catalogue of services should be maintained and governance in place to ensure re-use of services and removal of duplication. In providing this layer it ensures consistent interaction with the core vertical business systems between the sales and fulfilment channels. Whilst a service may be interacting with multiple business systems to fulfil a channels request, it will appear seamless to the end user. As an end user moves between interaction channel, the selected channel will present the same services and information in an appropriate form, e.g. on an ePOS display, mobile PDA, Kiosk or Website. It should be made clear that this may not have to be a technology layer, but could simply be a catalogue of the interaction services provided by the underlying business systems, though typically due to legacy business applications it will almost always need to be a technology layer!

The reality these days is the 'Buy vs Build' tenet manifesting itself in sets of packaged or best-of-breed platforms, delivering business systems for specific functions of the retail organisation. Those vertical components in the diagram above represent these. In most cases, the business units being supported by these systems will access them directly rather than via a channel or the business interaction services (E.g. Call Centre staff accessing the CRM platform, Distribution Centre staff accessing the Warehouse Mgmt system).

• Warehouse Management - this function would be in place if the retailer manages its own warehouses, this may also be extended to logistics fleet management. Here we would see processes and services for picking, packing, dispatching and individual warehouse inventory management.


• Customer Relationship Management - a broad function, covering all customer contact - inbound calls, website visits, outbound marketing, etc. It is this function that understands and develops the interactions with the customer. It will also manage the single view of the customer, providing services to the channels for creating and manipulating customer information.


• Product Information Management - the central management of the product life cycle, here is where the product master data is managed ensuring the product data is available for consumption by all channels. This capability will also manage rich content associated to product; images, video, baseline descriptions (the channels may enrich this with localised content appropriate to the channel). One approach may be to hold this as a central catalogue and for channels to take a subset of products and localise their content.


• Order Management - providing the capability to capture and manage a customers order centrally. Ideally, the order management platform would also provide fulfilment planning to determine which home delivery enabled warehouse is best placed to process a customers order. For Global organisations (and dependent upon their organisational design) this would provide services to 3rd party fulfilment partners or their separate operating companies fulfilment operations via the business interactions service layer.


• Finance & HR Management - these core capabilities, typically implemented through the use of an ERP system, are unlikely to be exposed through any of the channels (though could be to streamline processes between the organisation and 3rd parties).


• Content Management - whilst product related content should ideally be managed within the product information management business systems, non-product content would be managed here. Examples might be marketing materials, property digital assets, non-channel specific content. A catalogue of core content could be created here, allowing channels to select content appropriate to their channel or locality and re-purpose as required.


• Retail Operations Management - this vertical contains all the systems for managing store processes, examples might be range planning, store planning, workforce task management. Again, whilst not necessarily obvious to expose processes through the business interaction services, it may be beneficial for optimising interactions with third parties.


• Master Data - the other most important part of this architecture is securing the single version of the truth. Ensuring only single data stores for each key logical data entity for the organisation. To retain integrity of that data, one of the business systems should be made responsible for maintaining that master data entity and access/modification of that data entity only possible through the services exposed by that business system.


• Technical Interaction Services - These services are provided as an alternative to the business interaction services layer, supporting legacy business systems, suppliers and partners that cannot interact through the preferred business interaction services layer. Use of these services should be kept to a minimum, though whilst transitioning to this architecture this is may be impossible to avoid.

A couple of technical points to labour; ensure loose coupling between channels and core business systems, and that a business system masters the data and access to that data is only achievable via that business system. The former will allow flexibility and choice of channels and the latter will enforce data integrity.

Of course, it doesn't take much imagine to compare the above to what we in IT commonly refer to as Service Oriented Architecture (SOA). However, given recent reports of the imminent death of SOA, at least as a term, I thought I'd avoid using it in my diagram and descriptions ;o)