The shadow cast by the service-management umbrella is broad, extending into the organization of the enterprise as well as IT. Service management practices can also guide the design and operation of enterprise clouds. This chapter introduces service management and the Information Technology Infrastructure Library (ITIL). A basic understanding of the goals of service management and ITIL is useful in building cloud-application architectures because many businesses have adopted ITIL practices and expect IT to support these practices. Most ITIL discussions and publications are about strategies for adopting ITIL practices in an enterprise and the effect of the practices on the organization. Service management adoption requires management buy-in training programs, and the enterprise organization may often be restructured. This is a big and difficult job, and the discussion in this chapter is about designing cloud architectures that support a service management approach to IT. The executives, managers and architects who implement the technology behind IT that is managed as a service have to understand service management practices, but they have a different set of questions and needs than the typical ITIL practitioner who guides an organization through the process of adopting service management practices. This chapter also discusses the service management strategic planning phase in detail. Chapters 6 and 7 will discuss service design, implementation, and operation.

Importance of IT Service Management

Other than a few paper reports, which are rapidly disappearing, IT has few direct physical outputs and the final products of IT services are seldom tangible. Unlike a factory, IT does not provide its consumers with goods. Instead, IT, for the most part, performs services for its consumers. Unfortunately, the fact that IT exists to provide services is sometimes forgotten. Traditionally, IT has required considerable physical assets. Management and IT practitioners are both occasionally overwhelmed with the wealth of expensive computers and other devices in the care of the IT department. When this is the case, the enterprise may start to think of IT as a sort of steward for the IT infrastructure instead of the service provider that it genuinely is. This illusion can be detrimental to the IT department.

In the days when a single computer required a specially designed floor, an expensive cooling system, and cost millions of dollars, it was easy to think that the investment was an end in itself; that keeping up with the latest innovations in computing was paramount. The enterprise assumed that valuable services would inevitably follow.

Experience shows that this was and still is a shaky assumption. Without concerted effort, value-generating services do not just pop up. In a few cases, a service may be developed without heed to its value and turn out to have great value, but many more failures can be ascribed to lack of consideration of the value of services that are developed.

IT departments that continue to be hardware stewards instead of service providers eventually suffer. The speed of IT advancement causes computing equipment to become obsolete quickly. Desktop computers, for example, are often replaced in a year or two, not because they are no longer functional but because their replacements have so much more functionality. In contrast, factory equipment may retain value for decades. To compensate for the rapid decrease in computing equipment value, the return on an investment in IT infrastructure must be rapid and large if it is to compare favorably to other enterprise investments. Consequently, when management takes a hard financial look at IT, it has often been disappointed and resolves to put IT under tighter fiscal control.

For the most part, the IT fairy tale days are over. Executive management measures IT departments on their contribution to favorable business outcomes. Unless they can be shown to contribute in proportion to their size, the large investment in IT infrastructure is a burden, not an asset.

Business alignment has risen in importance, but the complexity and breadth of the IT infrastructure has also increased steadily. IT services have also become more mission critical. For example, increased Internet merchandizing and dependence on online financial transactions have increased the dependence of business on the smooth functioning of IT.

As the infrastructure has grown in size, complexity, and importance, business alignment has become more critical and significantly more difficult. Instead of supporting a few back-end accounting and inventory services that are hidden from customers, IT now provides hundreds of services that still depend on the traditional back-end services, but also include a wide range of customer-facing services. Businesses provide customer support through social media, field mobile apps, and stream video—to name a few of the diverse services that appear on the IT agenda. The list goes on and on with new services appearing all the time.

Each of these services must be properly provisioned to operate appropriately and align with business. This is both a technical and business challenge. All these services must be coordinated into a coherent business plan that will meet enterprise goals such as growth and profitability. The services must be technically reliable and attain required service levels while keeping within financial constraints on infrastructure investment. In order to do this, the services have to fit within an IT technical architecture that provides an agile and extensible platform and makes the best use of the IT investment.

This is a challenge. IT service management is an important approach to meeting the challenge.

What Is Service Management?

IT must pay attention to the services it provides, but the processes required to enable IT to drive solid business services are not simple. Without an adequate process, IT often gets a list of business requirements that it does not understand and bears little relation to what the IT department needs to know in order to build or modify a service. Worse, the requirements may not take into account existing IT resources or advances in technology that would provide an excellent return on the investment.

IT service management (ITSM) is a special form of service management that aims to increase cooperation between IT and all the elements of an enterprise to further enterprise goals. Often those goals are increased revenues and decreased costs, although some enterprises, such as government agencies or nonprofit organizations, will have other goals. The service management process assures that the goals are directly or indirectly represented in every action taken in the IT department and that every investment is optimized for accomplishment of these goals. Business alignment is a state where actions and investments are all tuned to provide maximum support for enterprise goals.

Value of a Service

ITIL provides some conceptual tools for understanding the value of a service. Two of these are warranty and utility. These concepts are useful for analyzing what makes a service successful.

Utility of a service

The utility of a service refers to what it does. If you recall, the ITIL definition of a service suggests that it is a means for delivering desired business outcomes to a consumer that transfer some of the cost and risk of delivery from the consumer to the provider of the service. The utility of the service is the business outcomes that the consumer gets from the service. Put more succinctly, the utility of a service is what the service does.

A service that does what the consumer expects is described as “fit for purpose.” This is another way of saying that the utility of the service provides the functionality the consumer wants.

Warranty of a Service

Utility is only one aspect of the value of a service. The other aspect is warranty, which is related to risk. Warranty is the fitness of the service for use by the consumer. A service that does the right thing but is not available when the consumer needs it is fit for purpose (its utility is adequate) but not fit for use (its warranty is inadequate).

For a service to be suitable for a consumer, it must be both fit for purpose and use. On the technical side, it is easy to obsess over utility and slight warranty. This is a dangerous mistake. Services that are not fit for use are not acceptable to the consumer. When a service unfit for use is delivered to a consumer, the results can be very bad. The developers usually feel blindsided—they did their work. The service does what it is supposed to, but the consumers feel betrayed—they are tantalized by the service functionality they want, but it is unusable. Learning to pay as much attention to warranty as utility is perhaps the most important lesson a developer can learn from service management.

Much of the entire process of service management is devoted to making clear both the utility and warranty of a service. There are many practices devoted to making the warranty of a service clear and ensuring that the warranty is met.

Perhaps the most prominent of these are service-level agreements (SLAs). SLAs are contracts between the consumer and provider. They contain specific, measureable levels of service that must be met by the provider, and obligations the consumer has to the provider. In addition, they may contain incentives and penalties. Well-written SLAs are characterized by the mnemonic acronym SMART—specific, measureable, achievable, relevant, and time bound.

Service Standards

Service management is a way of approaching IT management that has changed the way IT is developed and delivered. Service management in IT is hard to separate from ITIL because ITIL was an early advocate of service management of IT and has received wide acceptance in IT circles. ITIL is also notable for its extensive certifications and training programs. ITIL calls itself a collection of best practices rather than a standard. For an army of service management experts and consultants, however, the ITIL collection of books is the authority for the practices under the service management umbrella.

ITIL is not the only source of service management practice. The ISO/IEC 20000 standard covers most of the same practices as ITIL. The Microsoft Operations Framework (MOF) is closely related to ITIL. The TM Forum, formerly the TeleManagement Forum (TMF) publishes Frameworx, which is management guidance for communications service providers. Frameworx is directed toward communications networks rather than IT, but it touches on many of the same topics as ITIL. There are also other frameworks for quality improvement that apply to IT service management such as Six Sigma, Total Quality Management (TQM), Capability Maturity Model (CMM), and others. However, ITIL dominates the IT service management world; and most of these frameworks have a mapping to ITIL.

Service Management Pitfalls

Few will argue that service management as a concept is faulty, but, in practice, ITIL and service management can be frustrating.

Implementation of ITIL practices is as much about business organization and management as it is about technology. It affects the way IT service requirements are gathered and how services are deployed and supported, but it affects even more the way the people and processes in an enterprise work together. Unfortunately, this strength can easily turn into a weakness. Service management promotes wholehearted cooperation between the business and the technical aspects of an enterprise. But in order for this to happen, both business and IT must endorse the service management discipline and be fully engaged in the service management process. If either side holds back, the effort becomes an exercise in seeking sound from a single hand clapping—it won’t work.

Consequently, implementation of service management practices seldom succeeds as a grassroots movement. Success requires spontaneous cooperation and commitment from departments that often have trouble speaking the same language. Service management practices are likely to do the most good where the IT department and business units are downright antagonistic, which is also the situation where implementing service management practices is most difficult. The quickest and surest way to implement service management practices is for upper management to fully commit to service management principles and be willing to take long-term decisive action.

It is important that the participants commit for more than a single quarter or year. Implementing these practices changes basic patterns of thought and organization. This takes time and can generate opposition. Breaking down resistance is not easy. There is always a chorus waiting to declare the new processes a failure and fall back into the old ways. Without long-term commitment, service management practices are likely to be dismissed as another faddish initiative that will disappear as quickly as the morning dew.

Executive commitment has its own perils. The entire set of service management practices exemplified by ITIL is intricate and all-encompassing. Establishing even a modest practice can be a big and difficult job. A service management implementation requires strong executive backing to overcome organizational inertia toward change. But strong executive backing can also mean that service management becomes a high-stakes initiative with heavy incentives for quick adoption. This can encourage early superficial practice adoption that offers few real benefits to the enterprise.

ITIL training is almost an industry itself, with a hierarchy of degrees culminating in the ITIL Master certificate. Swarms of consultants with PowerPoint slides and training materials are ready and able to help an enterprise manage services in the ITIL way. These classes and consultant services are all valuable, but there is a hidden risk: ITIL and all its trappings sometimes threaten to become ends in themselves. When an organization begins to score itself on the quality of its ITIL implementation rather than the quality of its business outcomes, it runs great risks.

An implementation of any quality framework, especially a complex framework like ITIL, can earn high scores for conformance to recommended practices without ever addressing business or technical goals. Awards get passed out, but, without addressing the issues, favorable business results do not appear and the bottom line does not change. When the bottom line does not change, other, almost always less palatable, changes are sure to come. This is especially ominous when the framework has been oversold to executive management.

ITIL History

In 1957, a British government agency, the Central Computer and Telecommunications Agency (CCTA), was established to advise the British government on the adoption of computing. In the 1980s, the CCTA began to develop a series of books on IT practices as guidance for various offices and agencies in order to promote consistency in implementing IT. These books became the original ITIL library of ten core books, covering service support and delivery. Other books were added on subjects like cabling and business continuity management. These books were issued in the late 1980s and early 1990s. The official government publisher for the UK, the Stationary Office (TSO), published the original ITIL library and all the later editions of ITIL.

Since the original collection of books, there have been three major releases of ITIL. In 2000, the second version, ITIL, volume 2, was released. ITIL, volume 2, consolidated the sprawling ITIL books into two core areas: service support and service delivery. In 2007, a third version, ITIL, volume 3, was released. ITIL, volume 3, is in five books, four devoted to stages in the ITIL service cycle and a fifth on continual service improvement. In 2011, a revision to ITIL, volume 3, was released, which made some additions and corrections to the 2007 release, but left the five-book structure intact.

Statistical Quality Control

Even though ITIL is the predominant set of practices for IT service management, service management was and is a wider movement than ITIL. Service management practices were developed in service industries such as banking, airlines, and insurance, where customer-centered services are critical. Service management is also related to the statistical quality control movement, formulated by thinkers such as W. Edward Deming and Walter Shewhart.

During World War II, statistical quality control was used in the war effort with good results. Walter Shewhart was a physicist and mathematician who is often called the inventor of statistical quality control. When he was an engineer at Bell Labs, Shewhart was assigned to improving the quality of telecommunications equipment—especially buried equipment that was hard to repair or replace.

Common- and Special-Cause Variation

Shewhart noticed that variations in part quality could be statistically divided into common-cause variation and special-cause variation.

Common-cause variation is variation attributed to randomness and the limits of the manufacturing process. For example, a milling tool may be designed to machine parts to within two-tenths of an inch of a target length. Any length that varies less than two-tenths of an inch from the target is due to the design of the machine. The variations from the target length that stem from the milling tool design are common-cause variations.

Special-cause variation is not caused by the limitations of the process and has an assignable cause. Suppose milling waste was allowed to build up and began to cause variations in addition to the common-cause variations inherent in the process. These variations could be eliminated by clearing away the accumulated waste. These are special-cause variations.

Common-cause variation cannot be reduced without fundamentally changing the process; special-cause variation can be reduced by identifying the cause and eliminating it. A frequent error is to mistake common-cause variation for special-cause variation. Because common-cause variation comes from randomness in the process itself, common-cause variations can only be reduced by reducing randomness, which can only be done by changing the process. Trying to eliminate common-cause variation by assigning it to a special cause is likely to disrupt the process and decrease quality rather than improve it. For example, adjusting a machine that is functioning within statistical limits is likely to put the machine out of adjustment rather than improve its performance.

Using statistical analysis, quality engineers can identify special-cause variations that can be eliminated. Suppose in our milling example, a goal of one-tenth-inch accuracy had been set, and at a point in the production process the length piece was checked and those that are out of standard were rejected. Assuming a normal distribution, even though the cutting machine is only designed for two-tenths-inch accuracy, most of the pieces will fall within the one-tenth-of-an-inch standard, but there will be some outside the standard. When milling waste builds up, more pieces will be off-standard, and when the waste is swept away, fewer pieces will be off-standard. By statistically examining the occurrence of off-standard pieces, the quality engineers can find the special-cause variations like the buildup of waste and work to eliminate the special causes. In this example, sweeping away the waste more often would eliminate the special cause and improve quality. At the same time, the engineers would discover the level of common-cause variation and be able to look to changing the process by switching to equipment with more precise tolerances. This is the basic principle of statistical quality control.

Although it may not be immediately apparent, statistical quality control has been influential in the development of service management. Statistical quality control places the process above the product. Instead of relying on inspection of the end product to identify quality issues, statistical quality control examines the production process. Following traditional quality control methods, when quality must increase, inspections increase in rigor and more parts are rejected or sent back for reworking. Statistical quality control starts by determining the statistical limits of the process and then identifying and eliminating the special causes of variation. Then, there may be a move to improve the process itself to further eliminate undesired variations. This is a continuing activity that may continue through the life of the process as special causes and new quality goals are set. This is also the continual cycle that service management imposes on IT services.

The Deming Cycle

Shewhart, and his later student and colleague W. Edwards Deming characterized the process of continual improvement by statistical quality control in what has come to be called the Shewhart Cycle or the Deming Cycle. Deming gave credit to Shewhart for the cycle, but it is more frequently called the Deming Cycle because Deming popularized it.

The cycle consists of four stages that repeat in a continual cycle. The steps are “plan—do–check–act” (Figure 3-2). In the plan stage, the production process is strategically defined and the expected results are decided upon, constraints identified, and goals set. During the next stage, the do stage, the process is implemented and goods, services, or whatever its output may be begin to be delivered.

The third stage, check, Deming preferred to call “study” because the word check implies that the results are checked against standards set in the planning phase. Some checking against standards is often done in the checking stage, but the point is to examine the working process carefully and consider all aspects of its operation and output. Statistical methods of distinguishing common and special causes of variation are often important in this stage.

Studying the working process carefully and systematically is at the heart of Deming’s approach to quality. In the checking stage, the impact of the process on the entire production line and enterprise is under scrutiny. This may involve questioning the effects of the scrutinized process on steps that occur later in the overall process and the effects on customer satisfaction.

The fourth stage is act. This stage takes the conclusions of the previous stage and adjusts the process to align with the original plan and other conclusions of the check stage. Special-cause variations may be eliminated and the limitations of common-cause variations are studied and understood.

The act stage is followed by another cycle of planning, implementation, study, and adjustment. The cycle does not end, but it may quiesce when a process reaches mature stability.

Continual Improvement and the Birth of ITIL

This methodology of continual improvement¹ is carried through in service management. Most business and IT services do not lend themselves easily to the control charts² and the quantitative methods of statistical quality control. Nonetheless, the emphasis on improving process rather than imposing ever-more-rigorous inspections on the end product, and the practice of identifying special causes and eliminating them apply to service management as well as manufacturing.

The software version of emphasizing process over product puts less emphasis on more rigorous quality assurance and more emphasis on identifying special causes in the development that generate defects. It also advocates improving the development process itself to reduce random-variation defects. A developer in need of additional training is an example of a special cause. Adoption of methodologies such as Agile and DevOps are intended to reduce defects that stem from the process itself. They do not add new tests to identity more product for recoding. Instead, they fix process that generated the defects.

Deming led the way in promoting quality as the key to making enterprises more cost-effective and efficient. Deming’s reputation was made in his work with Japanese industries as they recovered from their defeat in World War II. Deming applied Shewhart’s approach to statistical quality control to Japanese industries. He also emphasized that effective application of statistical quality control requires changes in management of production as well as changes in production itself.

Deming convinced Japanese industrialists to apply statistical quality-control principles to Japanese industry with striking results. The Japanese made strides in quality that would lead the world. The ascendance of Japanese automobile manufacturers in the 1980s and ’90s can be traced directly to Deming’s work with the Japanese auto industry. Other countries had to struggle to match Japanese quality and innovations, and statistical quality control became well established.

Toyota was among the Japanese enterprises that were influenced by Deming. Toyota developed its own system known as either lean manufacturing or the Toyota Production System (TPS). TPS emphasizes avoidance of waste, which it characterizes as anything that does not benefit the customer. It also assigns importance to avoiding disruptions in the production process.

The ITIL authors were working in the 1980s in a milieu saturated with Deming, statistical quality control, and systems such as TPS. The practices described in ITIL, volume 1, were profoundly influenced by this ferment, and the influence continues through the current release of the library.

Interest in and analyses of the production process in addition to its output was an important consequence of statistical quality control. In the old style of quality control, defective products got attention, but the causes of the defect were only loosely analyzed. The basic remedy for low quality was more rejection and reworking. If a reason could be found for the rejection, the reason was corrected, but there was no mechanism for examining the process.

Service management brings the same emphasis on process to the management of IT services. Instead of focusing on elimination of bad outcomes after they occur, ITIL strives for a system that avoids bad outcomes from the beginning and has a systematic method for correcting conditions that lead to bad outcomes.

ITIL divides the IT service management process into the following four phases, which correspond to the four stages of the Deming Cycle:

• Service strategy: corresponds to the plan stage
• Service design: corresponds to the do stage
• Service transition: corresponds to the check stage
• Service operation: corresponds to the act stage

The four phases do not necessarily occur in chronological order, although each phase provides input to the next phase. Unless a service is created tabula rasa, all of the phases are likely to occur at the same time. Management may strategize new roles for a service in operation while enhancements are designed and other fixes are in transition. Nevertheless, each phase has its own inputs and outputs and all contribute to the overall improvement and success of the service.

In this chapter, we concentrate on service strategy and service design.

Service Strategy

Service strategy is the first phase in the development of a new service. The documents and guidance produced in the service strategy phase continue to play a role though the entire life of the service. Business strategy is the driver for service strategy. The service strategy team must be aware of the long- and short-term goals of the enterprise and recognize the role of IT services in meeting these goals. The service strategy determines requirements for new services and scrutinizes existing services for modifications needed to meet changing enterprise directions. In this stage, business requirements are the primary concern. Technology helps define the limits of possible implementations and suggests directions opened by new or unfamiliar technologies.

Methodology

Senior enterprise management is usually represented on the service strategy team. The team identifies and prioritizes the importance of existing and future services. The team is responsible for gathering business requirements and identifying the enterprise resources that might be used in implementing requirements.

An example of a strategic business requirement is a directive that a financial organization must reduce dependence on a particular outside customer credit rating service. Exactly how the dependency must be reduced would probably not be part of the directive. One solution might be development of a complete independent in-house credit rating service. A more moderate solution might reduce dependence on the undesirable external service by combining the results of several services. A yet-more-moderate solution might be to continue using the outside service but supplement the outside information with the enterprise’s own account, sales, and demographic records on the customer.

The strategy team would explore these solutions, comparing them to the original directive and other business requirements. There may be conflicting business requirements. For instance, a long-term contract with an outside service may increase costs if usage drops. The strategy team would have to sort out possible conflicts with the overall directive, resolve them, and properly prioritize the requirements.

The team also examines existing resources that may be available. For example, the team might determine if the enterprise has easily accessible records and data to supplement external credit assessments. Financial resources might be among the resources examined and IT financial management could be brought into the discussion.

The team also investigates the enterprise-level constraints on the service. For example, a Sarbanes-Oxley regulation may require audit controls on some aspect of a new service. The service strategy team is expected to identify this constraint and point it out to the service designers.

The strategy team also examines the impact of services or customers. Although the team may leave to the design team the exact metrics and service levels for customer and user satisfaction, they look at and document the critical factors that affect customers and users.³

The determinations of the strategy team take the form of a set of documents that are associated with the service. These documents are the foundation for the next phase in the service management cycle, design. They also are the basis for the checking phase of the cycle. The key activity at the check phase compares the operational service to the requirements and constraints laid out in the strategy phase.

IT technologists can make important contributions to the strategy phase. Although technology does not have a leading role, technologists can often add much-needed information on the resources already available in the IT infrastructure that may not be apparent to business strategists. They may also be able to suggest strategies enabled by new technologies or extensions of existing technologies that are unfamiliar to the business side. They also often have a better understanding of the costs of implementation than those more distant from the IT operations.

Engineering, on the other hand, also has much to learn from strategy discussions. By being aware of the service strategy, engineering is better prepared to make decisions that have implications for the ease and expense of expanding or contracting the infrastructure in strategic directions. Tactics should always align with strategy. With an understanding of strategic motivations and direction, technologists can make informed tactical decisions that support both short- and long-term strategy. Sometimes this might involve a decision such as implementing on a public cloud instead of a private cloud. Other times, it might be a decision to expand an existing network switch or purchase a new switch with capacity for the future. These may be tactical decisions to address an immediate and limited need, but they have strategic implications and should align with strategy.

Service Portfolio

The most important tool for service strategy is the service portfolio. The portfolio can be paper, but it usually is an electronic document or document management system. The portfolio is used to manage services from inception to retirement.

A service portfolio is not the same as a service catalog. As ITIL uses the term service catalog, it is a document for current or potential service consumers. The catalog lists all the services currently available and serves as a sort of menu that consumers can use to choose services for subscription. It contains a description of what the service does and how it is used, how it is billed, and the service-level agreements that are in place.⁴

Unlike the service catalog that contains information that is useful for operations, the service portfolio contains all the information needed to manage the full-service life cycle. The portfolio contains services that are operational, but it also contains services in various stages of planning and design that may never become operational. In addition, it contains services that were once operational but are now retired. Thus, the service catalog only contains a subset of the services in the service portfolio.

The service portfolio also contains information that a service catalog does not have. One of the critical functions of service strategy is to charter services. The charter bears some similarity to the description of services in the service catalog, but it has a different emphasis and often is not suitable to present to service consumers. The portfolio contains all the information the strategy team has collected on each service.

Service charters are an important part of the service portfolio. The charter is the main input to the service design team. It contains the scope, requirements, and directions from which the service design is developed, but it is not the design itself. For example, the charter for a customer purchase tracking system used for sales lead generation might designate the types of sources for the tracking system, the governance for access and privacy, and how frequently the system must be updated. However, designating the format or contents of specific data elements would be inappropriate unless the elements were strategically significant.

More detailed implementation characteristics are specified in the next phase of the cycle: service design. Some products of this phase also go into the service portfolio. After the design phase is completed and service begins transition to operation, a description of the service is usually compiled for the service catalog. The catalog description will go into the service portfolio because it is important information about the service and useful for managing the service life cycle. However, as a consumer document, the catalog will probably contain a selective condensation of the design documents contained in the portfolio.

Service retirement plans will probably not be included in the service catalog although retirement is important in the service portfolio. Strategic service retirement planning is concerned with issues like the criteria for a decision to retire a service and the business implications for retirement. Although retirement plans may not be made at the inception of the service, eventually they will be needed and should be included in the service portfolio when they are created.

The strategy team uses the service portfolio as a compendium of information for managing the service. In addition to the information previously mentioned, the service portfolio usually contains an analysis of the alignment of the service’s capacity and the enterprise’s demand for the service along with the documents used to assess and manage the risks involved with the service. All this is input to make strategic decisions for the implementation and operation of the service.

The key functions of the service strategy team are to approve the final charter and authorize entry into the design phase. However, the responsibilities of the strategy team do not end there. The service management Deming Cycle is not a waterfall methodology. It is closer to agile development. Agile development progresses by completing a part of the project and delivering the part to users. The results of the first delivery influences the requirements and design of the next delivery. This process is repeated until the project requirements are met. A little strategy, some design, and maybe a step forward to transition—but just as likely, to design—may reveal a need for more strategy and transition may show up strategic or design flaws. The Deming wheel can spin very fast. The phases work together, each contributing, and always keeping, to the basic principle that results are checked and fed back into the cycle.

Financial Management of IT

The ITIL service strategy also includes the financial management of IT. Financial management, including IT financial management, is a complex and specialized subject that requires experts. However, enterprise IT architects and IT professionals need to understand some of the problems in financially managing IT. Only a few high points are touched on here.

Financial data goes into the service portfolio and is included in many IT service decisions. The goal of financial management of IT is to assess and manage the cost of IT service delivery in a way that makes costs, values, and investments clear and unambiguous. IT financial management is the basis for guiding prudent enterprise investment in IT. This job is not as easy as it may appear.

IT is highly abstract and not as readily financially analyzed as other aspects of the enterprise. The products of a production line can be counted and measured relatively easily, but services are not so easily measured. The value of a service is often dependent on the satisfaction of the consumer. Consumer satisfaction measured through an IT business-reporting service depends on easily measured variables like the number of data elements in the report and the timeliness and reliability of report delivery, but its value also depends on intangibles such as the aptness of the data in the report and the ease of drawing significant conclusions from the report presentation. The intangibles are not so easily measured and consumers may not agree on the value of the service.

The investment in IT services may also be confusing. IT involves several different types of costs. Some are capital costs, like investment in a facility whose value continues over time and appears on the balance sheet as an asset. Capital costs are distinguished from operational costs, which do not accumulate value over time or appear as assets. Payroll, for example, is an operational expense. Some costs are traceable directly to users of IT services, such as payroll for subject matter experts whose time can be billed to the service transactions they handle. Other costs are indirect—that is, not directly attributable to a given consumer transaction—but nonetheless are a necessary cost of a service. Payroll for network engineers whose work contributes to many services is an indirect cost because it cannot be allocated directly to consumer transactions. Yet other costs are fixed, such as most capital costs, and do not change in proportion to usage of services.

Most of the time, charges that vary in proportion to usage are desirable. IT service consumers want to pay only for what they use and expect to pay less when they use less. But a mixture of capital costs and direct, indirect, and fixed costs can make usage-based charges difficult to ascertain. The cost of a service is often only partially related to the usage of the service. For example, if a service requires four servers of a given capacity in order to be available, the hardware cost remains the same when the service has one user and when it has a thousand. Some costs like electricity and cooling may increase slightly for a thousand users, but for the most part, this increase is negligible and the costs remain constant. If the IT department charges per user, the department may show a serious deficit during a business downturn when fewer users access the service. With fewer users, revenue from the service decreases, but the fixed costs do not. This can squeeze the IT budget into a deficit.

Charges can become particularly confusing when the provider and consumer of the service are in the same organization. When business is down, the consumers all want to pay less for services, but the IT department’s costs are fixed and do not change with the business cycle. When usage goes down but fixed costs do not change, charge-back formulas can generate anomalous results. If the fixed costs are allocated between departments in proportion to usage, departments may find their charge back increasing even as their usage goes down because other departments have cut back more on their usage and the fixed costs come to dominate the charge-back formula (Figure 3-3). Part of the challenge of IT financial management is to avoid confusing anomalies like this.

IT finances directly affect technical architectures. The anomalies previously described are one of the most important reasons for businesses moving to cloud implementations.

Much has been made of the benefits of shifting CAPEX to OPEX, but the shift is probably less important than the need to align service costs with service usage. By and large, IT infrastructure costs are fixed and do not vary by service usage. When IT infrastructure is moved to a cloud implementation, usage of cloud resources aligns much more closely to service usage. Even if the cloud is a private cloud owned by the enterprise, the cost of the service is clarified and the total enterprise infrastructure resource requirement may be reduced.⁵ When the cloud is public, the cost of the service will follow usage more closely, and the total cost to the enterprise will be rationalized and perhaps reduced.

ITIL for Developers

Architects and developers should pay close attention to the service management concepts in this section. They may seem distant from software and hardware engineering, but the principles here are some of the most basic drivers of enterprise software design. Creating a system that delivers a service is a significant achievement, but creating a system that the business side can use profitably advances the enterprise.

ITIL can be frustrating for developers. ITIL training is usually oriented toward enterprise adoption of ITIL and how an organization that follows ITIL practices should function. There is often little in this training that developers can take away as a useful advice in their jobs.

Much of the ITIL message is that IT is more business than technology. That can be disheartening to engineers and technologists whose chosen vocation is to understand and use technology to its fullest; to create software that does new things; to utilize the infrastructure at peak capacity; to design and manufacture new devices; and to extend the infrastructure to support new tasks. For them, technology is the most important part of IT.

However, the fact that the ITIL literature does not dwell on IT technology does not mean that technology is not critical to service management. Without technology, there would be no IT services and without hardware and software innovation, IT services would not improve and provide services to meet future needs.

For engineers, it is unfortunate that ITIL training and literature appears to slight the technical side of the interplay between business and technology. This neglect is perhaps explained by the number of expensive projects in the past that failed to deliver value to their owners because inadequate attention was paid to business requirements and goals. Engineers have to remember that ITIL bridges the gap between business and technology. When ITIL practices are working the way they are intended, services make better use of technology, but technology’s role is enhanced, not diminished. The best job security is a job well done. Technologists should see ITIL as a way of increasing the value of their work and their esteem within the enterprise.

The challenge to engineers and technologists is to understand what ITIL practices are trying to accomplish and how to use input from ITIL practices to build better IT services.

The ITIL provides some technical advice on the overall support management infrastructure, such as what a service desk ought to track and the data to be kept in a configuration management database. ITIL also provides insight into the requirements-gathering process and the service-deployment process. Developers and business managers often use their own language and see issues differently when looking at requirements and deployment plans. Opening up these processes to all parties is often one of the most important implications of ITIL practices for developers.

Enterprise software and hardware engineers should not look at ITIL superficially and shrug off ITIL training as irrelevant to their concerns. They may not realize that they need to understand service management concepts because the classes and presentations seldom directly address the problems facing development. However, without the kind of systematic attention to collecting requirements from all the stakeholders and continual examination and feedback of results, IT risks building services that fail to advance business goals.

ITIL practices help answer questions like these for development:

• Who are the stakeholders who must be satisfied at a given stage in service development and maintenance?
• How do I prioritize and resolve competing and contradictory technical and business requirements?
• How do I design applications that align with enterprise goals and do not require reworking as soon as they are released?
• How are development processes affected by ITIL practices?

This chapter and the ones that follow address these challenges.

Conclusion

Service management as a discipline grew out of efforts to improve manufacturing quality and efficiency in the mid-twentieth century. These efforts identified the importance of processes in quality and efficiency, and lead to recognition of IT as a collection of services that could be subjected to the same regimen of planning, implementation, study, and adjustment as a production line in a factory. ITIL is a set of practices that can be implemented to follow this regimen. Service strategy is the first phase in the ITIL service management plan. At this stage, enterprise goals and requirements shape a high-level plan for IT services. The service portfolio is the most important tool for service strategy. IT financial management is one aspect of service strategy.

¹Some practitioners carefully distinguish between continuous and continual improvement; others use the terms interchangeably. Strictly speaking, continuous improvement is a continuum—that is, continuous improvement implies a smooth upward curve with no gaps or steps. Continual improvement can be continuous, but it may also be a series of step-wise incremental changes, which is often the case with change in IT.

²A control chart is a basic tool of statistical quality control that plots a significant metric against time. The mean and standard error of the points in the chart are calculated and indicated on the chart. Various methods are used to spot variations that are outside statistical control on the chart.

³Customers and users are not exactly the same thing. A customer is the purchaser of a service. The purchaser may also be the user of a service, but not necessarily. For example, management may purchase an e-mail service for corporate employees. Management (the customer) may be satisfied with the service due to low cost and robust data-retention support, but the employees (the users) may be dissatisfied with delivery latency and limits on e-mail attachment sizes.

⁴There are service catalog applications that go beyond the ITIL service catalog. Consumers can subscribe to services from the service catalog application and the application may automatically set up billing and provision the consumer with access to the service. Often these service catalog applications are linked to the enterprise service desk. Although service catalog applications are natural extensions to ITIL practice, the ITIL service catalog is a listing of services, not a service subscription portal.

⁵Actual costs may not be reduced, but the infrastructure capacity available to the enterprise may be increased, which means services can be expanded with less new resources required. There are many factors that influence the available capacity. For example, if peak usage times for a number of heavy-hitting services coincide, available capacity increases are likely to be eaten by the need for peak usage capacities. However, the financial clarity provided by the cloud implementation is always helpful.