ITIL , DevOps and IT4IT

1. As the name suggests,DevOps is a handshake of development and operations with the adoption of agility. The
objective of DevOps is to diminish the barriers between software development and IT operations .The development
process is focused on delivering new features faster; operations are focused on a manageable and stable production
environment. During the development process,many concerns of different stakeholders are taken into account,but
often the requirements of the operations stakeholder are forgotten.One of the principles of DevOps is to involve
operations in the development process and to involve developers in the operations environment. Or go even further,
do away with the divide altogetherand have a combined production team.
Despite some common misperceptions, ITIL is not explicitly opposed to Agile and DevOps. The Service Design
volume supports iterative and incremental design,and mentions Agile and XP. And Service Strategy, with its strong
grounding in current management theory, mentions the need for continualfeedback between the ITIL service
lifecycle stages (Strategy, Design, Transition, Operations, and Improvement). And finally ITIL has made an
indelible contribution in promoting service-centric, outside-in, customer-focused thinking as an alternative to overly
technical and piecemeal approaches to supporting the customer.
Volume three, service transition of ITIL, is where we see the most profound impact of DevOps - specifically in the
areas of change management, release, deployment and monitoring.
“DevOps is the practice of operations and development engineers
participating together in the entire service lifecycle,fromdesign
through the development process to production support.”
“ITIL and ITSM still are best codifications of the business processes
that underpin IT Operations, and actually describe many of the
capabilitiesneeded in order for IT Operationsto support a DevOps-
style work stream.”
“The IT4IT is a vendor-neutral open standard Reference Architecture
and value chain-based operating model for managing the businessof
IT.”

2. In the well-managed and well-controlled IT environments we have experienced (and continue to experience) long
release cycles; with perhaps just one or two major application releases per year. Change management and precise
control over the configuration items help us understand the impact of what we are doing, and enable us to roll back
in the event of an issue or manage situations using incident and problem management. This managed release of new
features is accompanied by planned service outages,something that IT has imposed on the business historically, but
which is increasingly spurned.
We are also witnessing the development of a new paradigm in the IT services industry today: as customers seek to
award smaller outsourcing contracts to multiple service providers we are seeing the emergence of service integration
and management (SIAM). SIAM could be considered to be an evolution of ITIL in some respects; joining together
the delivery of technology towers from different service providers, all managed and as sured by a SIAM function that
undertakes various ITIL processes (and more) across the whole landscape.
When we discuss DevOps approaches we now also, from time to time, implement Kanban techniques to manage the
workload of a continuous release train of small incremental changes,perhaps performing ten releases per day,
delivering software and adding new features and functionality to address the demands of the business.This is a
whole new way to deliver agility right into the production environment; exploiting automation technologies to give
consistency,repeatability and efficiency. Another area where we have a collision of these different types of
management is when we have DevOps application deployments that are hosted on traditional shared hosting
services. We need to marry the continuous and lightly-managed Kanban environment with the heavily ITIL change-
managed network and hosting infrastructures.
As with other agile development techniques a standard ‘waterfall’ approach is incompatible with DevOps and
Kanban; we can’t just wrap old-world techniques around new approaches and expect them to work. The same
applies to the typical CAB (change approval board), often held weekly on complex services or daily in busy
environments
This has to be replaced by automated testing,approval and release techniques.In such a dynamic environment
product managers have their own preferences and these drive the development of any new piece of functionality.
Quality assurance managers need to ensure functionality is not broken by new features, and special care needs to be
taken to ensure configuration issues don’t affect othercustomers if there is a common code base.
The service desk, ticketing systems and service monitoring tools all rely on the information contained within a
configuration management database (CMDB); if DevOps now begins to dynamically change the environment we
need to ensure we capture this in the CMDB too.
This means that the DevOpsand ITIL need to work hand in hand, or else, we would be in a situation
wherein we cannot get the complete benefits of DevOps and ITIL. And it’s well said that things half
cooked are more dangerous.

3. In order to remove the barrier between ITIL and DevOps, the best approach would be to implement ITIL using
DevOps practices which would ensure that we have a win -win agreement between both since they both alone are
not sufficient in today’s demanding IT world that expects fast paced automated IT environment with quality,
efficiency and optimal cost.
To help implement the guidance contained in the ITIL v3 framework, below DevOps practices can be adopted:
Focus on better communication
Build softwarefor discovery
Establish baseline releases
Implement continuous delivery
Automatethe workflow
Amplify feedback loops
Improve process and automation iteratively
All these will ensure that we are not ignoring the importance of ITIL and DevOps and we have a common platform
to cater to all their requirements.
Now, the next interesting topic is IT4IT which also needs to be understood and considered.
The IT4IT Reference Architecture provides prescriptive guidance to design, source,and manage services in a
business value chain-based framework called the IT Value Chain
The IT4IT Reference Architecture and ITIL are complementary. ITIL is a process and capability-based framework
that provides best practice guidance for IT Service Management. The IT4IT Standard provides an information (data-
driven) model and reference architecture that offers prescriptive guidance across IT management. The IT4IT
Standard provides a foundation upon which best practice-based process models like ITIL may run.
Many times ITIL process owners are not aware of their adjacencies nor their place in the value streamto support an
IT Value Chain-based IT operating model. But wherever you are within an IT organization it is very important to
understand yourfunction in the wider value chain and yourpart in driving value for the business by measuring
service outcomes to the business – not limiting your work to doing continuous improvement on one IT process.
Finally, because of its strong information model, the IT4IT service backbone will give you the basis to report out to
the business on yourservices; for example, on where the problems/issues are in yourservice quality or delivery. By
organizing your services and service delivery around the IT4IT service model and information model, you get the
value for your IT leadership.