Common Types of Omnichannel Services

Dec 18, 2014
Christian Forsberg

tiersThis is an overview of the most common types of omnichannel services, and on the left as well as in the below video you find an overview figure that describes a typical omnichannel service architecture.

It shows the devices, or channels, the touchpoints (e.g. apps or webs), the back-end (legacy) systems, and the services. The services are divided into three main tiers – low-end, high-end, and front-end services.

Starting from the bottom, the low-end services use functionality and get information from the back-end systems. They handle the specific interfaces, security measures (types of authentication, authorization, encryption, etc), and data structures. Ideally, the low-end services deliver data back to its consumers in a format that conform to a master data model. If a MDM (Master Data Management) initiative has defined the format and storage of the most important information, like customers and products, the nice thing here is that the low-end services can make sure that the data they deliver conform to that model even if the back-end systems are not yet supporting it.

Then we have the high-end services that implement a certain domain of functionality, like order handling or booking, which often include the processes that are related to that domain. These services can be designed in a generic way, and independent of its consumers. For example, if a consumer is asking for the information about an order, all the information related to that order (customer, addresses, order items, payment conditions, etc) is returned. The high-end services are usually the result of a SOA (Service Oriented Architecture) initiative.

The front-end service deliver functionality optimized for touchpoints (e.g. apps or webs), which mean that they use effective data formats, like JSON, and only the information that is to be shown in the user interface. An important difference with the other types of services is that front-end services should be built at the same time as the consuming touchpoints are implemented. I have often seen the mistake of building the front-end services first, and then the touchpoints, which have generated a lot of extra work or even duplication of efforts on several client platforms. Building front-end services in the project to implement one or more touchpoints will make sure that a specific functionality is implemented in the right place (e.g. common logic on the server) and will also make it easier to handle changing requirements.

Finally, the low-end services are data-oriented while the high-end and front-end deliver functionality, and services can use other services on the same or lower level, but never on a higher level.

…and please also embed video with <iframe width=”560″ height=”315″ src=”//www.youtube.com/watch?v=U_LCtEZR5s0?rel=0″ frameborder=”0″ allowfullscreen></iframe>

About the author

Global Digital Channels Lead Architect | Sweden
Chris Forsberg is Sogeti’s Global Chief Architect, and his current passion is serverless architectures with microservices, cognitive solutions like chatbots, automation, and beautiful delivery. He has a long background as an architect of digital solutions for many clients on all the major platforms, and love to experiment with new technology.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Slide to submit