Comments on: ITIL and DevOps: Differences & Frameworks Working Together BMC Software Tue, 03 Nov 2015 23:59:00 +0000 hourly 1 By: Charles T. Betz Thu, 03 Sep 2015 23:45:00 +0000 That’s the great paradox of ITIL – how something intended as a definitive statement of “service” thinking became translated into process guidance.

Agree with your nuanced statement that process has a place, but should not rule. That reflects my emergence model I’m using in my new textbook, “Agile IT Management: From Startup to Enterprise” ( ). In that model, process management comes in the second half of the book, preceded by more fundamental questions of IT value, product management, work management, culture, and more. (See ).


By: Stephen Alexander Thu, 03 Sep 2015 20:27:00 +0000 In my experience most of the ITIL experts, consultants, practitioners, and the like came from Operations. And more likely from the Service Desk. This has shaped their world view about how IT works in a very different way than someone else who grew up in “development” or as a solutions architect (meaning, working closer to the business to design/develop services to meet a need).

ITIL itself seems to have focused on “process” over all other things – namely “services.” This has lead to a view, belief and practice that diminishes “value creation” at the expense of the written word (of the policy/process/procedure). Somewhere along the way it was forgotten that the only point to have a process was to better deliver a service which is where the value is being created. The process itself is valueless and if we are not careful the enactment of the process can lead to value destruction.

Along with that is a mistaken belief that a single process is good enough for the enterprise – regardless of the number of services, customers, lines of business, or even situation. It is simply ridiculous to imagine a single process (say, a Change Process) can be sufficient for any mid to large IT enterprise given the diverse set of services, customers, lines of business and situations encountered on a monthly, weekly, daily…or faster basis. Having all changes flow through a single process, even if there is the “exception process” will quickly lead to a bottleneck…which leads to rubber stamping…which leads questioning the value of the process in the first place…which leads to entrenchment (defenders of the faith)…which leads to disillusionment (from all others).

DevOps make more sense because it is more naturally aligned with value creation (the faster deployments, tighter feedback loops).

This is not to say that process has no place – only that it is not king, and should not be king. There is no one size fits all and not everything that happens in IT fits nicely in a standard workflow (think Problem Management) that can be SLA’d. Process needs to be adaptive to the service and not a great leveler across the enterprise. Process needs to facilitate business not obstruct it. So, this could mean, for some services, check-ins and reviews/approvals of code before promotion – which could happen multiple times a day and for others it could mean a general announcement 5 business days prior to the implementation of the change with a tight change window – but neither should be mandatory in all cases.

It is the failure of many ITIL practitioners (and the like) to recognize this that has lead to ITIL getting the black eye that it has.

By: Charles T. Betz Fri, 03 Jul 2015 12:36:00 +0000 I’ll respond to both your points, which are excellent and thoughtful. First, the biggest second thought I’ve had about this piece is exactly what you raise: that services ARE products. “Functional silos” can formalize, institute a service interface, automate, put in BRM/CRM and established rates, and then they ARE by definition now a product, and therefore now “good” in the current fashion.

But in the field, the “service catalog” part of ITIL has been limited to primarily infrastructure services — the application world mostly didn’t buy in. And, there are often unintended consequences from creating such an internal market of systems, including the tendency of potential internal customers to run away from rate cards and go rogue. Other problems include uncompetitive pricing and default FIFO queuing combined with still too much manual effort, which results in a suite of internal “services” seeking to be monopoly providers, and prone to gridlock.

I also agree that there are different connotations around the term “ITIL” as with any controversial concept (e.g. Taylorism). Yes, I am focusing on the tendency for a centralized, essentially functional management model. I have seen the wreckage of this now too many times, and the reality is that DevOps does not get along well with this “management model of ITIL” as you call it.

And, given the repeated occurrence of this dysfunction in companies widely separated in time and business vertical, I think it is fair to ask, “what is it about ITIL that promotes or encourages this?” Sure, perhaps its the combination of the ITIL text PLUS the incentives of the training ecosystem. But that combination IS what people experience as “ITIL.”

And, in terms of the pure ITIL vision, I do stand by the assertion that if it were to be rewritten today, it should have much greater emphasis on feedback and experimentation. It does lack there, demonstrably.

By: rydma01 Thu, 25 Jun 2015 17:23:00 +0000 Bonus beats: the other thing about ITIL that gets lost in the glare is that services are a kind of product, service management is readily apparent as a type of product management, and as product development evolves, so will service development and consequently service management — all of which is to say that ITIL is actually not “about” process management anyway. It simply includes diagramming of management issues in the form of processes.

By: rydma01 Thu, 25 Jun 2015 17:19:00 +0000 I think that there is a “social history” of ITIL that is more significant than many of the atomic complaints about what is in the publication-to-date.

Clearly, the notion of providing reference knowledge changed forever with Wikipedia, and there are no really significant debates that I can think off regarding the inevitability that a knowledgebase called ITIL will largely cease to be a versioned resource. That in no way eliminates the value of periodic expert assessment of (a.) its to-date conceptual model and (b.) the evident applicability of its current state.

The social history of ITIL *usage* is rife with ambitions that exceeded the value proposition of the library. This is because the motivation and justification for creating the library never changed. But there was no philosophical nor pragmatic requirement that the library had to “fulfill” a completeness criterion at a deep level of granular specification. Managing the knowledge within ITIL is really nothing more nor less than a conventional scientific inquiry which, *of course*, requires documentation in order to promote the forward discourse. But just as we thought of Physics one way in 1950 and a radically different way in 2010, neither the subject nor the objectives of ITIL has changed during its lifespan. And neither before, nor now, is there any logical basis for claiming that “completeness” has been achieved.

Instead, the excessive ambition around ITIL (not *of* ITIL) has always been to achieve applied science within a centrally managed construct driven mainly by the goal of standardized accountability. Most of the agony and anxiety of ITIL has come from trying to implement not the ITIL conceptual model but instead a centralized “management model of ITIL” (not *from* ITIL). It is not surprising in the least, then, that the two most infamous flashpoints of “ITIL Implementation” have been its lexicon and the brute-force insistence on processes being “prescriptive”.

Most debates about ITIL are actually debates about the utility value of ITIL. Lots of them would go away rather quickly if “practitioners” stopped trying to use it as a screwdriver instead of as a map.

By: Tim Coote Thu, 11 Jun 2015 09:11:00 +0000 Interesting. I come from a s/w background, so ITIL’s definition of CM was strange. The idea that you can work out the configuration items and states of an existing system is largely broken. And verification and audit never seem to happen. However, you do need to know what you’ve got/how the overall service hangs together. Devops approaches can help with cloud deployments, where it’s possible to move away from lovingly constructed edifices that touch each other in unknown ways (eg application team, database team, server team, network team all part of the system), to a sort of application reset button to put you back in a known state.

I’ve recently been involved in IoT initiatives and, despite the good h/w engineering practices around changing designs / components, configuration management and getting to a known state is sadly not well understood or appreciated. Also, many of the Config Items are not owned by the IoT system supplier (wireless networks, internet connections, phones), making CM even harder. fwiw, I’m putting tooling into applications to work out the e2e configuration (or fail fast if they cannot).

By: Charles T. Betz Mon, 08 Jun 2015 13:50:00 +0000 Agree 110% on Configuration Management. The language of that “process” (e.g. Configuration Status Accounting, Configuration Verification) is derived from early military/aerospace programs and is alien to most real world IT practitioners.

If there is one area in ITIL that I feel quite critical about, it’s configuration management. I think the ITIL conception, dating back to v2, has damaged the industry and resulted in tremendous waste and confusion.

By: Tim Coote Mon, 08 Jun 2015 08:32:00 +0000 One of ITIL’s issues is that it comes from half of the traditional IT delivery value chain and its early language (especially Configuration Management) is not well aligned with what the development community understands. As it’s become possible to “Treat Infrastructure as Code” and as the costs of building systems as a work of art, rather than a work of engineering became more apparent (I hope some of my work at Tideway helped there 😉 ), it’s become possible to reengineer the IT value chain to some benefit.

As the groups mix, the end user focus of ITIL and its common language, and the engineering practices of development have helped both communities and maybe even broken some of the negative sum games that they used to play: eg, Development (or project management) cannot avoid the costs of scoping out ‘design to run’ and Operations learns to finish jobs.

However, there’s a continuing language issue (eg CM), and some problems with the Agile approach in understanding the big picture. There’s also a lingering worry about the cost of skills to support all those multi-skilled people: for large scale systems, the route to a working solution can be arduous – and arguably can only work where there’s the room of a startup to make mistakes as there’s no legacy to grapple control of first.

By: Charles T. Betz Sun, 07 Jun 2015 23:54:00 +0000 I am reading Mintzberg’s Designing Effective Organizations – he is touching on exactly the issues – I am wondering if the fundamental issue is the attempt to separate process architecture from organizational design.

By: Charles T. Betz Sun, 07 Jun 2015 22:43:00 +0000 These are often heard points, although it is difficult to get a clear evidence-based understanding of ITIL uptake & satisfaction. If we accept for the sake of argument that things are as bad as you imply, the questions I have are: how did this happen? and how do we prevent it from happening again? There were very, very smart people involved, doing their best with the tools available.

I am on friendly terms with the BPM (Business Process Management) community. But in reviewing the major BPM authors over the last few days (Rummler/Brache, Harmon, Sharpe, Burlton) I have not seen any mention of the multitasking, context switching and queue saturation issues I believe are central. The overall process architecture of organizations with respect to the resource base is I think an important driver. The assumption is the organization can always tolerate another process, in the interests of deepening its sophistication.

My hypothesis therefore would be something like:

[Desire for improvement] leads to
[ungoverned increase in variety of processes] leads to
[thrashing and overburden]

It’s just a working hypothesis and I’m not sure how to falsify it. I will say, it may be obvious in hindsight, but I think I could easily have fallen into the same trap ten years ago. In other words, cause and effect understandable only in hindsight – the definition of systems complexity (e.g. in Cynefin).