Service Design - Building Structural Service Integrity PDF

28/8/07 14:01 Page 45 | Service Design – building structural service integrity equirements The business/customers Service Strategy Policies Resource and Constraints Objectives from Requirements Strategies Service Design SDPs Standards Architectures Solution Designs ing on from Service Strategy, Serv...

28/8/07 14:01 Page 45 | Service Design – building structural service integrity equirements The business/customers Service Strategy Policies Resource and Constraints Objectives from Requirements Strategies Service Design SDPs Standards Architectures Solution Designs ing on from Service Strategy, Service Design is the age in the ITIL Service Lifecycle. While the lifecycle entirely linear, we will portray each stage from a progression. The key concepts of Service Design e around the five design aspects and the design of s, service processes and service capabilities to meet ss demand. The primary topics that will be sed here are not the entire spectrum of Service , but the main elements that illustrate the ves of this stage in the Service Lifecycle: pects of Service Design vice Catalogue Management vice Requirements The Service Design publication provides a greater level of detail on these and also on application and infrastructure design principles. The main purpose of the Service Design stage of the lifecycle is the design of new or changed service for introduction into the live environment. It is important that a holistic approach to all aspects of design is adopted and that when changing or amending any of the individual elements of design all other aspects are considered. Thus when designing and developing a new application, this shouldn’t be done in isolation, but should also consider the impact on the overall service, the management systems and tools (e.g. the Service Portfolio and 45 28/8/07 14:01 Page 46 Service Design – building structural service integrity anagement and operational requirements are sed as a fundamental part of the design and are not as an afterthought. ain aim of Service Design is the design of new or ed services. The requirements for these new services racted from the Service Portfolio and each ement is analysed, documented and agreed and a n design is produced that is then compared with ategies and constraints from Service Strategy to that it conforms to corporate and IT policies. BUSINESS VALUE ood Service Design it will be possible to deliver , cost-effective services and to ensure that the ss requirements are being met. lowing benefits are as a result of good Service practice: duced total cost of ownership (TCO): cost of nership can only be minimized if all aspects of vices, processes and technology are designed perly and implemented against the design proved quality of service: both service and erational quality will be enhanced proved consistency of service: as services are signed within the corporate strategy, architectures d constraints sier implementation of new or changed services: there is integrated and full Service Design, and the duction of comprehensives Service Design Packages proved service alignment: involvement from the nception of the service ensuring that new or anged services match business needs, with services signed to meet Service Level Requirements  Improved IT governance: assists with the implementation and communication of a set of controls for effective governance of IT  More effective service management and IT processes: processes will be designed with optimal quality and cost-effectiveness  Improved information and decision-making: more comprehensive and effective measurements and metrics will enable better decision-making and continual improvement of service management practices in the design stage of the Service Lifecycle. 5.2 FIVE ASPECTS OF SERVICE DESIGN There are five aspects of design that need to be considered: 1 The design of the services, including all of the functional requirements, resources and capabilities needed and agreed 2 The design of service management systems and tools, especially the Service Portfolio, for the management and control of services through their lifecycle 3 The design of the technology architectures and management systems required to provide the services 4 The design of the processes needed to design, transition, operate and improve the services, the architectures and the processes themselves 5 The design of the measurement methods and metrics of the services, the architectures and their constituent components and the processes. A results-driven approach should be adopted for each of the above five aspects. In each, the desired business outcomes and planned results should be defined so that 28/8/07 14:01 Page 47 Service Design – building structural service integrity | able consistency and continual improvement hout the organization. There are no situations IT service provision with either internal or external providers where there are no processes in the e Design area. All IT Service Provider organizations y have some elements of their approach to these pects in place, no matter how basic. Before starting implementation of the improvement of activities ocesses a review should be conducted of what nts are in place and working successfully. Many e Provider organizations already have mature ses in place for designing IT services and solutions. IDENTIFYING SERVICE REQUIREMENTS e Design must consider all elements of the service by a holistic approach to the design of a new service. pproach should consider the service and its uent components and their inter-relationships, ng that the services delivered meet the functionality uality of service expected by the business in all areas: e scalability of the service to meet future uirements, in support of the long-term business ectives e business processes and business units supported the service e IT service and the agreed business functionality d requirements e service itself and its Service Level Requirement R) or Service Level Agreement (SLA) e technology components used to deploy and iver the service, including the infrastructure, the vironment, the data and the applications e internally supported services and components and  The externally supported services and components and their associated Underpinning Contracts (UCs), which will often have their own related agreements and/or schedules  The performance measurements and metrics required  The legislated or required security levels. The relationships and dependencies between these elements are illustrated in Figure 5.1. The design needs to be holistic, and the main problem today is that organizations often only focus on the functional requirements. A design or architecture by very definition needs to consider all aspects. It is not a smaller organization that combines these aspects, it is a sensible one. The design process activities are:  Requirements collection, analysis and engineering to       ensure that business requirements are clearly documented and agreed Design of appropriate services, technology, processes, information and process measurements to meet business requirements Review and revision of all processes and documents involved in Service Design, including designs, plans, architectures and policies Liaison with all other design and planning activities and roles, e.g. solution design Production and maintenance of IT policies and design documents, including designs, plans, architectures and policies Revision of all design documents and planning for the deployment and implementation of IT strategies using roadmaps, programmes and project plans Risk assessment and management of all design 47 28/8/07 14:01 Page 48 Service Design – building structural service integrity 5.1 Design dependencies Business service a Business service b Business service c 3 Business process SLAs 2 1 Service A Service Strategy The business 6 4 C D B 9 5 Business process Business process F E G 8 7 IT Services IT Service Transition Service Operation Service Knowledge Management System Service Portfolio Service Design Services Service Catalogue Processes Service Improvement SLM SCM Supplier Security Availability IT Service Continuity Capacity Architectures Measurement methods Support teams Suppliers SERVICE DESIGN MODELS adopting a design model for a major new service, a of the current capability and provisions with t to all aspects regarding the delivery of IT services be conducted. This review should consider all s of the new service including:  Scope and capability of external suppliers  Maturity of the organizations currently involved and their processes  Culture of the organizations involved  IT infrastructure, applications, data, services and other components involved  Degree of corporate and IT governance and the level 28/8/07 14:01 Page 49 Service Design – building structural service integrity | DELIVERY MODEL OPTIONS gh the readiness assessment determines the gap en the current and desired capabilities, an IT zation should not necessarily try to bridge that gap lf. There are many different delivery strategies that used. Each one has its own set of advantages and 49 disadvantages, but all require some level of adaptation and customization for the situation at hand. Table 5.1 lists the main categories of sourcing strategies with a short abstract for each. Delivery practices tend to fall into one of these categories or some variant of them. 5.1 Delivery model options y strategy Description ing This approach relies on utilizing internal organizational resources in the design, development, transition, maintenance, operation and/or support of a new, changed or revised services or data centre operations rcing This approach utilizes the resources of an external organization or organizations in a formal arrangement to provide a well-defined portion of a service’s design, development, maintenance, operations and/or support. This includes the consumption of services from Application Service Providers (ASPs) described below rcing Often a combination of insourcing and outsourcing, using a number of outsourcing organizations working together to co-source key elements within the lifecycle. This generally will involve using a number of external organizations working together to design, develop, transition, maintain, operate and/or support a portion of a service ship or multi-sourcing Formal arrangements between two or more organizations to work together to design, develop, transition, maintain, operate and/or support IT service(s). The focus here tends to be on strategic partnerships that leverage critical expertise or market opportunities s process outsourcing (BPO) The increasing trend of relocating entire business functions using formal arrangements between organizations where one organization provides and manages the other organization’s entire business process(es) or function(s) in a low-cost location. Common examples are accounting, payroll and call-centre operations tion service provision (ASP) Involves formal arrangements with an ASP organization that will provide shared computer-based services to customer organizations over a network. Applications offered in this way are also sometimes referred to as ‘on-demand software/applications’. Through ASPs the complexities and costs of such shared software can be reduced and provided to organizations that could otherwise not justify the investment 28/8/07 14:01 Page 50 Service Design – building structural service integrity SERVICE CATALOGUE MANAGEMENT he years, organizations’ IT infrastructures have and developed, and there may not always be a icture of all the services currently being provided or stomers of each service. In order to establish an te picture, it is recommended that an IT Service io containing a Service Catalogue is produced and ined to provide a central accurate set of ation on all services and to develop a serviced culture. preceding chapter, we learned about the Service io and its constituent elements. Among them is the e Catalogue. bjective of Service Catalogue Management is to e the information contained within the Service gue and to ensure that it is accurate and reflects the t details, status, interfaces and dependencies of all s that are being run or being prepared to run in the vironment.  Interfaces and dependencies between all services and supporting services within the Service Catalogue and the CMS  Interfaces and dependencies between all services, and supporting components and Configuration Items (CIs) within the Service Catalogue and the CMS. When initially completed, the Service Catalogue may consist of a matrix, table or spreadsheet. Many organizations integrate and maintain their Portfolio and Catalogue as part of their CMS. By defining each service as a CI and, where appropriate, relating these to form a service hierarchy, the organization is able to relate events such as Incidents and RFCs to the services affected, thus providing the basis for service monitoring and reporting using an integrated tool (e.g. ‘list or give the number of Incidents affecting this particular service’). It is therefore essential that changes within the Service Portfolio and Service Catalogue are subject to the Change Management process. rvice Catalogue provides business value as a central of information on the IT services delivered by the provider organization. This ensures that all areas of siness can view an accurate, consistent picture of services, their details and their status. It contains a mer-facing view of the IT services in use, how they ended to be used, the business processes they , and the levels and quality of service the customer pect of each service. The Service Catalogue can also be used for other Service Management purposes (e.g. for performing a Business Impact Analysis (BIA) as part of IT Service Continuity Planning, or as a starting place for redistributing workloads, as part of Capacity Management). The cost and effort of producing and maintaining the catalogue, with its relationships to the underpinning technology components, is therefore easily justifiable. If done in conjunction with prioritization of the BIA, then it is possible to ensure that the most important services are covered first. e Catalogue Management activities should include: The Service Catalogue has two aspects: inition of the service duction and maintenance of an accurate Service alogue  Business Service Catalogue: containing details of all of the IT services delivered to the customer, together with relationships to the business units and the 28/8/07 14:01 Page 51 Service Design – building structural service integrity | chnical Service Catalogue: containing details of all IT services delivered to the customer, together with ationships to the supporting services, shared vices, components and CIs necessary to support the vision of the service to the business. This should derpin the Business Service Catalogue and not form t of the customer view. y activities within the Service Catalogue ement process should include: eeing and documenting a service definition with all evant parties erfacing with Service Portfolio Management to agree contents of the Service Portfolio and Service alogue ducing and maintaining a Service Catalogue and its ntents, in conjunction with the Service Portfolio  Interfacing with the business and IT Service Continuity Management on the dependencies of business units and their business processes with the supporting IT services, contained within the Business Service Catalogue  Interfacing with support teams, Suppliers and Configuration Management on interfaces and dependencies between IT services and the supporting services, components and CIs contained within the Technical Service Catalogue  Interfacing with Business Relationship Management and Service Level Management to ensure that the information is aligned to the business and business process. The Service Catalogue forms an integral part of the overall Service Portfolio and is a key, customer-facing view of the services on offer. It establishes the expectations of value and potential that customers can expect from their IT 5.2 Service Catalogue elements The Service Catalogue Business Process 1 Business Process 2 Business Process 3 Business Service Catalogue Service A Service B Service C Technical Service Catalogue Service D Service E 51 28/8/07 14:01 Page 52 Service Design – building structural service integrity provider(s). The Service Design core publication ns detailed guidance on the construction and ement of a Service Catalogue. SERVICE LEVEL MANAGEMENT e Level Management (SLM) negotiates, agrees and ments appropriate IT service targets with entatives of the business, and then monitors and ces reports on the Service Provider’s ability to deliver reed level of service. SLM is a vital process for every ice Provider organization in that it is responsible for ng and documenting service level targets and sibilities within Service Level Agreements (SLAs) and e Level Requirements (SLRs), for every activity within hese targets are appropriate and accurately reflect quirements of the business, then the service ed by the Service Providers will align with business ements and meet the expectations of the customers ers in terms of service quality. If the targets are not d with business needs, then Service Provider es and service levels will not be aligned with ss expectations and problems will develop. A is effectively a level of assurance or warranty with to the level of service quality delivered by the e Provider for each of the services delivered to the ss. The success of SLM is very dependent on the of the Service Portfolio and the Service Catalogue eir contents, because they provide the necessary ation on the services to be managed within the SLM s. bjectives of SLM are to: ine, document, agree, monitor, measure, report and iew the level of IT services provided  Monitor and improve customer satisfaction with the quality of service delivered  Ensure that IT and the customers have a clear and unambiguous expectation of the level of service to be delivered  Ensure that proactive measures to improve the levels of service delivered are implemented wherever it is cost-justifiable to do so. The key activities within the SLM process should include:  Determine, negotiate, document and agree           requirements for new or changed services in SLRs, and manage and review them through the Service Lifecycle into SLAs for operational services Monitor and measure service performance achievements of all operational services against targets within SLAs Collate, measure and improve customer satisfaction Produce service reports Conduct service review and instigate improvements within an overall Service Improvement Programme/Plan (SIP) Review and revise SLAs, service scope OLAs, contracts and any other underpinning agreements Develop and document contacts and relationships with the business, customers and stakeholders Develop, maintain and operate procedures for logging, actioning and resolving all complaints, and for logging and distributing compliments Log and manage all complaints and compliments Provide the appropriate management information to aid performance management and demonstrate service achievement Make available and maintain up-to-date SLM 28/8/07 14:01 Page 53 Service Design – building structural service integrity | 5.3 The Service Level Management process Business Unit A The business 3 Business Process s) elop contacts lationships, rd & manage plaints & pliments ort teams 6 2 5 Business Process 1 4 SLM SLA(s) Determine, document & agree requirements for new services SLRs & make SLAs As Business Unit B Service A B C Monitor service performance against SLA & produce service reports D F G SLA(s) Conduct service review & instigate improvements within an overall SIP Collate, measure & improve customer satisfaction Document standards & templates Assist with the Service Catalogue & maintain document templates Service Catalogue Service Reports Review & revise SLAs, service scope & underpinning agreements Supplier Management Contracts Suppliers 53 28/8/07 14:01 Page 54 Service Design – building structural service integrity are a number of potential options, including the ng. rvice-based SLA s is where an SLA covers one service for all the tomers of that service – for example, an SLA may established for an organization’s e-mail service, vering all of the customers of that service. Where mmon levels of service are provided across all areas the business, e.g. e-mail or telephony, the serviceed SLA can be an efficient approach to use. ltiple classes of service, e.g. gold, silver and bronze, n also be used to increase the effectiveness of vice-based SLAs. stomer-based SLA s is an agreement with an individual customer up covering all the services they use. For example, eements may be reached with an organization’s ance department covering, say, the finance system, accounting system, the payroll system, the billing tem, the procurement system, and any other IT tems that they use. Customers often prefer such an eement, as all of their requirements are covered in a gle document. Only one signatory is normally uired, which simplifies this issue. ulti-level SLA me organizations have chosen to adopt a multi-level A structure. For example, a three-layer structure as ows: Corporate level: covering all the generic SLM issues appropriate to every customer throughout the organization. These issues are likely to be less volatile, so updates are less frequently required Customer level: covering all SLM issues relevant to  Service level: covering all SLM issues relevant to the specific service, in relation to a specific customer group (one for each service covered by the SLA). The wording of SLAs should be clear and concise and leave no room for ambiguity. There is normally no need for agreements to be couched in legal terminology, and plain language aids a common understanding. It is often helpful to have an independent person, who has not been involved with the drafting, to do a final read-through. This often throws up potential ambiguities and difficulties that can then be addressed and clarified. For this reason alone, it is recommended that all SLAs contain a glossary, defining any terms and providing clarity for any areas of ambiguity. 5.7.1 Service Level Requirements This is one of the earliest activities within the Service Design stage of the Service Lifecycle. Once the Service Catalogue has been produced and the SLA structure has been agreed, a first SLR must be drafted. It is advisable to involve customers from the outset, but rather than going along with a blank sheet to start with, it may be better to produce a first outline draft of the performance targets and the management and operational requirements, as a starting point for more detailed and in-depth discussion. Be careful, though, not to go too far and appear to be presenting the customer with a fait accompli. It cannot be overstressed how difficult this activity of determining the initial targets for inclusion with an SLR or SLA is. All of the other processes need to be consulted for their opinion on what are realistic targets that can be achieved, such as Incident Management on incident targets. The Capacity and Availability Management processes will be of particular value in determining 28/8/07 14:01 Page 55 Service Design – building structural service integrity | Monitoring service level performance g should be included in an SLA unless it can be vely monitored and measured at a commonly point. The importance of this cannot be essed, as inclusion of items that cannot be vely monitored almost always results in disputes and al loss of faith in the SLM process. A lot of zations have discovered this the hard way and as a have absorbed heavy costs, both in a financial sense as in terms of negative impacts on their credibility. sential that monitoring matches the customer’s true tion of the service. Unfortunately this is often very t to achieve. For example, monitoring of individual onents, such as the network or server, does not ntee that the service will be available so far as the mer is concerned. Where multiple services are ed to a single workstation, it is probably more ve to record only downtime against the service the as trying to access at the time (though this needs agreed with the customers). are a number of important soft issues that cannot nitored by mechanistic or procedural means, such omers’ overall feelings (these need not necessarily the hard monitoring). For example, even when have been a number of reported service failures, mers may still feel positive about things, because may feel satisfied that appropriate actions are being to improve things. Of course, the opposite may and customers may feel dissatisfied with some (e.g. the manner of some staff on the Service Desk) few or no SLA targets have been broken. he outset, it is wise to try to manage customers’ ations. This means setting proper expectations and priate targets in the first place, and putting a 55 SLAs are just documents, and in themselves do not materially alter the quality of service being provided (though they may affect behaviour and help engender an appropriate service culture, which can have an immediate beneficial effect, and make longer-term improvements possible). A degree of patience is therefore needed and should be built into expectations. 5.7.3 Key performance indicators Key performance indicators (KPIs) and metrics can be used to judge the efficiency and effectiveness of the SLM activities and the progress of the SIP. These metrics should be developed from the service, customer and business perspective and should cover both subjective and objective measurements such as the following.  Objective:     Number or percentage of service targets being met Number and severity of service breaches Number of services with up-to-date SLAs Number of services with timely reports and active service reviews  Subjective:  Improvements in customer satisfaction. Practising SLM can achieve a high trust factor between the business and the service provider. It establishes a pattern of quality and service management practices, demonstrated through reporting and interaction with the customer over time, that can instil a sense of trust and expectation from the business, which in turn engenders loyalty. No service provider should underestimate how important SLM is. The Service Design core publication offers detailed guidance in SLM. 28/8/07 14:01 Page 56 Service Design – building structural service integrity stage. It is for this reason that the Capacity ement Process is included in this book. Capacity ement is supported initially in Service Strategy the decisions and analysis of business requirements stomer outcomes influencing the development of ns of business activity (PBA), levels of service (LOS) rvice level packages (SLPs) are identified. This es the predictive and ongoing capacity indicators d to align capacity to demand. An example of a onent-based SLP is illustrated in Figure 5.4. ty Management ensures that the capacity and mance of the IT services and systems match the ng agreed demands of the business in the most cost-effective and timely manner. Capacity Management is essentially a balancing act:  Balancing costs against resources needed: the need to ensure that processing Capacity that is purchased is not only cost-justifiable in terms of business need, but also makes the most efficient use of those resources  Balancing supply against demand: the need to ensure that the available supply of IT processing power matches the demands made on it by the business, both now and in the future; it may also be necessary to manage or influence the demand for a particular resource. 5.4 Component-based Service Level Package Onsite support Hardware security token Notebook PC Data encryption service Standard E-mail ‘24x7 x365’ 3G Wireless Phone Wireless Voice & Data Service Components Worldwide Mobility Desktop Phone Dial-tone Office Fax 28/8/07 14:01 Page 57 bjectives of Capacity Management are to: duce and maintain an appropriate and up-to-date pacity Plan, which reflects the current and future eds of the business vide advice and guidance to all other areas of the siness and IT on all capacity- and performanceated issues ure that service performance achievements meet or eed all of their agreed performance targets, by naging the performance and capacity of both vices and resources ist with the diagnosis and resolution of formance- and capacity-related incidents and blems ess the impact of all changes on the Capacity Plan, d the performance and capacity of all services and ources ure that proactive measures to improve the formance of services are implemented wherever it ost-justifiable to do so. pacity Management process should include: nitoring patterns of business activity and service el plans through performance, utilization and oughput of IT services and the supporting astructure, environmental, data and applications mponents and the production of regular and ad hoc orts on service and component capacity and formance dertaking tuning activities to make the most cient use of existing IT resources derstanding the agreed current and future demands ng made by the customer for IT resources and ducing forecasts for future requirements Service Design – building structural service integrity | 57  Producing a Capacity Plan that enables the Service Provider to continue to provide services of the quality defined in SLAs and that covers a sufficient planning timeframe to meet future service levels required as defined in the Service Portfolio and SLRs  Assistance with the identification and resolution of any Incidents and Problems associated with service or component performance  The proactive improvement of service or component performance wherever it is cost-justifiable and meets the needs of the business. The elements of Capacity Management are illustrated in Figure 5.5. 5.8.1 Business Capacity Management This sub-process translates business needs and plans into requirements for service and IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned and implemented in a timely fashion. This can be achieved by using the existing data on the current resource utilization by the various services and resources to trend, forecast, model or predict future requirements. These future requirements come from the Service Strategy and Service Portfolio detailing new processes and service requirements, changes, improvements and also the growth in the already existing services. 5.8.2 Service Capacity Management The focus of this sub-process is the management, control and prediction of the end-to-end performance and capacity of the live, operational IT services usage and workloads. It ensures that the performance of all services, as detailed in service targets within SLAs and SLRs, is monitored and measured, and that the collected data is 28/8/07 14:01 Page 58 Service Design – building structural service integrity edge of all the areas of technology used in the y of end-to-end service, and often involves seeking from the specialists involved in Resource Capacity ement. Wherever possible, automated thresholds be used to manage all operational services to that situations where service targets are breached atened are rapidly identified and cost-effective s to reduce or avoid their potential impact mented.  Component Capacity Management cus in this sub-process is the management, control ediction of the performance, utilization and capacity vidual IT technology components. It ensures that all onents within the IT infrastructure that have finite ce are monitored and measured, and that the ed data is recorded, analysed and reported. Again, ver possible, automated thresholds should be mented to manage all components, to ensure that ons where service targets are breached or ened by component usage or performance are identified, and cost-effective actions to reduce or their potential impact are implemented. are many similar activities that are performed by f the above sub-processes, but each sub-process very different focus. Business Capacity Management sed on the current and future business ements, while Service Capacity Management is d on the delivery of the existing services that rt the business, and Component Capacity ement is focused on the IT infrastructure that pins service provision. e Capacity Management Information System MIS): holds the information needed by all     Business Capacity Management to determine what infrastructure components or upgrades to components are needed, and when The Capacity Plan: used by all areas of the business and IT management and is acted on by the IT Service Provider and senior management of the organization to plan the capacity of the IT infrastructure, it also provides planning input to many other areas of IT and the business. It contains information on the current usage of service and components and plans for the development of IT capacity to meet the needs in the growth of both existing service and any agreed new services. The Capacity Plan should be actively used as a basis of decision-making. Too often Capacity Plans are created and never referred to or used Service performance information and reports: used by many other processes. For example, the Capacity Management process assists Service Level Management with the reporting and reviewing of service performance and the development of new SLRs or changes to existing SLAs. It also assists the Financial Management process by identifying when money needs to be budgeted for IT infrastructure upgrades, or the purchase of new components Workload analysis and reports: used by IT operations to assess and implement changes in conjunction with Capacity Management to schedule or re-schedule when services or workloads are run, to ensure that the most effective and efficient use is made of the available resources Ad hoc capacity and performance reports: used by all areas of Capacity Management, IT and the business to analyse and resolve service and performance issues Forecasts and predictive reports: used by all areas to analyse, predict and forecast particular business and IT 28/8/07 14:01 Page 59 Service Design – building structural service integrity | 5.5 Capacity Management elements Service Portfolio Business requirements Capacity & performance reports Business apacity Management /SLR IT service design Review current capacity & performance Improve current service & component capacity Service apacity Management Assess, agree & document new requirements & capacity Component apacity Management Plan new capacity Capacity Management Tools Capacity Management Information System (CMIS) Forecasts Capacity Plan 59 28/8/07 14:01 Page 60 Service Design – building structural service integrity onal detailed guidance can be found in the Service publication. The Availability Management process should include:  Monitoring of all aspects of availability, reliability and AVAILABILITY MANAGEMENT bility Management is the window of service quality usiness customer. A Service Provider who does not solid practices to AM and who cannot offer reliable, service availability will never have a customer’s. bjectives of Availability Management are to: duce and maintain an appropriate and up-to-date ailability Plan that reflects the current and future eds of the business vide advice and guidance to all other areas of the siness and IT on all availability-related issues ure that service availability achievements meet or eed all of their agreed targets, by managing serviced resource-related availability performance ist with the diagnosis and resolution of availabilityated Incidents and Problems ess the impact of all changes on the Availability n and the performance and capacity of all services d resources ure that proactive measures to improve the ilability of services are implemented wherever it is t-justifiable to do so. bility Management should ensure the agreed level of bility is provided. The measurement and monitoring vailability is a key activity to ensure availability levels ng met consistently. Availability Management look to continually optimize and proactively ve the availability of the IT infrastructure, the services e supporting organization, in order to provide cost-          maintainability of IT services and the supporting components, with appropriate events, alarms and escalation, with automated scripts for recovery Maintenance of a set of methods, techniques and calculations for all availability measurements, metrics and reporting Assistance with risk assessment and management activities Collection of measurements, analysis and production of regular and ad hoc reports on service and component availability Understanding the agreed current and future demands of the business for IT services and their availability Influencing the design of services and components to align with business needs Producing an Availability Plan that enables the Service Provider to continue to provide and improve services in line with availability targets defined in SLAs and to plan and forecast future availability levels required as defined in SLRs Maintaining a schedule of tests for all resilient and failover components and mechanisms Assistance with the identification and resolution of any Incidents and Problems associated with service or component unavailability Proactive improvement of service or component availability wherever it is cost-justifiable and meets the needs of the business. 28/8/07 14:01 Page 61 ailability Management process (Figure 5.6) has two ements: active activities: the reactive aspect of Availability nagement involves the monitoring, measuring, alysis and management of all events, Incidents and blems involving unavailability. These activities are ncipally involved within operational roles oactive activities: the proactive activities of ailability Management involve the proactive nning, design and improvement of availability. ese activities are principally involved within design d planning roles. bility Management is completed at two nnected levels: rvice availability: involves all aspects of service ilability and unavailability and the impact of mponent availability, or the potential impact of mponent unavailability on service availability mponent availability: involves all aspects of mponent availability and unavailability. ing principle of Availability Management is to nize that it is still possible to gain customer ction even when things go wrong. One approach to chieve this requires Availability Management to that the duration of any Incident is minimized to normal business operations to resume as quickly as ible. An aim of Availability Management is to ensure ration and impact from Incidents impacting IT s are minimized, to enable business operations to e as quickly as is possible. The analysis of the ded incident lifecycle’ enables the total IT service ime for any given Incident to be broken down and ed against the major stages that all Incidents Service Design – building structural service integrity | 61 5.9.1 Identifying vital business functions The term ‘vital business function’ (VBF) is used to reflect the business-critical elements of the business process supported by an IT service. The service may also support less critical business functions and processes. It is important that the VBFs are recognized and documented to provide the appropriate business alignment and focus. 5.9.2 Designing for availability The level of availability required by the business influences the overall cost of the IT service provided. In general, the higher the level of availability required by the business the higher the cost. These costs are not just the procurement of the base IT technology and services required to underpin the IT infrastructure. Additional costs are incurred in providing the appropriate service management processes, systems management tools and high availability solutions required to meet the more stringent availability requirements. The greatest level of availability should be included in the design of those services supporting the most critical of the VBFs. When considering how the availability requirements of the business are to be met, it is important to ensure that the level of availability to be provided for an IT service is at the level actually required and is affordable and costjustifiable to the business (Figure 5.7). 28/8/07 14:01 Page 62 Service Design – building structural service integrity 5.6 The Availability Management process Reactive activities Monitor, measure, analyse report & review service & component availability Availability Management Information System (AMIS) Investigate all service & component unavailability & instigate remedial action Availability Management reports Proactive activities Risk assessment & Management Implement cost – justifiable countermeasures Plan & design for new & changed services Review all new & changed services & test all availability & resilience mechanisms Service Failure Analysis e Failure Analysis (SFA) is a technique designed to e a structured approach to identifying the ying causes of service interruptions to the user. SFA a range of data sources to assess where and why lls in availability are occurring. SFA enables a holistic o be taken to drive not just technology vements, but improvements to the IT support zation, processes, procedures and tools. SFA is run Availability Plan Availability design criteria Availability testing schedule opportunities to enhance levels of availability. SFA is a structured technique to identify improvement opportunities in end-to-end service availability that can deliver benefits to the user. Many of the activities involved in SFA are closely aligned with those of Problem Management and in a number of organizations these activities are performed jointly by Problem and Availability Management. The high-level objectives of SFA are: 28/8/07 14:01 Page 63 Service Design – building structural service integrity | 5.7 Relationship between levels of availability and overall costs Special solutions with redundancy Costs High availability design Effective Service Management Systems Management Base products, technology and components Availability identify the underlying causes of service interruption users assess the effectiveness of the IT support anization and key processes produce reports detailing the major findings and ommendations ensure availability improvements derived from SFAven activities are measured. tiatives should use input from all areas and all ses including, most importantly, the business and Each SFA assignment should have a recognized business) and involve resources from many technical and process areas. The use of the SFA approach:  Provides the ability to deliver enhanced levels of availability without major cost  Provides the business with visible commitment from the IT support organization  Develops in-house skills and competencies to avoid expensive consultancy assignments related to availability improvement  Encourages cross-functional team working and breaks barriers between teams and is an enabler to lateral 63 28/8/07 14:01 Page 64 Service Design – building structural service integrity vides a programme of improvement opportunities t can make a real difference to service quality and r perception vides opportunities that are focused on delivering nefit to the user vides an independent healthcheck of IT service nagement processes and is the stimulus for process provements. ing for availability is a key activity, driven by bility Management, which ensures that the stated bility requirements for an IT service can be met. er, Availability Management should also ensure that this design activity there is focus on the design nts required to ensure that when IT services fail, the can be reinstated to enable normal business ions to resume as quickly as is possible. ‘Designing covery’ may at first sound negative. Clearly good bility design is about avoiding failures and delivering possible a fault-tolerant IT infrastructure. However, his focus, is too much reliance placed on technology as as much emphasis been placed on the faultnt aspects of the IT infrastructure? The reality is that s will occur. The way the IT organization manages situations can have a positive effect on the tion of the business, customers and users of the IT s. message failure is an important moment of truth – an rtunity to make or break your reputation with usiness. process of Availability Management contains a ber of methods, techniques and practices for sing, preventing and analysing service failures. ls about these methods can be found in the 5.10 IT SERVICE CONTINUITY MANAGEMENT Service failures of extreme magnitude are not something any business or service provider wants to experience. Even the best-planned and managed services however, can be the victim of catastrophic failure through events that are not in the direct control of a service provider. Most of us purchase insurance to protect us in the event something of great value, such as our home, becomes the victim of a catastrophic event. Insurance gives us peace of mind that if the unplanned happens, we have the means to recover from such disasters. The amount of insurance we purchase is gauged on the predicted replacement value of our possessions, the likelihood such a disaster could happen and how quickly we can restore our losses. This is a form of risk management. IT Service Continuity Management is the part of ITIL practice that evaluates the level of insurance we need to protect service assets and a manuscript to recover from a disaster. The goal of ITSCM is to support the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, telecommunications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales. The objectives of ITSCM are to:  Maintain a set of IT Service Continuity Plans and IT recovery plans that support the overall Business Continuity Plans (BCPs) of the organization  Complete regular Business Impact Analysis (BIA) exercises to ensure that all continuity plans are 28/8/07 14:01 Page 65 nduct regular risk assessment and management rcises in conjunction particularly with the business d the Availability Management and Security nagement processes that manages IT services within agreed level of business risk vide advice and guidance to all other areas of the siness and IT on all continuity- and recovery-related ues ure that appropriate continuity and recovery chanisms are put in place to meet or exceed the eed business continuity targets ess the impact of all changes on the IT Service ntinuity Plans and IT recovery plans ure that proactive measures to improve the ilability of services are implemented wherever it is t-justifiable to do so gotiate and agree the necessary contracts with ppliers for the provision of the necessary recovery pability to support all continuity plans in conjunction h the Supplier Management process. SCM process includes: e agreement of the scope of the ITSCM process and policies adopted siness Impact Analysis (BIA) to quantify the impact t loss of IT service would have on the business k analysis – the risk identification and risk essment to identify potential threats to continuity d the likelihood of the threats becoming reality. This o includes taking measures to manage the identified eats where this can be cost-justified duction of an overall ITSCM strategy that must be egrated into the BCM strategy. This can be produced owing the two steps identified above and is likely to lude elements of risk reduction as well as selection Service Design – building structural service integrity | 65  Production of ITSCM plans, which again must be integrated with the overall BCM plans  Testing of the plans  The ongoing operation and maintenance of the plans. Service continuity is implemented and managed in four stages (Figure 5.8): 1 Initiation – Policy setting, defining scope and terms of reference, project planning and resource allocation 2 Requirements and strategy – Business impact analysis, risk assessment 3 Implementation – Executing risk reduction measures, recovery option arrangements, testing the plans 4 Ongoing operation – Education and awareness, change control of ITSCM plans, ongoing testing. A good place to start is by assessing the threats and risks to VBFs (as described in the preceding section on Availability Management). This will help reveal vulnerabilities to vital business operations and ensure that preventative and recovery plans and mechanisms are in place. Consistent with the ITSCM process, this should be continually evaluated to ensure that changes to services or business requirements have not affected the ability of the ITSCM process to be effective when needed. The Service Design core publication offers detailed guidance on how to establish and maintain ITSCM. 28/8/07 14:01 Page 66 Service Design – building structural service integrity 5.8 Service Continuity lifecycle Lifecycle Business Continuity Management (BCM) Business Continuity Strategy Business Continuity Plans Invocation Key activities Policy setting Scope Initiate a project Initiation Requirements and strategy Business Impact Analysis Risk Assessment IT Service Continuity Strategy Implementation Develop IT Service Continuity Plans Develop IT plans, recovery plans and procedures Organisation Planning Testing strategy Ongoing Operation INFORMATION SECURITY MANAGEMENT the world, organizations create value through the ctual property they own and use to deliver products rvices. Protecting intellectual capital is a primary or business and is increasingly legislated by law. The ology today offers us unlimited potential to create, and amass vast quantities of information. A service er is responsible to ensure that they can guarantee siness information is protected from intrusion, theft, d unauthorized access. ation security is a management activity within the ate governance framework, which provides the ic direction for security activities and ensures Education, awareness and training Review and audit Testing Change Management purpose of ISM is to provide a focus for all aspects of IT security and manage all IT security activities. The term ‘information’ is used as a general term and includes data stores, databases and metadata. The objective of information security is to protect the interests of those relying on information, and the systems and communications that deliver the information, from harm resulting from failures of availability, confidentiality and integrity. For most organizations, the security objective is met when:  Information is available and usable when required, and the systems that provide it can appropriately resist attacks and recover from or prevent failures 28/8/07 14:01 Page 67 ormation is complete, accurate and protected ainst unauthorized modification (integrity) siness transactions as well as information exchanges ween enterprises, or with partners, can be trusted thenticity and non-repudiation). zation of confidentiality, integrity and availability be considered in the context of business and ss processes. The primary guide to defining what be protected and the level of protection has to come he business. To be effective, security must address business processes from end to end and cover the al and technical aspects. Only within the context of ss needs and risks can management define security. tivities should be focused on and driven by an Information Security Policy and a set of pinning specific security policies. The policy should he full support of top executive IT management and the support and commitment of top executive ss management. The policy should cover all areas of y, be appropriate, meet the needs of the business ould include: overall Information Security Policy e and misuse of IT assets policy access control policy password control policy e-mail policy internet policy anti-virus policy information classification policy ocument classification policy emote access policy policy with regard to supplier access of IT services, ormation and components Service Design – building structural service integrity | SLRs, SLAs, contracts and agreements. The policies should be authorized by top executive management within the business and IT, and compliance to them should be endorsed on a regular basis. All security policies should be reviewed and where necessary revised on at least an annual basis. The five elements within an Information Security Management System (ISMS) framework are:  Control The objectives of the control element of the ISMS are to:  Establish a management framework to initiate and manage information security in the organization  Establish an organization structure to prepare, approve and implement the information security policy  Allocate responsibilities  Establish and control documentation  Plan The objective of the plan element of the ISMS is to devise and recommend the appropriate security measures, based on an understanding of the requirements of the organization. The requirements will be gathered from such sources as business and service risk, plans and strategies, SLAs and OLAs and the legal, moral and ethical responsibilities for information security. Other factors, such as the amount of funding available and the prevailing organization culture and attitudes to security, must be considered. The Information Security Policy defines the organization’s attitude and stance on security matters. This should be an organization-wide document, not 67 28/8/07 14:01 Page 68 Service Design – building structural service integrity plement e objective of the implementation element of the MS is to ensure that appropriate procedures, tools d controls are in place to underpin the Information urity Policy. ongst the measures are: Accountability for assets – Configuration Management and the CMS are invaluable here Information classification – information and repositories should be classified according to the sensitivity and the impact of disclosure e successful implementation of the security controls d measures is dependent on a number of factors: The determination of a clear and agreed policy integrated with the needs of the business Security procedures that are justified, appropriate and supported by senior management Effective marketing and education in security requirements A mechanism for improvement aluation e objectives of the evaluation element of the ISMS to: Supervise and check compliance with the security policy and security requirements in SLAs and OLAs Carry out regular audits of the technical security of IT systems Provide information to external auditors and regulators, if required intain e objectives of this maintain element of the ISMS are Improve on security agreements as specified in, for example, SLAs and OLAs  This should be achieved using a PDCA (Plan-Do- Check-Act) cycle, which is a formal approach suggested by ISO 27001 for the establishment of the ISMS or Framework. This cycle is described in more detail in the Continual Service Improvement publication. Security measures can be used at a specific stage in the prevention and handling of security incidents, as illustrated in Figure 5.9. Security incidents are not solely caused by technical threats – statistics show that, for example, the large majority stem from human errors (intended or not) or procedural errors, and often have implications in other fields such as safety, legal or health. The following stages can be identified. At the start there is a risk that a threat will materialize. A threat can be anything that disrupts the business process or has negative impact on the business. When a threat materializes, we speak of a security incident. This security incident may result in damage (to information or to assets) that has to be repaired or otherwise corrected. Suitable measures can be selected for each of these stages. The choice of measures will depend on the importance attached to the information:  Preventive: security measures are used to prevent a security incident from occurring. The best-known example of preventive measures is the allocation of access rights to a limited group of authorized people. The further requirements associated with this measure include the control of access rights (granting, maintenance and withdrawal of rights), authorization (identifying who is allowed access to which information and using which tools), identification and authentication (confirming who is seeking access) and access control (ensuring that only authorized personnel 28/8/07 14:01 Page 69 Service Design – building structural service integrity | 69 5.9 IT Security Management process Produce and maintain an Information Security Policy Communicate, implement and enforce adherence to all security policies Assess and categorise information assets, risks and vulnerabilities Monitor and manage security incidents and breaches Regularly assess, review and report security risks and threats Impose and review risk security controls, review and implement risk mitigation Report, review and reduce security breaches and major incidents Information Security Information Management Security Policy(s) System (ISMS) Security reports and information ductive: further measures can be taken in advance minimize any possible damage that may occur. miliar examples of reductive measures are making ular backups and the development, testing and intenance of contingency plans tective: if a security incident occurs, it is important discover it as soon as possible – detection. A familiar mple of this is monitoring, linked to an alert cedure. Another example is virus-checking software pressive: measures are then used to counteract any ntinuation or repetition of the security incident. For mple, an account or network address is temporarily Security controls Security risks and responses  Corrective: damage is repaired as far as possible using corrective measures. For example, corrective measures include restoring the backup, or returning to a previous stable situation (roll-back, back-out). Fallback can also been seen as a corrective measure. The documentation of all controls should be maintained to reflect accurately their operation, maintenance and their method of operation. ISM faces many challenges in establishing an appropriate Information Security Policy with an effective supporting process and controls. One of the biggest challenges is to 28/8/07 14:01 Page 70 Service Design – building structural service integrity s no support from the business, IT security controls k assessment will be severely limited in what they hieve because of this lack of support from the ss. It is pointless implementing security policies, dures and controls in IT if these cannot be enforced hout the business. The major use of IT services and is outside of IT, and so are the majority of security and risks. e organizations the business perception is that y is an IT responsibility, and therefore the business es that IT will be responsible for all aspects of IT y and that IT services will be adequately protected. er, without the commitment and support of the ss and business personnel, money invested in sive security controls and procedures will be largely d and they will mostly be ineffective. o the Service Design core publication for further nce and detailed practices on Information Security ement. SUPPLIER MANAGEMENT pplier Management process ensures that suppliers e services they provide are managed to support IT targets and business expectations. The aim of this n is to raise awareness of the business context of g with partners and suppliers, and how this work st be directed toward realizing business benefit for ganization. sential that Supplier Management processes and ng are involved in all stages of the Service Lifecycle, trategy and design, through transition and operation, rovement. The complex business demands require mplete breadth of skills and capability to support of suppliers and partners are essential to the provision of quality IT services (see Figure 5.10). The main objectives of the Supplier Management process are to:  Obtain value for money from supplier and contracts  Ensure that underpinning contracts and agreements     with suppliers are aligned to business needs, and support and align with agreed targets in SLRs and SLAs, in conjunction with SLM Manage relationships with suppliers Manage supplier performance Negotiate and agree contracts with suppliers and manage them through their lifecycle Maintain a supplier policy and a supporting supplier and contract database (SCD). The Supplier Management process should include:  Implementation and enforcement of the supplier policy  Maintenance of an SCD  Supplier and contract categorization and risk         assessment Supplier and contract evaluation and selection Development, negotiation and agreement of contracts Contract review, renewal and termination Management of suppliers and supplier performance Agreement and implementation of service and supplier improvement plans Maintenance of standard contracts, terms and conditions Management of contractual dispute resolution Management of sub-contracted suppliers. IT supplier management often has to comply with 28/8/07 14:01 Page 71 Service Design – building structural service integrity | 5.10 Supplier Management – roles and interfaces ice Provider Supplier Mgt. Process Owner Finance & Purchasing Contracts Manager Legal Supplier Manager 1 Service Supplier Manager 2 Service Supplier Manager 3 Service Supplier Manager 4 Service Service Service Supplier 6 Supplier 5 Supplier 4 Supplier 3 Supplier 2 Supplier 1 Sub-contracted Supplier 1 ction surveys also play an important role in ng how well supplier service levels are aligned to ss needs. A survey may reveal instances where there atisfaction with the service, yet the supplier is ntly performing well against its targets (and vice This may happen where service levels are opriately defined and should result in a review of ntracts, agreements and targets. Some service ers publish supplier league tables based on their Sub-contracted Supplier 2 conjunction with the procurement department) and IT will have established their objectives for the relationship, and defined the benefits they expect to realize. This forms a major part of the business case for entering into the relationship. These benefits must be linked and complementary, and must be measured and managed. Where the business is seeking improvements in customer service, then IT 71 28/8/07 14:01 Page 72 Service Design – building structural service integrity , trusted relationships with suppliers are an integral nt of successful service management and enhance ue of any service provider to the business. rvice Design book contains all the details to guide rough Supplier Management and achieve this level tionships with suppliers. 28/8/07 14:01 Page 73 28/8/07 14:01 Page 74