USER REQUIREMENTS CHAPTER 20 IT SERVICE MANAGEMENT AND BUSINESS CONTINUITY T2S project Team Reference: T2S-07-0370 Date: 15 novembre 2007 Version: 1 Status: Final
TABLE OF CONTENTS 20 IT service management...3 20.1 Operating times... 3 20.2 T2S service desk... 4 20.3 Incident Management... 6 20.4 Problem Management... 7 20.5 Change management... 7 20.6 Release Management... 9 20.7 Configuration Management... 11 20.8 Service Level Management... 12 20.9 Capacity Management... 12 20.10 Availability Management... 12 20.11 Financial Management... 13 20.12 IT Service Continuity Management... 13 20.13 Documentation... 18 Version: 1 Page 2 of 18 Status: Final
20 IT service management To ensure that the agreed level of service will be provided to the customers, the T2S service provider shall ensure that best practices for IT service management are being followed. IT Service Management recommendations of ITIL will be fully applied and the IT Service Management Standards ISO 20000 shall be followed as much as possible. The Information Technology Infrastructure Library (ITIL) is a set of best practices for managing information technology (IT) infrastructure, development, and operations. ITIL is published in a series of books, each of which cover an IT-management topic. ITIL gives a detailed description of a number of IT Practices with comprehensive checklists, tasks, procedures which can be tailored to any IT Organisation. In essence, it can be considered as the world-wide de facto standard in IT service management. The following sections present a list of high level IT Service Management requirements as extracted from ITIL version 2 (IT Service Management organised around the IT service delivery and IT service support) and slightly amended where necessary. This will form the basis for the development of General Functional Specification in the next project phase. T2S will satisfy ITIL concepts WS6.217 To ensure service support and delivery according to agreed service levels, the service provider of T2S should use predefined processes based on the proven ITIL concept. 20.1 Operating times Daily Operations timelines are defined in detail in chapter 3 and are out of scope of this document. The T2S-System must be able to cope with these requirements. 20.1.1 Online Operating Window Access to and update of data in T2S in on-line mode is a key element of the user requirements. This access covers every kind of data, be they static or settlement related ones. Version: 1 Page 3 of 18 Status: Final
T2S calendar WS6.203 A calendar will be established for T2S different from Target2 calendar. The T2S calendar will be in line will the Central Bank calendar of T2S settlement currencies. Night downtime WS6.205 T2S is allowed to maintenance window downtime of maximum of 2 hours per 24h at night (03:00 to 05:00 CET). 20.2 T2S service desk A Service Desk will be available at the T2S service provider to promptly respond to any technical issue raised by the T2S stakeholders. T2S Service Desk for technical incidents WS6.218 A T2S Service Desk with skilled staff must be established as a single point of contact for the T2S users in case of technical incidents. 20.2.1 Service Desk operating time T2S Service Desk operating on a 24h basis WS6.206 The T2S Service Desk will be accessible on 24 hours basis during operating days. Version: 1 Page 4 of 18 Status: Final
The service level will be different according to the time in the day. 20.2.2 Technical inquiry response time Based on the level of complexity of the technical enquiry the T2S Service Desk should operate according to a published response time matrix, and measure its performance against this matrix. Call recording by the T2S Service desk WS6.208 The T2S Service Desk will record all enquiries and provide confirmation to CSDs or directly connected instructing parties when calls are received. Trouble management system WS6.219 Service Desk shall be supported by a Trouble Management System (TMS). In addition, all activities of the T2S service provider related to IT Service management processes should be supported by the Trouble Management System, covering the workflow and serve as an information base providing e.g. status of an incident/problem, involved actors as well as details about reason and solution. On line access to Trouble management system for CSDs WS6.220 CSDs should have online access to the tool. Direct access for directly connected instructing parties to the Trouble Management System (TMS) is currently not required. The communication between service desk and customer should be based on telephone, fax and email. 20.2.3 Service Desk reporting Regular Management Information will need to be provided to the CSDs covering the performance of the T2S Service Desk in comparison to the agreed service level. Version: 1 Page 5 of 18 Status: Final
On line access to Trouble Management System for CSDs WS6.209 A Service Desk Management information report including types of inquiries, number of inquiries per month from directly connected instructing parties, number of unresolved inquiries and time elapse will be provided to CSDs and directly connected instructing parties. Monthly Service Desk Management Information reporting WS6.210 Service Desk Management information report will be provided on a monthly basis. Service Information reporting WS6.194 Reports - including key performance indicators - shall be made available to the governance structure and to the users for a Service Level Management of the T2S application. 20.3 Incident Management By definition, an incident is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption, or a reduction in quality, of that service. Incident Management procedure should be in place to restore normal service operation WS6.221 Incident Management service should be in place. The primary goal of Incident Management is to restore normal service operation as quickly as possible and minimise the adverse impact on business operations, thus ensuring that the best possible levels of service (quality and availability) are maintained as defined by the SLA. Version: 1 Page 6 of 18 Status: Final
Incident Management is to inform of errors as soon as possible WS6.222 Incident Management should inform / warn all relevant parties of errors or malfunctions at the earliest possible time. 20.4 Problem Management Problem Management should be in place to minimise the adverse impact of Incidents and Problems WS6.2221 Problem Management service should be in place. The goal of Problem Management is to minimise the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, and to prevent recurrence of Incidents related to these errors. In order to achieve this goal, Problem Management seeks to get to the root cause of Incidents and then initiate actions to improve or correct the situation. The Problem Management process has both reactive and proactive aspects. The reactive aspect is concerned with solving Problems in response to one or more Incidents. Proactive Problem Management is concerned with identifying and solving Problems and Known Errors before Incidents occur in the first place. 20.5 Change management The goal of the Change Management process is to ensure that standardised methods and procedures are used for efficient and prompt handling of all Changes, in order to minimise the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organisation. Any changes shall be prepared and implemented under the control of a change management process. Change management procedures should be defined WS6.252 Change management procedures should be defined and implemented in order to efficiently track and manage the changes and to mitigate the risks associated with these changes. Version: 1 Page 7 of 18 Status: Final
Change governance structure WS6.249 A change governance structure should be in place to collect, assess and prioritise requirements to be considered for the coming release. It should as well decide on the release contents. Change governance policy WS6.248 Change governance policy should be defined under the application governance body responsibility. Changes should be grouped WS6.250 Multiple changes to T2S should be included in one single release if possible. 20.5.1 Emergency changes In certain cases an incident may demand for an urgent change of the application or system software in the production environment. Such a change clearly aims in ensuring a quick restoration of T2S services and not in changing the functionality. Due to its urgency, such a change cannot be processed by following the complete process for changes. Therefore such changes shall fall under a special category called emergency changes. However, even emergency changes shall be controlled by a lightweight change management procedure. Changes are always under the control of the change manager WS6.257 Emergency changes shall be immediately reported to and approved by the Change Manager. Version: 1 Page 8 of 18 Status: Final
Emergency procedures for short term access to production environment WS6.258 Procedures will be in place to allow short term access to production data and production code to dedicated personal. Auditing and monitoring procedures on emergency changes WS6.259 Procedures will be in place to that automatically monitor and audit the activities performed on the system during the emergency phases. 20.5.2 Bug fixing response time An identified software bug may either be of non-critical nature (and therefore can be scheduled for a regular systems maintenance activity) or of critical nature (and therefore requires an immediate correction). Immediate reaction to critical bug fixing is requested WS6.245 Reaction to critical bug fixing should be immediate 20.6 Release Management The focus of Release Management is the protection of the production environment and its services through the use of formal procedures and checks. New releases will be prepared and implemented under the control of a release management process. 20.6.1 Releases planning and communication New releases will cover major changes in relation to the functionality of the application and/or infrastructure changes. Version: 1 Page 9 of 18 Status: Final
Release planning process WS6.253 There must be established a release planning process (except for emergency changes and minor changes without any functional impact) Software development staging process WS6.251 All releases should follow the staging concept, i.e. installation in production environment is only allowed after testing it in the former stages, especially on customer test environment. Release communication 18 months in advance WS6.255 Major releases should be announced 18 months in advance. Detailed documentation in the release contents should be available at the same time. Detailed contents of release communicated 9 months in advance WS6.256 Final announcement and detailed contents of major changes should be given 9 months in advance. 20.6.2 Software life-cycle planning The T2S application will be an evolving application increasing and improving services by following a defined Software Development Life Cycle. During the application lifecycle changes and upgrades will be performed. On a case by case basis it will need to be determined whether such changes will require the directly connected instructing parties to perform an Version: 1 Page 10 of 18 Status: Final
end-to-end test. These cases need to be communicated to the directly connected instructing parties as early as possible to allow for adequate planning and to establish the correct test cases and procedures. All other changes which may have an impact on directly connected instructing parties will also need to be announced at the earliest stage possible. An exception to this will be any form of emergency updates due to a problem in the production environment. New requirements collection and prioritisation WS6.2561 There must be defined planning process for the requirements gathering and analysis concerning functional changes leading to a new software release. Software development life cycle procedure WS6.2562 There must be defined Software Development Life Cycle for the planning and development of a new software release. 20.7 Configuration Management T2S will ensure a continuous management of its configuration WS6.2470 The goals of Configuration Management are to: account for all the IT assets and configurations within the organisation and its services, provide accurate information on configurations and their documentation to support all the other Service Management processes, provide a sound basis for Incident Management, Problem Management, Change Management and Release Management, verify the configuration records against the infrastructure and correct any exceptions. Version: 1 Page 11 of 18 Status: Final
20.8 Service Level Management The goal of the Service Level Management process is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or cost justification.. All services provided by T2S should be managed through Service Level Agreements WS6.2471 All services provided by T2S should be managed through Service Level Agreements (SLAs) by a defined Service Level Management process. 20.9 Capacity Management The goal of the Capacity Management process is to ensure that cost justifiable IT Capacity always exists and that it is matched to the current and future identified needs of the business. Capacity Management process in place WS6.2472 The required IT capacity should be provided by following a defined Capacity Management process. Cf chapter 17 Volumes and performance 20.10 Availability Management The goal of the Availability Management process is to optimise the capability of the IT Infrastructure, services and supporting organisation to deliver a Cost effective and sustained level of Availability that enables the business to satisfy its business objectives. Version: 1 Page 12 of 18 Status: Final
Availability Management process in place WS6.2473 A cost effective and sustained level of availability that enables the business to satisfy its business objectives should be ensured via a defined Availability Management process. 20.11 Financial Management The goal of the Financial Management process is to provide cost-effective stewardship of the IT assets and resources used in providing IT Services for T2S. Financial Management process in place WS6.2474 To assist decisions on IT investment by providing detailed business cases for changes to the IT Services provided by T2S, a Financial Management process should be defined and implemented. 20.12 IT Service Continuity Management "The goal for ITSCM is to support the overall Business Continuity Management process by ensuring that the required IT technical and services facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk can be recovered within required, and agreed, business timescales." IT Service Continuity Management process in place WS6.2475 A ITSCM process should be put in place to ensure that the T2S IT services can be recovered within the require and agreed timescales. 20.12.1Business Continuity Model Objective : To have procedures in place to trigger and complement the T2S system high resilience. Version: 1 Page 13 of 18 Status: Final
Rotation procedure and process between the 2 regions WS6.4 There must be in place a rotation procedure and process between the 2 regions that describes in detail organisational and procedural arrangements. Switch procedure between the 2 sites inside region WS6.5 There must be in place a switch procedure between the 2 sites inside region that describes in detail organisational and procedural arrangements for testing. Each of the T2S site must satisfy the agreed service level. WS6.235 Each of the four sites of T2S must be able to fulfil the agreed service level. Skilled staff must have access to the system in any circumstances WS6.236 In addition to the resilient architecture, skilled staff must be available and their access to the system (remote and/or local) must be possible under any circumstances without decrease of agreed service level. Business continuity model shall satisfy to the widest range of possible system failures WS6.237 The business continuity model foreseen for the T2S should be able to cope with trivial and serious failure as well as with site and regional area disaster scenarios. Version: 1 Page 14 of 18 Status: Final
The infrastructure and staff of the two regions should be independent and not affected by the same regional security events. WS6.238 Out-of-region sites should not be dependent on the same labour pool or infrastructure components used by the primary region and should not be affected by a wide-scale evacuation or the inaccessibility of the region's population. Disaster recovery period is under 2 hours WS6.244 The maximum disaster recovery period of T2S should be under 2 hours from the moment when the decision is taken by the Crisis managers. This time can be used to allow the T2S parties to control, prepare and reconcile their own environments towards the re-establishment of a functioning T2S environment. 20.12.2 Crisis Management Crisis Management is an important element of Business Continuity, and as such a Governance issue. It is important to note that, differently from the incident management process, the crisis management should cover an interruption on the supply of the service to be provided. Objective: To have a structure and procedures in place to manage incidents and events that exceeds a preagreed severity threshold. Crisis management process and crisis management structure will be defined by the T2S Governance structure WS6.2241 Crisis management process and crisis management structure will be defined by the T2S Governance structure. Version: 1 Page 15 of 18 Status: Final
Crisis management process to guarantee coordination of activities in crisis situations WS6.224 Crisis management process is to guarantee effective coordination of activities within all the involved organisations in a crisis situation. Crisis management process to guarantee appropriate communication in crisis situations WS6.225 Crisis management process is to guarantee appropriate communication i.e. an early warning and clear instructions to all concerned if a crisis occurs. Resilient crisis communication tools to guarantee appropriate communication in crisis situations WS6.223 To ensure efficient communication in a crisis situation, resilient communication infrastructure spanned over the two regions shall be available. Crisis management process to guarantee continued assessment of crisis consequences WS6.226 Crisis management process is to guarantee a continued assessment of actual and potential consequences of the crisis. Crisis management process to guarantee business continuity during and after the crisis WS6.227 Crisis Management process is to guarantee a continuity of business operations during and immediately after the crisis. Version: 1 Page 16 of 18 Status: Final
Crisis management process to guarantee business continuity during and after the crisis WS6.228 Crisis Management process is to guarantee a clear structure about escalation and decision making process. Crisis management process to guarantee information to the relevant T2S parties WS6.229 Crisis Management process is to guarantee clear communication rules including information of customer. 20.12.3 Additional contingency measures Considering the requested resilience of T2S and the Business Continuity measures to be implemented, it could happen that the T2S service is not available for a limited time (e.g. severe software bug). Objective To limit possibly impacts of a T2S interruption on other systems (e.g. Target2) and financial markets. Business contingency procedures will be defined under the responsibility of the Governance structure. WS6.240 Business contingency procedures will be defined in under the responsibility of the Governance structure in lines with best practices. Additional contingency tools is not required WS6.2401 Considering that there is no time critical settlement requirement T2S shall not implement any additional contingency tool. Version: 1 Page 17 of 18 Status: Final
20.13 Documentation T2S application shall be documented WS6.230 A comprehensive set of T2S documentation shall be prepared covering inter alia following subjects: Architecture Storage Network documentation Service Desk Documentation Operational Procedures Training System acceptance Planning Service Level Information Testing etc Documentation will be distributed under T2S governance structure control WS6.2301 T2S Governance structure will establish the distribution list for documentation. Functional specifications will be communicated to the CSDs WS6.231 T2S documentation on Functional Specification needs to be available to CSDs. Version: 1 Page 18 of 18 Status: Final