The Information Technology Infrastructure Library, self-described as “the most widely accepted approach to IT service management in the world,” is living up to that claim and becoming increasingly influential in defining best practices for the modern, well-run enterprise IT organization. The best-known ITIL volumes are the "Red" Service Delivery volume and the “Blue” Service Support volume, which together comprise the gateway through which most new ITIL initiates pass.
These volumes focus on topics such as Configuration, Change, Incident, Problem, and Release Management; IT Finance; Capacity Management; and other topics regarding the large-scale IT operation. However, there is an expanded ITIL color palette, and the full IT Service Management picture does not emerge until one takes into account the other major ITIL volumes:
-Application Management
-Software Asset Management
-Planning to Implement Service Management
-ICT Infrastructure Management
-Security Management
-and the forthcoming volume The Business Perspective
This is a review of the “Gold” or “Yellow” Application Management volume, a significant, boundary-breaking book that bridges the gap between “build” and “run,” and should be required reading for both development and service managers.
Like any ambitious framework, ITIL (and IT Service Management more generally) prompts questions around its scope and relationships to other communities of practice. For example, what is the relationship of ITIL to the Capability Maturity Model and software engineering more generally? Or to the emerging momentum around using concepts of portfolio management for the strategic direction of the large scale IT operation?
Answering such questions are the fundamental purpose of the Application Management volume, which is the most outward-looking of any of the ITIL volumes I have read. It specifically discusses major questions of software engineering and discusses standards bodies, products, and non-ITSM practice areas in a way that makes the other ITIL volumes seem a little insular at times.
This review is in two parts, one focusing on higher-level process questions, the other focusing on tooling and technical implications of the Application Management volume.
Part one: Application management purposes and process relationships
The volume is based on several coherent themes:
-The IT investment in its business context
-The concept of application portfolio
-Non-functional requirements in software engineering, filtered through the lens of IT Service Management
-Control and quality for both development and operations
The discussion on the IT investment in business context is largely drawn from Henderson and Venkatraman (“Strategic Alignment: Leveraging Information Technology for Transforming Organisations” J.C. Henderson, N. Venkatraman 1993 IBM Systems Journal, Vol. 32, No. 1, pp. 4-16) which is an interesting framework, showing as it does reasonably rigorous distinctions between IT as a cost center, profit center, service center, and investment. Other aspects of it (the idea of a business model) seem to be indebted to enterprise architecture concepts, but enterprise architecture (EA) is not mentioned, which seems an oversight. (When EA is mentioned, it is in its purely technical aspect, which shortchanges the EA discipline.)
The application portfolio “is an information system that contains key attributes about applications being utilised within the company…. if the application is considered a corporate asset, it should be included in the portfolio … no successful business would consider managing its financial assets without utilising an investment portfolio. Any business would be wise to follow the same rule with its application assets.”
The concept of application portfolio will be discussed in depth in the second part of this review.
Software engineering
The Application Management (AM) volume concludes with the following:
“Managing applications as corporate assets will focus management attention on the service delivery capabilities rather than on the short-term project implementation.”
This quote neatly sums up the main thrust of the book, which on its surface is similar to many other works on enterprise architecture, data management, and software engineering: applications need to be engineered for the long term, and too often are compromised to meet schedule and cost constraints.
However, the ITIL guidance on exactly what constitutes a high quality, operable application is rigorous and top-notch, based as it is on the well established ITIL Service Delivery and Service Support process areas. The volume states that “This book does not cover application development practices nor address project management and business management issues in detail,” which is wise scope management. Instead, the value-add core of the volume is basically to propose an extended application lifecycle which includes the classic software development lifecycle with addition of “Operate” and “Optimize” phases.
It’s hazardous to generalize too much about something as widely written about as the software development lifecycle, but in the 10 or so software engineering books I have read by McConnell, Humphries, Booch, Kan, McCarthy, and others there is clearly a bias towards the first four steps, and little to no coverage of the “Operate” and “Optimize” phases ITIL adds.
This is because much of the software engineering literature seems to come from the packaged software or military/aerospace viewpoints, which only partially address the challenges in building and running software for large, data-centric, nonmilitary enterprises. On the other hand, ITIL in the Service Support and Service Delivery volumes collapse the entire software development lifecycle into a subsection of Release Management.
The Application Management volume therefore plays a critical mitigating and bridging role, between the software development literature and Service Management and is probably one of the most important texts the enterprise IT software engineer can read.
The core of the AM volume is a systematic exposition of the six-step AM lifecycle, with attention to the ITIL service management concerns throughout; essentially, the IT service management areas become the source for what are traditionally known as “non-functional requirements” in software engineering. Think of the book’s material as a matrix, with some detail in each cell:
This is a valuable contribution to the practice, as many software engineers may not understand the relationship between change and configuration management, or incident vs. problem management. It is a formalization of non-functional requirements not typically well or consistently covered in the mainstream software engineering literature.
The volume drily notes that "The lack of Service Management considerations within all phases of the application lifecycle has been a serious deficiency for some time" and goes on to make some hot-button recommendations that will bring a smile to the lips of cynical architects:
“The requirements team will require representation from a number of the key Service Management areas…the design team needs representation from the same key areas within the Service Management team..” and so on.
Such recommendations look good on paper, but are typically very hard to achieve given the timeline-driven incentives of most projects. But IT Service Management has excellent mindshare right now, and it’s possible that by directly tying good software engineering practices to the ITIL locomotive, more progress may be possible than previously imagined.
Concluding remarks
If tying ITIL to software engineering was all the book had covered, it would be a success. Here are some concluding comments in no particular order on other aspects of the book. Again, a more detailed technical analysis of the application portfolio management implications is forthcoming.
There’s a minor misstep when Content Management gets confused with software and project configuration management: “content management becomes increasingly important and requires more sophisticated techniques for managing project documents, application and systems code.” Let’s not mix up our terminology.
A detailed discussion of the relationship between “application” and “service” (as in service level management, not persistent daemon-based service) is well framed and much needed.
Finally, while this work makes important strides in linking ITIL with other industry concepts, recognizing for example the work of the OMG and DMTF, I’d still like to see more ITIL recognition of the fields of Data Management and Enterprise Architecture. The volume’s discussion of Knowledge Management would have been an ideal hook for bringing in the concept of metadata management, which as I’ve noted elsewhere is a historic surrogate for configuration management. Data management is alluded to in the Security section, which notes that “All authorised Users should feel confident that the data presented to them is accurate and not improperly modified.” Protecting against improper modification is only partly a security question, and the reader is referred to the general field of data management and data quality for further discussion (see Larry English’s book on Amazon for starters.)
However, the criticisms are minor, compared to the volume’s sound and systematic contributions in bridging IT Service Management and Software Engineering. Again, highly recommended.
