In This Chapter
Seeing how service management fits into a business model
Discovering the six layers of service management
Coping with changes in the six layers
Setting the value of service management
In earlier chapters, we mention that service management is a big field that covers information technology of every conceivable kind and also involves understanding how to organize staff to manage that technology, not just to make it run, but also to make it run effectively and (ideally) in highly optimized fashion. Service management also embraces the governance of IT, best practices, the alignment of IT with the business, the integration of all the technology, and the monitoring of both business key performance indicators (KPIs) and IT KPIs.
We confess right now that this book doesn't give a detailed explanation of every service management process, underlying technology, and tactic that you can adopt to provide effective services. Luckily, that isn't the goal of this book. What we intend to do is give you an all-round appreciation of what service management is and how to deliver it successfully in the context of a living, breathing organization.
In this chapter, we present service management in overview, making the link between service management at the business level and at the IT level. We provide a way of looking at the whole service management process and also tackle the question of the value of service management within an organization.
You may wonder why we haven't yet defined precisely what falls under the heading of service management from a technology perspective, so we'll do that immediately. Consider the simple diagram in Figure 8-1. This figure depicts the fact that from an external perspective, an organization can be viewed as a collection of business services performed directly or indirectly for the benefit of customers. Within that model, from an IT perspective, many elements of the various business services involve IT business applications. Those business applications operate effectively (if they do) because of the technologies, processes, and skills that collectively make up service management.
If you consider IT from an external perspective, you can think of service management as being mainly invisible. The IT applications provide automation to various parts of the business processes that run through the organization, and they need a variety of resources to deliver their benefits. Service management monitors those applications and sometimes also monitors the business processes that they serve.
Perhaps to a businessperson, service management is mainly invisible, limited to the voice at the help desk and a relationship manager to negotiate service-level expectations and costs.
A simpler way to look at service management is to divide it into layers, as we do in the following section.
Service management is carried out with a variety of applications. Business applications consist of software and data; they run on computer hardware; and they have users. Given just those facts, you have four distinct layers to think about: software, data, hardware, and staff.
Now add the fact that all these business applications and the computers involved in running them need to be housed somewhere, either on desktop computers or in specially built data centers. That fact correlates to a foundation layer.
Finally, you need to acknowledge that in one way or another, some service management activities may be delivered as services. Some help-desk activity could be outsourced to a call center, for example, or some of the facilities provided to run applications could be delivered by a service provider. This fact gives you a sixth layer. Figure 8-2 shows all six layers.
In the following sections, we describe these layers one by one.
Most companies have one or more data centers where all shared computer resources are kept. With the current state of technology, even medium-size organizations have a clear need for data centers, because computers require specialized electrical power, physical security, atmospheric control (usually, a dramatic amount of air conditioning), and communications. A data center may also perform specialized activities, such as printing, scanning, or creating DVDs. Data center space is very expensive because of its specialized nature, and a data center can't be expanded easily and simply.
Organizations that are geographically distributed may have multiple data centers, of course, and there may even be multiple data centers just for the sake of disaster recovery. The distribution of client computers around an organization should be considered to be part of the Facilities and Data Center layer, which is all about the accommodation of computing and communications resources. Ultimately, that means that all areas accommodating network access devices, such as automated teller machines or kiosks in shops, are part of this layer.
As in all other areas of IT, an organization has to make choices about the sizes of the computers it buys and about how those computers are managed as a collective resource. Sometimes an application has to be implemented on a specific item of hardware, but usually, some flexibility is available. The direction of technology is toward greater flexibility, with the idea of an application being able to run on almost any hardware platform.
Naturally, organizations attempt to optimize their use of hardware in whatever ways possible, such as by establishing purchasing and replacement strategies. They're likely to have different strategies for data center computers, desktop computers, and the full variety of mobile devices.
Application data presents several problems apart from how it needs to be used in applications or shared among applications (which isn't the problem of service management). Primarily, data has to be located in a convenient place; secured against theft; and backed up so that it can be restored in the event of hardware or software failure and, probably, just to meet auditing/compliance requirements. This requirement naturally extends to desktop devices and mobile devices; hence, the fairly simple needs for availability, security, and recovery alone can become complex.
Application data isn't the only kind of data. A whole set of data is created and used in service management activities, such as log files, asset data, and management data of all types.
Software has the same characteristics as data in some ways because it's stored as data, so everything we note about data also applies to software. In addition, software needs to be configured for use, and management of the configuration of thousands of software components in a large network is itself a complex activity.
Also, software − whether it's application, operating-system, or management software − has a life cycle that also demands management.
All service management activities include manual elements and demand a certain level of skill from staff members. Many of these activities are structured according to experience with the task, built up over years, or implemented from best practices based on some authority. Collectively, the staff (including all its management elements) can be viewed as being the presiding intelligence of service management.
All service management activities are internal business services of one sort or another whose function is to support other business services, including − most important − those services that are provided to customers. Some of these business services can be outsourced. Indeed, some organizations have taken the rather drastic step of outsourcing the whole of their operational IT activities. Thus, in those instances, almost all service management activities have been outsourced.
The point is that you can think of service management activities (business services) as being assembled and constructed from the combination of the resources in the five layers below them (Staff/Operatives, Software/Applications, Information/Data, Computer Hardware, and Facilities and Data Center).
We present this six-layer model to draw attention to a couple of facts: Each of these layers can be considered in isolation, and various policies or broad guidelines can be created for managing each layer. More important, however, is the fact that these layers are not at all static. Everything keeps changing, which makes managing the whole ensemble difficult.
In the following sections, we discuss the layers one by one again, but this time, we discuss them from the perspective of change.
If you look back over the past 15 years, you see huge changes in the nature of the typical data center. It went from catering to tens of servers to hundreds of servers or (in some companies) thousands of servers. As the data center grew dramatically, the parameters for air conditioning and cooling changed, and so did the power requirements.
Now consider other computing devices. Laptops have replaced desktops for many people, and smartphones are replacing mobile phones to some degree. If those changes weren't enough, we're slowly moving to a world of embedded processors and radio-frequency identification (RFID) tags attached to anything that moves. Therefore, any facility or space is potentially a computing facility and connected to the corporate network in some way.
Regular dramatic changes in the capabilities of computer hardware have been the rule rather than the exception for decades now. These changes have been driven by Moore's law, which not only affects CPUs, but also confers its gifts on memory, switches, disk speeds, and just about every other component of a computer. Consequently, no fixed approach to computer and network architectures is possible. The parameters keep changing, making hardware configurations that were once impractical quite viable. All disk files used to be local to the server running the application that used them, for example. Then came file servers, storage area networks (SANs), and network attached stores (NAS). Applications that used to run on a single sever are now spread across multiple servers.
At one time, all data was structured data, held in files or databases. The advent of document management and text mining tools added less-structured data to the mix. Then came sound, images, and video. At the same time, the volume of data grew. Companies that once stored megabytes of data began to preside over gigabytes and then terabytes − and recently in some companies, data volumes have grown to the petabyte level.
Naturally, the growth in computer power has been accompanied by a growth in the number of useful applications that businesses can exploit. The advent of the Internet connected most of the computers in the world and subsequently delivered new ways of carrying out many business activities, from buying airline tickets to disposing of unwanted inventory. The Internet has continued to ramp up the speed of change in terms of new applications, and change will only get faster as smartphones displace less-sophisticated mobile phones.
This situation has unwelcome aspects, particularly in the area of IT security, where investment in software is necessary for self-protection. To add to the complexity, all software − whether it's infrastructure or application software − goes through regular revisions and enhancements, so nearly all the software that an organization runs changes over time. These changes make managing the Software/Applications layer very difficult, because incompatibilities and errors need to be prevented at all costs.
As the technology continually changes in every layer, the skills required for understanding how systems function also change. This situation can cut both ways. The complexity of operating and managing technology sometimes increases and sometimes diminishes. As a result, the people who are in charge of managing a complex network of computers need to be retrained regularly, and they need to be familiar with technology developments in the industry.
The service levels that customers or IT users expect from business services evolve all the time. A company in a particularly competitive market may decide to improve its level of service dramatically so that no competitor can match its performance, for example. In general, however, as technology sophistication improves, customer expectations of service grow, and as customer expectations expand, IT has no choice but to meet rising expectations.
This situation is precisely what happened when e-mail became an increasingly important corporate service. At one time, e-mail users − including employees, customers, and partners − may have been satisfied with 99 percent availability. That level of availability, however, meant that the e-mail service would be unavailable 3.65 days a year, which would translate into 15 minutes of downtime every day. We don't know many companies that would put up with that performance level now that e-mail has become part of the business fabric. Such changes in service demand are difficult to predict and can't be met without investments of one sort or another.
How do you decide on the value of service management? This question is such a good one that we're not sure why we haven't mentioned it before. Unfortunately, it's not an easy one to answer. We're going to take a stab at answering it, though, because chapter after chapter of this book discusses the benefits of service management. Service management isn't free . . . or cheap. So unless you have an infinite budget − and we suspect that you don't − examining the value of service management is important.
So far in this chapter, we've discussed service management in terms of layers. Keeping these layers in mind, we turn now to looking at service management in terms of costs. We consider costs in the following areas:
Support
Optimization
Risk
Change
These different strands of service management deliver benefits in distinctly different areas, and we discuss them separately in the following sections.
Just for fun, we'll start by getting all mathematical and proposing an equation, which we'll call Equation A:
App cost = Cost of app resource + cost of SM resource
This equation shouldn't scare you, because it's very simple. Just think of any business application; its cost consists of all the resources it uses directly plus all the management support it requires (service management, represented in the equation as SM). Look at it this way: You could buy the application and all the resources it needs to run, including operators (if any), and then you could just run it.
If you did that without considering the service management component, however, the service that the application provided would degrade quickly. Various hardware, software, and even user errors would occur over time, and someone would need to handle those errors to keep the application healthy. Support costs are inevitable for all applications, and service management processes deliver the support.
Support cost is what an organization pays to deliver the acceptable service level for a particular application over a targeted life span, and that service level is determined by the organization's demands. If you look at service management this way, you also need to distinguish between the operational personnel who run the applications and the support personnel who manage the service.
Here, we introduce another equation, Equation B:
Total facility costs = σ Cost of app resource + σ cost of SM resource −σ SM savings
This equation also is quite simple. It suggests that the costs of the whole IT facility are equivalent to the sum of the costs of all applications and the costs of SM activities minus (excluding) the amount of savings that the SM activities achieve.
For each of the six layers we describe in this chapter (refer to "Understanding the Six Layers of Service Management," earlier in this chapter), you can achieve economies of scale simply by managing the entire layer as a single entity. You can manage the Facilities and Data Center layer as a single entity, the Computer Hardware layer as a single entity, the Information/Data layer as a single entity, and so on. This practice has many aspects. Negotiating intelligent contracts with hardware and software vendors can reduce unit costs; virtualization strategies may reduce the square footage required in the data center; and common data backup procedures may reduce the cost of backup and recovery. All such activities fall into one layer or another.
Equation B, therefore, states that you can use service management technology and processes to optimize many aspects of the IT operation, and when you do so successfully, you bring down the costs.
Suppose that your organization has a service level of 99.95 percent availability. What does a service level of 99.95 percent availability actually mean? No doubt it means that the IT department will do what it can to ensure that an application is available almost all the time, to the extent that it is unavailable for four hours or so every year.
That availability level is only a target, however. In reality, ensuring such a high level of availability is very difficult, and you have no hard-and-fast way to ensure meeting such a target. All you can do is ensure the probability of meeting the target.
Think in terms only of simple failures, and you realize that this statement must be true. An application may fail because of hardware or network failure, and although you can put a great deal of redundancy into the computer architecture to make failure unlikely, making failure impossible would be very expensive. To complicate this example beyond simple failure, consider the possibility of operating-system errors, errors in other fundamental software, or bugs in the application itself. You can also include mistakes made by staff members, and just for good measure, you can add unavailability due to security breaches, which have been known to bring down whole networks.
When you look at this situation this way, you realize that you have no simple way to ensure any specific level of availability. All you can do is manage the risk that the system will become unavailable.
When an application does become unavailable, a definite cost is involved, and this cost can have three elements:
Lost business: This cost is the direct cost of sales that never happened because of the system's unavailability.
Brand damage: This cost is the drop in customer confidence caused by the service failure.
Repairs: This cost can be small or perhaps even nonexistent, but in the case of a security breach, it can be very high indeed.
This situation presents quite a conundrum, because you can always sink more money into various areas of IT to deliver better service levels. Also, to a certain degree, service levels are points of competition. Underinvestment in high service levels may lead to loss of business, whereas overinvestment surely leads to unnecessarily high costs. We can produce a mathematical formula, Equation C, to express the situation:
SM cost = Probability ×(Cost of lost business + cost brand damage + cost of repair)
The point is that it's unwise to invest any more in service management than is necessary to improve service levels or justified by the cost of failures. In other words, you shouldn't invest any more than customer expectations require.
The obvious exception occurs when a company deliberately raises its service level as a competitive move. In this situation, the expense is related to a business decision − not a technical decision − and in the end, that business decision may be the secret to a great service management strategy.
Finally, we come to investment in service management that is implemented specifically to manage change. The problem with the factor of change in IT is that change comes in two flavors:
Predictable
Disruptive
Under the heading of predictable change come all the factors that can be measured and tracked: the cost of computer hardware, the cost of software, the growth of data, the number of users, the number of customers accessing systems, the variety of transactions being supported, and so on. The growth of these factors can be predicted with reasonable accuracy over time. Then this growth can be combined with corporate plans for new products and services to determine future investments in service management and new IT applications.
The more difficult problem is disruptive change. By definition, disruptive change is unpredictable, and it can demand unexpectedly high levels of investment simply because a business has no easy way to prepare for it. Legislative change, such as that imposed by the Sarbanes-Oxley Act of 2002 in the United States, can be disruptive. Exploding security problems are an example of disruptive change in the technology world. Sudden economic changes, from currency swings to stock-market crashes, also can be highly disruptive. The best preparation for dealing with disruptive change is having a service management system that is coherent and flexible.
If you've been following this discussion closely, you probably wonder what we mean by a service management system. That's the topic of the next chapter.