INSPIRE Maintenance & Implementation:

Draft Change Management process

Title / Draft Change Management process
Creator / Peter Parslow, MIG WP5
Creation date / 20145-076-3025
Subject / INSPIRE Maintenance – change control
Status / Draft
Publisher
Type / Text
Description / MIG WP5 working draft process for change management
Contributor / Giacomo Martirano, Darja Lihteneger
Format / Word 2010
Source
Rights / Public
Identifier / Change management process – draft 1.0b
Language / EN
Relation / Not applicable
Coverage / Project duration

Executive Summary

Text in italics is ‘very draft’, dependent on other technical choices yet to be made.

Many changes to INSPIRE will result in changes to the Abstract Test Suites of the various Technical Guidance documents. These changes should result in a change to the validator. These changes need to be managed, so that the data provider and user community can make a managed transition from the old version to the new.

This paper adopts the Change Management approach from ISO/IEC 20000-1:2011 IT Service Management to propose a way of working for MIG-T, JRC, and any organisations supporting the proposed validation service for INSPIREwhoever will be supporting the validator. This approach aims to be transparent, tracking changes on a public website ( and making the details available via the (proposed) INSPIRE Register.

This paper focuses on change management processes for the components of the proposed validation service. Thise approach could be extended and adopted for all the INSPIRE artefacts that are liable to change, but are not managed as items within the register, such as Technical Guidance documents, UML models, and GML application schemas.

Requirements

A ‘configuration management database’ register in the INSPIRE registry, to contain details of the configuration items, i.e. all the documents and technical components for which change needs to be managed. MIG-T would be the register owner. Requires a register manager, and a control body?

An issue tracker, currently

A software support/development team appropriate to the validator once implemented. This could be a contract with another organisation, depending on the technical choice made.

Background

The INSPIRE Maintenance & Implementation Group created Work Package 5 to create ‘a common, officially approved, validator … accessible from INSPIRE web’.

At the second meeting of the work package members (Aarhus, 16th June 2014) we realised that we will not get the validator ‘right’ at the first go. Also, we know that the specifications will change over time. We therefore identified a need for a process and tools to control change of the validator, and of the documents and technical items on which it will depend: specifications, abstract test suites, executable test suites, GML application schemas, and so on.

This is an initial second working draft of such a change management process, relating the concepts of change management from ISO 20000 to the INSPIRE organisational and technical environment. It assumes I assume that the technical environment will contain an INSPIRE registry, managed in accordance with ISO 19135, and is therefore dependent on MIWP-6.

The process for managing change in INSPIRE was discussed and minuted at the MIG Kick-off meeting; it currently forms part of the MIG Terms of Reference[1]. In general, like any other maintenance issue, a request for change to an INSPIRE configuration item wasill to be raised to the MIG-T by a National Contact Point, the Commission, or the European Environment Agency[2]. The MIG-T would will create a sub-group or workshop to handle the RFC, and the MIG agrees to the implementation of any resulting change. I assume this function of the MIG is now to be done by ‘MIG-T’. Issues are tracked on

In ISO 20000 terms, the MIG-T acts as Change Advisory Board.

Definitions

Change

“A change is an event that is:

  • approved by management
  • implemented with a minimized and accepted risk to existing IT infrastructure
  • results in a new status of one or more configuration items (CIs)
  • provides increased value to the business (Increased Revenue, Avoided Cost, or Improved Service) from the use of the new or enhanced IT systems.”

(Wikipedia article: on 30th July 2014).

In principle this applies to changes of any size, including both bug fixes and requested changes. In common with most organisational processes, the MIG process distinguishes ‘substantial change’ and ‘minor change’ (e.g. bug fix). It is important that both kinds of change are managed in a controlled manner, although it is reasonable to take a risk based approach to the amount of consultation required. It is the level of risk created by the change that should drive the decision about how much control to exert, not a consideration of whether it is ‘a bug’ or ‘a new feature’. It is currently not clear who makes the decision whether a change is minor or substantial – perhaps MIG-T?

Change Advisory Board

This term is used to describe a group of business and technical people who approve changes and releases. In the MIG context, this would be the MIG permanent technical sub-group (MIG-T) unless they choose to establish a sub-group and delegate this activity to that sub-group.. In the INSPIRE MIG process, MIG-P endorses the work programme, which should include all substantial changes.

Change Management System

A system in which RFCs are logged, and managed through the process. Logically, this is equivalent to an ISO 19135 registry, with each RFC being a registered item. It could therefore be managed as a register within the INSPIRE registry. However, there are a number of widely used commercial and open source web based change management systems.

Configuration item

‘element that needs to be controlled in order to deliver a service or services’ (ISO/IEC 20000-1:2011). This is commonly abbreviated “CI”.

In the context of MIG WP5, the INSPIRE validation service, the configuration items will include:

  • Abstract Test Suites for metadata, spatial data themes, and services
  • Executable Test Suites for metadata, spatial data themes, and services
  • XML schema definitions (XSD files; XSD file sets for a single namespace)
  • Schematron rule sets
  • Software components of the common validator(s) – depending on the technology adopted
  • Others to be defined

In the wider MIG context, other CIs could be Technical Guidance documents and data model artefacts listed at

ISO 20000 recommends that CIs are recorded in a configuration management database; in the INSPIRE context, this could be implemented as a register within the INSPIRE registry. The Control Body for that register (see ISO 19135) would be the Change Advisory Board of this process, that is MIG-T.

MIG-T

“the MIG technical sub-group, whose tasks are to discuss and provide advice on the technical aspects of INSPIRE maintenance and implementation” ( as at 31 July 2014)

Release

‘collection of one or more new or changed configuration items deployed into the live environment as a result of one or more changes’ (ISO/IEC 20000-1:2011)

Request for Change

‘proposal for a change to be made to a service, service component or the service management system’ (ISO/IEC 20000-1:2011)

Also known as a Change Request.

Service

‘means of delivering value for the customer by facilitating results the customer wants to achieve’ (ISO/IEC 20000-1:2011)

In the context of MIG WP5, the services are the validation tools. Each service uses a package of CIs: regulation, guidance, ATS, ETS, XSDs,…

In the wider MIG context, the services that INSPIRE manages could include:

  • the software services (portal, reporting, validation,…)
  • the package that defines each INSPIRE requirement (regulation, guidance,…)
  • perhaps divided by theme: each package of regulation, guidance, schemas etc that define a theme.

User acceptance test (UAT)

Acceptance test: “the test of a system or functional unit usually performed by the purchaser on his premises after installation with the participation of the vendor to ensure that the contractual requirements are met.” ISO/IEC 2382-20:1990, Information technology — Vocabulary — Part 20: System development.

In this case, whichever group(s) initiated the change to the validation service should be involved as the ‘users’ who accept that the validator has been changed correctly.

Process overview

( - copy right requested)[PMP1]

See diagram in Annex 1 Process diagram.

This overview considers the change process specifically for the validation service(s). If MIG-T agree, it could decide be made more general to apply the same process to other INSPIRE Configuration Items.

1. An RFC should be raised by any MIG Work Package that changes the Abstract Test Suite[DL2][PMP3] in the specification (Technical Guidance) of for any INSPIRE metadata, any service, or any theme. This includes changes that impact the XML Schema Definition files, but also changes that do not. It would be better to raise an RFC even if it is not clear that the validation service will need to change.

Note: it should also be possible for the team supporting the validation service to raise a change request, for example to upgrade underlying technology.

A Change Manager (JRC staff?) shall review the RFC with whoever raised it, ensuring that it is clear and unambiguous. Depending on the Change Management System chosen, this may take place within the system or before the agreed RFC is logged.

2. The RFC shall be recorded. This could be as a linked issue on the collaboration platform, or theire may be benefit in managing the RFC nearer the code of the validator, or as a registered item in the INSPIRE registry. Whichever is chosen is ‘CMS’ (Change Management System) in the diagram above.

3. The RFC shall be reviewed by the team supporting the validation service. Some RFCs may not require any change to the validator. Some RFCs may need further discussion to determine detailed requirements. This review should inform MIG-T’s decision as to whether to treat this as a minor or substantial change.

4 Once agreed, the technical support team will evaluate (and often develop) the release necessary to implement the requested change, documenting all the changes that will be required to implement it.[3] This could include changes to any of the configuration items:

  • other Abstract Test Suite(s)
  • Executable Test Suite(s)
  • XML schema definition files
  • Schematron files
  • Other code aspects of the validation service

All changes should follow the principles being prepared by MIWP-18:

  • Minimise breaking changes
  • Retain old versions, allowing users to transition to the new version over time
  • Consistent application of version numbering

(Note: the MIWP-18 proposal is not complete; a draft was discussed, work continues)

This evaluation often includes developing the new version of the configuration items in a development environment. In more complex cases, it may be worth returning to MIG-T with design alternatives, before proceeding with development. The MIG change process assumes this. It includes testing the release in a widely accessible ‘user acceptance test (UAT)’ environment. It may include further discussion with MIG-T as the scope of the release emerges – how much change will it be.

Recommend: all breaking changes should be agreed in principle with MIG-T before proceeding to UAT. This is because these kind of changes will need more communication to all interested parties. The MIG change process has MIG-T deciding whether a change is ‘minor’ and can simply be published, or ‘substantial’, requiring review, consultation, and a formal ‘opinion’ stage from National Contact Points.

5. The release, including release notes and UAT results, shall be agreed by MIG-T

6. Plan the update: given the requirement (desire?) to keep old versions available, this will ‘just’ be the point at which the ‘live’ / default version changes from the old one to the new one. What this entails in practice depends on the ‘distance’ between the UAT & live environments, which in turn depends on the technology choices made when implementing the validator.

For example, if the validator is available as a web service, and the web service URL is itself versioned, then the release would be applied to the live server, resulting in a new URL version being available. This could be the UAT environment, with ‘live’ release ‘simply’ being switching any ‘default’ URL from the old version to the new.

A large part of the plan should be communicating the change to the user community.

7. Review: three months after the release, the change should be reviewed. This review report should be considered by MIG-T by exception i.e. if it was high profile, or if any problems occurred – either technical or in communication.

8. Closure, including attaching the review report to the RFC.

Roles

MIG-P

  • endorse work programme containing substantial changes

MIG-T: Change Advisory Board

  • decide whether a change is minor or substantial
  • prepare / update work programme (for substantial changes)
  • agree change (or refuse – although what would they then do with a changed ATS and not agreeing the change to the validation service?)
  • agree release, i.e. sign off the test results & release plan

JRC

  • change manager: log and track RFCs, ensuring progress
  • contribute to classification
  • review RFCs three months after release
  • management reports on the overall change process

Software support

  • act as a ‘permanent MIG sub-group’ for proposing solutions to changes to the validation service
  • assess RFCs
  • design & propose solutions
  • implement & test solutions
  • release – or this could be a separate role

References

ISO/IEC 20000-1:2011

noting that “The ITIL.ORG Web site is not the official Website of ITIL, but is a site that is sponsored and operated by Glenfis AG. The official ITIL Web site is Further noting that that site has been acquired by Axelos. Their site contains useful ITIL information, and appears to be endorsed by the IT Service Management Forum (see

Diagram informed by one in

MIG change management process:

Annex 1 Process diagram

Annex 2: RFC Template

This section proposes the fields that would be required in an RFC. Additional fields will be added due to managing the RFC in a register or pre-built change management system.

To be completed before assessment:

  • Originator – individual or role name and contact details
  • Originator reference, e.g. MIWP-99
  • Initial submission date
  • Acceptance date i.e. when the Change Manager agrees that the RFC is unambiguous
  • Title – brief, human readable statement of the desired change in functional terms, e.g. “Amend dataset validation service for Hydrology Network Schema to support version 5”
  • Attachments e.g. revised ATS and GML application schema, probably by reference (URLs)
  • Desired delivery date
  • Any further narrative

To be completed during assessment

  • Date of assessment / review
  • Name & contact details of assessor
  • Configuration Items likely to be affected e.g. ETS, Schematron files, components within the service
  • Proposed version numbers of new CIs to be developed
  • Interactions with other changes under consideration
  • Risk profile
  • Possible time scale for implementation

To be completed during MIG-T decision process

  • Date of MIG-T review
  • MIG-T decision: go/no go; minor or substantial
  • For ‘substantial’ link to version of work programme, via which MIG-P endorsement can be discovered

To be completed during development

  • References to actual versions of configuration items changed, which together make up the release
  • Test results
  • Release plan

To be completed during review & closure

  • Review report
  • Date of closure

Annex 3: An example

This section narrates an example, in which the Metadata Guidelines have been updated, requiring the ‘Unique resource identifier’ element to be a URI.

Actor / Action / Notes
MIWP8 team / Raise RFC / Recommend doing this in parallel with drafting the revised Metadata TG.
Change Manager (JRC) / Ensure RFC is complete & unambiguous.
Enter RFC in change management system. / Any revisions to remove ambiguity may or may not be managed within the Change Management System
JRC / Review RFC / With support team. To prepare for MIG-T decision.
Support team / Review RFC, noting that the metadata Schematron file is the only CI likely to be affected / Also not interactions with other RFCs being processed – e.g. possibility to release with another change.

In this case, the risk profile indicates that this RFC should be handled as a minor change. However, as it will render many/most existing metadata records invalid, advise MIG-T to plan the release of the revised Metadata TG & validator carefully & with lots of communication!

Actor / Action / Notes
MIG-T / Decide whether it is minor or substantial / Assume they go with ‘minor’, but require a phased changeover – validator to accept ‘old’ & ‘new’ for one year
JRC Change Manager / Updated RFC with MIG-T decision
Support team / Consider that MIG-T proposal, and prepare a revised design / Hopefully, we’re building a system that can do this!
MIG-T / Agree change
JRC Change Manager / Updated RFC with MIG-T decision
Support team / Develop & test solution
MIWP8 team / Conduct user acceptance testing
Support team / Develop release plan
MIG-T / Agree release / i.e. accept the test results, and confirm the release plan/schedule fits into their wider work programme & communication
JRC Change Manager / Updated RFC with MIG-T decision
Support team (or separate release team) / Release
JRC? / Communicate release
JRC / Review / After (say) three months
JRC Change Manager / Close RFC

[1] as at 2015-07-18T10:20

[2] The process in the ToR requires three submitting organisations to agree before MIG-T even considers the change.

[3] That is, the technical support team acts as a MIG-T sub-group for addressing all RFCs that impact the validation service.

[PMP1]This diagram has disappeared. Now we need to make our own! Partly done in EA project; need to merge in registry management bits;

[DL2]Is this the entry point or the change to the technical guidelines is the entry point?

Some views from data specifications: the hierarchy is: INSPIRE Directive, Implementing Rules, Technical guidelines, XSD (based on UML – GML/XML transformation), ATS, ETS, code. ATS is related to IR and TG requirements, to XSD and other registers (code lists, CRS register, etc.). Maybe this is different for metadata and services. ATS for data themes includes some tests for metadata and view service and some tests that could be done on data provider side only and not by common validator (for example: some tests in Data Consistency Conformance Class).

[PMP3]I believe this is the correct entry point, in that if someone changes a TG in a way that does not impact its ATS, that cannot require a change to the validation service.