ECB-UNRESTRICTED T2S OPERATIONAL GOVERNANCE PROCESS FRAMEWORK

Transcription

1 T2S OPERATIONAL GOVERNANCE PROCESS FRAMEWORK Status: Baseline

2 TABLE OF CONTENTS 1 INTRODUCTION CHANGE MANAGEMENT CHANGE MANAGEMENT FOR COMMON AND SPECIFIC CHANGE PRINCIPLES PROCESS DESCRIPTION FOR CHANGE MANAGEMENT CHANGE MANAGEMENT FOR T2S DOCUMENTATION EMERGENCY CHANGE NON-FUNCTIONAL CHANGE NOT AFFECTING T2S FUNCTIONALITY CSD AND CENTRAL BANK SPECIFIC BUSINESS CONFIGURATIONS RELEASE DEFINITION DEFINITION PRINCIPLES PROCESS DESCRIPTION MAJOR RELEASE CYCLE SERVICE TRANSITION PLANNING PROCESS DESCRIPTION SERVICE VALIDATION AND TESTING DEPLOYMENT MANAGEMENT T2S SOFTWARE RELEASE OR CONFIGURABLE PARAMETER DEPLOYMENT EMERGENCY CHANGE DEPLOYMENT PROCESS DESCRIPTION ii

3 INTRODUCTION This document aims at clarifying the break-down of operational process such as Change, Release and Deployment Management, Service Transition Planning as well as Service Validation and Testing as well as the high-level process descriptions for decision-taking in these processes, based on 5 compliance with existing legal, contractual and regulatory obligations; 6 7 agreements achieved on project and operational topics in various governance groups, subgroups and workshops This framework details the implementation of change, release and deployment management, as defined in the Framework Agreement and the Currency Participation Agreement, as operational processes that document the tasks and interactions of the Operational Managers Group (OMG), Project Managers Group (PMG), Change Review Group (CRG) and the Eurosystem as Service Provider. The process descriptions in this document will be the basis for further detailing the operational processes in T2S documentation such as the Manual of Operational Procedures or relevant User Testing documents. Operational governance addresses the interaction and involvement of the technical groups (being the Change Review Group, Project Managers Groups and Operations Managers Group) aiming at an efficient decision taking and communication between these groups. All defined terms in this document are capitalised terms and are found in the T2S Glossary 1. The T2S Steering Level approves the T2S Operation Governance. The following table documents the governance bodies that own the processes specified in this framework document. Process Change Management Release Definition Service Transition Planning Service Validation and Testing Deployment Management Owner Change Review Group Change Review Group Project Managers Group Project Managers Group Operational Managers Group 21 1 Link to T2S glossary: Page 1 of 30

4 This document shall be maintained as a T2S Operational Phase document and listed as deliverable in Schedule 2, Annex 8 of the Framework Agreement and Currency Participation Agreement. The processes shall take effect on approval by the T2S Steering Level. Page 2 of 30

5 CHANGE MANAGEMENT Change Management governs the lifecycle of requested modifications and enhancements to software and services. The subsequent sections explain the processes that apply to the different categories of change CHANGE MANAGEMENT FOR COMMON AND SPECIFIC CHANGE Change Management for common and specific change clarifies the scope, actors and implementation of the high-level process, as provided in Schedule 9 of the Framework Agreement and the Currency Participation Agreement Scope Definition Common Change Common Changes are for the benefit of all T2S Actors and are subject to the change management process. There are several types of change that fall under the scope of Common Change A functional modification of the T2S software that results in corresponding changes to the T2S Scope-Defining Set of Documents A modification in the T2S Scope-Defining Set of Documents without resulting in a modification to the T2S Software. Such changes may occur when there is a need to further detail, clarify or correct information provided in such documents A modification to the requirements that the Network Service Providers (NSPs) must fulfil, as laid down in and taking into account the provisions of the NSP License Agreement A change to the General Principles of T2S, which define and delineate the scope of T2S and the setup and operations of T2S A modification of the configurable parameters in T2S (These do not include changes to CSD and Central Bank specific business configurations) A change to the harmonised configuration parameters in T2S, such as tolerance amounts, partial settlement thresholds; 50 A change to system parameters, such as duplicate check period, retention period; 51 A change to technical parameters, such as the number of instructions in a pool A non-functional change affecting the T2S functionality. Non-functional changes that affect T2S functionality are modifications to the technical platform on which T2S operates or to the T2S software that do not change the functional scope or functionality, but their implementation Page 3 of 30

6 potentially impacts the interoperability and services of CSDs, Central Banks and/or Directly Connected Parties (DCPs). An example for this category of change would be an upgrade of the database software that would require testing by CSDs and Central Banks prior to its implementation in production. Change Management also differentiates between Normal Changes and Fast-track Changes, which are qualifying time attributes of Common Changes A Normal Change is a change for which sufficient time is available to go through the Change Management Process, according to the procedure and timeline set forth in section 4.2 of Schedule A Fast-track Change is a change that requires an expedited decision-making on an ad hoc basis in order to implement legal and regulatory requirements; risk management resolutions by the T2S Steering Level; changes critical for the stability of the T2S Platform; and measures of Central Banks for safeguarding the currency and ensuring financial stability Specific Change A Specific Change is any new feature, functionality or service or any amendment of an existing feature, functionality or service which is not implemented as a Common Change, but which some Participating CSDs and/or Central Banks wish to implement, provided that it is compliant with the Lean Scope of T2S, and for which they jointly accept to bear the investment and running costs PRINCIPLES Change Management is a continuously running process that starts when a T2S Stakeholder raises a Change Request to ensure that the Change Review Group initiates the processing of the Change Request without delay in order to achieve an earliest possible decision. 77 Change Management runs independently from the Release Definition process Both the PMG and OMG may raise Change Requests directly to the CRG. The CRG should not challenge the necessity of a change that either the PMG or OMG requested The CRG has the flexibility to decide whether to submit fast-track change requests only for detailed assessment in order to expedite the review and approval process. 82 The CRG also reports rejected Change Requests to the T2S Steering Level When the CRG agrees to propose to the T2S Steering Level the approval of a preliminary assessment or a detailed assessment for a Change Request, it also submits the Change Request in parallel to the OMG for an operational impact assessment. Page 4 of 30

7 The OMG should ensure that its operational impact assessment is organised and completed in such a way that it occurs no later than the Steering Level approval of the Change Request for assessment by the Eurosystem T2S Service Provider. The Change Management process is to be reviewed in the coming months if the time taken for the Eurosystem T2S provider to complete its assessment of the Change Request exceeds the eight-week maximum for a preliminary Change Request assessment or the ten-week maximum for a detailed Change Request assessment In its recommendation to the T2S Steering Level to approve or reject a Change Request, the CRG includes in its submission the operational impact assessment of the OMG, which highlights any concerns that the OMG may have with the proposal to accept or reject the Change Request. Page 5 of 30

8 PROCESS DESCRIPTION FOR CHANGE MANAGEMENT 96 Page 6 of 30

9 The current process description does not document any activities or process flow for Specific Change requests, which Schedule 9 of the Framework Agreement and the Currency Participation Agreement also define. After the Steering Level approval of an initial baseline version of the T2S Operational Governance Framework, a later version of this document will include either an adapted change management process definition to include the activities and process flow for Specific Changes or a separate process for managing Specific Change requests. The latest deadline for defining the process to manage Specific Changes is the end of the Migration Period. Icon Label Description Change request Register the Change Request Confirmation of receipt of change request Perform formal validation of Change Request The requestor submits a Change Request to the Eurosystem T2S Service Provider using the standard Change Request Form. The requestor may be a CSD, a Central Bank, T2S Advisory Group, the T2S Service Provider or a T2S governance body (e.g. OMG, PMG). CSD participants and payment banks propose Change Requests to their respective CSD or Central Bank. If the CSD or Central Bank rejects the proposal, then the respective CSD participant(s) or payment bank(s) can propose the initiation of a Change Request as a resolution in T2S Advisory Group. If agreed, then the T2S Advisory Group submits the Change Request for registration. The Eurosystem T2S Service Provider will check whether the Change Request is formally complete and unambiguous on receipt and registration of the Change Request. The requestor receives from the Eurosystem T2S Service Provider a formal confirmation for the receipt and registration of the Change Request. The Change Review Group (CRG) receives the Change Request after its registration to perform a formal validation. The CRG will check the categorisation, completeness and clarity of the change, and may modify the request in consultation with the requestor to ensure that the change is properly specified. The CRG can decide in this step whether to submit the change request to the T2S Steering Level with a recommendation to approve a detailed assessment in order to minimise the duration of the assessment (e.g. for a Fast-track Change Request) or to perform a preliminary assessment of the Change Request. Page 7 of 30

10 Icon Label Description Approve preliminary assessment Approve detailed assessment Additional information requested Additional information received Confirmation of receipt for additional information Publish Change Request on T2S website Update Change Request with additional information Change Request rejection confirmed Response to Change Request rejection received Close Change Request The T2S Steering Level takes a decision on whether to submit the Change Request for preliminary assessment. The initiation of the approval of the Change Request for a preliminary assessment triggers in parallel the preparation of the preliminary assessment by the Eurosystem T2S Service Provider and an operational impact assessment by the OMG. The T2S Steering Level decides on the recommendation from the CRG to either approve or reject the Change Request for detailed assessment. Should the CRG require additional information or clarifications as an outcome of its validation to ensure the completeness or clarity of the change, then it submits a formal request for additional information to the requestor. The Eurosystem T2S Service Provider receives the additional information from requestor that the CRG requested to ensure the completeness or clarity of the Change Request for its validation. The Eurosystem T2S Service Provider formally confirms the receipt and registration of the additional information from requestor that the CRG requested to ensure the completeness or clarity of the Change Request for its validation. After the validation by the CRG, the Eurosystem will publish the registered Change Request on the T2S website if the Change Request does not concern safeguarding the integrity of a currency and/or financial stability as part of the crisis management measures of a Central Bank or CSD. The Eurosystem T2S Service Provider registers the additional information from requestor that the CRG requested and submits the additional information with a potentially revised Change Request to the CRG to undertake the formal validation. After formal validation or assessment of the Change Request by the CRG, the CRG may decide to reject the Change Request. In this case, the CRG notifies the requestor of the rejection of its Change Request. The CRG receives a formal response from the requestor on its rejection of the Change Request. If the requestor agrees with the rejection of the Change Request by the CRG, then the Eurosytem T2S Service Provider closes the Change Request. Page 8 of 30

11 Icon Label Description Change Request closure notified Notification of Change Request closure Escalate disagreement Notification of disagreement to close Change Request Prepare preliminary assessment The requestor receives a formal notification from the Eurosystem T2S Service Provider that the Change Request is closed. The T2S Steering Level receives a formal notification from the Eurosystem T2S Service Provider that the Change Request is closed. If the requestor does not agree with the rejection of the Change Request by the CRG, then the CRG escalates the disagreement to the T2S Steering Level. The T2S Steering Level receives the escalation on the disagreement to close the Change Request. After approval of the T2S Steering Level to carry out the preliminary assessment, the Eurosystem T2S Service Provider will prepare the preliminary assessment of the Change Request that includes A validation that the Change Request falls within the Lean Scope of T2S 2 and does not conflict with another already submitted Change Request A functional and operational impact assessment A technical assessment to determine the technical feasibility and complexity, including potential impact on real-time gross settlement (RTGs) and collateral management systems (CMS) in Cooperation with the relevant Central Banks. Preliminary cost indication resulting from an implementation of the Change Request. A risk assessment on potential effects on the stability and performance of the T2S Platform. 2 means the scope of T2S defined by the URD resulting from the market involvement and is restricted by the General Principles of T2S, as referenced in the URD. Page 9 of 30

12 Icon Label Description Assess operational impact Average 6 weeks and at latest 8 weeks after request for assessment Provide preliminary assessment Review preliminary Change Request assessment The OMG assesses whether the Change Request has an operational impact on T2S services, CSDs, Central Banks and their respective communities when receiving a Change Request from the CRG that the CRG also submitted in parallel to the T2S Steering Level in order to approve its preliminary assessment or detailed assessment. It undertakes this assessment only once for a Change Request, as the Change Request should contain the necessary information for such an assessment. If the T2S Steering Level approves a Change Request for a preliminary assessment, then the OMG performs the operational impact assessment in parallel to the approval process for the preliminary assessment. If the T2S Steering Level approves a Change Request for only a detailed assessment, then the OMG performs the operational impact assessment in parallel to the approval process for the detailed assessment. If the T2S Steering Level does not approve the assessment of the Change Request while the OMG assessment in still in progress, then the OMG terminates its parallel assessment of the Change Request. Eurosystem T2S Service Provider has a maximum of eight weeks for the preliminary assessment. Eurosystem T2S Service Provider will provide the information necessary for the preliminary assessment that is required for the CRG to evaluate the Change Request. The CRG will review and consider it from the potential impact of the change on services and operations as well as on their respective communities to determine whether to submit the Change Request for detailed assessment. Page 10 of 30

13 Icon Label Description Prepare detailed assessment At the latest 10 weeks from launch of detailed assessment Provide detailed assessment The Eurosystem T2S Service Provider will perform a detailed assessment of the Change Request that includes A functional impact assessment to determine the consequences of the change to the software functionality as well as operational impact assessment. A detailed technical assessment to determine the technical feasibility and complexity, including potential impact on real-time gross settlement (RTGs) and collateral management systems (CMS) in cooperation with the relevant Central Banks. A cost assessment for the change that includes the precise investment cost and the annual running costs as well as a breakdown of costs for hardware, software and telecommunication. A legal impact assessment to evaluate possible impact of the Change Request on the legal construction of T2S and to determine any intellectual property rights-related issues. A service level impact assessment to determine any impact on the service levels and associated key performance indicators. A documentation impact assessment to determine the scope of changes that need to be made to the T2S Scope Defining Set of Documents and other specification documents. A security impact assessment to determine potential security risk that may stem from the change. The Eurosystem T2S Service Provider submits its detailed assessment in parallel to the CRG and the OMG. Eurosystem T2S Service Provider has a maximum of ten weeks for the detailed assessment. Eurosystem T2S Service Provider will provide the information necessary for the detailed assessment that is required for the CRG to evaluate the Change Request. Page 11 of 30

14 Icon Label Description Review operational impact assessment Review detailed Change Request assessment Agree T2S Steering Level recommendation Recommendation for Change Request approval Submission of issue(s) for guidance or decision Provide guidance or decision on issue(s) Reassess Change request The OMG reviews the detailed Change Request assessment from the Eurosystem T2S Service Provider to identify substantive changes to its original operational impact assessment and raises any identified issues to the CRG prior to the CRG finalising its recommendation to the T2S Steering Level on approving or rejecting the Change Request.. The CRG will review and consider it from the potential impact of the change on their services and operations as well as on their respective communities to determine whether to recommend approval of the Change Request. When agreeing a recommendation to the T2S Steering Level, the CRG takes into account the outcome of its review of the detailed Change Request assessment and any issues that the OMG identified in its review of the detailed Change Request assessment. The T2S Steering Level receives the recommendation to approve the Change Request. If the CRG is not be able to agree on approving or rejecting the Change Request, then it documents the identified issues and submits them to the T2S Steering Level for guidance. The T2S Steering Level provides guidance to the CRG for their decision-making on a Change Request or provides their decision on a Change Request when the CRG requests guidance or decision on a Change Request. The CRG reassesses the Change Request based on the guidance that the T2S Steering Level provides. 102 Page 12 of 30

15 CHANGE MANAGEMENT FOR T2S DOCUMENTATION Annex 8 of Schedule 2 of the FA and CPA (to be further detailed in version 2.0 of the T2S Processes Framework) defines a specific change process for T2S Documentation with the following categories: Other T2S Specification Documents T2S Operational Phase Documents T2S Project Documents Other T2S Specification Documents Other T2S Specification Documents mean the set of documents, when added to the T2S Scope- Defining Set of Documents, which provide a full description of T2S. These include deliverables such as the User Handbook (UHB) and the Business Process Description (BPD). T2S Operational Phase Documents T2S Operational Phase Documents mean the set of documents that describes how T2S provides its services when it is in production. This category includes changes to Manual of Operational Procedures (MOP) that do not result from Operational Service Changes. T2S Project Documents T2S Project Documents mean the set of documents required for planning, monitoring of project activities and project organisation. This category includes the reporting frameworks and User Testing Terms of Reference EMERGENCY CHANGE An Emergency Change, as further specified in Schedule 6 of the Framework Agreement, means a change to resolve or avoid an incident that results in a complete unavailability of all or some services for which no work-around is available. Emergency Changes are not subject to a change management process, but are a result of Crisis Management and a triggering event for Deployment Management NON-FUNCTIONAL CHANGE NOT AFFECTING T2S FUNCTIONALITY Non-functional changes that do not affect T2S functionality are modifications to the technical platform on which T2S operates and their implementation does not impact the interoperability and services of CSDs, Central Banks and/or DCPs. They are changes to ensure that the T2S Operator can deliver T2S Services in accordance with the Key Performance Indicators (KPIs) of the Service Level Agreement (SLA). The T2S Operator generally reports such changes in advance in a monthly update Page 13 of 30

16 of the non-functional change calendar. The monthly update of the non-functional change calendar is an input for the service transition planning of the PMG. This type of change does not require the definition of a change management process, but are managed in accordance with the principles defined in the Manual of Operational Procedures for such changes. The T2S Operator also provides a monthly report of ex-post technical changes CSD AND CENTRAL BANK SPECIFIC BUSINESS CONFIGURATIONS Changes to CSD and Central Bank specific business configurations are modifications to the following types of parameters that allow CSDs and Central Banks to parameterise services for themselves and their participants and payment bank, respectively Restriction types; Conditional securities delivery rules; Report configurations; Message subscription Such changes are within the remit of the respective CSD or Central Bank and do not require a multilateral assessment within any of the governance groups. They are subject to specific rules and procedures, defined in the Manual of Operational Procedures. Page 14 of 30

17 RELEASE DEFINITION 3.1 DEFINITION Release Definition is a specific process to score and prioritise Change Requests and to subsequently define the scope of a new T2S release. The prioritisation and scoring includes pending problems. The principle is that known defects in a T2S software release become problems once the software release goes into production. Release Definition includes all types of possible releases. 155 Major releases 156 Minor releases 157 Fast-track releases 158 Hot-Fix releases PRINCIPLES The scope definition of major and minor releases is time-driven, based on a release calendar that defines the regularly scheduled implementation dates for releases The prioritisation of change requests and the scoping of a release include functional changes and non-functional changes affecting T2S functionality In the process of defining a release, the PMG assesses the feasibility of implementing the proposed release scope by the target implementation date prior to the submission to the T2S Steering Level. The detailed Service Transition Planning by the PMG takes place after the approval of the release scope and target implementation date by the T2S Steering Level The PMG is responsible for planning the milestones for the Release Definition process in order to ensure its alignment with the overall Service Transition Plan The Release Definition process will involve the PMG so that it can assess the feasibility to implement the proposed release scope by the target go-live date of the release The CRG involves the OMG in the prioritisation of Change Requests and the scoping of a T2S release. The OMG provides its assessment on the prioritisation of Change Requests and the scoping of a T2S release to the CRG. 175 Page 15 of 30

18 PROCESS DESCRIPTION 177 Page 16 of 30

19 Icon Label Description Hot-fix release required The OMG determines the need to implement a Hot-fix Release. Fast-track release required Minimum 18 month and maximum 24 months prior to major or minor release Provide hot-fix release scope proposal Prepare list of authorised Change Request Score and prioritise approved Change Requests Assess Change Request prioritisation Propose changes to prioritisation Review proposed prioritisation changes Propose alternative prioritisation Assess alternative prioritisation The CRG determines the need to implement a Fast-track Release. The definition of a new release begins 18 to 24 months prior to its planned implementation date. The OMG defines the scope of the hot-fix release and submits it to the T2S Steering Level for approval. The Eurosystem T2S Service Provider prepares a list of authorised Change Requests with the detailed information on each Change Request and submits it to the CRG. Based on the list of authorised Change Requests, the CRG examines the approved changes in detail and ranks them based on the agreed scoring mechanism for Change Requests. The CRG members should involve their organisation, specifically their operational managers, prior to this activity when preparing their prioritisation required by respective organisation. The OMG reviews the list of prioritised Change Requests in order to assess whether it adequately addresses its operational needs. The OMG either confirms its agreement to the prioritisation proposal from the CRG or proposes changes in prioritisation to the CRG. If the OMG identifies that its operational needs are not adequately reflected in the prioritisation of Change Requests, then it proposes changes in the prioritisation to the CRG. The OMG also provides the business justification to the CRG for their proposed change to prioritisation. The CRG reviews the proposed changes to prioritisation if the OMG provides a proposal to change the prioritisation. The CRG provides an alternative proposal to take into account the proposals of the OMG. The OMG reviews the revised list of prioritised Change Requests that the CRG provides in response to the OMG comments. The OMG either confirms its agreement to the prioritisation proposal from the CRG on the prioritisation of Change Requests or requests the CRG to document and escalate the disagreement to the T2S Steering Level. Page 17 of 30

20 Icon Label Description Document and escalate dispute on prioritisation Dispute escalation for prioritisation Provide release scope proposal Assess release scope proposal Assess implementation feasibility Submit release scope for approval If the CRG and OMG do not agree on the prioritisation of Change Requests, then the CRG documents the issues concerning the prioritisation and submits them to the T2S Steering Level for guidance or decision. The T2S Steering Level receives the issues for resolution concerning the proposal of the CRG on the prioritisation of Change Requests. Based on the agreed list of prioritised Change Requests, the CRG defines a release scope and submits it to the PMG to assess the feasibility to implement the proposed release by the target implementation date. The CRG members should involve their organisation, specifically their operational managers, prior to this activity when preparing their prioritisation required by respective organisation. Furthermore, the CRG will invite the OMG to a joint meeting to present and discuss the proposed release scope. The OMG reviews the proposed release scope in order to assess whether it adequately addresses its operational needs. It provides its assessment to the CRG. The PMG reviews the proposed release scope in order to assess the feasibility to implement the proposed release by the target implementation date. The PMG provides its assessment to the CRG. The CRG submits its proposal for the scope of a major release, minor release or fast-track release to the T2S Steering Level after defining a release scope proposal. Propose alternative release scope Document and escalate dispute on release scope Dispute escalation for release scope The CRG provides an alternative proposal to take into account the proposals of the OMG and/or issues concerning the implementation feasibility of the proposed release scope by the target implementation date from the PMG. If the OMG does not agree with the CRG on the proposed release scope or if the PMG does not deem the implementation of the proposed release scope feasible by the planned target implementation date after one review cycle, then the CRG documents the issues concerning the release scope and submits them to the T2S Steering Level for guidance and/or decision. The T2S Steering Level receives the issues for resolution concerning the proposal of the CRG on the release scope. Page 18 of 30

21 Icon Label Description Release scope proposal The T2S Steering Level receives the release scope proposal. Hot-fix release notification The T2S Steering Level receives a notification on the scope and justification for a hot-fix release. Page 19 of 30

22 MAJOR RELEASE CYCLE Maximum duration 2 months Maximum duration 2 months Maximum duration 2 months Maximum duration 2 months Agree Change Request prioritisation Agree release scope proposal Steering Steering Level Level release scope transition approval plan approval On-going service transition planning & monitoring Ser vice Tr ansition Plan Proposal On-going service transition planning & monitoring Eurosystem software development & testing T2S User Testing Duration 8 to 12 months Duration 4 to 6 months 179 Major release life cycle 18 to 24 months 180 Page 20 of 30

23 The target for developing and deploying a major release should normally not exceed 12 months. However, more time may be necessary, if the T2S Steering Level agrees to a release definition with an extensive scope. The Eurosystem may require more time for development and testing. CSDs, Central Banks, and their respective communities may require additional time to adapt and test their processing platforms. It remains the objective to deploy a new major and a new minor release of T2S each year. Consequently, the definition of releases and their subsequent development and testing phases will overlap. The release definition for a next release would occur when the current release may still be in its development or testing phase. Page 21 of 30

24 SERVICE TRANSITION PLANNING The purpose of Service Transition Planning is to develop and agree the overall comprehensive planning for new releases and all types of changes to enable all T2S Actors to develop and validate their internal project plans. A major focus of the service transition planning is to detail the implementation of major and minor releases after the T2S Steering Level approves the release scope. However, service transition planning is an on-going activity of the PMG that tracks all activities as well as risk and issues regarding the changes in the T2S Services. 197 Page 22 of 30

25 PROCESS DESCRIPTION 199 Page 23 of 30

26 200 Type Label Description Approved T2S release scope Service transition status report Release calendar update Test requirements for new release Monthly update of the non-functional change calendar Review monthly update of the nonfunctional change calendar Provide monthly update of the nonfunctional change calendar Assess service transition planning impacts Update service transition plan No service transition plan update required Issue(s) for guidance/resolution The receipt of the approved T2S release scope for a minor release, major release or fast-track release triggers an assessment of the service transition planning by the PMG. The service transition status report is a regular status update for on-going T2S service transition projects. It triggers an assessment of the service transition plan by the PMG. A general release calendar update from the OMG for forthcoming months or the next years triggers an assessment of the service transition plan by the PMG. The test requirements for a new release from the OMG triggers an assessment of the service transition plan by the PMG in order to determine if the new requirements affect the testing schedule and effort. The Eurosystem T2S Service Provider submits the monthly update of the non-functional change calendar to the OMG for review. The OMG reviews the monthly update of the non-functional change calendar to assess whether scheduled non-functional changes operationally impact CSDs and/or Central Banks and their respective communities. The OMG provides the monthly update of the non-functional change calendar to the PMG to assess any impacts on the current planning and to include the scheduled activities in the overall service transition planning. When the PMG receives inputs from the various governance bodies, it assesses their impacts on the current service transition planning. The PMG updates the service transition plan when it identifies the need to do so from its assessment of the inputs from the various governance bodies. The process terminates when the PMG does not identify the need to update the service transition plan from its assessment of the inputs from the various governance bodies. The T2S Steering Level receives the issues for guidance and/or resolution when the PMG cannot agree on an update of the service transition planning. Page 24 of 30

27 201 Type Label Description Service transition plan proposal The T2S Steering Level receives the service transition plan proposal from the PMG for approval when the PMG agrees on an update of the service transition planning. Page 25 of 30

28 SERVICE VALIDATION AND TESTING Service Validation and Testing (SVT) define the processes to ensure that T2S services are compliant with the T2S Scope Defining Set of Documents and that service operations are able to support the new service SVT is the responsibility of the PMG and describes the T2S service validation and testing activities before the deployment of a T2S release into the T2S production environment The PMG owns and maintains the User Testing Terms of Reference (UT ToR) and the user testing guide Changes to any terms in the UT ToR concerning the Pre-Production test environment are under the remit of the OMG The PMG may propose such changes to the terms of reference for the Pre-Production test environment to the OMG for the approval by the OMG. If the OMG does not agree to a PMG proposal for the Pre-Production test environment, but the PMG still deems the change to the terms necessary, then the PMG may raise the disagreement to the T2S Steering Level The User Testing Terms of Reference must define the standardised exhaustive list of entry criteria that must be validated through SVT to assess the production readiness of a release. The OMG defines the standardised exhaustive list of entry criteria The OMG is responsible for defining whether a subset of the standardised exhaustive list of entry criteria should apply to a specific software release. Page 26 of 30

29 DEPLOYMENT MANAGEMENT Deployment management organises the rollout of software releases and any associated operational service changes. The organisation of the process must take into account categorisation of the deployment and the responsibility of a T2S environment T2S SOFTWARE RELEASE OR CONFIGURABLE PARAMETER DEPLOYMENT A T2S release in the context of deployment management is a change or set of software and/or configurable parameter changes (see section ) that requires installation in a T2S test environment or on the T2S production environment. Such a deployment is subject to approval by the Operational Managers Group when it is to be undertaken on the Pre-Production or Production environments. The Project Managers Group is responsible for approving deployments to the Interoperability test environments after the Migration Period as well as the Migration and Community test environments during the Migration Period. However, the operational processes from the Manual of Operational Procedures (MOP) will apply for the management of the Community test environment. Each Central Bank and CSD must appoint either a test manager or an operational manager as interlocutor for the operational processes, executed for the Community test environment EMERGENCY CHANGE DEPLOYMENT An Emergency Change means a deployment of a change directly to the Production environment by the T2S Operator to resolve or avoid a major incident that results in a complete unavailability of all or some services for which no work-around is available. Crisis management triggers the deployment of an emergency change through the T2S Operator. Page 27 of 30

30 PROCESS DESCRIPTION 242 Page 28 of 30

31 Type Label Description Emergency Change deployment Hot-fix release Crisis management might trigger the deployment management process through the request to deploy an emergency change to resolve or avoid a major incident. The process continues with a software deployment by the T2S Operator if avoiding or remedying the major incident requires a software change. If the T2S Operator can avoid or remedy the major incident without a software change, then the process continues with the T2S Operator deploying any other type of change. The requirement to implement a hot-fix release triggers a release deployment. At the latest 3 business days before planned deployment Deploy other change Deploy software release Advise deployment readiness Assess readiness to deploy software release The deployment management process for scheduled software release deployments starts at the latest three business days prior to the scheduled deployment, as specified by the service transition plan or release plan for bug fix releases. The T2S Operator undertakes the necessary corrective measures to remedy or avoid a major incident in the Production environment. The T2S Operator deploys a T2S software release or configuration parameter change(s) on a test environment or on the Production environment based on the respective approval. The T2S Operator confirms the deployment to the PMG and to the OMG when the deployment pertains to the Community test environment, Pre-Production test environment and Production environment. The T2S Operator advises the Operational Managers Group (OMG) on its readiness to deploy software to either the Pre-Production test environment or the Production environment. The T2S Operator advises the Project Managers Group (PMG) on it readiness to deploy software to the Interoperability, Migration and Community test environments during the migration period and to the Interoperability test environment after the migration period. The OMG assesses the readiness to deploy the software release either to the Pre-Production test environment or the Production environment based on defined entry criteria for deploying the software release to the respective environment. The PMG assesses the readiness to deploy the software release either to the Interoperability, Migration and Community test environments during the migration period and to the Interoperability test environment after the migration period. Page 29 of 30

32 243 Type Label Description Confirm OMG readiness for software deployment Confirm PMG readiness for software deployment End of process The OMG formally confirms their agreement that the software release complies with the entry criteria for software deployment. If the readiness confirmation of the OMG pertains to the Pre-Production test environment, then the OMG confirms readiness to the T2S Operator. If the readiness confirmation of the OMG pertains to the Production environment, then the submission of the OMG readiness confirmation depends on whether the deployment requires an explicit approval by the Steering Level or the OMG has a delegated authority for the deployment. The T2S Steering Level still needs to define such delegated authority. The PMG formally confirms their agreement on their readiness to deploy a software release to the Interoperability, Migration and Community test environments during the migration period and to the Interoperability test environment after the migration period. The process terminates either when the T2S Operator has deployed the software release or required change, or after deployment is not approved. Page 30 of 30