(Feedback from Australia)

The detailed Change Log for GSIM V1.5 is a valuable artefact.

Complementing that, at a higher level, might be some more general advice for those who have already implemented GSIM V1.1.

Change management for existing implementers is likely to be more significant when moving from GSIM 1.1 to GSIM 1.5 than was the case between GSIM 1.0 and GSIM V1.1.  This is because GSIM 1.0 had only been current for one year.  GSIM V1.1 has been current for 5 years and not all of the proposed changes are backwards compatible for existing implementers.

One example from the ABS perspective is the implementation of Substantive Value Domains and Sentinel Value Domains.  If these had been present in GSIM V1.1 in 2013 the ABS may well have implemented them prior to our Statistical Business Transformation Program (SBTP) starting in mid 2015.

Given some of the drivers for this change have emerged in the course of SBTP, ABS recently assessed the possibility of moving to the GSIM 1.5 solution.  Such a move was found not to be sustainable in terms of change impact on our existing Data Architecture in 2018.  

While only a few NSOs have implemented GSIM V1.1 in detail, it may be helpful for the confidence of the implementer community to have some short statement of what is expected/recommended for existing implementers of GSIM V1.1 when deciding how to respond to the release of GSIM V1.5.  ("Adopt what is useful, but don't feel compelled to make changes to existing implementations"?)

Such a message might also be reassuring for agencies that may consider implementing GSIM V1.5 in more detail over coming years.  The change management message should reassure those implementers that their implementation of GSIM V1.5 will not be invalidated in 5 years time if GSIM is revised further in 2023.

More specific guidance could be tied into the supporting documentation that will be released at a later date, summarising at a more specific level the importance of certain changes and what kind of data would benefit most from implementing those changes. For example, NSOs that deal with data that has many missing or unknown values would benefit from implementing substantive and sentinel value domains, whereas an NSO that does not have many would not see significant benefits.

From ABS experience with implementation, for example, we have found that once infrastructure has been built around a specific metadata version, it becomes difficult and quite costly to make changes in future due to the need to remediate all metadata that has been loaded previously. Some ideas that the ABS has implemented to alleviate this issue include:

  • Adding in default values for new attributes or relationships where possible, such that older metadata can be "upgraded" to newer models automatically without needing manual intervention from various groups.
  • Where new attributes or relationships are added to existing classes, they are introduced as optional to increase backwards compatibility
  • No labels