Sé el primero en recomendar esto
Let’s get this straight. ITIL is not about implementing dozens of processes, or about establishing a CAB to review every change request, or about the never-ending story of creating a CMDB. The ITIL framework has been designed to help IT organizations to move from being a black box technology provider – often viewed as a disposable cost centre – to becoming a service provider, and a true partner for the rest of the business. We know – we own the framework.
Unless your customer can achieve their objectives with the technology you run, and can get assistance when needed, no-one cares whether your architecture is built on a monolith, uses microservices, or can brag about being serverless. Agile as a mind-set covers the whole value chain, but common practices are limited to development only. DevOps as a philosophy covers the whole value chain, but common practices are limited to the deployment-focused intersection of development and operations only. Understanding the organisation's strategy, developing the product strategy, and dealing with customer issues are expected to be taken care of by someone else, as if by magic. Because of this, DevOps faces a risk of becoming the largest local optimisation exercise ever undertaken for way too many organisations
In tens of thousands of companies around the world, ITIL has helped to develop an organizational capability that has provided them with a competitive advantage. More than three million people have been certified, and ten times as many trained over the years. Yet, we have all heard the horror stories, too. So what is it that separates a successful adoption of ITIL from an unsuccessful attempt at implementing the framework? What are the common problematic practices and anti-patterns we have seen in the wild, and what does the guidance in ITIL really say? How can you move from a broken approach to IT Service Management to one that delivers value. Can you still use ITIL in the DevOps world? Do you even need to? Or, perhaps, the questions is whether DevOps can survive (in the enterprise) without embracing the service mind-set.