There’s a battle afoot within many IT organizations.
In one corner is the “up-and-comer” DevOps, with its promise to be responsive and deliver technology-based solutions with velocity, while making positive changes to the culture of an IT organization.
And in the other corner, the wily veteran ITIL® , featuring its time-tested advice for supporting and delivering technology-based solutions. Over its 30 years of existence, ITIL – done well – has been shown to work. ITIL has often been referred to as the “de-facto” standard for IT Service Management.
Within many organizations, the battle is real.
Will it be ITIL?
Or will it be DevOps knocking ITIL off of its throne?
And how will ITIL4 impact the battle?
ITIL vs. DevOps
ITIL has long been a popular methodology for the delivery and support of services based on the use of technology. ITIL has gone through a number of iterations since first appearing in the 1980s, with the most recent iteration published in 2011.
Meanwhile, around 2009, a grassroots movement started that eventually became known as DevOps. DevOps emerged as a better way for IT development and IT operations teams to work together.
Many organizations took note of the movement and began adopting DevOps. DevOps was seen as a way to become more responsive to business needs and improve the velocity of solution delivery. DevOps was embraced as a way to exploit emerging technologies and capabilities – things that ITIL books didn’t discuss.
In the meantime, ITIL guidance, other than publication of ITIL Practitioner in 2016, stood in place for nearly eight years.
My perspective of ITIL adoption
I’ve always thought of ITIL as a collection of good “common sense” for ensuring that the use of technology results in business value. Yes, ITIL books were a bit wordy and dryly written, but they contained good knowledge and wisdom. With good planning and execution, the concepts and guidance described within ITIL just plain work.
But the use of ITIL has not been without its challenges.
Some have perceived ITIL as being bureaucratic and “waterfall-ish”. I would agree that parts of the guidance seemed more suited to waterfall development (e.g. Release and Deployment), but perhaps that reflected the era. Where I’ve seen bureaucracy, it was due to how ITIL was adopted – and not because of was advised. That’s because many of the companies that adopted ITIL over-engineered processes, focused on “control” and not “enablement”.
Many ITIL adoptions were aimed only at IT operations. This approach essentially put a fence around an organization’s IT infrastructure. ITIL concepts were then forced onto other parts of IT. ITIL adoption was treated as an “IT thing”, expecting others within an organization to simply comply.
It’s these types of experiences that are frequently referenced by ITIL detractors. To them, “ITIL” is a four-letter word. In my experience, many (most?) of those people either a) never took the time to experiment, learn, and improve their ITIL-based ITSM implementations or b) really don’t know what they’re talking about.
Having said that, I will agree that aspects of the ITIL framework have become a bit dated. While the concepts remain fundamentally sound, guidance for leveraging or incorporating new and emerging technologies, methods, and capabilities are sorely missing from ITIL.
My perspective of DevOps adoption
I like DevOps. I like the fresh perspectives on how to deliver value while leveraging emerging technology. I like the idea of smaller increments of work delivered more quickly. The overarching concept of CALMS – culture, automation, lean, measurement, and sharing – is a great approach to ensure that these critical aspects are both top of mind for the IT organization and considered with each product produced by IT. DevOps has been embraced by many organizations as a way to be more responsive to ever-changing business needs.
DevOps addresses an area of ITIL that always has been underdeveloped, or (as some would say) ignored – application development. While there were books about application management, ITIL has not offered much about application development.
But like ITIL, DevOps adoption has also seen its challenges.
Because of some of the hype that surrounds DevOps, many companies expect to immediately jump to tens and hundreds of deployments per day. The fact that leading companies in this space invested years of effort to get to that level of velocity is often overlooked. Some organizations expect to just throw technology at the issue, rather than develop the workflows (processes) needed to enable that velocity.
Many DevOps adoptions appear to be very “development” focused, rather than viewing IT holistically. Terms and concepts like “DevSecOps” and “BizDevOps” have emerged to underscore the need to take a holistic and inclusive approach to software development.
Some have taken a technology-centric approach to DevOps adoption. While I don’t hear of this as often now, many envisioned DevOps as a way to circumvent necessary controls or to eliminate the IT operations organization. There are also some that view DevOps as just “automation”, or an excuse to reinvent good working practices if for no other reason than “they can”.
ITIL4 is being introduced this month (February 2019) with the publication of the Foundation volume, with more in-depth guidance to follow. ITIL4 represents an evolution in, not a replacement of, ITIL guidance. ITIL4 Foundations delivers some interesting new concepts, such as the Service Value System and the Four Dimensions model. ITIL4 also revisits some previous concepts, such as the Guiding Principles that were introduced in Practitioner.
What makes ITIL4 different than previous versions of ITIL?
Here are a few of the differences:
- Emphasizes practices over processes – Too many look at ITIL as a collection of processes. With the introduction of practices, ITIL4 has de-emphasized processes in favor of value streams and practices.
- Promotes systems thinking – Lifecycle approach described in ITILv3 sometimes had unfortunate effect of promoting silo thinking within IT (even though ITIL guidance clearly discussed the interdependencies between lifecycle phases).
- Acknowledges that there are other models and approaches – ITIL4 puts in writing that it embraces new ways of working, such as Lean, Agile, and DevOps.
Who will win the battle?
How will ITIL4 impact the battle for the hearts and minds of IT organizations? Is ITIL4 “too late”? Only time will tell. But DevOps and ITIL4 have much in common. Both want to make the best use of people and technology to deliver value and meet the needs of the business. Both promote continual improvement and effective measurement. Both advise that in order to deliver value that first IT must understand what is valued by the organization.
Most IT organizations will need some of either and a lot of both to have success. Both have weaknesses and strengths. The fact is that no single approach or framework will be able to accommodate all possible situations.
The key to success is that the modern IT professional must understand the business of the business, then decide how best to leverage frameworks, models, approaches, and standards to deliver the outcomes and value needed by the business. Perhaps this is where ITIL4 will have an impact.
Tedder Consulting is offering DevOps Foundation and ITIL4 Foundation classes next month! Click here to learn more.Share