What’s ITIL got to do with DevOps? Lots more than you’d think

Source:-https://devclass.com

Sponsored It’s been over a decade since DevOps first burst onto the tech world, promising to blow away organisational silos and old ways of working that were strangling companies’ ability to innovate.

Many DevOps adherents embraced it as an antidote to the steady-as-she-goes approach they saw in traditional IT Service Management (ITSM, as personified by ITILbest-practice guidance).

But that’s a view that can rapidly lead to an us and them situation – which is ironic, in that both approaches are ultimately focused on delivering value to the customer. ITIL has been around since the late 1980s and is amongst the most widely held IT certifications in the world. ITIL v3 was published in 2007 and updated in 2011. The latest version, ITIL 4, debuted last year.

So, it’s significant that DevOps first emerged at the end of the noughties, between the two major ITIL updates. DevOps – along with its close associates, continuous delivery and continuous integration – holds out the promise of faster delivery of software, untrammeled by bureaucratic processes and other perceived blockers to innovation.

Advertisement

DevOps devotees often point to “waterfall” software releases as summing up the problems with traditional ITSM, describing them as overly cautious and simultaneously too risky, delivering too little, too late and too infrequently. Far better, DevOps’ adherents would say, to have multiple, smaller and faster releases, which reduces risk while delivering value to the customer – and the company – more quickly. It’s a view that also puts developers at the centre of the universe, exactly where it seemed they should be – at least to developers.

So has DevOps won the battle for hearts and minds, delivering a blueprint for how all organisations should deliver software and technology in future? And if so, where does that leave the vast body of expertise and knowledge built up around ITSM, particularly in the shape of ITIL?

The answer to the first question is “yes, partly”, while the answer to the second question is “probably in exactly the same place”. The reality is the two approaches were never as far apart as it might have seemed, and ITIL 4 goes a long way to explicitly closing this perception gap.

To break down silos, open the doors of perception
As Mark Smalley, lead editor of the ITIL 4 Specialist: High-velocity IT module, explains, “There’s a tension here. Within the software development area, fast is good and fast is driven by milestones and stuff like that. Whereas traditionally in IT service management, safe is good, because business is going to fail if the systems fails to drive and support your business. So we have that seemingly irresolvable paradox between safe is good and fast is good. How do we get around that?”

One way is by simply shifting our perspective and considering the broader context of both approaches.

As Smalley explains: “One of my observations of the DevOps world is that it can be very narrow, very much focusing on the deployment area.” In the DevOps Handbook, he says, “Most of the practices are about that narrow deployment.”

But, he continues, “If you step back a bit and look at the DevOps Handbook’s principles, you can apply them much more broadly to the prequel to DevOps and to the sequel as well.“ And this plays to the broader worldview that ITSM takes.

Smalley says it’s also worth remembering that the evolution of IT service management as a discipline was itself a reaction to systems that were rapidly evolving and needed more careful management and delivery. IT service management had a tendency to lock things down, “with the best of intentions”. But this also slowed things down, eventually prompting the Agile movement/.

“And now I think ITIL is catching up to recognise that things have changed,” he says, and is “very much inspired by the changes in the Agile community in the DevOps community to reconstruct the way things were done previously.”

The result, he says, is that IT services management is now “much more capable in interacting effectively with Agile teams and DevOps teams that have a different way of working.” And, he continues, IT service management has rethought its own practices, “So you see integration of DevOps practices.”

For instance, he says, the traditional “big release” approach, bundling together numerous changes once or twice a year, did indeed carry enormous risk. “Because you don’t do it often, you don’t build up the capabilities to do change well,” says Smalley. “Whereas if you break it down into small changes, not only is the intrinsic risk of a small change, smaller, but because you change more often more frequently, you’re building up better change capabilities. And suddenly you’ve reduced that tension between fast is good and safe is good.”

At the same time, Smalley says ITSM brings an expanded idea of what it means for work to be “done”. Agile focused on a “potentially shippable increment” of software, while DevOps extended this to “shipped” software, he says.

“But I’d like to extend it looking at IT Service Management ideas, thinking about co-created value, where it’s only valuable when somebody actually does something with the system,” he says.

“So you should extend the scope of the product team, not only to deploy stuff, but actually make sure that the users are using it well, getting feedback, thinking about the service experience, for instance, and extending the traditional service level agreements, which are often very clunky and difficult to define, to address outcome and experience.”

Many of these ideas were worked into the 2011 ITIL update, he says. They have been further refined in ITIL 4, in the form of seven guiding principles: focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimise and automate.

All of these principles will immediately ring bells for anyone with even a passing familiarity with DevOps.

Even more obviously, the ITIL 4 qualifications explicitly focus on embedding Lean, Agile and DevOps ways of working, for example in the ITIL 4 Specialist: Create Deliver and Support and High-velocity IT modules. At the same, a focus on value streams and the importance of cultural principles runs through the entire syllabus.

It’s also worth considering that the latest version of ITIL lays the groundwork for a common perspective on DevOps. As Smalley points out no one organisation “owns” DevOps, and “because there isn’t an official owner of DevOps, your interpretation is just as legitimate as mine.”

Despite this, some research suggests that in the last couple of years, ITSM personnel are less likely to get involved in an organisation’s DevOps initiatives. This would be a lost opportunity for both sides.

AXELOS – the organisation that develops and enhances ITIL – is clear what ITSM staffers should do to redress this. First, they should not wait for an invite to get involved in DevOps initiatives – this is all about breaking down silos, and it’s in the interests of both the organisation and individual teams to be working together.

On a purely practical level, and in the spirit of Stephen Covey’s “first seek to understand, and then to be understood”, ITSM staffers should view their ITIL practices through a DevOps lens. This will help identify what fits and what doesn’t and expose any real – not imagined – areas of duplication or potential conflict. Once this happens, there may be far less difference in objectives and practices than either team might think at first.

Teams should also work together to create common metrics, which makes it easier for DevOps and ITSM teams to cooperate. If they don’t, at least one team will be out of sync about what’s really important to the business. At worst, both teams will be.

So, even as businesses embrace the promise of DevOps, it’s in everyone’s interests to recognize the accumulated knowledge of the ITIL community and the fact that it is embedding DevOps and other new practices at the heart of its approach. Ultimately, both groups are in the business of delivering value to the customer. Everything else is a matter of perspective.