Architecting your Omni-channel Initiative

Multi-channel retailing has multiplied the opportunities for Retailers to do more business with their customers by going beyond their bricks and mortar in order to sell over the web, through smart phones and tablets, perhaps soon on smart TVs and through Partners and Resellers.

I wish to help you see how you can achieve a significant increase in revenue by adopting an IT architecture that will bring you a rapid return on investment and help put your retail business right at the helm of a fundamental change in the industry.

From Multi to Omni

An emerging trend identifies a particular kind of multi-channel customer who is of extreme value to your retail business. Allow me to introduce her to you:

She is smart, well-informed and very much on the move. She wants to get the same level of information about products, the same promotions and access to product reviews whether she be in the store, commuting on the train or sitting at home.

She is smart, well-informed and very much on the move. She wants to get the same level of information about products, the same promotions and access to product reviews whether she be in the store, commuting on the train or sitting at home. She wants to be able to make a purchase online and perhaps pick it up at the store or even the store of her choice! She wants to purchase at the store and and have that purchase afford her possible discounts from her mobile phone. Wherever and whenever, she wants the same deal. She is the Omni-channel Customer and she is likely to consume up to 70% more than the average single-channel customer and she is also likely to influence her friends with her purchasing habits by the power she wields through her Facebook posts!

From Single-channel Visibility to 360 Degree Visibility

Part of this trend is the recognition of the mutual benefit of achieving a “360 degree view” of your Customer across all the channels. It is of tremendous benefit for your business that you know your customer and recognise her in every one of her interactions. You must learn about her preferences and purchasing habits in order to tempt her with opportune recommendations! She must feel that she gets the same deal wherever she shops, that her experience is of your brand, NOT the channel within your brand!

 

From Applications to APIs and Apps

Modern SOA architectures have shifted the focus of IT from the isolated requirements of departments or lines of business to the enterprise as a whole and from the development or purchase of similarly focused black box application software to orchestrations of reusable services that map to the business processes of the enterprise as a whole and consumed typically by internal and customer facing web front ends.

The same architecture is now forming the basis of a new wave of much simpler, coarse grained, customer and partner facing Web APIs which reuse the same automated business processes. These typically RESTful APIs are completely decoupled from the clients that consume them and so are open to a multiplicity of light-weight consuming Single Page web front ends, Android and iOS Apps and even the services that Partners have in their own IT infrastructures.

One API for Many Channels

External facing APIs can effectively expose your Business as a service to any consuming App in any of your business channels. Whether it be your main web-portal, your iOS App or your Android App or the Point-of-Sale in the store, the decision to centralise the execution of your IT automations in Web APIs will allow you to bridge the channel gaps so that all those touch points are providing your Omni-channel Customer with that single, familiar experience she demands and the 360 degree visibility of her transactions that you should strive for.

One API for More Channels

By providing your loyal customer with this Omni-experience through this single point of entry into your automated business: the same API can provide access to data which may be of keen interest to other Retailers. You could monetise the use of your APIs to these unforeseen partners who may wish to exploit the valuable statistics they can provide and use them in their own recommendation engines.

Case Study: Álainn Cosmetics

Business Initiative

Having identified the Omni-channel industrial trend as key to their strategic growth, Álainn Cosmetics have embarked on a program to guarantee a 360 degree view of their customer so that her loyalty is rewarded regardless of how she chooses to shop with them. They will provide her with personalised promotions, allow her to get news on the top selling brands and trends in the markets, receive recommendations, read product reviews, draw up a wish list, make orders and spread her enthusiasm for previous purchases through social media. The expected increase in revenue as a result of this initiative is calculated at 40% within 2 years.

Current

The IT department has already invested significant effort in building up a suite of reusable services as part of their SOA architecture. Orchestrations of these services are currently kicked off from the web portal and from points-of-sale in the stores.

Planned Architecture

The new architecture has 3 broad goals:

  1. It should provide that defining element of Omni-channel: a common experience for the cusutomer across all the channels. In order to achieve this, the team must guarantee a decoupling of all of the back end systems from the channels they cater to. In effect, there must be no channel specific systems.
  2. It should facilitate agile solutions which are responsive to changes in the Business, whether they take the form of modification of existing Business Processes or the addtion of entirely new Busienss Processes. To this end the team must strive to build and purchase Solution logic guided entirely by Business Process and focussed entirely on Business Process.
  3. It should faciliate a great reduction in Time to Market. To achieve this the team must guarantee heavy re-use of the solution logic.

The current SOA landscape at Álainn is considered the ideal stepping stone to delivering a consolidated and uniform interaction with the customer and partners by web, mobile and all other channels in line with the stated goals.

It is also expected that the data collected through these distinct touch points on the common API will be of great value to other retailers who are interested in the purchasing habits of cosmetics shoppers and are willing to subscribe to the API to the benefit of their own recommendation engines.

Client Apps

  • New Customer Portal: replacement for current Portal aiming to deliver a Web 2.0 experience through the Angular framework
  • iOS Apps: apps for deployment on iPhone and iPad to be developed by external provider
  • Android Apps: apps for deployment on Android phones and tablets to be developed by external provider
  • Point-of-sale: migrating them to consume new REST facade instead of directly into SOA services in order to bring them in under the API Management umbrella
  • Partner APIs: partners and resellers in order to expose our products on their own front-ends.
  • Other Retailers: retailers interested in the statistics we gather round all interaction with our customers

Choice of Platform

Álainn find the complete lifecycle message of MuleSoft´s Anypoint Platform for APIs extremely compelling and having thoroughly evaluated the platform, they have agreed to deploy the IT solution on the API Platform and Mule ESB.

Anypoint Platform for SaaS, SOA and APIs

The need to expose a single layer of APIs which consumes reusable SOA Services is met entirely with Anypoint. It boasts the following features:

  • Complete Lifecycle: Design, Build, Test, Document, Deploy, Manage, Engage and Consume APIs.
  • Standardised Definition: RAML boasts an extremely lightweight language and complete Design, Test, Document features in API Designer.
  • Centralised application of Policies: Whether it be Security, Quality of Service, Contract Enforcement or any custom logic you can think of, all can be applied at the flick of a switch with literally zero-coding.
  • Fine-grained Analysis: Analyse the traffic of your API Consumption based on the Applications, dates and times, geographic location and platform.
  • REST and SOAP: Exposition and consumption of both SOAP and RESTful Webservices.
  • Easy Administration: Centralised control and visibility of Servers, Applications and the Messages passing through there.
  • Write once, deploy Anywhere: On-premise or Cloud (API Gateway, Mule ESB, Clouhub) deployments of the same Application.


We'd love to hear your opinion on this post


4 Responses to “Architecting your Omni-channel Initiative”

  1. Nial – nice article.
    Before I ask my question a disclaimer – There is a lot of content on the web that explains difference between the approach to SOA vs APIs . The more I read the more I get confused. So here I make another attempt to ask the question and see if I can get clarity.
    In the example above, the client has a service oriented architecture which forms a solid foundation. The API layer on top i.e specifically the orders resource is just a wrapper and internally it calls an orchestrated SOA service ( Order fulfilment service).
    I do understand and appreciate the API design first approach and appreciate the fact that tools like API designer will allow to test and mock the APIs before they are developed. But is that the only takeaway ?
    I can see that all clients that you have mentioned would have the capability to consume a Webservice . Wouldn’t it make sense for the client to leverage the SOA governance tool(assuming it is already in place) ?

    • Hi Ramesh,
      Regarding SOA and APIs, the only difference I see is that of evolution. The SOA approach has evolved to the point of exposing APIs for consumption by multiple client software including client software from third parties across multiple digital channels and even to looking upon these APIs as business products which can be another revenue stream. The analysis of the consumption of these APIs is important to the business.
      Many principles which drive the service oriented approach continue to be relevant in this API economy. Consider Thomas Erl´s Principles of Service Design.
      As a technical artifact, the API was always present of course: way before the days of SOA. The need to separate interface and implementation goes way back even to structural programming. Though SOA never promoted the use of “webservices” per se, SOAP webservices became a defacto standard and they also had their own API. The WSDL was a formal definition of their programming interface. Nowadays our use of the term “API” as evolved to mean the same as service and typically RESTful services are the preferred approach and JSON is more popular than XML.
      Now to your actual question: by clients, do you mean the client software? If so, I see it purely as a question of convenience. Javascript frameworks like Angular make it much easier to consume an API which accepts and delivers JSON payloads because their libraries are prepared for this. JSON is after all a notation for Javascript. Likewise, the lightweight aspect is very convenient for the resource aware clients like Apps for Mobile phones. So, I guess you should consider the convenience factor here. Before I go on, can you clarify your question?

    • Hi Ramesh,

      The biggest “takeaway” is that an API-led approach to integration will ultimately lead to the ability to get accurate information to your customers, employees and partners in a timely and compelling manner regardless of the channel of interaction or digital touchpoint through which they engage.

      What do you mean by leveraging the SOA governance tool?