Skip to main content

Speed and agility is key to a successful multichannel architecture

(Image credit: Image source: Shutterstock/Kalakruthi)

ZeroUI as a concept has caught the imagination of enterprises. ZeroUI has been around in various forms for some time, just that it’s been predominantly leveraged in the consumer electronics and gaming space.

As per Goodman who coined this term says, "There are always going to be user interfaces in some form or another, but this is about getting away from thinking about everything in terms of screens."

 ZeroUI opens up a great deal of possibilities for enterprises in the space of financial institution, retail, logistics etc. to interact with their customers.

This approach essentially expands the interaction approach of a user with a computing device from the traditional keyboard and more recent touch to various other mediums such as gestures, voice and chat.

However this throws up a challenges around the need for high speed of response to a request within the architecture.  Customers when interacting over chat and various other modes such as Amazon Echo, tolerance for low speed response will significantly impact User experience. Importance of speed of response holds good in the case of Desktop and Mobile channel’s too.

If we were to look at the current digital assets like Mobile app or Web Apps. Google has done an interesting study on this.

Both mobile and desktop has shown significant improvement in Page load time, however both these channels are well over the 3 sec. This is 2013 data, I am sure this has improved in the recent times.

Based on various User experience studies there are few psychological constants.

These constants are based on the scenario where a user makes a request within a HTML based application and waits for a response to come back. Typically a user during this wait period is thinking of what else can be done while the page is getting loaded. In order to keep the user engaged, response from the web app has to be within 1000ms.

This constants becomes sacrosanct when it comes to other interaction mediums like chat. Considered a situation of asking a question on Amazon echo or Chat and waiting for over 3 seconds for a response to come back.

For an architecture to enable ZeroUI paradigm, mode of communication is a critical decision factor.


For both Mobile and Web Applications, we have traditionally been using HTTP. This protocol being friendly to various infrastructure components of an enterprise like the firewall, load balancers etc, makes it a good potential choice for other channels too. Before I get into the details on HTTP some interesting information.

  • TCP which is the underlying protocol that HTTP is using is designed for slow start. TCP does not use full bandwidth from the start
  • For a 3 way TCP handshake (SYN, SYN ACK, ACK) between NY and London will take 56ms over a fiber link, please note this is just the handshake, there is no data transfer yet. This delay has nothing to do with bandwidth, this latency is attributed to the client and the server between the 2 locations. This makes connection reuse a critical optimisation area.
  • HTTP does not support multiplexing, what this means is if a client made a request for data having text and image, until both these 2 contents are ready to be severed, client has to wait. Even if the developer was willing to prioritise content, it would not matter.
  • Increase in bandwidth after certain limit has limited impact on latency.

  • In the Mobile world, for getting a packet from a server to a mobile device in NA with 4g network would take 150-400ms, if the user gets into an EDGE zone that time climbs to 600-750ms

All these points to a potential improvement in the protocol layer, HTTP 2.0 is an attempt to improve in the following areas:

  • Improve end user perceived user latency using TCP
  • Enable server to push data to client
  • Enable  prioritisation of content delivery to the client

HTTP2.0 a critical component in enabling ZeroUI to it true potential, Tech stack that are implementing this would comprise of NGINX on the server side.  This is a significant change in the way client and servers are going to communicate.


Enabling multiple channels which is what ZeroUI provides customer to interact with the enterprise will require a different form of architecture from the 3 tier model that been around for some time now. I have attempted to put down some few the business demands that could come along with ZeroUI paradigm.

  • Support for each channel to have its own evolution or feature. For example Mobile channel & Chat channels could have their own evolution path for feature say ‘investment summary’ in a banking app.
    Mobile app could give more details given screen real estate versus chat could cut down the data points displayed.
    If there was a need to move Investment from summary mode in the home page to limited details mode, the architecture should enable this change to happen fairly fast in comparison to a monolithic app.
    Chat as a channel might want to start features that provide information retrieval related features such as account balance and over period move towards updates.
  • Each channel would like to make incremental changes specific to their channel at speed without making large scale deployment impacting all the channels. 
  • Channel specific interaction will require application to be available as API

All of these factors lends itself very well into Microservices architecture being a good choice of ZeroUI paradigm.  Ted Schadler's from Forrester has written an interesting blog on the need to shift

to 4 tier architecture model.


ZeroUI from a business perspective opens up exciting possibilities for opening up various channels to interact with customers, however, this opens up important architectural considerations before embarking in following areas:

1. Should the client go for HTTP 2.0 or Websockets
2. Protocol & Impact on Infra components such as
       a. Firewall
       b. Load balancer
       c. Web Server
       d. Impact on Transport Layer Security

3. Micros service architecture considerations
4. Build and Deployment strategy
       a. Should I go with docker or VM or a combination
       b. How will be teams be organised
       c. What kind of branching mechanism I should use when I have part of my app as Monolithic web services.

5. Testing Strategy

It’s clearly a multi-disciplinary topic, Mphasis with its strong pedigree delivering digital solutions by combining strong domain, technology and User experience capability has the right elements for a success digital asset delivery.

Biju Mathews, Vice President Industry Solutions Group, Strategic Business Unit, Mphasis
Image source: Shutterstock/Kalakruthi

Biju Mathews is Vice President Industry Solutions Group, Strategic Business Unit at Mphasis.