Draft Change Management Process

INSPIRE Maintenance & Implementation: Draft Change Management process

Title Draft Change Management process Creator Peter Parslow, MIG WP5 Creation date 2014-07-30 Subject INSPIRE Maintenance – change control Status Draft Publisher Type Text Description MIG WP5 working draft process for change management Contributor Format Word 2010 Source Rights Public Identifier 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 20000 to propose a way of working for MIG-T, JRC, and whoever will be supporting the validator. This approach aims to be transparent, tracking changes on a public website (https://ies- svn.jrc.ec.europa.eu/issues/2189) and making the details available via the (proposed) INSPIRE Register. This 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 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 https://ies-svn.jrc.ec.europa.eu/issues/. 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) 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 working draft of such a change management process, relating the concepts of change management from ISO 20000 to the INSPIRE organisational and technical environment. I assume that the technical environment will contain an INSPIRE registry, managed in accordance with ISO 19135. The process for managing change in INSPIRE was discussed and minuted at the MIG Kick-off meeting. In general, like any other maintenance issue, a request for change to an INSPIRE configuration item was to be raised to the MIG by a National Contact Point, the Commission, or the European Environment Agency. The MIG would 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 https://ies-svn.jrc.ec.europa.eu/issues 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: http://en.wikipedia.org/wiki/Change_management_(ITSM), on 30th July 2014) 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. 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 configuration items will include:  Abstract Test Suites  Executable Test Suites  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. 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. MIG-T “the MIG technical sub-group, whose tasks are to discuss and provide advice on the technical aspects of INSPIRE maintenance and implementation” (https://ies- svn.jrc.ec.europa.eu/projects/mig-inspire 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. Process overview (http://www.itil.org/en/vomkennen/itil/servicetransition/servicetransitionprozesse/chan gemanagement.php - copy right requested) This overview considers the change process specifically for the validation service(s). If MIG-T agree, it could be made more general to apply to other INSPIRE Configuration Items. 1. An RFC should be raised by any MIG Work Package that changes the Abstract Test Suite in the specification (Technical Guidance) of any INSPIRE service or 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. 2. The RFC shall be recorded. This could be as a linked issue on the collaboration platform, or their 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. 4 Once agreed, the technical support team will evaluate and develop the release necessary to implement the requested change, documenting all the changes that will be required to implement it. This could include changes to:  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 includes developing the new version of the configuration items in a development environment. It includes testing the release in a widely accessible ‘user acceptance test’ 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. 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-T JRC Software support

References ISO/IEC 20000-1:2011 https://www.iso.org/obp/ui/#iso:std:iso-iec:20000:-1:ed- 2:v1:en www.itil.org, 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 www.itil-officialsite.com.”