DevOps and ITIL at IBM Innovate - Can DevOps learn from ITIL?

I thought I was fairly happy with DevOps until I came to Innovate. Then someone from the media told me that DevOps was incompatible with ITIL processes and I started to worry a bit (although that certainly isn’t the official IBM view). And what is DevOps? At its simplest, I think, it’s extending Agile to Ops and allowing Developers and Operations to work together more closely, for rapid application delivery, using automation. It might be incompatible with some over-bureaucratic implementations of ITIL but I doubt if it is incompatible with the ITIL life-cycle model because that concerns itself with what is necessary to deliver a reliable business service and a lot of informed thought has gone into this. What could DevOps safely leave out? Besides, most of what I know about DevOps came from a largely ITIL-oriented community, so I’m surprised if it’s entirely hostile to DevOps.

DevOps is interesting just now, partly because IBM has come up with a strong DevOps story at Innovate: in its essentials, it’s about creating a shared pipeline for getting applications software from an agile development environment to production, via agile ops processes, with high quality. The quality comes partly from taking advantage of simulation, courtesy of GreenHat, to eliminate most integration problems early on, without the overheads of setting up real external environments. It was good to see Jamie Thomas (VP of Tivoli Strategy and Development) and Harish Grama (VP of Rational Product Development and Delivery and Customer Support) talking DevOps from the same platform.

One of IBM’s stories is around its SmartCloud Continuous Delivery beta and the implications of this for developers. This is technology still in beta because, according to Ruth Willenborg (an IBM Distinguished Engineer who presented at Innovate with fellow Distinguished Engineer, Steve Abrams (see developerWorks here), the broader life-cycle issues – Release Management, Approval Processing and integration with ITIL and other operational and change management frameworks – are still being worked on (continuous delivery out of the box seems to be the part of IBM’s DevOps story that might need fleshing out).

This is potentially a very good story, I think, and represents progress from where we often are today, as long as it doesn’t take too long to deliver. That is, it addresses the issue of ops acting as a bottleneck to rapid application delivery, and looks towards decreasing the barriers between dev and ops.

Nevertheless, I have some concerns that this may be seen as a developer-oriented story (hardly surprising, given the Innovate audience) and could miss out some of the “business service delivery” ideas from the latest ops thinking. What the business wants, I believe, is a whole business service, with both manual and automated processes (I don’t think many, if any, business-level processes are ever entirely automated), contracts, SLAs etc. around a software application, not just software – and, to be fair, Willenborg (and the people I meet from Tivoli) seems entirely happy with this point of view (as reflected in her Innovate presentations with Abrams). I suppose I still need to be entirely convinced that the extremely welcome reduction of the barriers between IBM’s Rational and Tivoli silos (which I’ve commented on before and which is highlighted by Danny Sabbah’s move to Tivoli) will actually bed-in in practice, in the near future, and be reflected in the processes actually adopted by IBM’s customers. We shall see – I’m sure the change in IBM is real (I’m less sure about all of its customers eliminating dev and ops silos) but changes are sometimes elastic and sometimes the status quo (in this case, silo’d thinking) returns.

I hope the sort of IBM DevOps-oriented initiatives it talked about at Innovate do become a new status quo for its customers (and perhaps some entirely laudable process initiatives from the IT industry generally that never really made it into the real world have made me over-cynical). For example, Chandra Venkatapathy (Sr. Product Manager, IBM Rational) tells me that, in the IBM vision, developers and operations work together to create patterns for deployment into the business that include early performance optimisation and testing of operations requirements in production-like environments (this is made much easier by cloud virtualisation, of course), thus removing operations as a last-minute (and expensive) barrier to delivery. Venkatapathy also points out that IBM sees visibility and traceability as key to developers and operations converging on optimal SLAs during the development process, not as a bolt on afterthought, which is good too.

I’d like to see developers’ horizons really stretched by the DevOps initiative – for instance, I think that they could even benefit from looking at the itil service lifecycle model for business service delivery, with its focus on business outcomes and its “service knowledge management system” (SKMS) to manage everything necessary for the maintenance of a business service, not just the IT components.

OK, I realise that most developers have hardly heard of ITIL (but a few have, especially in Europe) and that many ITIL practitioners aren’t thinking at the SKMS level anyway. However, I think that, if you separate out the logical model of ITIL from the physical “best” practices (which perhaps relate to an older style of business automation) beneath it, ITIL is a valuable resource; and that using it will prevent developers “reinventing the wheel” as they become increasingly focussed on business service delivery rather than just software delivery.

Today is indeed a good time for developers but I think that some, or perhaps many, of tomorrow’s developers may look a lot more like ops people, orchestrating services (probably from the cloud) in order to deliver business outcomes.