Part Two of this book presents 12 key infrastructure processes used in IT systems management. There is a separate chapter dedicated to each process. Each chapter contains a formal definition of the process, desirable traits for a process owner, steps on how to develop and implement the process, and worksheets to use in evaluating the quality of each process.
But in today’s environment, no discussion of IT infrastructure processes is complete without mention of the Information Technology Infrastructure Library (ITIL). The first edition of IT Systems Management offered practical, proven practices on how to improve infrastructure processes. It was based on my many years of managing IT infrastructures in a variety of environments. I wrote about what I knew and what I had experienced. And this is what I continue to emphasize in this second edition.
Several of the professional reviewers who critiqued the first edition commented on how closely the book aligned itself with the IT Infrastructure Library (ITIL). At that time, I had little knowledge of what ITIL was and even less on the specifics about what it entailed. The version of ITIL available at the time was not widely used in the United States until 2002, three years after I started work on the first edition and a year after it was first published.
As a result of the first edition being compared to ITIL, I decided to learn all about this new framework (which really wasn’t so new after all). I wanted to compare the processes I had written about to the ITIL processes, and I wanted to know to what degree the similarities existed. That is the primary purpose of this chapter: to compare and contrast the processes in this book with those of ITIL. We will see that there are many similarities and a few noteworthy differences. ITIL has become the de facto world standard for best practices of IT infrastructure processes and warrants a brief summary here of its framework.
My education about this new framework led me to becoming certified as an ITIL practitioner and instructor, heading up several ITIL implementations, speaking on ITIL at various conferences and seminars around the world, and certifying over 1000 IT professionals on the fundamentals of the ITIL framework. Still, the emphasis of this book is on practical implementation and management of what I consider key infrastructure processes, and we will see that while they are close to ITIL, they are not identical.
This chapter begins with some of the developments that led to ITIL and a discussion of the cornerstone of ITIL: IT service management. This is followed with a brief look at the history of ITIL. We then describe the six service delivery processes of ITIL followed by its six service support processes (this includes the service desk function). Next we compare and contrast the ITIL processes in this chapter with those presented in Part Two. The chapter closes with descriptions of some of the myths surrounding the implementation of the ITIL framework based on my experiences as an ITIL consultant and instructor.
Over the past 25 years, IT managers in the United States have sponsored a number of initiatives to improve the overall efficiency of their infrastructures. Some of these efforts ended almost as soon as they started, leading some detractors to label them as ‘the management fad of the month’. Initiatives that fell into this category included:
• Quality circles
• Focus groups
• Work simplification programs
Other initiatives geared themselves toward the more effective management of personnel. This included:
• Mentoring programs
• Employee empowerment
• Cross-training
• Rotation of staff assignments
While these initiatives were worthwhile and effective, they required ongoing executive support to sustain their existence. Unfortunately, when executive turnover occurred (as it inevitably does), many of these personal development initiatives turned over as well.
In the late 1980s and early 1990s, a new series of process-management initiatives took hold in American industry. Fueled by intense foreign competition, these American initiatives focused on various methods to improve the quality of products and services. Total quality management, continuous process improvement, statistical process controls, and the Malcolm Baldrige National Quality Award were part of a movement to improve the quality of American output in the global economy. Only remnants of these programs are still evident today, with the Six Sigma defect reduction initiative the one notable exception.
What this tells us is that process-improvement programs are easy to start, difficult to sustain, and prone to very short life cycles. So what is it about ITIL that has made it last longer than the others? One of the primary reasons for the longevity of ITIL is that it is built on a foundation of IT service management. The next section describes the basics of IT service management, including the evolution of IT into a more service-oriented organization and the three primary objectives of IT service management.
When IT professionals began developing the original ITIL framework, they quickly realized that IT service management was the common link on which the numerous best practices of IT infrastructure management was based. Service management in general focuses the quality of products and services on the reasonable expectations of customers. When applied to an IT environment, service management focuses the quality of its IT services on the reasonable business expectations of its customers and end-users.
IT Service Management (ITSM) bridges the gap between the business goals of a company and the technology used to accomplish those goals. It sets up formalized and regular communications channels to allow requirements, requests, and difficulties to be expressed and dealt with. This serves the very important function of ensuring IT aims are correctly aligned to the business.
This notion of IT service management was not always prevalent within IT. In fact, the first decade or so of the IT industry had little or no emphasis on service management. Eventually, IT environments evolved from being totally technical entities into service-oriented organizations, as was described in Chapter 4, “Customer Service.”
This evolution to a service-oriented IT organization leads us to the three primary objectives of IT service management:
- To ensure that the organization’s business needs are supported by high-quality, cost-effective, value-adding IT services
- To improve the quality of IT service provision
- To reduce the long-term cost of IT service provision
These objectives were very much in the minds of the developers of the original version of ITIL. The next section describes how ITIL came into existence and led to world-wide acceptance of its framework.
ITIL began in Great Britain in the mid-1980s. The British government saw that its vast bureaucracy was depending more and more on computers to process the huge amounts of numeric and text data required of its various agencies. It also realized that the more dependent they became on computers, the poorer the job they were doing at providing reliable, responsive service to its users.
The British government was not the first to notice that users were not always satisfied with the quality of IT services they were receiving. The dominant supplier of computer hardware and software at the time was the International Business Machines Corporation (IBM). IBM attempted to address this problem in part with a series of books in 1981 that came to known as the IBM Yellow Books. They touched on issues of infrastructure performance, programming standards, and service levels. But the books never really caught on in the United States and were barely even heard of in Europe, although some of the infrastructure issues were similar to what ITIL would eventually address.
In 1986, the British government authorized its Centralized Telecommunications and Computing Agency (CTCA) to sponsor a program to promote improved management of IT services. The CTCA put out a call for IT experts from the public, private, and academic sectors to come forward and establish a framework of best practices for managing the ever-expanding IT environment. Approximately 40 individuals from the public sector of government, the private sector of business, and the academia sector participated in the effort. In 1989, they completed a set of 42 books that comprised the initial set of books covering the first version of ITIL.
In 1991, a user forum for ITIL was formed in the Netherlands and called the Information Technology Service Management Forum (itSMF). The itSMF logo is now recognized world-wide, and the forum acts as a clearinghouse and sounding board for discussions and suggestions on how to implement and improve ITIL. In 1997, the first U.S. chapter of itSMF was started in Dallas, Texas. There are hundreds of itSMF chapters in existence around the world today.
By 1995, the total number of ITIL books had grown to more than 60 and that volume was becoming more than a bit unwieldy. Based on input from the itSMF, work began in 1998 on a second, more condensed version of ITIL known as version 2 (V2). This reduced the list of available books to the following seven books, presented herein the order they were published:
- Service Support
- Service Delivery
- Security Management
- Application Management
- ICT[*] Infrastructure Management
- Planning to Implement Service Management
- The Business Perspective
[*] ICT is Information and Communications Technology
The two books that proved to be most beneficial to IT infrastructure managers were those of Service Delivery and Service Support. Perhaps coincidentally, also in 1998, the itSMF issued its first version of the widely popular Pocket Guide, which condensed the basic elements of the Service Delivery and Service Support books to a pocket-sized booklet of only 70 pages.
The Service Delivery and Service Support books comprise the bulk of the infrastructure processes on which certifications are based (along with a small portion from Security Management). Table 6-1 lists the processes associated with each of these two books.
In 2000, several ITIL-related events occured. In the United Kingdom, the CCTA merged into the Office of Government Commerce, reinforcing the notion that technology should serve business rather than the other way around. Microsoft became one of the first American companies to embrace ITIL and developed an operations architecture on top of it called the Microsoft Operations Framework (MOF). MOF added the roles of teams and risk discipline to the implementation of ITIL. And the first book of ITIL V2 was published: Service Support.
In 2001, the Service Delivery and Security Management books of ITIL V2 were published with the other four books following by 2002. A new version 3 (V3) of ITIL became available in June 2007. As was the case with ITIL V2, the itSMF provided many practical suggestions from ITIL users for the development of V3. Hundreds of companies from around the world that either utilize the ITIL framework or provide products and services in support of it also contributed greatly to V3.
The most significant change between ITIL V2 and V3 is the introduction of the concept of a Service Lifecycle. This notion describes an IT service as having five distinct stages throughout its life:
• Service strategy
• Service design
• Service transition
• Service operation
• Continual service improvement.
The six processes of V2 service delivery are included in the V3 lifecycle stages of service strategy and service design, along with four new processes. The six processes of V2 service support are included in the V3 lifecycle stages of service transition and service operation, along with three new processes and three new functions. Table 6-2 lists a timeline of major events in the evolution of ITIL.
The use of the ITIL framework was primarily confined to European nations up through the late 1990s. ITIL did not start gaining acceptance (and later prominence) in the United States until just after the turn of the new century. There were several reasons for the timing of this increased American interest in ITIL, including:
• Expanded use of the Internet. Companies were expanding their e-commerce over the Internet and required best practices for infrastructure management.
• Legislation. New laws in response to accounting scandals, such as Sarbanes Oxley (SOX), mandated documented controls and processes on how data was being managed.
• 9/11. After the tragedy of the New York World Trade Center on September 11, 2001, many companies wanted to invest in proven, world-class processes to improve the management and protection of their infrastructures.
• Globalization. American companies were starting to set up data centers in Europe and vice versa; infrastructure managers of American companies noticed the superior use of ITIL processes in data centers of their European counterparts and became interested.
Although ITIL has experienced a number of refinements over the years, it remains at its roots a set of publications that provides guidance for service management. It has emerged as the international de facto standard framework of best practices for IT service management. It is a public domain framework. It is not proprietary. You have to pay for the publications, but you do not have to pay to use them; you can apply them freely in your organization. It is a best-practice framework, and that means it is not an academic or theoretical view of how to manage IT services; it is actually culled from practitioners out in the field.
ITIL focuses on providing high-quality services and supports quality systems such as ISO 9000, total quality frameworks such as the European Framework for Quality Management (EFQM), and major quality recognition programs such as the Malcolm Baldrige National Quality Award (MBNQA). The British Standards Institute (BSI) published A Code of Practice for IT Service Management (PD0005), which was based on ITIL. There is now a standard BS15000 in support of IT service management. The International Standards Organization (ISO) published in December 2005 a standard for IT Service Management, ISO20000, that is based heavily on the ITIL processes.
ITIL constitutes codes of practice for quality management of IT services and infrastructure processes in which the services are matched to business needs. There are a number a unique characteristics and benefits of ITIL, including:
• Best practice guidance. ITIL was written by practitioners, for practitioners. It is not an academic or theoretical framework of how IT processes should be or could be; it is a methodology of what works in actual practice derived from what practitioners around the world have indicated truly works.
• Non-proprietary. ITIL is not a single vendor view of IT processes. Although you must purchase the publications to own them, you can apply ITIL in your organization without paying a fee to use it.
• Comprehensive. The value of IT service management processes is in their interaction and interdependence. Rather than focusing on just one process domain, ITIL captures all of the essential service support and services delivery processes and integrates them to work together. Infrastructure professionals may call them something else, and in all likelihood a version of some of the ITIL Service Management processes are operating in their organizations, whether they recognize them or not.
• Consistent terminology. One of the greatest benefits of ITIL is that it uses consistent terminology throughout its implementation across all of the Service Management processes. It gives everyone a common vernacular for terms of reference. This is a huge advantage, especially in large organizations where various individuals may refer to something as an incident, error, issue, problem, event, or fault—and they think they are all talking about the same thing but they are actually referring to different entities.
Now that we have learned some of the background of ITIL, it is time to compare its processes to those covered here in IT Systems Management. As mentioned previously, the processes here differ slightly from the ITIL framework because they are based on my personal application of key infrastructure processes and because ITIL did not gain prominence in the United States until after the turn of the new century.
There are far more similarities than differences between the IT Systems Management processes and those of ITIL. One of these differences is the manner in which processes are categorized as either strategic or tactical. Table 6-3 shows the criteria I use to make this distinction and the infrastructure processes that pertain to each of these two groupings. In comparison, Table 6-4 shows the criteria ITIL uses to distinguish its two groupings of processes, how this criteria is used, and the processes that pertain to each grouping. It is worth noting that ITIL uses the term ‘tactical’ to describe what many may refer to as strategic, and it uses the term ‘operational’ to describe what some may refer to as tactical. These terms should not be confused when used among the various sets of processes. An easy way to distinguish the groupings is to think of one group as always being ‘long-term’ in nature and the other as always being ‘short-term’.
There are other notable similarities and differences between these two tables. Aside from the difference in terms, the criteria used to distinguish the two groupings is very similar. The total number of processes in both groups is identical at 12. The number of processes is evenly divided six-to-six with the ITIL criteria and closely divided five-to-seven with the IT Systems Management criteria. The specific processes named in each grouping are identical for only seven of the 12 processes in each group. But as we will see in the next section, even in this regard there are more similarities than differences.
Table 6-5 shows how the 12 processes in IT Systems Management compare to the 12 processes of the ITIL framework. As previously noted, ITIL treats the service desk as a function rather than a process but includes it with the other 11 processes because of its key role of integration with many of the other processes. For simplicity, I refer to the ITIL service desk as one of the 12 ITIL processes.
As shown in Table 6-5, there are far more similarities than differences. Of the 12 processes covered here in IT Systems Management, only three of them do not directly correspond to ITIL: storage management, network management, and facilities management. Most anyone who has ever managed a data center will attest to the importance of these processes, which is why they are included in both editions of this book.
Some of the processes take on different names or forms in ITIL. For example, performance and tuning is a separate process here but is part of capacity management within the ITIL framework. Similarly, production acceptance in this book is part of release management in ITIL.
In a similar manner, Table 6-6 shows how the 12 ITIL processes compare to the 12 of IT Systems Management. As expected, there are more processes that are similar than there are processes that are different. The only two ITIL processes not covered in this book are service level management and financial management for IT services. Three other ITIL processes are addressed in one way or another with processes not identically named. These are the service desk and incident management (covered under problem management) and release management (covered under production acceptance).
During the past several years I have certified more than 200 IT professionals on the fundamentals of ITIL. Before and during that time I have also offered consulting services to dozens of clients who wanted to implement some or all of the ITIL processes. These experiences have offered me the opportunity to witness first-hand a number of myths about the implementation of ITIL. This section describes 10 common myths about implementing ITIL that I have encountered with organizations in recent years:
- You must implement all ITIL or no ITIL at all
- ITIL is based on infrastructure management principles
- ITIL applies mostly to data center operations
- Everyone needs to be trained on ITIL fundamentals
- Full understanding of ITIL requires purchase of library
- ITIL processes should be implemented only one at a time
- ITIL provides detailed templates for implementation
- ITIL framework applies only to large shops
- ITIL recommends tools to use for implementation
- There is little need to understand ITIL origins
Many individuals who first learn of the ITIL set of processes believe that all 10 of them, in addition to the function of the service desk, need to be implemented at the same time in order to gain the full benefit of the framework. This is not only false, it is not even recommended by many of those who specialize in assisting with ITIL implementations. The ITIL framework is an extensive series of IT management best practices, and few believe that it can be effectively implemented all at the same time. While it is true that all of the processes interact and integrate well with each other and should be designed with that in mind, many shops implement only what they need at the outset to ensure a successful early win.
Because ITIL is a library of books describing best management practices for infrastructure processes, many erroneously believe that ITIL is based primarily on the principles of sound infrastructure management. Responsible IT management certainly plays an important role when ITIL processes are being designed and implemented. But in fact, ITIL is based primarily on the principles of IT service management. The business value of basing IT support and delivery on service management may seem obvious today. But that was not the case 15-20 years ago, when originators developed the first version of ITIL.
The premise of having IT managers partner with customers to solve their business problems, and to offer them service levels that they negotiated and agreed to with IT representatives, was a fairly radical notion at the time. Not everyone is aware that this was the real basis for the development of the IT Infrastructure Library (ITIL).
The fact that ITIL is involved with infrastructure processes and the management of them leads some to presume that ITIL pertains primarily to data center operations. In reality, ITIL pertains to all areas of IT in which deliverables are provided. This includes the service desk, database administration, applications deployment, hardware upgrades, and network provisions. ITIL also goes far beyond the data center in terms of SLAs and financial management. Service-level management involves regular meetings and sometimes extensive negotiations between customers and the service-level manager. In many shops, the service-level manager is not even a member of the data center staff but instead may be on staff to the CIO.
This myth applies to some infrastructure managers and several of the engineers reporting to them. IT professionals occasionally feel that to take advantage of the benefits of ITIL, all personnel must be trained on its fundamentals. I know of some IT organizations that have implemented the ITIL framework very successfully with only a handful of their staff formally trained on ITIL fundamentals. The key here is to ensure that everyone involved with the design, implementation, use, and maintenance of ITIL processes is familiar with the fundamental concepts of the framework. These concepts include the principles of IT service management, the integration of processes, and the use of metrics and management reporting. Not everyone needs to be formally trained on ITIL fundamentals to gain an understanding of these key concepts.
The IT infrastructure library is, in fact, a set of books prescribing best practices for managing an IT infrastructure. The intent of these books is to maximize the quality and value of IT services and to ultimately reduce their costs. Some believe that to acquire a thorough understanding of ITIL and to realize its full benefits, all of the books in its library need to be purchased, read, understood, and applied.
This is a myth in that many organizations acquire a deep understanding of ITIL and profit from its benefits without ever purchasing a single book. An understanding of ITIL and how to apply it can be obtained in a variety of ways. Some of these methods include searching the Internet, attending user forums, participating in seminars, having discussions with other ITIL shops, signing up for training, and contracting with subject-matter experts.
The initial version of ITIL contained 42 books and covered areas in far greater detail than what many felt were practical. Many of the books, such as those that described how to install power supplies and how to design fire suppression systems, were dropped when later versions of ITIL were published. There currently are seven books in the library, of which the two on Service Delivery and Service Support contain the majority of information needed to effectively utilize the ITIL framework.
This myth is essentially the opposite of Myth #1. Myth #1 suggested that to obtain any of the benefits of ITIL, all of its processes should be implemented at the same time or not at all. Myth #6 suggests that the proper method of implementation is to install each process separately and serially. The basis for this myth is that each process is considered to be so intricate, so structured, so far-reaching, and so complicated.
In reality, the ITIL processes are all intertwined with each other and work best when implemented in an integrated manner. This does not mean that all of the processes must be implemented at once (as we saw with Myth #1), but it does mean that some groups of processes could and should be implemented together. Some examples of optimal groupings are Incident and Problem Management; Configuration, Change and Release Management; Availability and Security Management; and Service Level and Financial Management. Several ITIL consulting companies and software vendors now offer services and software suites of two or three of these processes combined.
At its core, ITIL is a framework of best practices for managing IT infrastructures. Nothing more and nothing less. By design, ITIL is a generalized, non-specific, process-oriented framework. As such, it does not include detailed templates for processes. When I am teaching certification classes to IT infrastructure personnel, students often inquire about checklists, worksheets, and assessment documents they hope to use when implementing ITIL processes. They are usually disappointed to learn that no such documents are available. One student became so indignant he questioned the real value of ITIL and threatened to leave the class.
The student fell victim to this common myth about ITIL by failing to realize that the absence of templates is one of the features that make ITIL so powerful. It is what allows ITIL to apply equally effectively to IT environments of various size, scope, and complexity. Templates are normally customized to a specific environment with specific requirements. I am often asked why ITIL does not provide forms for tracking incidents in incident management or for submitting change requests in change management. My response is that ITIL offers suggestions of what fields to include on both of these forms, but ITIL intentionally steers clear of specifics so that templates can be tailored to the needs of the specific environment.
When authors of ITIL developed the original version of their framework in the mid and late 1980s, mainframes in large shops were the order of the day. Personal computers (PCs) were just starting to come on the scene, client/server applications were few and far between, and very few people were using or had even heard of the Internet. So it’s not surprising that some 20 years ago many may have associated ITIL with large mainframe shops.
But the framers of ITIL understood that their mission was to develop management guidelines that were based on process rather than function, on service rather than size and scope, and on being independent rather than dependent on specific platforms. The structure and principles of ITIL apply to all environments regardless of size, scope, complexity, or platforms.
One of the most frequently asked questions I receive from IT professionals concerning ITIL is “What tools does ITIL recommend for implementation?” The answer is simple, “None.” It was never the intention of ITIL to recommend specific tools to use when implementing its framework. ITIL is process-oriented library of best practices. It is not technically-oriented, which is what it would become if it was involved with evaluating and recommending specific products. There are forum groups available—itSMF, for one—that offer guidance in this regard. But it is a myth to think that the ITIL framework itself will recommend tools for implementation.
I have met a number of managers who debated with their staffs about the merits of ITIL before finally deciding to get involved with this framework. The essence of their discussions usually centered on the amount of time and costs they would need to commit to in order to implement ITIL. Once they committed to the implementation of the processes, they focused on moving forward with ITIL rather than looking back at how ITIL got started. They erroneously believe that there is little to be gained by expending time and effort to learn of ITIL’s past.
What these managers do not realize is that understanding the origins of ITIL can actually help with future implementations. Integration and collaboration are two of the key cornerstones of ITIL and these were prevalent from the start. When the government of the UK commissioned a framework of best practices to be developed, it fostered a collaborative effort among specialists from private industry, academia, and government. The final product was very much an integrated work among three very diverse groups of people. But it reinforced the notion of cooperation and communication, much like today’s version reinforces the same among IT service providers, customers, and suppliers. So there can be value in understanding the origins of ITIL and applying those principles when implementing ITIL processes.
This chapter introduced the IT Infrastructure Library (ITIL). It began with some of the developments that led up to ITIL and a discussion of IT service management. Next was presented a brief summary of how ITIL came into existence. We then described the six service delivery processes of ITIL followed by its six service support processes. Then we offered a comparison of the ITIL processes with those presented in Part Two. The chapter concluded with descriptions of the 10 common myths surrounding the implementation of the ITIL framework.
1. IT Service Management bridges the gap between the business goals of a company and the technology used to accomplish those goals. (True or False)
2. ITIL service delivery processes are considered user-facing while service support processes are considered customer-facing. (True or False)
3. Which one of the following is not considered an objective of IT Service Management?
a. to ensure that the organization’s business needs are supported by high-quality, cost-effective, value-adding IT services
b. to maximize the performance of IT hardware and software resources
c. to improve the quality of IT service provision
d. to reduce the long-term cost of service provision
4. The new standard for IT Service Management from the International Standards Organization (ISO) that is heavily based on ITIL processes is ____________ .
5. What are some of the cultural changes an IT organization would have to make to transition from being technology-oriented to becoming more service-oriented?