top of page
Search
Markus Bühler

Enterprise data normalised via APIs: A real-world use case

Updated: Feb 6, 2023



Moving to the cloud often sounds like a major overhaul for enterprises with on-premises IT systems. Data needs to be moved to the cloud, and security and governance processes must be defined. Once this is done, tools can be created with little effort that makes everyday business more efficient and flexible. In this article, we use the example of one of our customers to explain how they can leverage the potential of their cloud infrastructure and profit from it.


Problem: Expensive application creation and lack of stability


Our long-standing customer – an airline – relied on a locally operated IT system. In general, the system solved the customer’s problems but was ineffective. Every time a new tool needed to be developed or updated, it was a large and expensive project.


For example, the development team had to access the database directly. This involved several steps: Getting access to that database, opening the firewall, writing the backend…. If the tool needs data from multiple databases, these procedures must be done every time. In the process, developers had to understand the database schema well. For example, they had to know application internals in order to interpret the data correctly. All too often, mistakes happened in the process, leading to inconsistencies between systems.


Another problem was that this architecture meant that the dependencies between applications were extremely large. If one tool broke down, other systems also stopped working.


Solution: A centralised API


To fix these problems, the customer decided to replace the old system in 2019. 1stQuad helped the client create a new system with a centralised API. The API documented all the steps the development team had to go through to access the databases. This means that the API automatically executes processes that developers previously had to do manually. As a result, new business applications can now be developed much faster, with few people involved, and therefore with little effort for the customer.


This approach can also decouple different systems of the customer. For this purpose, we use the so-called microservice architecture. This increases the stability of the system. If one of the tools fails, the others continue to function.


Let’s examine how airline employees can benefit from the application.


Example: A new tool for day-to-day planning


For example, look at an application we developed after the infrastructure was modernised. The tool cost the customer many times less after the fact than if they had built it with the previous infrastructure.


The application pulls crew scheduling data from multiple systems through the central API and makes it available to employees. It’s not about their planning (there are, of course, well-rehearsed and double-checked processes for that), but about the planning of their colleagues. The application provides answers to questions such as: “Who is on the flight with me?”, “When will Franziska be back?”, “Does anyone else need to be on the flight to the Maldives?”. These are not critical questions, but nevertheless, the answers help the crew members to better prepare for the mission or to better plan their daily routine.


Use Case 1: Flight overview


The application provides an overview of all airline flights for a given date range. This sounds simple, but if you consider the reality of detours, medical layovers and the like. So you quickly realise there is a big difference between planned flights and the ones that are actually carried out. This is further complicated by the fact that different systems have data sovereignty during the planning and execution of the flights. On the API, this complexity is hidden.


The app provides workers with a centralised view of:

  • Aircraft data: Flight number, type of aircraft, enrollment number.

  • Departure and arrival location: from where to where the plane is flying.

  • Departure and arrival time: when should the flight depart and land.

  • Crew: positions and names of the employees who are on this flight (chiefs, flight attendants and cabin crew).

Crew can use the search function to search for flights based on these criteria. Since the app contains live data, any changes become immediately available, whether there is a flight delay or a change in staff.


The app can also display past data, which is especially relevant for operations centre staff. They can export this data directly as an Excel file to make evaluations.


Use Case 2: Surprise crew friends and family


Airlines offer a bonus to their employees: When someone from their family or friends is on board, this person is surprised with a glass of champagne. To organise this surprise, there used to be a manual process, which has been implemented digitally in the new solution.


With the application, the surprise is organised fully automatically. Employees can specify the person’s name and their companion to be surprised. When the crew is on the plane, they are notified about it in the application. This way, employees can be sure that their loved ones will be offered champagne.


Creating an API doesn’t have to be a huge project


The good thing about this approach is that you don’t have to do everything at once. An API can be introduced gradually and grow over time.


In the beginning, it is important to clarify a few basic questions (e.g. security & permissions & user groups) and to have clarity about which system has the respective data sovereignty. Often the data sovereignty of an entity is distributed across multiple systems, or it changes during the lifecycle – for example, a flight comes from the planning system at the beginning and the operations system at the end. Once these transitions are defined, the API can be extended to include the systems involved. This approach can also be used to replace a legacy system gradually. For example, certain properties still come from the legacy system at the beginning and are replaced by it with the introduction of a new application.


If you consider moving your IT systems to the cloud, 1stQuad is here to help. We will help you assess the business value of the cloud for your specific case and will be happy to support you at every stage of your cloud journey. We will guide you through the transition to a cloud environment, build a reliable cloud infrastructure, develop cloud-based applications and advise you on the integration of cloud microservices. Let us know what we can do for you.

Commentaires


bottom of page