ITIL V3 Application Management is a skinny little weakling

ITIL attempts to establish authority over Application Management. Does ITIL V3 have what it takes? No. As bodies of knowledge go, it is scrawny and under-developed.

This blog post came about in response to a couple of excellent comments about the problems faced in the interface between Development and Production. See also the recent post about how ITIl V3 failed to get it together with a leading body of App Mgmt knowledge called ASL. Heck they didn't even make much use of another body of App Mgmt knowledge called ITIL V2.

Everyone agrees that production handover is a weakness in lots of organisations, that there has to be something better than chucking the dead cat over the wall. That's not the question. The question is whether ITIL is the answer, as it were.

Does ITIL's idea of App Mgmt even come within pissing distance of what is really needed to get the Development geeks under control? (Development/solutions may run a tight ship when it comes to version and build management, requirements gathering, parallel development, RAD, JAD, RUP, JUP... but they typically don't know jack about interfacing with the real world. Actually they could know if they wanted to, they just don't care: "My work here is done. Operate this.")

Or is it but a token effort to tick the box? A paltry five pages to cover what used to be a whole book in ITIL V2, and still is in ASL.

ITIL V3's section on App Mgmt is nearly as embarassing as its Information Security. It would be bad enough to muscle in on other domains with something powerful in hand. To barge in there with these emaciated bodies of knowledge - when in both cases established substantial BOKs exist - will make us a laughing stock.

P.S. the photo is Astro. he's the reason I haven't had much sleep for the past few days - my son's new puppy. Somehow he made me think of ITIL V3's section on App Mgmt.


I am concerned.

I am concerned.

"P.S. the photo is Astro. he's the reason I haven't had much sleep for the past few days - my son's new puppy. Somehow he made me think of ITIL V3's section on App Mgmt."

And you associate your new pet with throwing dead cats over walls?


ITIL V3 Application Management is a skinny little weakling

ITIL has primarily focused on the Operations part of IT. V3 is an improvement by looking more at the full lifecycle. I agree it still has some way to go. Typically project methodogy and development practices are better implemented than operational processes. So ITIL does have it's place and tries to address the gap between the two with v3 service introduction.
Even though ITIL has a way to go, there are very few IT organisations that are ahead of it - which begs the question where does it get it's best practice from?


Indeed. perhaps we should add a third category to proven guidance and bleeding edge thought-leadership for this case? "Lagging the leading edge but far enough out that nobody is quite sure".

As an Application Manager

As an Application Manager new to ITIL and looking for best practices and standards related to application documentation, do you think it is worth picking up the V2 Application Management book? I have the ITIL V3 suite and have found it seriously lacking when it comes to application requirements and design documentation. I've looked into ASL publications but I'm not sure I will find what I'm looking for there either.

v2 App Mgmt review

It's worth a look. I reviewed it in detail here. Disclaimer: This was written four years ago, and I might write a more critical review today.

But, to your point, application documentation & requirements were never in scope for ITIL. I would look to the software engineering community for those, e.g. Alistair Cockburn's Writing Effective Use Cases and Paul Clements' Documenting Software Architectures. Tons of material out there.

Charles T. Betz

Great Review of v2 App Mgmt

Your review is what turned me onto the book in the first place, the lifecycle/service management matrix is a simple but fantastic illustration.

Recommend v2 App Management?

Generally speaking, I think that it's a pretty good book and I don't have a problem recommending it, though your intended use is really the key factor in evaluating its suitability.

From my perspective, I believe that:
1. It's a good bridge for someone steeped in development to bridge over to the Ops world (from the ITIL perspective) and see how they are seen (by Ops). I think it's also helpful in understanding ITIL.
2. I do think it's a source of some good ideas and thoughts. For example, the book outlines an application lifecycle and for each stage, there are some questions listed that are appropriate to the stage. Some of these questions are extremely good and worthy of consideration.
3. I don't think that this is a great source of "best practice", as it's pretty light on recommendations. Indeed, it's often been noted that the framework is largely descriptive, not prescriptive.

Bottom line is that if you're looking for lots of detail, you'll need to keep looking. If you want something that is useful from a general reference and mapping perspective, I'd say that this is fine. I own it and am not displeased with my purchase. I can't say that for *all* of the ITIL books!

Maybe I like it because it addresses an area that I really enjoy! I think that I'll get back into it someday -- then again... ;-P

Recommend v2 App Management?

I am an old App Man dog, and I have been in ITIL for some time. If you come from any of those worlds, both V2 App Management and ITIL V3 are good for looking over the fence and putting yourself in the other guy's shoes. Of course, for anything more serious than that, a truckload of good specialized books is allways available.

I was pleased with a few new things in V3, in this context one of them was Application Requirements. Something I would like my boss to read. Heck, most of the geeks I work with on a current project wouldn't get it. It is really best practices, as they were done 10 years ago. If you talk Extreme, Agile, SCRUM and some other recent stuff, V3 lacks them. But they can be implemented if you know your stuff. Not easily, but, nothing is easy in application management...

The Ops Guy Loves Me

Excellent thanks for the feedback, glad to hear the book was useful. It is especially comforting since I purchased the book minutes before navigating back to this site to look for responses to my post. :-)

Also I can't believe I used the term "best practice" in my original comments, thanks for ignoring the urge to beat me over the head with my own words. My intended use is really to make sure our newly-suited-ITIL-ready SDLC falls in line with all of the other prescribed ITIL pieces (eg Ops). One petty concern I have as an example is that requirements documentation may use different/inconsistent verbiage or not capture all of the necessary information; ultimately causing unneeded confusion and rework on up the service chain. Section Application Requirements in Service Ops V3 is all but useless. For example, open up the book and turn to page 139 and look at what is written for "Usability Requirements". Anyway I'm really hoping I get more "meat" with this V2 book.

Intended use...


1. Sounds to me like you'll get some good use out of the book.
2. As far as restraint goes, unless directly attacked, you'll always get that from me... some "others" (cough, cough) who show up here in Skep-ville aren't nearly as civil! LOL
3. I share your criticism of the cited passage. Indeed, I have quite a number of similar criticisms. How about (same section) that there is no express linkage to the cost of (or planned budget for) the application?? There is a linkage to return on investment, but that's way to indirect for my liking. There's a reason why we play the "good-fast-cheap, you only get 2" game. Money matters. If you don't address it up front, you regret it in the end.


Who killed the cat?

"Development/solutions may run a tight ship when it comes to version and build management, requirements gathering, parallel development, RAD, JAD, RUP, JUP... but they typically don't know jack about interfacing with the real world."

Very relevant observation, from my perspective.

There are lots of good development processes and well-intentioned (and hard working) people. Unfortunately, this does not add up to either well built software or happy users/customers. Add a little hubris and arrogance to the mix and you have a potent (as in toxic) cocktail for failure.

To lay this solely on the doorstep of app dev would also be a mistake. In my experience, I've seen the same quality of behavior from Ops teams as well... it just expresses itself in a different direction. It takes something to break free and start orienting properly to the customer.

What's missing is getting people in communication. There'll be no happy kitties without it. No amount of writing in the ITIL books will make that happen.

As far as v2 goes, I really liked the Yellow Book. I found that it was an interesting read to help glue together what I read in the other books. It was also substantial enough to make the point about app management, but didn't try to cover the ground that is rightfully covered in traditional development books. I can see some of the core concepts in v3, but it's a shadow of its former construction.

Then again, the disappointing piece is that the overwhelming majority of people I get to talk to have no idea that there was anything more than what was in Service Delivery and Service Support.

"Application Management, what's that?"... Ugh!

3 Types

Interesting how the three main types of IT people (system, network and developers) speak three totally different languages. So it is only natural that something important to the sys guy is irrelevant to development...


With all due respect, doc, I think this is part of the problem. It's all relevant, just a matter of degrees.

In the earlier days of my development career, having a knowledge of assembler for various microprocessors was an important part of my skill set. I needed to understand this to ensure that I was getting all I could from the underlying platform.

Later, the focus came to be about generic data structures and the use of libraries provided by third-generation languages. They provided some freedom (due to the layer of abstraction from the underlying hardware), but came at a price in performance. The nice thing was that I could "dip down" and get to the assembler if I needed it.

From there, we saw the introduction of various 4GLs and graphical development environments that started making programming look more like system administration -- tinkertoy programming. "Now, even non-programmers can program... it'll build the code for you. You focus on solving the problem". I remember people waxing poetically about how it would level the playing field and render programmers obsolete (sound familiar, anyone?).

With each level of abstraction, we've had to add processing power to accomodate the extra overhead that the abstraction layer added. Is that worthwhile? Yes, I think so. Unfortunately, these days, with the quality of education that passes for "computer science", we just use these tools to write crappier code faster than ever. How's that for progress??

The point here is that further specialization and "progress" has allowed us to take our eyes off of some fundamentals. The ability to think (and design) from a systemic level was one of the first casualties. You could build software without any responsibility for the unintended consequences resulting from any inefficiencies in the tools you chose to use.

I don't think that people need to be experts in everything. That being said, it doesn't absolve us of the responsibiity of having proper knowledge of what those in other domains are responsible for. In fact, I think that is within our capabilty and should be part of our responsibility. We should actively try to understand what life is like in other domains and take this into account when we are looking at building software.

You need to be good at your part, but you can't lose sight of the whole. The further removed we are from core principles of how things work and seeing the proper fit with (as part of) the whole, the more dangerous and costly the consequences are. I believe that was seems "natural" is really not.

The dead cat...

I was speaking to some developers who were about to throw a dead cat over the wall. They looked at me at said I spoke the same "language" as that guy, pointing to the data center manager. It made me realize that if service management is not understood by developers, then who on earth is going to write or develop any decent tools. Maybe that is why there are none and those that do exist have such limited functioanlity that they are priced beyond their business value.

App Man


There is also chapter 6.5 in Service Operation, explaining the app. lifecycle and distribution of knowledge about related stuff thru ITIL Lifecycle stages. A bit more then 5 pages.

Still, describing a complex domain as application management in such a scattered way troubles me too, looks way too untidy.

BTW, putting development geeks under controls requires much more then a pile of best practices and standard procedures.

Syndicate content