Stability versus responsiveness

No matter how good the functionality is of an IT service and no matter how well it has been designed, it will be worth far less if the service component s are not available or if they perform inconsistently.

This means that Service Operation needs to ensure that the IT Infrastructure is stable and available as designed. At the same time, Service Operation needs to recognize that business and IT requirement s change.

Some of these changes are evolutionary. For example, the functionality, performance and architecture of a platform may change over a number of years. Each change brings with it an opportunity to provide better levels of service to the business. In evolutionary changes, it is possible to plan how to respond to the change and thus maintain stability while responding to the changes.

Many changes, though, happen very quickly and sometimes under extreme pressure. For example, a Business Unit unexpectedly wins a contract that requires additional IT services, more capacity and faster response time s. The ability to respond to this type of change without impacting other services is a significant challenge.

Many IT organizations are unable to achieve this balance and tend to focus on either the stability of the IT Infrastructure or the ability to respond to changes quickly.

Figure 3.2 Achieving a balance between focus on stability and responsiveness

Table 3.2 outlines some examples of the characteristics of positions at extreme ends of the spectrum. The purpose of this table is to assist organizations in identifying to which extreme they are closer, not to identify real-life positions to which organizations should aspire.

	Extreme focus on stability	Extreme focus on responsiveness
Primary focus	Technology Developing and refining standard IT management techniques and process es.	Output to the business Agrees to required changes before determining what it will take to deliver them.
Typical problem s experienced	IT can demonstrate that it is complying with SOPs and Operational Level Agreement s (OLAs), even when there is clear misalignment to business requirement s	IT staff are not available to define or execute routine tasks because they are busy on project s for new services
Technology growth strategy	Growth strategy based on analysing existing demand on existing system s New services are resisted and Business Unit s sometimes take ownership of ‘ their own’ systems to get access to new services.	Technology purchased for each new business requirement Using multiple technologies and solutions for similar solutions, to meet slightly different business needs.
Technology used to deliver IT service s	Existing or standard technology to be used; services must be adjusted to work within existing parameters	Over-provisioning. No attempt is made to model the new service on the existing infrastructure. New, dedicated technology is purchased for each new project
Capacity Management	Forecasts based on projections of current workload s System performance is maintained at consistent levels through tuning and demand management, not by workload forecasting and management.	Forecasts based on future business activity for each service individually and do not take into account IT activity or other IT services Existing workloads not relevant.

Table 3.2 Examples of extreme focus on stability and responsiveness

Building an IT organization that achieves a balance between stability and responsiveness in Service Operation will require the following actions:

• Ensure investment in technologies and processes that are adaptive rather than rigid, e.g. virtual server and application technology and the use of Change Model s (see Service Transition publication).
• Build a strong Service Level Management (SLM) process which is active from the Service Design phase to the Continual Service Improvement phase of the ITSM Lifecycle.
• Foster integration between SLM and the other Service Design processes to ensure proper mapping of business requirements to IT operational activities and component s of the IT Infrastructure. This makes it easier to model the effect of changes and improvements.
• Initiate changes at the earliest appropriate stage in the ITSM Lifecycle. This will ensure that both functional (business) and manageability (IT operational) requirement s can be assessed and built or changed together.
• Ensure IT involvement in business changes as early as possible in the change process to ensure scalability, consistency and achievability of IT service s sustaining business changes.
• Service Operation teams should provide input into the ongoing design and refinement of the architecture s and IT services (see Service Design and Service Strategy publications).
• Implement and use SLM to avoid situations where business and IT managers and staff negotiate informal agreement s.

Дата добавления: 2014-12-23