Search
Search
Close this search box.
Search
Close this search box.

5 Essential Components Of A Profound Airline Dashboard Software

With many of my blog posts, I focus on the aspect of the content and visualization aspects of airline dashboard software. However, this represents only one part of the airline dashboard software. There's a second part that is probably even more important. And this is about the software components you need to set up an airline dashboard.

Nevertheless, to be more precise, a considerable portion of our clients —or a considerable proportion of our client’s users— are predominantly interested in visualizing their dashboard. So, for example, what kind of KPIs are displayed? Which visualization forms are used? Etc.

KPIs Are Just The Icing Of The Cake Of An Airline Dashboard Software

However, the type of information, data, and KPIs that are finally visualized are only the icing on the cake. Especially in case an airline dashboard software is more than just a visualization of one data source. A sophisticated backend is required if you are aiming for profound software that also provides functions beyond a simple KPI dashboard. A backend that —most often— consists of several software components.

Additionally, when discussing the usage of our product (aWall) with clients, it is of immense importance to understand the backend ecosystem and components. This helps our clients to unleash the full potential of the software and utilize all functionalities.

Let’s Take A Look Under The Surface Of An Airline Dashboard Software

On a higher level, we divide a dashboard software ecosystem into five essential components. The components are seamlessly and flawlessly integrated and use a standardized XML-driven data object model. Here’s the first overview of these software components:

  • Data Hub
  • Master Data Services
  • Data Warehouse
  • Notification Service
  • Event Service

Airline Dashboard Software Components In Detail

Data Hub

The data hub reflects a dedicated integration software component that mainly serves two tasks. First of all, it connects the airline’s source systems. Therefore, the data hub provides ready-to-use standard interfaces for many common airline software systems. Here are a few examples:

  • Sabre
  • Amadeus Altéa Suite (FM, CM, DCS)
  • Netline
  • ACARS
  • AIMS
  • AMOS
  • etc.

Furthermore, a whole bunch of message protocols is supported. Examples in that context are:

  • Apache ActiveMQ
  • Apache Qpid
  • S/FTP
  • HTTP/S
  • IBM Websphere MQ
  • SMTP
  • SOAP
  • STOMP
  • TIBCO EMS
  • And many more.

The additional core functionality of the data hub is in integrating data into standardized XML objects. As a result, these XML objects represent a standardized and well-documented communication base. Objects cover different entities of an airline:

  • Flight leg
  • Aircraft
  • Weather
  • Passenger
  • Maintenance Event
  • Etc.

Summarized, the data hub connects all relevant sources, processes and enriches data.

Master Data Services

Master Data Services reflects an additional component of our airline dashboard software. This service is necessary to enrich dynamic data with an airline’s master data. Therefore, we operate a dedicated master data system as part of our airline dashboard software.

There are two essential use cases when it comes to Master Data Services. On the one hand, the services already include a vast amount of ready-to-use master data, for example:

  • Time zones
  • Country information
  • Basic airport information
  • Standard delay costs
  • etc.

On the other hand, the airline can maintain airline-specific master data. As a valuable side-effect, the airline can use the Master Data Services in the context of our product and other solutions within the airline’s IT landscape. 

Data Warehouse

We consider the data warehouse as the heart of our airline dashboard software. The Warehouse contains different layers, each serving another purpose. 

Some important are:

Archive Layer

The layer that is responsible for archiving all incoming airline data. Subsequently, clients use the results of this layer to access archive data with 3rd party BI tools. Tableau or PowerBI are just two prominent examples. Moreover, the archived data builds the fundament for further layers.

Aggregation Layer

The aggregation layer is an essential layer of the airline dashboard software for enhanced analytics and KPI calculation. The core function of this layer is to apply dimensions to data (duration, traffic areas, operator, etc.). As a result, the layer provides various OLAP cubes.

Index Layer

The index layer —simplified— counts KPI figures within dimensional contexts. Accordingly, this layer calculates the results you can see on an airline dashboard.

As mentioned, the above list of layers isn’t complete. Nevertheless, it provides the first overview of a sophisticated warehouse system as part of airline dashboard software.

Notification Service

The Notification Service is an additional component of our airline dashboard software. However, it isn’t required to calculate and display KPIs. However, it adds additional value to the complete software.

The Notification Service is a rule-based component that constantly analysis KPIs. Based on defined rules —again XML-driven— the service recognizes if KPIs change over a specified period. Accordingly, if a state is fulfilled, the service actively sends out a push notification to mobiles or smartwatches (for example, OTP drops by 2% within 30 minutes).

The Notification Service is tightly linked to the Data Warehouse since the Warehouse constantly pushes KPI values to the Notification Service.

Event Service

Similar to the Notification Service, the Event Service isn’t primarily required to calculate KPIs but brings additional benefits to the table.

The Event Service receives the complete, integrated data set from the data hub. Then, based on client-defined rules, the collected data is processed. Subsequently, if a state is matched, the Event Service pushes an event to a queue or directly sends it out.

Here’s A Practical Example

I know that sounds theoretical. So, let’s give you a practical example: Let’s say your airline focuses on premium/first-class passengers. Most likely, you are operating a department that takes care of these passengers. So, of course, that department must rely on correct and up-to-date information. 

And here, the Eventer comes in. We have connected several systems for many clients—their operations control system, passenger system, ACARS, etc. Subsequently, since the Event Service is receiving all that data, one can define a rule.

If an ETA for a flight indicates a delay (compared to the STA) 
AND first-class passengers are on-board
AND some of the first-class passengers have a connecting flight
AND (due to the delay) the connecting time for these passengers isn't sufficient 
PUSH AN EVENT

I think you get the point. In easier words, the Event Service processes incoming data from various sources, checks according to rules, and pushes events.

What Do You Think?

Always happy to receive your feedback and thoughts.

You might also like