An aviation oriented Master Data Management solution means first of all: to have all the master data around airports, aircraft, airlines and others – but packed into the right functionality and data modeling.
- A bi-temporal data model allows totally flexible data management, which reflects the everyday business processes like retrograde updates, temporary updates and more.
- Virtual groups allows an application or department-driven grouping of master data (fleet, positions, …).
- Three step work-flowing (Proposal, Accept/Reject, Release, ...) for generating certified and high quality ma ter data – variable at any time by setup.
- Master matrix for data gathering from concurrent data sources with an automatic quality switch, which can be setup at any time.
- Services for publishing certified master data and comprehensive query services, following the standards of SOA.
- Aviation-oriented master data packages: aircraft, airport, minimum ground times, turnaround management, codes, …
As a aviation-specific solution, A:MDM offers all the typical master data for planning, operations and maintenance as well as the many aviation code tables – within the information clusters: airline, airport, aircraft and others.
All entities include system attributes like effective date, discontinue date, snapshot, active flag, source, ... as well as comments. See also the feature of virtual groups, therefore no groups (fleet, gate groups, ...) are mentioned in the following.
This information cluster includes geographic information.
|Airport||IATA code, ICAO code, title, type, longitude, latitude, restrictions with references to city, country, timezone, traffic area|
|City||ISO code, title, longitude, latitude with references to timezone, country, traffic area|
|Country||ISO code, title, telephone code with reference to traffic area and continent|
|Timezone||Country code, country zone, GMT/UTC variation, DST variation. DST start date and time, DST end date and time, DST status|
|Traffic area||Code, title|
This information cluster gives an inner view to an airport.
|Aircraft position||Airport, position code, title, pushback indicator, restrictions|
|Gate||Airport code, gate code, title, bus indicator, restrictions|
|Terminal||Airport, terminal code, title|
|Runway||Airport, runway code, title|
|Minimum ground times||Airport, aircraft type, origin (airport, country, ...), destination (airport, country, ...), service type in/out, airline in/out, transit indicator, minimum ground time|
|Minimum connecting times||Airport, Standard times, gate to gate times, security times, ...|
|Taxi times||Airport, aircraft position to runway times|
This information cluster offers the complete, IATA-oriented aircraft/type hierarchy.
|Aircraft family||IATA code|
|Aircraft type||IATA code, ICAO code, model name with reference to aircraft family|
|Aircraft configuration||weights (MTOW, MZFW, MLW, ...), engine with reference to aircraft type|
|Aircraft||Registration, owner, given name, delivery date, restrictions with reference to aircraft configuration|
|Aircraft version||Code, seats per compartment, blocked seats, ... with reference to aircraft|
This cluster holds not only airline headinfos but also information about the organization (partner airlines, subsidiaries, ...).
|Airline||IATA code (2), IATA code (3), ICAO Code, title|
|Partner||Airline code, service types, aircraft owner, aircraft types, ...|
|Handling||Airline code, service types, aircraft owner, aircraft types, ...|
|Passenger||Airline code, passenger status types|
Typically paper-driven master data: Codes - even, if they are changed often (sub-delay codes for example) ...
|Service type||Code, description|
|Delay reason||Code, description|
|Sub delay reason||Delay reason, code, description|
|Disposition type||Code, description|
|Change reason||Code, description|
|Reason for loss||Code, description|
This information cluster includes all the meta data for setup (online, on demand) of the A:MDM.
|Virtual group||Entity, set, labels, data owner, ...|
|Master matrix||Sources, quality level, ...|
|Workflow||Entity, workflow, deadline, period of changes|
|Dictionary||Entity, attribute, value, languages, label|
|Notification||Entity, attribute, value, languages, label|
Later this year the A:MDM will be extended by the following packages:
- OCC Management
- HCC Management
- Crew Management
- Safety and Risk Management
- Business Intelligence
Since all entities are containers (enabled for bi-temporality, workflow, ...) in an A:MDM 'machine', it is very easy to extend this by own entities as well as extending the existing entities above.
Bitemporality at Work
Since the master data services also consider the aspects of data warehousing, they are constructed historically, driven by a versioned data model.
A master data record is always defined for a period of time, implicitly – valid from today – or explicitly – valid from January 1, 2011; valid as well until December 31, 2011. Often data only have a valid-from date with no until-limitation – until the next change takes place. Then a new valid-from date is set, again without until-limitation – and in this way the previous entry is limited implicitly with regard to its until-limitation.
With every change, a new master data record is created – the previous one is still valid for the past. Thus it is possible to get the correct data for any reference date, which can be in the past as well as in the future. This data contains not only the information, but also the validity.
Having a demand for a reference-date related view, a second time dimension arises. Therefore the master data services work with bi-temporal data modeling: Not only is the business-logical validity (valid from/valid until) important, but also the date of the record creation or update.
The bi-temporal model implies the dimensions of classical validity plus the dimension of changes.
The bi-temporal model implies the dimensions of classical validity plus the dimension of changes - extended by queries (Q1, ..., Q3).
The bi-temporal model implies the dimensions of classical validity plus the dimension of changes - extended by queries (Q1, ..., Q3) and by snapshots (t1, ..., t4) of these queries.
The master data services technically work with journaling, which creates a new record with every change, working from history. The collection is carried out from the oldest forward to the latest entry.
The query of a journal-based model must allow for bi-temporary modeling of course. The following are examples: The second query comprises a longer validity period, whereas the other two are valid for one day (e.g. ‘today’). These queries generate the following results or 'sums':
The examples have the implicit reference date ‘today’ (t4), but of course other reference dates can be chosen any time, here e.g. t1 or t2. This results in different outcomes at each point in time – according to the journal and intuitively meant this way, since the user has made several changes over the course of time.
All queries have the following in common:
- It is always reference-date related – where no reference date is chosen, the day of the query is used (“today”).
- The entries of an item (with the same key) are scanned from the latest entry to the oldest entry, in reverse chronological order, and are totaled according to the period of time.
- It is always validity-related – where no validity is indicated, it is assumed that the record is valid for today.
- When a validity period is indicated, all entries are collected and added to a reference-date related view. In this way new entries can ‘overwrite’ older ones (interim changes).
Workflows on demand
Master data is often edited in a workflow, for example airport or station-focused data like minimum ground times or related process times, which are configured worldwide, but then have to be certified and released from a central department (OCC, ...).
A:MDM offers workflows that can be switched on and off as required, for any entity, simply by dialog driven settings, including definitions for deadline and validity.
One, Two, Three
- The preset one step workflow provides a record with a release status.
- A two step workflow distinguishes between collection (proposal) and release (released) in order to be able to build and discuss data first before enterprise publishing.
- A three step workflow distinguishes between one or several entering persons, who add the data (proposal), as well as a manager, who checks the data and then accepts it, or gives it back to the person who entered it for correction, via rejection.
- Furthermore, it is possible to inactivate an item. It is still released, but inactive like gates under reconstruction or inoperative aircraft, and can be selected.
- Finally, deletions are also possible, certainly (but only in the sense of bi-temporality, not physical but snapshot driven).
Most of the discussions about the right master data entities revolve around hierarchies or categories. The best examples for these are the aircraft types (subfleets, subtypes, fleets, configurations, ...). Very often it is nothing more than different departments having different views.
Therefore, A:MDM offers an effective way of handling these views without diluting the relationships in the master data model. The mechanism of a grouping is now generalized, i.e. provided by an application-independent functionality of the tool, by so-called virtual groups, which can be added freely by users.
Typically groupings occur by categorizations, which are given by ‘natural’ relationships, e.g. the type of aircraft. This is achieved by a reference to the category, within the element itself.
This has the serious disadvantage that there can be only one assignment – or then via n:m relationships is solved in some tables in turn.
Instead of n:m relationships, these can be solved in terms of views by virtual groups or virtual relationships:
These allow a collection of keys (aircraft, airports, gates, …) per entity and per data owner (client, department, system, or application) and per title (“A1-A33“, “ramp“).
A:MDM allows for any entity/attribute/value-combination labels for multiple languages, in addition to the English labels as standard. These labels can easily be added by meta data in the A:MDM Manager.
Multi-language meta data
It is the clear intention to support multiple and de-centralized repositories of master data, instead of keeping the master data in an enterprise database only.
In the era of Service Oriented Architecture it is a matter of course that A:MDM offers all the master data via Enterprise Services and an Enterprise Service Bus, not only as query services by SOAP services, but also as updates via topic queues. As a part of the A:Foundation the A:MDM services work with different ESB providers.
- Every entity comes with an XML schema – on its own and within hierarchies, given by the entity group. Those XML schemas are wrapped by SOAP/WSDL or offered as an XML schema file per URI for the usage of topic queues.
- Besides these type-strength services there are also generic services, which are highly configurable by query parameters and always deliver the data as tables in a choice of formats such as XML, JSON or CSV.
- All services encompass MDM internal aspects like bi-temporality, status of workflows and others. They deliver the classical data model of effective/discontinued master data.
- The query services allow comprehensive content filtering.
- The topic queues offer updates only, within a very simple data mimic with inserts, updates and deletions (after a change of validities for example) for the repository of the master data.
- There are also daily to monthly delivery services using the good old FTP, of course support legacy systems.
- It is also possible to use the query dialogs in the A:MDM Web Client and when exporting the data.
- And finally, every kind of interface can be added by customization – with all the experience gained from our A:Hub projects and technologies.
The A:MDM comes as product out of the box – only a server and a Web Browser is required, nothing more.
- Queries with extensive and filter options.
- Editing, if granted by the access control, is dialog and validation driven, comments are possible.
- Workflows are seamlessly integrated into the queries (show all rejected items, show and accept all open items, ...) and the edit dialogs (make a proposal) - switchable on demand.
- Exports, if granted, can be made in all (filtered) queries, simply by pressing a button.
- In combination with the Portal the A:MDM allows widely configurable user access control within multi-tenancy.
- Dialog-driven setup of the master matrix, workflows and more.
- Web browser only.