Release Management and Publication of Standards

How AIDM is used by different stakeholders in Standards Development Processes

The Airline Industry Data Model (AIDM) methodology defines an agile, model driven approach to building modern data exchange standards under the Passenger Standards Conference.

Continuous Quality Assurance, Rapid Delivery

Using the latest capabilities provided by the AIDM, Groups will have quick access to alpha and beta releases at any point during the development process in order to ensure quality and correct implementation of changes. This allows for a “continuous QA, rapid delivery” mechanism to be put into place, ensuring any issues are detected early in the process leaving ample time for resolution.

Continuous QA (Quality Assurance) throughout the development cycle allows Groups to frontload the effort which has traditionally come at the end of the process, leaving little risk that there are any surprises during final release preparations prior to the Board votes. These changes come together to build the capabilities necessary to support up to four releases a year as defined in Resolution 009.

Each iteration of a release should be accompanied by accompanying release notes, detailing the changes implemented since the previous iteration of the release. This enables the industry members reviewing the release to quickly identify if a change was justified by an approved change request and help filter out unintended changes to the standard.

At a scheduled point in time, the scope of a release will be frozen. Group secretaries should send all new and modified messages to be included in the upcoming release publication to the technology Group secretary for consolidation.

IATA will prepare the final release package for a final week of QA with the industry. Both the technical Group and each business Group submitting new standards or changes to existing standards will be included in the QA process.

As each Group will have been continuously reviewing iterations of releases as part of the development process, the final industry QA should focus on identifying any final issues, focusing on the overall quality of the release package.

How AIDM is publishing Standards on Release Cycle

In accordance with Resolution 009, there are four release points throughout the year. Each Business Board has the freedom to determine the frequency of publication for each standard they own.

As an example, new standards may require a higher frequency of release in order to address a rapid growth of requirements, whereas other more mature standards may only be released once per year.

This decision is up to each Business Board and the next year’s publication schedule needs to be communicated by the end of each year. This allows for both the industry Groups and standard adopters the ability to adequately plan their developments.

Standards are published on IATA’s developer portal via the IATA Standards Releases Download page as unique file package including latest version of the Data Exchanges Standards, each schema messages are using namespace to document message version and date of last modification in a release (ie. for example offerandOrder schemas will refer to the release id = 21.3 baseline until new change request is implemented to enhance this message with new change request, meanwhile correction of a validated defects (Severity 1 only) in a past release will also be available in all subsequent releases with specific communication to inform the implementers community that a new package is available with a summary of changes.

Release publication will come along with release notes and related implementation guides. As part of the release, the source business and data models used to generate the messages will also be publicly available on the developer portal in the View the Models partition (B2)

How to define Severity and Prioritization of Defects

All defects will be initially prioritized by the IATA Group secretary following the criteria below and shared with the Group for full transparency. Any disagreements on defect priority will be resolved by Group consensus.

Note: Only the defects validated as Severity 1 will be fixed in the current Release package after validation and affected schemas updated with new message version, others defects marked as severity 2 or 3 will be considered for a future release cycle.