ITIL Intermediate SOA - Technology and Implementation Considerations Tutorial

Technology and Implementation Considerations

Welcome to lesson 10 ‘Technology and Implementation Considerations’ of the ITIL Intermediate SOA tutorial, which is a part of the ITIL Intermediate SOA Foundation Certification course. This lesson deals with SOA technology and implementation considerations.

Let us look at the objectives of this lesson.

Objectives

By the end of this ‘Technology and Implementation Considerations’ lesson, you will be able to:

• Explain the SOA technology and implementation considerations. Service design which is specifically used to identify good practices and evaluation criteria for technology and tools related to process implementation is also explained.

• Explain the Service operation which provides the specifics on planning and implementing service management technology support as well as a guide to generic requirements for technology.

• Explore the three lifecycle stages used to deal with the challenges, Critical success factors and risks related to implementing practices and processes.

Let us start with SOA Technology Considerations.

SOA Technology Considerations

Tools and Technologies play an important role 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

• A 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).

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, modeling 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 section.

Service Management Tools

The service management tools are helpful in the following ways:

• Enable 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 these 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 analyzed, 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.

Defining Tool Requirements

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 analyzed, 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 modeling 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).

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.

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 the 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 of the relevant stakeholder groups should be adopted during this stage.

Based on the evaluation, a reasonable number of products should be shortlisted. 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.

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 in establishing the tool selection criteria :

• An 80 percent fit to all functional and technical requirements

• Meeting of all mandatory requirements

• Little product customization required

• Adherence to 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.

Planning and Implementation

There are some 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 licenses that the organization needs. Licenses are often available in the following types

• Dedicated Licenses: For use by those staff that requires the frequent and prolonged use of the module (e.g., Service Desk staff would need a dedicated license 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 license

• 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 by 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 has 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 need upgrading or replacement, 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.

The timing of Technology Deployment:

Care is needed to ensure that tools are deployed at the appropriate time about 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.

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 section let us learn about implementing service design.

Implementing - Service design

Here is a process diagram for implementing service design.

The first step is to understand what the vision is?

The answer to this could be the following:

• 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

The 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?

It is done 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 as follows:

• Must be defined before implementation

• Must be able to identify if future state of service has been achieved

• Checks and reviews should be complete At 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.

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 life cycle:

• 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 cooperation 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 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

• Difficulty ascertaining the return on investments and the realization of business benefit.

Service Design - Risks

There are some 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 is 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 the 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 is given to the design phase, or insufficient training given to the staff tasked with the design.

• Insufficient engagement or commitment to the application’s functional development, leading to insufficient attention to Service Design requirements.

In the next section, we will look at the challenges of Service Transition.

Challenges - Service Transition

Service Transition is a very important stage of 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 some challenges for Service Transition to be successful.

The challenges of 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.

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.

Challenges - Service Operation

There are some challenges faced within Service Operation that need to be overcome. These include:

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 maneuvering. 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.

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 the 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 license costs through the better management of licenses 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 use 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 some 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.

Also, 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 of the lifecycle have different metrics, which encourages Service Design to complete the project on time, to specification and in the 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. The operation, Change, and Transition Managers must have the authority to deny any changes into the operational environment, without exception, that is not thoroughly tested.

In the next section, we will discuss the critical success factors of service operation.

Critical Success Factors - Service Operation

The Critical Success Factors (CSFs) can be listed as follows:

• 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.

Conclusion

With this, we come to an end of the ITIL Intermediate SOA tutorial. We hope that now you have a clear idea of the ITIL SOA topic. To enhance your skills further in SOA, you can enroll in our ITIL Intermediate SOA Course.