Change Management

This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.

The iSHARE Trust Framework is dynamic. The change management process describes the steps that the Scheme Owner MUST take to make changes that impact the Trust Framework or functioning of data spaces operating with the Framework as the standard.

These changes include alterations to:

• iSHARE Trust Framework documentation and -specifications;

• The Scheme Owner API;

• Scheme Owner tools (e.g. test- and certification tools).

Goal

The goal of the release management process is to:

• Decide in a standardised, transparent way on what changes are (not) made;

• Release changes in a standardised way, with minimal disruption to the functioning of the iSHARE network.

Responsibilities

Several parties have responsibilities and tasks in the release management process:

• The Scheme Owner is responsible for facilitation of a swift course of the process, and for minimising the impact of changes and releases for all participants;

• The Change Advisory Board has the responsibility to advise the Scheme Owner on proposed changes;

• Adhering/ Certified Parties/ Satellites can (cooperatively) prepare and submit a Request for Change (RFC) to the Scheme Owner.

Sequence

The following sequence is based on ITIL v3.

1. One or several submitting parties (this can also include the Scheme Owner) submit an RFC which describes at a minimum:

   1. A description of the desired change;

   2. A description of the context/immediate cause;

   3. An indication of what priority the change should have;

   4. The potential solution (direction);

   5. The impact for Certified and/or Adhering Parties and the Scheme Owner;

   6. The justification of the change in a business case.

2. The RFC is logged by the Scheme Owner;

3. The Scheme Owner assesses the feasibility and impact of the submitted RFC and:

   1. Schedules the proposed RFC for review by the Change Advisory Board. He communicates this to the submitting party(ies);

   2. Does NOT schedule the proposed RFC for review by the Change Advisory Board. He issues a written statement to the submitting party(ies) explaining why;

4. The Change Advisory Board assesses the RFC and provides the Scheme Owner with advice on how to proceed;

5. On the basis of the CAB advice, a draft solution and the estimated impact, the Scheme Owner either:

   1. Accepts the RFC and prioritises the change; or

   2. Rejects the RFC;

6. The Scheme Owner issues a written statement to the CAB and the submitting party(ies), explaining the reasoning behind the acceptance/rejection of an RFC and the change's priority;

7. If relevant, the Scheme Owner updates the release calendar and the priority of upcoming changes;

8. The Scheme Owner alters the iSHARE Scheme based on the release calendar, and publishes a new version of the scheme accordingly.

Emergency changes are changes that MUST be implemented as soon as possible, for example to resolve a major or critical incident. In case of an emergency change the Scheme Owner accelerates the execution of the process. They can choose to consult (members of) the CAB on an ad-hoc basis if timing permits and deemed necessary.

If a change does NOT impact the legal or technical scheme agreements, the change MAY be made without taking the steps described here. Such changes include (but are not limited to) the restructuring of content, correcting grammatical mistakes, and maintenance to hyperlinks and labels.

Versioning guidelines

Each version of the iSHARE Trust Framework has a unique identifier that conveys the significance of changes between releases, whereby the first sequence is changed for the most significant changes, and changes to sequences after the first digit represent changes of decreasing significance. iSHARE uses a sequence of three digits for its versioning (x.y.z):

1. MAJOR version for significant and/ or backwards-incompatible changes (v1.0 to v2.0)

2. MINOR version for regular changes and/ or new functionality (v1.5 to v1.6)

3. PATCH version for small fixes (v1.7 to v1.7.1)

The Scheme Owner may choose to jump multiple minor versions at a time (v1.2 to v1.5) to indicate significant changes have been made, but are not enough to warrant incrementing a major version number.