They sound similar, says Ingunn Ingimars, IT Consultant at Aviation42, but which you choose will have significant consequences for IT management and users

What‘s in a word?

We all know that no one in their right mind would market a product as a fragmented, isolated software system. ‘Integration’ is the key word but what does integration tell you and is your interpretation of the term the same as the vendor‘s understanding?  Integration means uniting and bringing together, creating a whole from two or more separate entities. In IT terms this means sharing and making information in one system accessible to other systems. The more you integrate the less risk you should run of duplicating the same piece of information across your systems, which can make updates or corrections quite a challenge. Carefully planned integration may also be time saving as users are not shuffling information back and forth between systems and data quality and integrity is strengthened.

Aviation requires quite a number of specialised, sophisticated software systems to run a smooth, safe and reliable operation. It is possible to start out small, buying a few software systems, none of which is too sophisticated nor too expensive.  You then couple your systems with manual processes and employees who can still maintain a good overview of your operation. However, as the organisation grows larger, levels of complexity also grow; soon there are increasing numbers of employees who need to maintain the same overview and you probably find yourself in a dilemma.

How do we interpret the word ‘integrated‘?

The first interpretation is of a software system with one database and multiple sub-systems or modules which all read and write from the same database. This is also referred to as a software suite. This way, the modules for, say, maintenance planning, crew planning and yield management all refer to the same instances of sectors as does the flight scheduling module. If a sector is delayed or cancelled, all modules involved are notified because they all work from the exact same data.

Figure1

The second interpretation is of a collection of software systems, each with their own database, and where the information is replicated (see paragraph below, ‘Replicate vs. duplicate‘) across the databases. If the flight scheduling system delays or cancels a sector, that information is sent out via an integration platform to all the other software systems.

Figure2

Replicate vs. duplicate

At first glance, there is not too much difference between the words replicate and duplicate. However, in IT terms it is good to think of replicating as something you do intentionally – e.g. you set up a link that replicates flight information from one system to the next, and not only once as you also replicate all subsequent changes and updates to those flights. When you duplicate, you are copying information from one system to the next, perhaps unaware of what happens to data integrity when/if the information in the first system changes.

The domain you work in

Consider the systems you have within your company. You might aim for an integrated system, a suite of modules covering many aspects of your business, but you also fetch and receive information from systems on the outside (e.g. Type B messages, currency exchange rates and fuel prices to name but a few). The IT domain in which you work is therefore greater than your in-house IT setup and ultimately there comes a time when you may want to think about integrating those systems with your own. By systems in general we are not only referring to an application installed on a PC in the classical sense but web pages, web services, RSS feeds and any piece of software that contains data in which you are interested and of which you can make use. It is not uncommon to see an IT environment with 80-100 different systems and it is the role of your IT department to get all the pieces of the puzzle together.

Methods of integration

Let us first look at what you actually do when you integrate something, i.e. when you are sharing information. Take a look at a very basic example: Your flight scheduling system gets updated with accurate take-off and landing times, delay codes and other bits of information. You also have your reservations system, where you want the exact same flights to reside and which also stores information on passenger loads. You then have your flight planning system, in which you also want information on flights and passenger loads.

The purple arrows indicate integration where you are transferring data between systems.  Flight sector information goes to the reservation system and the flight planning system and information on numbers of passengers on each flight goes to the flight planning system for accurate fuel, load and balance calculations.

Figure 3

There are a number of possibilities when it comes to transferring information from one system to the next; so let us start with the most correct, by the book, way of doing it.

API – Application Programming Interface

This method requires the most time and effort but it is by far the most sophisticated one. You get access to information in system X by ‘talking to‘ its interface and you take that information and move it to system Y by passing it through its interface as well. Think of these interfaces as self-service kiosks where you walk up to the counter and do your business when it suits you. Changes to the databases in either system do not affect you because the interfaces remain the same.

Figure 4

When using APIs, you create small applications, often referred to as agents, which are programmed specifically to carry out a task such as ‘every 5 minutes, check for changes in system X to a running three day period (from yesterday to two days ahead) and, if changes are found, to send those changes to system Y‘.

Other methods include:

Push/pull using files

System X pushes information out and system Y pulls the information in. This can be done by saving files in a shared and accessible location such as a folder on a hard disk/server or an FTP folder. As with the API method this would generally involve a piece of middleware or agent to automate the process and present the data from system X to system Y in the correct format.

Import/export using files

A user using system X generates a file with information and exports it. A user using system Y imports the file. Again, a piece of middleware may be required to transform the data from system X to system Y in the correct format.

Accessing the database

This is never a recommended way of transferring data between systems as you access the data for system X in the database and transfer it to system Y. By writing to or amending a database directly, there is a very high risk of corrupting the data (and the vendor, in all likelihood, releases himself of liability for keeping your data stable).

An integration platform

An integration platform is a software system in its own right. It is a tool for integrating applications and business processes alike. InfoSphere Information Server by IBM, MuleSoft by MuleSoft and webMethods by Software AG, to name a few, are all integration platforms. Some integration platforms offer visual representation of the agents which are running, alerting you if an agent between two systems fails, thus jeopardizing data integrity. You also use the platform to schedule when these agents should run and what should happen in case of failures (e.g. e-mail sent to IT administrators).

Please bear in mind that you may not always need a special integration platform in order to get some integration under way but as you grow and expand it is a good idea to have a platform that manages all your agents.

Assessing the API

When choosing a software system, you should not only look at the functionality of the system itself and what it can do for your users. You should also place great emphasis on what the system can do for your other systems, i.e. through its interface. The functions in the interface most often have quite descriptive names such as getAircraftInfo, getFlight which you can call with or without search criteria and they return the information requested by reading from the database and passing the data over to you. The interface should also have set functions such as setPaxLoad which allow you to pass information through the interface and which gets written to the database.

You should study the interface documentation carefully and possibly bring in an expert if needed. Think to yourself what kind of data you would like to be able to retrieve from the system, e.g. you need to be able to send delay information from operations control to maintenance as well as flight planning and you would like to send passenger loads from reservations to flight planning.

The mobile office and business intelligence

Today‘s mobile office places a greater demand on your IT strategy. Employees are on the go and use tablet computers and phones to a greater degree than before. They prefer clear and concise information in dashboards and reports, built on data which you may need to pull in from various systems, preferably through APIs. A solid integration platform enables you to cater to these needs.

The upside and downside of integrated systems

As your company grows and expands the integrated system needs to grow with you.  The more carefully you select the integrated system, the longer it benefits you. This includes making sure the system is geared towards the kind of operation you are running (cargo, charter, scheduled or VIP flights), what areas you operate into and what regulatory framework you need to fulfil.

A few upsides are:

• When starting up the company you have one system that covers many areas of operations;
• A consistent user interface eases training especially where cross departmental use is concerned;
• The system may be modular so starting with key modules and adding further modules later can ease implementation and initial cost;
• It is a one stop shop regarding contracts, support and upgrades;
• You have single sign on and centralised user management.

The downsides are:

• An integrated system may not be ‘best of breed’ in some areas. Perhaps it has a strong engineering module but the crewing does not meet an organisation’s requirements;
• You are locked into one vendor whose system runs your entire business;
• If you decide to break away from one of the modules in the integrated system, e.g. crew planning, it may proof to be difficult and expensive to integrate the new crew planning system into the integrated system, if at all possible and feasible;
• The integrated system may not grow with your company and the vendor’s development roadmap may differ substantially from what you need in some of the modules;
• The vendor may not place great emphasis on creating and maintaining a good API for you for external use as so much of the information flow takes place within the system itself.

The upside and downside of integrating your systems

On the upside you:

• Have the freedom to choose whatever software system that fits your business needs the best;
• Can introduce new systems when you need them and thus control the speed and cost of implementation;
• You will be able to connect most of your systems together in any way you like, provided they offer good APIs;
• Have a better chance of creating reports, dashboards and working with business intelligence.

The downsides are a few, including:

• More difficult and volatile user rights as you need to manage multiple access controls;
• Possibly higher database licensing fees as you have more types and instances of databases;
• You need a stronger and more capable IT department to manage different systems, interfaces and the integration;
• In addition to software licensing you need a budget for interface and integration development;
• You may have to bring in third party developers and manage the communication between the software providers and the developers.

It is important to keep in mind that the cost of integration is sometimes much higher than having well-defined processes that require some manual work. This applies in particular to processes that are executed infrequently. What this all boils down to is that careful, long-term planning will reap the greatest benefits.

Conclusion

A single database system, an integrated system, that covers all areas of aviation doesn‘t exist although you will find a few that tackle a fairly big part of your operation. You should be prepared for eventually finding yourself with a mixture of systems and databases which you may want to integrate. Therefore, laying out the long term strategy and choosing an integration platform is a wise move. Moreover, managing your software systems is a marathon and not a sprint as integration is a complex undertaking that can, and should be, carried out in small steps.

Further links
http://en.wikipedia.org/wiki/Integration_platform
http://en.wikipedia.org/wiki/Application_programming_interface