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