ITIL Intermediate SOA - Technology and Implementation Considerations Tutorial

10.1 Technology and Implementation Considerations

Learning Unit 10 deals with SOA technology and implementation considerations. Service design is specifically used to identify good practices and evaluation criteria for technology and tools related to process implementation. Service operation provides the specifics on planning and implementing service management technology support as well as a guide to generic requirements for technology. All three lifecycle stages (namely service design, service operation and service transition) are used to explore the challenges, Critical success factors and risks related to implementing practices and processes.

10.2 SOA technology considerations

Tools and Technologies in SOA support whole service lifecycle, like Management of all stages of the Service Lifecycle, aspects of the service and its performance Identifying service achievement Consolidating metrics and Metrics Trees Consistent and consolidated views across all processes, systems, technologies and groups Comprehensive set of search and reporting facilities Management of service costs Management of relationships, interfaces and inter-dependencies Management of the Service Portfolio and Service Catalogue Maintenance and support of Configuration Management System (CMS) Maintenance and support of Service Knowledge Management System (SKMS).

10.3 Service Design Tools

Developing Service Designs can be simplified by the use of tools that provide graphical views of the service and its constituent components, from the business processes, through the service and SLA to the infrastructure, environment, data and applications, processes, OLAs, teams, contracts and suppliers. Some Configuration Management tools provide such facilities, and are sometimes referred to as an element of Business Service Management (BSM) tools. They can contain or be linked to ‘auto-discovery’ tools and mechanisms and allow the relationships between all of these elements to be graphically represented, providing the ability to drill down within each component and obtain detailed information if needed. The service design tools are useful in: Speeding up the design process Ensuring that standards and conventions are followed Offering prototyping, modelling and simulation facilities Enabling ‘What if?’ scenarios to be examined Enabling interfaces and dependencies to be checked and correlated Validating designs before they are developed and implemented to ensure that they satisfy and fulfill their intended requirements Enable designs in hardware, software, data and environment Similarly let us look at the Service management tools in the next slide.

10.4 Service Management tools

The service management tools: Enables the Service Design processes to work more effectively They increase the efficiency and effectiveness In the long term they provide cost savings and increased productivity which in turn can lead to an increase in the quality of the IT service provision The use of tools will enable the centralization of key processes and the automation and integration of core Service Management processes The raw data collected by the tools can be analysed, resulting in the identification of ‘trends’ Preventative measures can then be implemented, again improving the quality of the IT service provision. Next, let us learn about the tool requirements.

10.5 Defining Tool Requirements

Evaluation Criteria for Technology The use of tools will enable the centralization of key processes and the automation and integration of core Service Management processes. The raw data collected by the tools can be analysed, resulting in the identification of ‘trends’. Preventative measures can then be implemented, again improving the quality of the IT service provision. Some points that organizations should consider when evaluating Service Management tools include: Data structure, data handling and integration Integration of multi-vendor infrastructure components, and the need to absorb new components in the future – these will place particular demands on the data-handling and modelling capabilities of the tool Conformity to international open standards Flexibility in implementation, usage and data sharing Usability – the ease of use permitted by the user interface Support for monitoring service levels Distributed clients with a centralized shared database (e.g. client server) Conversion requirements for previously tracked data Data backup, control and security Support options provided by the tool vendor Scalability at increasing of capacity (the number of users, volume of data and so on). Let us learn the MoSCoW analysis and the selection processes, based on Statement of Requirements (SOR).

10.6 Statement of Requirements

Requirements Classification – MoSCoW Consideration must be given to the exact requirements for the tool. What are the mandatory requirements and what are the desired requirements? Generally the tool should support the processes, not the other way round, so minimize modification of the processes to fit the tool. Where possible, it is better to purchase a fully integrated tool (although not at the expense of efficiency and effectiveness) to underpin many (if not all) Service Management processes. If this is not possible, consideration must be given to the interfaces between the various tools. It is essential to have a Statement of Requirements (SoR) for use during the selection process – this statement can be used as a ‘tick list’. The tool requirements should be categorized using the MoSCoW analysis: M – MUST have this S – SHOULD have this if at all possible C – COULD have this if it does not affect anything else W – WON’T have this time but WOULD like in the future.

10.7 Tool Evaluation Process

Now let us have a quick look at the tool evaluation process. The first step is to identify all the requirements and convert them into a ‘Statement of Requirements’. It should cover all the business requirements, mandatory features, and conformance to standards. The next step is to identify products and document all relevant information about the products. The third step is to develop a set of ‘selection criteria’ based on which the identified products will be evaluated. Apart from cost of software, hardware and licenses required, the selection criteria should include vendor and tool credibility, percentage fit to requirements, training effort and cost, ease of use and maintenance, etc. The next step is to evaluate the products based on the selection criteria developed. An unbiased approach involving various members from the relevant stakeholder groups should be adopted during this stage. Based on the evaluation, a reasonable number of products should be short listed. Those that do not pass the mandatory criteria should not find a place in this list. The next step is to score the products based on a well-defined scoring system. The scoring system should cover financial, vendor market standing, tool features and performance, market and customer reviews, security and integrity and other relevant aspects. Once the scoring of the products is completed, the next step is to rank the products based on scores given. An appropriate weightage to the different categories of scores should be given to ensure correct ranking of products. The final step is to select the product. It is not essential to go for the product with the highest rank. While ranking enables easier selection of products, it is basically the alignment to requirements and objectives that should drive the selection of the most appropriate tool.

10.8 Tool Selection Criteria

Tool Selection Criteria In general it is difficult to find a tool that fits all the requirements of the processes or service management activities. The key consideration should be to look for tools that match as much of the mandatory requirements as possible. Vendor and tool credibility, training needs of the organization, ease of implementation and maintenance, and various other aspects should be given due importance during tool evaluation and selection. Let us have a look at the points to be considered during establishing the tool selection criteria : An 80 pearcent fit to all functional and technical requirements Meeting of all mandatory requirements Little product customization required Adherence of tool and supplier to service management best practice A sound data structure and handling Integration with other service management and operational management tools Support of open standards and interfaces Being business-driven not technology-driven Administration and maintenance costs within budget Acceptable levels of maintenance and release policies Security and integrity Availability of training and consultancy services Good report generation Scalability and growth.

10.9 Planning and Implementation

There are a number of factors that organizations need to plan for in readiness for, and during deployment and implementation of, ITSM support tools. These include the following Licenses: The overall cost of ITSM tools, particularly the integrated tool that will form the heart of the required toolset, is usually determined by the number and type of user licences that the organization needs. Licences are often available in the following types • Dedicated Licenses: For use by those staff that requires frequent and prolonged use of the module (e.g. Service Desk staff would need a dedicated licence to use an Incident Management module). • Shared Licenses: For staff who make fairly regular use of the module, but with significant intervals in between, so can usually manage with a shared licence • Web Licenses: Usually allowing some form of ‘light interface’ via web access to the tool’s capabilities, this is usually suitable for staff requiring remote access, only occasional access, or usage of just a small subset of the functionality (e.g. engineering staff wishing to log details of actions taken on incidents or users just wanting to log an incident directly). • Service on Demand: There has been a trend within the IT industry for suppliers to offer IT applications ‘on demand’, where access is given to the application for a period of demand and then severed when it is no longer needed – and charged on the basis of the time spent using the application. Deployment: Many ITSM tools, particularly Discovery and Event Monitoring tools, will require some client/agent software deploying to all target locations before they can be used. This will need careful planning and execution – and should be handled through formal Release and Deployment Management. Even where network deployment is possible, this needs careful scheduling and testing – and records must be maintained throughout the rollout so that support staff have knowledge of who has been upgraded and who has not. Some form of interim Change Management may be necessary and the CMS should be updated as the rollout progresses. Capacity Checks: Some Capacity Management may be necessary in advance to ensure that all of the target locations have sufficient storage and processing capacity to host and run the new software – any that cannot will need upgrading or replacing, and lead times for these actions need to be included in the plans. The capacity of the network should also be checked to establish whether it can handle the transmission of management information, the transmission of log files and the distribution of clients’ and also possibly software and configuration files. Timing of Technology Deployment: Care is needed to ensure that tools are deployed at the appropriate time in relation to the organization’s level of ITSM sophistication and knowledge. If tools are deployed too soon, they may be seen as an immediate panacea and any necessary action to change processes, working practices or attitudes may be hindered or overlooked. A tool alone is usually not enough to make things work better. There is an old adage: ‘A fool with a tool is still a fool!’ Type of Introduction: A decision is needed on what type of introduction is needed – whether to go for a ‘Big Bang’ introduction or some sort of phased approach. As most organizations will not start from a ‘green field’ situation, and will have live services to keep running during the introduction, a phased approach is more likely to be necessary. In many cases a new tool will be replacing an older, probably less sophisticated, tool and the switchover between the two is another factor to be planned. This will often involve deciding what data needs to be carried forward from the old tool to the new one – and this may require significant reformatting to achieve the required results. Ideally this transfer should be done electronically – but in some cases a small amount of rekeying of live data may be inevitable and should be factored into the plans .

10.10 Deployment considerations

Now let us understand the factors that must be considered during implementation of tools. They are: Availability of client and agent software Scheduling of deployment Testing of tool Deployment records Change Management Updating configuration management system Moving ahead, in the next slide let us learn about implementing service design.

10.11 Implementing - Service design

Here is a process diagram for implementing service design. The first step is to understand what is the vision? • Establish a vision, aligned with the business vision and objectives • Establish the scope of the project or programme • Establish a set of high-level objectives • Establish governance, sponsorship and budget • Obtain senior management commitment • Establish a culture focused on: • Quality • Customer and business focus • A learning environment • Continual improvement • Commitment to the ‘improvement cycle’ • Ownership and accountability. Next would be to understand, Where are we now? This will be understood by • An internal review or audit • Maturity assessment • An external assessment or benchmark • An ISO/IEC 20000 audit • An audit against COBIT • A Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis • A risk assessment and management methodology Third step would be to check on where do we want to be? This could be defined by • Improved IT service provision alignment with total business requirements • Improved quality of Service Design • Improvements in service levels and quality • Increases in customer satisfaction • Improvements in process performance. Fourthly, how do we get there? Through • Improvement actions • The approach to be taken and the methods to be used • Activities and timescales • Risk assessment and management • Resources and budgets • Roles and responsibilities • Monitoring, measurement and review Lastly, Did we get there? This would be defined by Service implementation measurements. These • Must be defined before implementation • Must be able to identify if future state of service has been achieved • Checks and reviews should be complete In the end to end process, Maintaining of the momentum on (How do we keep going?) is a very essential aspect. This can be done by • Developing a learning environment • Establishing a desire to improve throughout the organization • Recognizing and reinforcing the message that quality and improvement are everybody’s job • Maintaining the momentum on improvement and quality. Next, let us understand the challenges of Service Design.

10.12 Challenges - Service Design

Every new initiative comes with various challenges. It is very difficult to design services and processes that meet the requirements of all stakeholders. The following are some of the challenges relating to service design stage of the lifecycle. Organizational resistance to change; Unclear or changing requirements from the business; Lack of awareness and knowledge of service and business targets and requirements; Resistance to planning, or a lack of planning leading to unplanned initiatives and unplanned purchases; Inefficient use of resources causing wasted time and money; Poor relationships, communication or lack of co-operation between the IT service provider and the business that may result in the design not achieving the business requirements; Use of old technology and legacy systems; Required tools are too costly or too complex to implement or maintain with the current staff skills; Lack of information, monitoring and measurements; Lack of focus on service availability; Ensuring alignment with current architectural directions, strategy and policies; The use of diverse and disparate technologies and applications; Cost and budgetary constraints; and Difficulty ascertaining the return on investments and the realization of business benefit.

10.13 Service Design - Risks

Service Design - Risks There are a number of risks directly associated with the Service Design phase of the Service Lifecycle. These risks need to be identified to ensure that they are not realized. They include the following: • If any of the PFSs for Service Design are not met, then the Service Design or Service Management process will not be successful. • If maturity levels of one process are low, it will be impossible to achieve full maturity in other processes. • Business requirements are not clear to IT staff. • Business timescales are such that insufficient time is given for proper Service Design. • Insufficient testing, resulting in poor design and therefore poor implementation. • An incorrect balance is struck between innovation, risk and cost while seeking a competitive edge, where desired by the business. • The fit between infrastructures, customers and partners is not sufficient to meet the overall business requirements. • A coordinated interface is not provided between IT planners and business planners. • The policies and strategies, especially the Service Management strategy, are not available from Service Strategy, or its content is not clearly understood. • There are insufficient resources and budget available for Service Design activities. • The risk of services developed in isolation using their ‘own’ assets and infrastructure. This can appear to be cheaper in isolation, but can be much more costly in the long term because of the financial savings of corporate buying and the extra cost of supporting different architecture. • Insufficient time given to the design phase, or insufficient training given to the staff tasked with the design. • Insufficient engagement or commitment with then application’s functional development, leading to insufficient attention to Service Design requirements . In the next slide, we will look at the risks of Service transition.

10.14 Challenges - Service transition

Service Transition is a very important stage within the overall service lifecycle and there is a lot of complexity involved in transitioning services from Service Design stage to Service Operation stage. This complexity poses a number of challenges for Service Transition to be successful. The challenges pertaining to Service Transition are: Managing many contacts, interfaces and relationships through Service Transition, including a variety of stakeholders, namely, customers, users, project teams, suppliers and partners; Harmonization and integration of the processes and disciplines that impact Service Transition; Inherent differences among the legacy systems, new technology and human elements; Achieving a balance between stability and responsiveness; Achieving a balance between pragmatism and bureaucracy; Being an enabler of business change and, therefore, an integral component of the business change programmes; Establishing leaders to champion the changes and improvements; Establishing ‘who is doing what, when and where’ and ‘who should be doing what, when and where’; Developing a culture that encourages people to collaborate and work effectively and an atmosphere that fosters the cultural shifts necessary to get buy-in from people; Ensuring that the service transition time and budget are not impacted by events earlier in the service lifecycle; Understanding the different stakeholder perspectives that underpin effective risk management; and Understanding, and being able to assess, the balance between managing risks and taking risks.

10.15 Risks - Service transition

Implementing the Service Transition practice should not be made without recognizing the potential risk to services currently in transition and those releases that are planned. A baseline assessment of current Service Transitions and planned projects will help Service Transition to identify implementation risks. These risks might include: • Change in accountabilities, responsibilities and practices of existing projects that de-motivate the workforce • Alienation of some key support and operations staff • Additional unplanned costs to services in transition • Resistance to change and circumvention of the processes due to perceived bureaucracy. Other implementation risks include: • Excessive costs to the business due to overly risk averse Service Transition practices and plans • Knowledge sharing (as the wrong people may have access to information) • Lack of maturity and integration of systems and tools resulting in people ‘blaming’ technology for other shortcomings • Poor integration between the processes – causing process isolation and a silo approach to delivering ITSM • Loss of productive hours, higher costs, loss of revenue or perhaps even business failure as a result of poor Service Transition processes. Let us understand the number of challenges faced within Service Operation.

10.16 Challenges - Service Operation

There are a number of challenges faced within Service Operation that need to be overcome. These include those set out in this section. Lack of engagement with development and project staff Traditionally, there has been a separation between Service Operation staff and those staff involved in developing new applications or running projects that will eventually deliver new functionality into the operational environment. This separation was originally deliberate and driven by the desire to prevent collusion and avoid potential security risks (in some organizations it is still a legislative requirement). However, instead of using this separation of duties to create positive contributions, in many organizations it is a source of rivalry and political manoeuvring. All too often, ITSM is seen as something that has been initiated in the operational areas and is nothing to do with development or projects. This view is very damaging as the appropriate time to be thinking of Service Operation issues is at the outset of new developments or projects – when there is still time to include these factors in the planning stages. The Service Design and Service Transition publications describe the steps needed to ensure that IT Operations issues are considered from the outset of new developments and projects. Next would be Justifying funding. It is often difficult to justify expenditure in the area of Service Operation, as money spent in this sphere is often regarded as ‘infrastructure costs’ – with nothing new to show for the investment. The Service Strategy publication discusses how to ensure a Return on Investment and eliminate the perception of investment as a purely Infrastructure ‘overhead’. Good guidance is offered on how to justify investment. In reality, many investments in ITSM, particularly in the Service Operation areas, can save money and show a positive Return on Investment – as well as resulting improvement in service quality. Some examples of potential areas of savings include: Reduced software licence costs through the better management of licences and deployed copies Reduced support costs due to fewer incidents and problems and reduced resolution times Reduced headcount through workforce rationalization, supporting roles and accountability structures Less ‘lost business’ due to poor IT service quality Better utilization of existing infrastructure equipment and deferral of further expenditure due to better capacity management Better-aligned processes, leading to less duplication of activities and better usage of existing resources. Challenges for Service Operation Managers The following is a list of some of the challenges that Managers in Service Operation should expect to face. There is no easy solution to these challenges, mainly because they are by-products of the organization culture and the decisions made during the process of deciding the organizational structure. The purpose of including the list is to ensure that Service Operation Managers are conscious of them and can create a plan to deal with them. The differences between Design activities and Operational activities will continue to present challenges. This is for a number of reasons, including the following: Service Design may tend to focus on an individual service at a time, whereas Service Operation tends to focus on delivering and supporting all services at the same time. Operation Managers should work closely with Service Design and Service Transition to provide the Operation perspective to ensure that design and transition outcomes support the overall operational needs. Service Design will often be conducted in projects, while Service Operation focuses on on-going, repeatable management processes and activities. The result of this is that operational staff are often not available to participate in Service Design project activities, which in turn results in IT services that are difficult to operate, or which do not include adequate manageability design elements. In addition, once project staffs have finished the design of one IT Service they could move onto the next project and not be available to support difficulties in the operational environment. Overcoming this challenge requires Service Operation to plan for its staff to be actively involved in design projects, to resource the transition activities and participate in Early Life Support of services introduced in the operational environment. The two stages in the lifecycle have different metrics, which encourages Service Design to complete the project on time, to specification and in budget. In many cases it is difficult to forecast what the service will look like and how much it will cost after it has been deployed and operated for some time. When it does not run as expected, IT Operations Management is held responsible. While this challenge will always be a reality in Service Management, this can be addressed by active involvement in the Service Transition stage of the lifecycle. The objective of Service Transition is to ensure that designed services will operate as expected and the Operations Manager can provide the knowledge needed to Service Transition to assess, and remedy, issues before they become issues in the operational environment. Service Transition that is not used effectively to manage the transition between the Design and Operation phases. For example, some organizations may only use Change Management to schedule the deployment of changes that have already been made – rather than testing to see whether the change will successfully make the transition between Design and Operation. It is imperative that the practices of Service Transition are followed and organization policies to prevent poorly managed Change practices are in place. Operation, Change and Transition Managers must have the authority to deny any changes into the operational environment, without exception, that are not thoroughly tested. In the next slide, we will discuss the critical success factors of service operation.

10.17 Critical Success factors - Service operation

Senior Management support is critical for obtaining and maintaining adequate funding and resourcing. Rather than seeing Service Operation as a ‘black hole’ for investment, Senior Management should quantify and champion the benefits of good Service Operation. They should also be fully informed of the dire results that can occur because of poor Service Operation It is important that the Business Units also support Service Operation. This level of support can be far better achieved if the Service Operation staff involve the business in all of their activities and are open in their reporting of both successes and failures – and their efforts to improve. ITSM projects and the resulting ongoing practice (performed by Service Operation staff) are often more successful if one or more ‘champions’ are forthcoming who can lead others through their enthusiasm and commitment for ITSM. Having the appropriate number of staff with the appropriate skills is critical to the success of Service Operation. Adequate training and awareness can have much wider overall benefits. As well as creating champions of a few, it can be used to win the ‘hearts and minds’ of many. Service Operation staff must all be aware of the consequences of their actions, both good and bad, on the organization – and all must be instilled with a ‘Service Management culture’. Many Service Operation processes and activities cannot be performed effectively without adequate support tools .

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*