Search

Enhancements to On-line Booking Systems

June 13, 2016


The hospitality industry is going through a digital transformation and industry players are using multiple channels to increase their market reach. The services in this industry are being offered on the e-market place and e-commerce transactions are facilitated via on-line booking systems tailored for the hospitality services industry.

Some of the on-line booking systems have monolithic and/or static work flow design for life-cycle management of services. On-boarding and provisioning of new services takes significant effort and time. This increases the time to market and potentially hampers business prospects especially in a highly competitive environment.

Let us consider an example here: There is a travel facilitator portal, which offers services like flight bookings, hotel reservations, holiday packages, etc. where each of these has its own specific workflow, schema, search attribute. And it could possibly be complicated by the fact that these may have been conceptualized and implemented by different teams at different points of time. While this seems to serve the basic purpose, however an operational problem can arise when a new service (which could either be of a different genre or could be a logical ëbouquetí of existing offerings) needs to be offered. This may entail the need for multiple changes starting from (re)defining workflow to (re)writing code and data schema. As a result, it sometimes can take upto 3-4 months to launch a new service.

The following subsections discuss the possible options to improve the situation.

Candidate Architectural options

An analysis of a typical on-line booking system helps to understand the issues underlying the launch of new service offering. Following are some of the candidate options after getting an understanding of the provisional work flow:

Application of SOA (Service Oriented Architecture) model

Using a loosely coupled architecture in line with SOA model, is one of the most common approaches to allow deployment of new services. Some of the key attributes of this approach are listed below:

  • This approach relies on creating each core functionality as an independent service offering with APIs to invoke the services (REST based)
  • Different services will be talking to each other over REST interfaces depending on the service being catered, criticality of response time etc.
  • Business Rule Engines can be used to allow flexibility in provisioning rules and required actions

While this is a tried and tested approach that helps in deployment, this method still does not allow a level of flexibility to extend the workflows without going through the conceptualize-implement-deploy cycle.

Using Micro Services Architecture:

This approach relies on having smaller (micro-)services which are logically pluggable to create a workflow. For communicating with other services, these micro-services use message queues. For instance, in the context of the booking system different micro-services that are involved are as follows:

  • searching of item of interest
  • selection of best option
  • availability check
  • booking with different payment options

All these micro-services can be configured to create the required workflow.

This approach allows better flexibility of defining new work flows using existing micro-services. However, this is a relatively complex and time consuming method and requires definition of the work flows (in the work flow engine) and implementation of supporting micro-services, if any.

Using Generic Service description templates

This approach is based on the premise that services (which are abstract in nature) can be treated as commodity products; which are stocked & sold as pre-packaged items with pre-defined tags (such as unique identifier, size attributes, validity period, price, etc.). The common work-flows related to inventory management, search/filtering, recommendation/ selection, purchase and fulfillment can be applied to any service (existing or new). The key step is to define a service(s) using extensible template(s) with a finite number of attributes (some of which could be optional and can be added on a need basis). Data model for any service would typically consist of a universal parameter set (which is common across different offerings) and specific parameter set (which is to be defined on per service basis). Once the life cycle management of these template based service(s) is in place, on-boarding of new services would be much simpler. This can help in launching new services in few weeks rather than few months. For on-boarding and launching a new service, the following steps are required:

  • Identify the common parameters from the universal set that applies to the service.
  • Identify parameters which are specific to the new service offering.
  • Create a schema file (XSD) and model classes for the new offerings.
  • Implement specific business processing layer, if specific business logic is needed. If not, the default Create, Read, Update, Delete, Buy, etc. processing for the generic data model will apply.
  • Update the presentational Layer, if specific screens are needed, else the generic UI can be used to facilitate the work-flows.

 

If the workflow and service handling logic for services like inventory management, purchase, search etc. is in place, then the Generic Service Description template approach can help in getting new services and offerings launched in a matter of few weeks. This approach eases the data modelling and handling complexities using Generic schema templates which can be extended as per new offerings and services.

 

 






No Comments




Add Comment

 
 

We use cookies (including third party cookies) to ensure you get the best experience while visiting our website. Click "Accept Cookies" to accept the cookie usage. Click "Cookie Settings" to adjust cookie settings.

Mandatory Cookies

These cookies cannot be disabled

These cookies are necessary for the website to function and cannot be switched off.

Cookies:
  • .ASPXANONYMOUS
  • .DOTNETNUKE
  • __RequestVerificationToken
  • authentication
  • dnn_IsMobile
  • language
  • LastPageId
  • NADevGDPRCookieConsent_portal_0
  • userBrowsingCookie

Analytics Cookies

These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.

Cookies:
  • _ga
  • _gat
  • _gid
  • wooTracker

Functional Cookies

These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

Cookies:
  • __atuvc

Targeting Cookies

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookies:

Not used.