Service Design

7. Technology Considerations

Often organizations believe that by purchasing or developing a tool all their problems will be solved, and it is easy to forget that we are still dependent on the process, the function and, most importantly, the people. Remember:

7.1 Service Design Tools

• Hardware design
• Software design
• Environmental design
• Process design
• Data design.

The tools and techniques are many and varied, including both proprietary and non-proprietary, and 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 checked and correlated
• Validating designs before they are developed and implemented to ensure that they satisfy and fulfil their intended requirements.

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.

If these types of tool also contain financial information, and are then linked to a 'Metrics Tree' providing KPIs and metrics of the various aspects of the service, then the service can be monitored and managed through all stages of its lifecycle. Sharing this single, centralized set of service information allows everybody in the service provider organization and the business to access a single, consistent, 'real-world' view of the service and its performance, and provides a solid base for the development of good relationships and partnerships between the service provider and its customers.

These types of tools not only facilitate the design processes, but also greatly support and assist all stages in the Service Lifecycle, including:

• Management of all stages of the Service Lifecycle
• All aspects of the service and its performance
• Service achievement, SLA, OLA, contractual and supplier measurement, reporting and management
• Consolidated metrics and Metrics Trees, with views from management dashboards down to detailed component information, performance and fault analysis and identification
• Consistent and consolidated views across all processes, systems, technologies and groups
• Relationships and integration of the business and its processes with IT services, systems and processes
• A comprehensive set of search and reporting facilities, enabling accurate information and analysis for informed decision-making
• Management of service costs
• Management of relationships, interfaces and interdesendencies
• Management of the Service Portfolio and Service Catalogue
• A Configuration Management System (CMS)
• A Service Knowledge Management System (SKMS).

The following generic activities will be needed to implement such an approach:

• Establish the generic lifecycle for IT Assets (Requirements, Design and Develop, Build, Test, Deploy, Operate and Optimize, Dispose) and define the principal processes, policies, activities and technologies within each stage of the lifecycle for each type of asset
• Formalize the relationships between different types of IT asset, and the relationship between IT asset acquisition and management and other IT disciplines
• Define all roles and responsibilities involved in IT asset activities
• Establish measures for understanding the (Total) Cost of Ownership of an IT service
• Establish policies for the re-use of IT assets across services, e.g. at the corporate level
• Define a strategy for the acquisition and management of IT assets, including how it should be aligned with other IT and business strategies.

For the applications asset type, additionally:

• Define a strategy for the acquisition and management of IT assets, including how it should be aligned with other IT and business strategies
• Document the role played by applications in the delivery of IT services to the business
• Ensure the generic IT asset lifecycle model is adapted to an applications lifecycle, tailored to different application types
• Set standards for the use of different approaches to developing applications, and recognize the role of development methodologies, including those based on 're-use' (see the section on Design and Development for further discussion)
• Ensure that procedures are in place to consider all requirement types (such as operability, service performance, maintainability, security) in the early stages of application development
• Set standards for deciding on the optimal delivery of applications to the organization, such as the use of Application Service Providers, customized developments, COTS and package customization.

For the data/information asset type, additionally:

• Establish how the general principles of IT asset acquisition and management can help to manage the data/information resources of an organization.

Ensure that data designs are undertaken in the light of:

• The importance of standardized and re-usable metadata
• The need for data quality
• The value of data to an organization
• The need for data administration and database administration skills
• Understanding the 'corporate' (or common/cooperative) subject area and individual service ('system') views of data
• The need to manage data of non-traditional data types such as text, scanned images, video and audio
• Awareness of the major storage, security and legal issues for data
• Specify how the generic IT assets lifecycle model can be adapted to the data asset type.

For the IT infrastructure and environmental asset type, additionally:

• Establish standards for acquisition and management of the IT infrastructure and environmental equipment (including hardware, power, O/S software, dbms software, middleware and networks) and ensure they provide a stable yet adaptable foundation that underpins the provision of IT services to the business
• Establish how the generic IT assets lifecycle model should be adapted to a specific IT infrastructure lifecycle
• Establish activities to optimize the usage of IT infrastructure assets through their re-use
• Specify the need for tools and describe how their overall use and integration assists in the management of an effective IT infrastructure and related services.

For the skills (people, competencies), additionally:

• Formalize how the competencies of individuals responsible for the IT assets and related services can be regarded as an asset within the organization and are managed as such
• Specify how the IT asset lifecycle applies to people assets, particularly in terms of measurable competencies, such as skill, knowledge, understanding, qualifications, experience, attitude and behaviour
• Ensure the documentation of the competencies currently in place and specify how these can be reused or enhanced
• Ensure organization standards are compatible with existing standard competency frameworks for the IT sector, such as SFIA+ (Skills For The Information Age) skills and competences are incorporated into roles and responsibilities.

In addition, in order to establish effective interfaces and dependencies:

• Define the interfaces that IT asset acquisition and management has with IT-enabled Business Change, IT Project Management and IT Security
• Formalize the interfaces that IT asset acquisition and management have with functions and processes outside IT
• Finally formalize measurement and reporting in this area by:
• Identifying suitable metrics and the reports on IT assets for distribution throughout the organization as appropriate
• Formalizing quality control and measurement in the acquisition and management of IT assets.

7.2 Service Management Tools

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

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.

The tool must be adequately flexible to support your required access rights. You must be able to determine who is permitted to access what data and for what purpose, e.g. read access to customers. In the early stages, consideration must also be given to the platform on which the tool will be expected to operate - this may be on existing hardware and software or a new purchase. There may be restrictions laid down by IT strategy - for example, all new products may have to reside on specific servers. This might restrict which products could be included in the evaluation process. Make sure that the procurement fits within existing approved budgets.

There are many Service Management tools available. Details can be found on the internet, Service Management publications, from asking other organizations, from asking consultants or attending seminars and conferences to see what products are available.

During the early stages of the selection process, think about vendor and tool credibility. Are they still going to be supporting the purchase in a few months' or a year's time? Consider the past record of the supplier as well as that of the tool. Telephone the supplier's Service Desk to see how easy it is to get through, and ask some test questions to assess their technical competence. Ask the vendor to arrange a visit to a reference site to see what the experience is with the tool in practice - if possible without the vendor or supplier present. Make sure that the organization has similar requirements of the tool. See the tool in operation and speak to the users about their experiences, both initially and ongoing.

Assess the training needs of the organization and evaluate the capability of the supplier to provide the appropriate training. Also the ongoing training and tool update (upgrades and changes in user requirements) will need to be assessed to ascertain the support and training costs. In particular, consider training costs, training location, time required, how soon after training the tool will be in use, and during the implementation project ensure that sufficient training is provided - think about how the new tool will impact both IT and customer. Also ensure that interfaces with other tools and telephony are functioning correctly. It is wise to identify whether the planned combination has been used (or tried) elsewhere and with what results. Consider periods of parallel running alongside existing solutions before finally going live.

When evaluating tools, a 100% fit to requirements should not be expected and will almost certainly not be found. The '80/20 rule' should be brought into effect instead. A tool is deemed to be fit for its purpose if it meets 80% or more of the business's operational requirements. Those operational requirements should be categorized as discussed earlier.

Any product should be rejected as unsuitable if not all of the mandatory requirements ('must haves') are met. In some circumstances, it will be impossible to find an existing software product that will either meet all of the mandatory requirements or provide an 80% match. In this situation, the product offering the best functional design should be selected and the unsuitable elements re-written. This enhancement process should be done by the vendor if at all possible. In some cases, part of the enhancement costs may be met by the purchaser. Some products have been designed to include user hooks - this provides accessibility to site-written code at key procedural points, without the need for the package to be modified.

It doesn't end when the product has been selected. In many ways this could be considered as only the beginning. The tool now has to be implemented. Once the hardware platform has been prepared and the software loaded, data population needs to be considered. What, where from, how and when? Timing is important to the testing, implementation and the go-live processes. Resources must be available to ensure success. In other words, don't schedule implementation during a known busy period, such as year-end processing. Today 'software as a service' products are available where hardware and software are not required. These products give network based access to and management of commercially available software. These types of products will still require planning and implementation, but this should simplify the process as no dedicated hardware is required. Consideration should also be given to managed service providers and Application Service Providers who may be able to provide the same functionality.

Whatever tool or type of tool is chosen, the fulfillment of the requirements can be differentiated between:

• Out-of-the box - the requirement is fulfilled
• Configuration - the tool can be configured with x days of effort to fulfill the requirement and this will be preserved over product upgrades
• Customization - the tool must be reprogrammed with x days of effort to fulfill the requirement, and this may have to be repeated on every product upgrade.

Extensive customization of any product is always best avoided because of the high costs incurred at product upgrade. Vendors may be unwilling to support old releases, and purchasers may be unable to resource the necessary re-application of any bespoke customization. Customization may also release the vendor from much of their support obligations - this would be disastrous if, as a result, your Service Management system is unavailable for any length of time. Further costs would be incurred in providing the bespoke training that would be required. It would be impossible to take advantage of any cheap scheduled training courses being run by the software supplier.

Figure 7.1 Service Management tool evaluation process

The process of tool evaluation is shown in Figure 7.1. It shows the standard approach of identifying requirements before identifying products, but pragmatically there may be some element of overlap, where exploration of tools on the market opens one's eyes to new options that change the requirements. These stages are targeted primarily at the evaluation of packaged software products, but a similar approach could also be used when evaluating custom-built software. Produce a clear Statement of Requirements (SoR) that identifies the .business requirements together with the mandatory facilities and those features that it would be 'nice to have'. Also identify the site policies and standards to which the product must conform. Such standards may include it running under particular system software, or on specific hardware.

Remember the considerations about the supplier's suitability, and carry out a formal evaluation of the products under consideration.

If well-developed and appropriate tools are used to support the processes, the results achieved will be far greater and often the overall costs of service provision will be less. Selecting the right tool means paying attention to a number of issues:

• An 80% fit to all functional and technical requirements
• A meeting of ALL mandatory requirements
• Little (if any) 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
• 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.

---