Airline dashboards aren’t solely about visualization. On the contrary, the bigger challenge when developing airline dashboard software is in the backend: Data integration, calculation, orchestration. Here are the software components you should consider when developing a profound airline dashboard software.

Visualization is Just the Icing on the Cake of an Airline Dashboard Software

When discussing airline dashboards with clients and users, most are predominantly interested in the visualization part. They usually want to know how the software can visualize content. And sometimes, this discussion goes as deep as the usage of colors.

However, the way content is visualized in the end is 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 aim 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.

A Very Techy Airline Dashboard Software Post

With this post, we want to take a look under the surface and introduce the software component we use to create stunning airline dashboards. However, I have to warn you that this post is a somehow techy post.

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 the first overview of these software components:

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

Airline Dashboard Software Components In Detail

Data Integration Hub

The data integration hub reflects a dedicated 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
  • 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
  • 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 

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!


Master Data Management Tools — 5 Critical Implementation Drivers


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


Benjamin is a content-maniac, music-lover, aviation-enthusiast, and CEO of Information Design (in this order). His daily business revolves around pioneering solutions to change the way airlines, airports, and aviators use information. His visions are based on expertise gained in more than 15 years in the industry and working with renowned airlines + airports worldwide.