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, a huge portion of our clients —or a considerable proportion of our clients’ users to be more precise— are predominantly interested in the visualization of their dashboard. 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. If you are aiming for profound software that also provides functions beyond a simple KPI dashboard, a sophisticated backend is required. 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 perfectly integrated and use a standardized XML-driven data object model. Here’s a 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 not only in the context of our product but also for 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 a different 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 when it comes to 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. Hoeever, it isn’t required to calculate and display KPIs. However, it adds further 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, in case 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. Based on client-defined rules, the collected data is processed. Subsequently, in case 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 focusses on premium/first-class passengers. Most likely, you are operating a department that takes care of these passengers. Of course, that department must rely on correct and up-to-date information. 

And here the Eventer comes in. For many clients, we have connected several systems. 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. Just hit me up on Twitter or get in touch on LinkedIn.


Want To Know More About Airline Dashboards And Software? Here’s Where To Start!


Previous

Master Data Management Tools — 5 Critical Implementation Drivers

Next

Two fundamental technological mistakes airlines are doing and why they are missing a big opportunity.

CEO

Benjamin is an information-enthusiast, a content-maniac, and CEO of Information Design (in this order). His daily business revolves around pioneering solutions with the aim to change the way companies use information. His visions are based on expertise gained in more than 15 years in the industry, and working with renowned companies all over the globe.