IT architect employed by Avinor from 2010. Have worked for Scandinavian Airlines for 5 years, primarily with integrations.

Linkedin: Ole Nymoen

Primary interests and experience of relevance for the ACI AOS Interface Definitions project:

  • Data modelling
  • Service design
  • Integrations
  • AODBs
  • Airport operational systems

Data definitions

In Avinor we created a data dictionary as part of the previous AODB++ project. This was to get control of all relevant data. 
This work has become the Airport Data Dictionary that now defines most the terms we use in the AODB/Baggage/Passenger operational systems. Having this defined set of data elements makes it easy to integrate systems. Every system uses the same terms, and if the system doesn't support it natively, transformations are done as close to the system as possible. Necessary transformations are seen as part of the system and owned by the system. No central group are responsible.

As time goes and the Airport Data Dictionary is used more and more it becomes easier and easier.

Data modelling

The Airport Data Dictionary only contains definitions of terms/elements, including their XML type. There are no data models or message formats there as they can easily be created as needed. This means that even though the data models used to define ATM data is widely different from the one defining a flight leg, it is easy to move data from the ATM model to the flight leg model, as the same terms are used.

See ON - Example Data Models for examples of Airport Data Dictionary based data models.

Service definitions

Avinor has a set of services where input and return data elements are defined in the Airport Data Dictionary, but any entities are defined in the service definition. See Airport Services for examples.

Avinor has recently designed a set of services that wrap an AODB. The services currently defined are shown here: ON - AODB Services

In the operational systems domain we strongly prefer to to design first, review and then implement/test. Having a fairly easy to understand service definition makes it much easier for the domain experts to relate to the details in the service definitions.

Architecture principles

There are many long lists of architecture principles to be found on the Internet.
Avinor has, as many other, a formal list that apply to all projects. It is, as they must be, fairly generic and high level. The first on is for instance "Keep Avinor legal and secure".

Some of the more detailed principles I follow in the design of operational systems are (in no particular order):

  • Keep it simple. Don't add unnecessary functionality to a component just because it's there and easier than to create a new component.
  • Keep it loosely coupled. No strong bindings between components, including chronological. Deploying a new version of one component should not require immediate deplyument of other components.
  • Use the Airport Data Dictionary for all data.
  • Use message based integrations between systems. 
  • ..
  • ..



  • No labels