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
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:
- Amadeus Altéa Suite (FM, CM, DCS)
Furthermore, a whole bunch of message protocols is supported. Examples in that context are:
- Apache ActiveMQ
- Apache Qpid
- IBM Websphere MQ
- 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
- Maintenance Event
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
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.
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:
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.
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.
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.
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.
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.