The A:Foundation, the Aviation Foundation, is a solution from Information Design, which provides a backbone with essential services: integration, middleware, business services, business intelligence, master data management, on a multi-client platform.

All modules – A:Hub, A:Warehouse, ... – have been rigidly tested and proven in the mission-critical environments of airports, airlines or air navigation providers, and are based on state of the art technologies. All user interfaces use Web browsers only, without plug-ins.


The A:Foundation follows clearly the standards of the Service Oriented Architecture (SOA) by focusing on services.

Information Design extends this approach. The services are business-logic only and the exchanged business objects are without any GUI aspects, being finally interpreted by the client in a graphical way.


    • The A:Foundation is based on a strict decoupling.
    • Only business objects ]are exchanged between the client and the services. These have a purely business-logic view and offer - apart from the data - the identity context and the available methods for the data. Information Design has developed a protocol for these business objects, which is called COS (Client-Object-Service) and is defined by an XML schema.


    • In addition to the common functionality of a Service Oriented Architecture, it delivers aviation specific aspects (data formats, data model, rule services, …) right out of the box.
    • The A:Foundation has been created with a focus on interoperability – in many ways it brings the legacy system landscape and third party solutions together.
    • All this together with a central Master Data Management, the A:MDM, not only for the classic master data of the aviation industry, but also for the setup of the foundation (permissions, multi-client ability, languages, …) and business services (setup of complex A:Services, …).


All calls between the client and the business service occur via the Portal. The Portal provides all application-independent services like security, routing, multi-tenancy handling and more.

The components are connected via an internal service bus, synchronously over Web or RESTful services, asynchronously over queues, which can be based on different technologies (JMS, Oracle Advanced Queues, ...).




  • Authentication, which is usually effected by a connector to the enterprise authentication services of the customer, but can alternatively offer internal services.
  • Authorization, which offers service permissions (all relevant service calls of an application with read-write dmin) and content permissions (limitations of lists, dimensions, table entries - for example, of airports order process codes).
  • Routing between the business services and physical or global service – including switches for multi-tenancy requirements.
  • Added-value services like multi-language services or content- management services (news, homepage intros, hotlinks, ...).
  • Administration with a Web-client based GUI for setup at runtime, as well as performance and regularity monitoring with the Portal Manager.

Service Modeling

Business services, also added by third party solutions, find in the A:Foundation an optimal environment, because almost all the application independent functionalities are driven by the Portal and the Client Platform.

Therefore, it’s possible to focus on the business logic only – that is the idea of SOA (but the architecture of the A:Foundation reaches out to an application-independent client as a graphical business object interpreter, which is an extension to SOA).

The A:Foundation offers very flexible orchestration of business services, which allows a mix of standards and customization – within multi-tenancy, if needed – simply by configuration.

Seamless co-existence of standardized and customized services

Seamless co-existence of standardized and customized services

This example shows the customizations as red areas. The Portal/Dispatcher related table shows that the standard service “S2” (New, Evaluation, Statistics, …) has been overwritten by the individual service “I3” – for all clients. Secondly, the standard task service “S3/T2” (a sub service) has been customized for the client “ID3” only. All other clients (in the sense of multi-tenancy) use the standard service as usual.

A business service on the A:Foundation therefore has the following characteristics and benefits:

  • It is running under ideal conditions: used by a superuser in English – because all security (service permissions, data permissions, …) and multi-language requirements are handled by the Portal, transparent for the business service.
  • It has no GUI-influenced logic – only a pure business view. (Conversely all the designs of GUIs are made by a designer, not by a developer – the difference is obvious.)
  • An application is manifested at runtime, on the one hand by configuration of the Portal, and on the other by service chaining. Typically, an application has common services (aviation specific queries and validations, …), standard services (straight out of the box) and the individual services (customized or developed for the customer).
  • The Portal applies the orchestration by a master data-driven dispatcher. This means: Customization can be performed strictly separated from the standard functionality delivered out of the box – and can be reused throughout the next major releases.
  • Different business models are possible with the A:Foundation. Information Design prefers the processtask business model: The process describes the workflow with its steps (tasks) and statuses of the workflow; the tasks within are the ‘workhorses’ with a clearly assigned function. Tasks are typically reusable, processes are typically very specific. Almost all workflows can be described by this pattern.
  • Because of the business-logic-only approach, it is easy to devise tests in the sense of unit tests – but for the whole application, even with complex and stateful workflows, without using the GUI. This is a premise for test automation, and again this is a premise for effortless regression tests, especially after the first release.
  • Business services on the A:Foundation are decoupled in many ways. And decoupling is a very promising approach to developing maintainable but customized software products
    – a safe investment, not only for the customer.

As with all SOA driven solutions, and this applies especially to the A:Foundation with its application independent Client Platform, the business services are independent from the technology.

This is not only useful for technology mixes, but far more so for the design of applications, which are planned with a longer life cycle, similar to industrial solutions. So, how can an application be maintained over ten years, if the underlying technologies are changed every two years (Java platform, …)? The only way it works is through a mix of technologies – newer business services use newer technologies. In this way, the application will be renewed and partially deployed over ten or more years.

Client Platform

The basic idea of the client platform is the support of different media, not only by re-using the same business services, but also by re-using the same client framework.

New objects are then simply displayed by new object renderers, which are added via Dynamic Package Binding. It is as simple as that. In contrast, another example is that select lists with multiple selection possibility can be displayed as a swap select, multi select or various other options. Designers, who design the business services in the GUI decoupled from the developers of the business services, are responsible for this.

The client is designed to be a graphical object interpreter – the received business objects are translated according to their grammatical structure within an aligned schema. In this way, business services, which follow a process and task structure, are displayed for example as a dialog with several tabs, where each tab represents a task.

Client as a graphical business object interpreter

Client as a graphical business object interpreter

Mobile Devices

The same applies to the mobile devices with their touch interfaces – simply adding different renderers to the client platform. Additionally, there are all the services for the offline mode: local storage, local authentication, synchronization with the mothership and more.

Supported Clients

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer 9+
  • Apple Safari 6+
  • Opera
  • iOS 9+
  • Android Marshmallow+

Technical Implementation

To support as much media as possible, the following technical path has been taken: the rendering is always performed by CSS/HTML able media. The functionality is implemented through JavaScript. Complex graphics or images are performed on the basis of SVG/VML.

In especial CSS/HTML has proven to be effective and easily adaptable to the corporate design of the customer. Today, JavaScript belongs to the essential frontend development languages, supported by powerful libraries (jQuery, …).

However, to max out the possibility of the relevant medium, Information Design chooses the hybrid approach: GUI elements (date picker, selects, …) are developed in CSS/HTML, but services (authentication, authorization, security, notifications, …) of the operating systems iOS, Android, … are used natively and are integrated seamless into the framework.


The A:Foundation comes with a Web client-based GUI – the Portal Manager – for monitoring and managing the Portal (routing, security, ...) and the business services, handled by the underlying A:MDM solution.

Snapshot Portal Manager

Snapshot Portal Manager


  • Setup of the business services, by adapting the logical services to physical services (server, domains, ...), including the transparent handling of multi-tenancy.
  • Setup of the security, by roles and users for service permissions (which services are allowed), and data permissions (which content is allowed), typically driven by dimensions (airports, airlines, ...).
  • Setup of the multi-language labeling service that extends all business objects with labels within the chosen language by the user.
  • Setup of the content management service to manage news, hotlinks or system messages.
  • Monitoring of service status, errors and performance as well as user demands, based on the A:Monitor.

Third Party Support

The A:Foundation can also be used by third party solutions - including the Client Platform with it business object interpreter. The Portal offers, for example, automatic transformations from SOAP to the light weight HTTP/JSON and vice versa.

Integration of third party service

Integration of third party service

Technical Implementation

  • The Business Services, which are covered and secured by the Portal, can be accessed by SOAP.
  • The Client Platform can be used for external, SOAP based services, if they use the business object grammar, which is documented by the A:Foundation Wiki.
  • If the business object grammar is not supported, then this can be transformed by specific business services of the A:Foundation.
  • Using different business services again allows the development of a multi-grammar-server (in addition to a multi-format or multi-protocolserver).