Mike_Kiev - Fotolia

It's ITIL and DevOps, not ITIL or DevOps

With Practitioner, ITIL targets a more digestible and flexible change management implementation. Is it a good compromise between traditional IT and DevOps?

With additional automation and tools brought by the DevOps movement, IT organizations can take the collaborative,...

lightweight ITIL approach for which the framework was originally designed.

DevOps promises more agility, faster change and more tuned-in IT operations with business needs, which are similar aims of the IT Infrastructure Library (ITIL) framework for IT service management (ITSM). Yet, many IT pros can't see ITIL and DevOps together.

The nightmare scenario of ITIL adoption is weighing down IT organizations with draconian change management, said Kaimar Karu, head of ITSM at AXELOS, the London-based joint venture company that maintains the ITIL framework.

"[Organizations create] a change advisory board [CAB] with an interdisciplinary group. Every change needs to go through the CAB, but they meet every few weeks -- or month," he said. This slows down IT and ruins responsiveness, and it doesn't foster much critical thinking about automation or impact of given changes -- a stark contrast to the change-embracing, fast-failing, business-tuned mantras of DevOps.

IT operations teams have over-engineered IT service management from either a sense of seizing control or from a lack of proper education on how to use it -- or both. "You want enough process to keep yourself from screwing up, but you can't have so much that you screw yourself into the ground," said ITIL consultant Doug Tedder.

To address improper implementation, AXELOS added a tier to its training and certification levels: ITIL Practitioner. This course translates the fundamentals of ITIL into ways to improve processes, organizational change, continual improvement to service and flexible change along with the business. This level of training enables IT teams to ask, "'What are we doing well, and what could we do better?' And, 'What's the business case for doing this?'" Tedder said.

A little bit of everything that works

With Practitioner, ITIL acknowledges that every organization is different and every initiative is different, explained AXELOS CEO Abid Ismail. It also doesn't assume ITIL is the answer to everything, and instead shows how to adapt ITIL to suit particular goals and priorities.

"Practitioner shows that Agile, Lean, DevOps -- they're all more aligned with ITIL than previously thought," Karu said. The combination of these concepts pushes IT organizations to improve and advance IT service management and think outside of IT.

Ohio State University's IT team combines its ITIL implementation with any other process management concepts that work, while following industry best practices as closely as possible, said Bob Gribben, director of service operations at OSU. The university has metrics in place to see when processes work and show value. If a process is floundering, the team looks for ways to do it better, he said.

More IT shops will need to follow suit. Through 2021, 80% of organizations that do not embrace multiple good ideologies -- Lean, DevOps, ITIL, Agile, Kanban and the like -- risk losing market share, according to research presented by George Spafford, research director at Gartner's IT Operations Strategies & Solutions Summit, this May in Washington, D.C.

DevOps methodology and culture was always implied in ITIL, but not explicit. ITIL isn't incompatible with modern infrastructure, which just brings a faster rate of change to IT, noted Kris Saxton, founder of the London-based IT consulting firm Automation Logic.

When you build DevOps on top of ITIL, "there's control, but it moves the ball forward with bite-sized units of work," said Tedder, who participated in the review board for ITIL Practitioner. Tedder admitted he hasn't yet seen ITIL and DevOps implemented harmoniously.

The typical fail scenario for ITSM: No business case, no results

ITIL consultant Doug Tedder explains where most IT organizations go wrong.

The IT operations team takes care of the operational component of ITSM by standing up incident management, a rudimentary change management process and a service catalog that's actually more of a request-fulfillment funnel. But they don't understand how processes interact and don't have an overarching plan. Operations drifts away from the business need and tools don't support the business. When the IT team tries to wrangle these individual aspects of service management into a working setup, they run into resistance from the executives who already saw enough spending on ITSM at the beginning of the process. Soon, people work around IT, because it's too difficult to do business with them, or outsource IT.

Vision and strategy, then IT

The culture of a collaborative approach to IT and business outcomes unifies various ITSM approaches, such as DevOps and ITIL.

The question an IT shop should start with doesn't involve IT. Practitioner teaches IT organizations to first ask, "What is the vision?" If the organizational vision isn't clear, is there a department vision, or team vision? Once you know what the vision is, you must translate it into concrete changes and then follow up with measurements for success.

Mature processes alone don't equal success, neither does increased app release frequency, Spafford pointed out. Success is enabling the vision, whether that's through a formalized escalation process, increased app updates or other mechanisms.

Whether you're taking a DevOps approach, following the ITIL framework or doing some mix of DevOps and ITIL, the mantra should be -- paradoxically -- slow down to speed up. "People try to eat the elephant in one bite," OSU's Gribben said. Step back, catch your breath and take your time, he advised. OSU experiences problems similar to a lot of corporate IT shops: It's difficult to keep infrastructure up to date and at-pace with users' needs, and they must consider regulations and security for data before adopting new services.  

"We live in an instant-gratification society," Gribben said, but the best way to make things happen fast is to ask: "'How do I run this five or 10 years down the road? How does the service look [then]?'"

If it takes a year to roll out and test a new application, service or IT tool set, that might seem like too long in the DevOps fail-fast world -- but the worst thing you can do is roll something out, start using it and then realize you have to change it, Gribben said. "More change is not self-evident as a good thing," Saxton agreed, whether the Agile evangelist in your organization says so or not.

IT shops that embrace DevOps must avoid short-term benefit that comes with long-term operational and support cost, Spafford instructed in his Summit talk. That's where skipping the initial vision and alignment questions comes back to bite them.

Meredith Courtemanche is a senior site editor in TechTarget's Data Center and Virtualization group, with sites including SearchITOperations, SearchWindowsServer and SearchExchange. Find her work @DataCenterTT or email her at [email protected].

Dig Deeper on DevOps and IT Certifications and Training