IBM Innovate Fytte 2

I thought I was fairly happy with DevOps until I came to Innovate. Then someone told me that DevOps was incompatible with ITIL processes and I started to worry a bit. 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 lifecycle 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, 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.

This is good, and represents progress from where we often are today. 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 is a Developer-oriented solution (hardly surprising, given the Innovate audience) and misses 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 manual processes, contracts, SLAs etc. around a software application, not just software. I think that developers could even benefit from looking at the ITIL 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 (perhaps relating 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.