Multichannel Retailing Reference Architecture: Update

The Multichannel Retailing Reference Architecture

This is a minor update to the architecture after the comments on the original posting. I've now added the 'Decision Support' component.

This component should contain the enterprise-wide reporting and Business Intelligence (BI) tooling not encompassed in any of the other components, such as the CRM. Ideally all reporting and BI should be performed using this component, though the reality is that many application packages will provide their own specialist reporting tools that may be better suited to the job at hand. These tools may be best placed for operational reporting, whereas the tools within Decision Support will be for non-operational reporting, such as data mining historic information and trend analysis.

The challenge here will be deciding what should be considered as operational and non-operational data. One possible approach could be as follows.

Partition the 'Master Data' in to two areas; Operational and Historic. The Operational Data Store (ODS) may enforce a policy of containing only 13-months of data, whilst the Historic Data Store (HDS) may contain all older data. Of course, each entity in the ODS may have data of varying age due to legislation and compliance issues, much as data in the HDS will also be governed by such factors. From a cost perspective the HDS may go further and implement Information Lifecycle Management (ILM) techniques to store the data, e.g. 1-3yrs online, 3-7yrs automated/retrievable offline, 7+yrs offline/offsite.

The tools providing reporting on the HDS are always likely to be generic, it's more cost-effective than having secondary instances of each of the business applications for specialist reporting on the historic data. However, this is where there will always be the challenge of the business user requiring the same level of reporting they have on their operational data. Though this frustration can usually be circumvented by demonstrating the data mining and flexibility of the BI tools. The only time it may be necessary to provide secondary instance of a business application against the HDS is for legislative compliance. A recent example I have experienced was to ensure a despatch system could reproduce all labelling for any customer orders shipped internationally for a period upto 7 years. To achieve this, we had a secondary instance of the application configured against the HDS that would only be started upon business request (e.g. during an audit) and agreed with the application vendor that this would not constitute the need for an additional software licence. A cost-effective solution, satisfying both the business stakeholders and our IT budget!

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)