With many of my blog posts, I focus on the aspect of content and visualization instead of talking about the backend components that are required to drive an airline dashboard. This certainly is important, since the two elements ultimately reflect the business benefits. 

Moreover, a huge proportion of our clients —or a considerable proportion of our client’s users to be more precise— are predominantly interested in the visualization of their real-time dashboard. What kind of KPIs are displayed? Which visualization forms are used? Etc.

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 is more than just a visualization of one data source and provides functions beyond a simple KPI dashboard, a sophisticated backend with several components is required.

Additionally, when discussing the usage of the A:Wall with clients, it is of immense importance to understand the backend ecosystem and components to be able to unleash the full potential and utilize all functionalities.

Let’s take a look at what under the surface.

On a higher level, we divide the backend ecosystem for an airline dashboard into five essential components. The components are seamlessly and perfectly integrated and use a standardized XML-driven data object model.

Airline Dashboard Component 1: Data Hub

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

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

Furthermore, a whole bunch of message protocols are supported, for example, Apache ActiveMQ, Apache Qpid, S/FTP, HTTP/S, IBM Websphere MQ, SMTP, SOAP, STOMP, TIBCO EMS, and many more.

The other core functionality of the Data Hub is in integrating data into standardized XML objects, that build the internal communication base. Objects cover different entities of airline operations, for example, flight leg, connex, weather, etc.

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

Airline Dashboard Component 2: Master Data Services

Besides dynamic data that is pushed by an airline’s operational systems, we provide the possibility to use Master Data Services as an additional component. Therefore, we operate a dedicated master data system. 

Master Data Services are usually used in two ways. 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 the A:Wall but also for other solutions within the airline’s IT landscape. 

Airline Dashboard Component 3: Data Warehouse

The data warehouse reflects the component we consider as the heart of our infrastructure. The Warehouse contains different layers, each serving a different purpose. 

Some important are:

Archive Layer

The layer that is responsible for archiving all incoming data the Data Hub provides. Together with a transformation layer, received objects are stored in a —mainly— relational data model. Subsequently, clients use the results of this layer to access archive data with 3rd party BI tools, for example, Tableau or PowerBI. Moreover, the archived data is used as a fundament for further layers.

Aggregation Layer

The aggregation layer is an essential layer when it comes to enhanced analytics but also KPI calculation. Within the aggregation layer, dimensions are applied to relevant data (duration, traffic areas, operator, etc.). As a result, the layer provides various OLAP cubes.

Index Layer

The index layer —simplified— counts KPIs within dimensional contexts. Thus, providing the ultimate result to display KPIs on the A:Wall.

As mentioned, the above list of layers isn’t complete, but gives a first overview of a sophisticated warehouse system, ran behind the A:Wall.

Airline Dashboard Component 4: Notification Service

The Notification Service is an additional component. It isn’t required to calculate and display KPIs but adds further value to the complete ecosystem.

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. 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.

Airline Dashboard Component 5: 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, and in case a state is matched, an event is pushed to a queue or sent out.

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. But that requires the department to be correctly informed about what is happening in operations. 

And here the Eventer comes in. For many clients, we have connected several systems, for example, their operations control system, passenger system, ACARS, etc. Since the Event Service is receiving all that data, one can define a rule “If an ETA for a flight received that 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 an event is pushed/sent out”.

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.


I hope that post can could give a brief overview of what is happening underneath the surface of an airline dashboard and which components can be applied. Indeed, you don’t need such a sophisticated infrastructure in case you just want to visualize some KPIs. 

Nevertheless, with our product, we want to add additional value and go beyond KPIs. Therefore, it is essential to operate seamless and well-oiled components that enrich the value of an airline dashboard.

In case you need more details on that feel free to get in touch with me: benjamin.office@id1.de


5 critical drivers, you should pay attention to when introducing a Master Data System at your airline


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


Benjamin is an aviation-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 aviation industry. His visions are based on expertise gained in more than 15 years in the industry, and working with renowned airlines such as Lufthansa, Emirates, Air India, Aegean Airlines, Saudia Airlines, S7, Icelandair and many others.