DevOps, fad, reality or simply the death of ITIL

During a speaking engagement this week I mentioned the term DevOps to a bunch of ITIL guru’s who looked at me as though I had 2 heads!  Now maybe I do have 2 heads but if you are an ITSM person and ignore it you might be in for a shock as DevOps is growing.


Fist let me define DevOps. 


DevOps is an IT service delivery approach that found its foundation in the agile philosophy with an emphasis on business outcomes. The objective is to bring development and operations together to deliver enhanced business outcomes with continual code and configurations promoted to production.


I recently asked several people if DevOps is a standard or framework methodology only to get the reply that there is a minimal source of documentation and no manuals available for purchase. IT is more a culture where the assumption is that both applications and infrastructure are “code.”


An example I experienced recently while talking to a fellow passenger next to me in row 26 on a flight from New York to San Francisco – he was puling backlog from this allocated backlog, coding the change, promoting his code to the test environment, getting the results back and then promoting to production.  During a 6 hour flight he completed and promoted 6 changes to production including one that failed which he backed out. No Change Advisory Boards, no change entered into the system, no incident reports and 6 changes to production and no downtime.


Typically, DevOps brings development and operations resources together, typically physically who usually do not work well together,  not simply handing off to each other. Rather than being a methodology, DevOps leverages other methodologies such as Kanban and SCRUM, which are typically built on agile techniques. In breaking down these organization silos and reducing change into smaller bite size pieces removes the risk associated with complex changes. A fundamental component of DevOps is building the test plan up front to ensure that you test and of course backing up the production environment to ensure that you can easily recover should you have an error.


Now DevOps is not for all environments and cloud service providers are early adopters of this methodology. Starting with a clean sheet of paper they can develop efficient approaches to continue integration and deployment between development and operations.


So does ITIL completely go away? No, but the manner that you use ITSM processes does change. For instance, the use of automation and automated controls is critical. An example could be as you promote some code from Dev to Test, you could update the change (which was automatically created when the backlog item accepted) and upon the successful conclusion of the testing the relevant changes to the system including the CMDB, configuration, inputs, outputs, reports and impacted processes so ITIL is not dead, simply refined and automated.


Now DevOps is not for everyone and most organizations cannot start over, but, DevOps works well in the cloud or Web 2.0 environments so can I suggest that you look at these initiatives or your Mobility activities as potential candidates.


What do you think?

The following two tabs change content below.

Robert Stroud

Vice President Strategy & Innovation IT Business Management at CA Technologies
Robert Stroud is vice president of innovation and strategy for IT Business Management at CA Technologies. Rob is dedicated to the development of industry trends, strategy and communication of industry best practices. Rob is a strong advocate for the governance, security, risk and assurance communities working closely with the community to author, develop and communicate standards and best practices. Rob also advises organizations on their implementations to ensure they drive maximum business value from their investments in IT-enabled business governance. Following a four-year term as an ISACA International vice president, Rob served on the ISACA Strategic Advisory Council, and is currently serving as ISACA ISO Liaison sub-committee. Earlier, Rob served on the itSMF International Board as Treasurer and Director Audit, Standards and Compliance, the itSMF ISO liaisons to multiple working groups and spent multiple years on the board of the itSMF USA. An accomplished author and blogger, Rob is widely recognized for perspectives on industry trends. He also has contributed to multiple standards publications including COBIT 4.0, 4.1 and COBIT 5, Guidance for Basel II and several ISO standards. Rob served as an active member of the ITIL Update Project Board for ITIL 2011 and in various roles in the development of ITIL v3 including the Advisory Group, mentor and reviewer. Prior to joining CA Technologies, Rob spent more than 15 years in the finance industry successfully managing multiple initiatives in both IT and retail banking sectors related to security, service management and process governance. Follow Rob on Twitter: @RobertEStroud

This article has 11 comments

  1. Hi Rob,

    I first heard about the DevOps concept from Adam Jacob in Velocity 2010, and I have been a fan of the concept ever since. I believe there are two major aspects in DevOps, as a culture movement and as a technical approach of doing things.

    As a culture movement, DevOps is about collaboration. Whether you are in Dev or in Ops, we are still on the same team. It is also not possible to work in isolation these days – having a well-run IT requires a collaborative effort. Personally, I much rather work with the inclusive folks and ditch the ones who promote this us-vs.-them attitude. DevOps as a culture and professional movement can be empowering for the people involved.

    As a technical approach of doing things, DevOps emphasizes the need for automation in order for it to succeed. But in order to do automation well, the organization needs a certain level of maturity in the configuration management and QA disciplines. Also, fully automating every aspects of an organization’s infrastructure these days can be a daunting task. There are still a number of infrastructure components that cannot be easily automated and integrated into DevOps just yet, (networking and security components come to mind). There are hurdles to cross but, with more and more infrastructure components being abstracted by cloud these days, we might get there sooner. Hence I agree with your observation that DevOps seems to lend itself well for the cloud and Web 2.0 projects.

    In summary, I believe DevOps, when understood and applied properly, is a good thing for IT. I am also in agreement that how we apply ITIL can be refined and benefited with the inclusion of the DevOps concept.

  2. I’m a great fan of automation (and also of Development and Operations talking to each other!) but the process is only as good as the automation that backs it up – it is reminiscent of that adage “to err is human, to really foul things up requires a computer”

    My background is Application Life-cycle Management (ALM) and one of the interesting things is that companies struggle to work out whether to put us under the Ops division or the Dev division. To have an official “OpsDev” label sounds wonderful! Does it have only to apply to Agile Methodology only though?

    Charles

  3. @Charles, DevOps does not need to apply to Agile shops only. If your shop can handle the DevOps approach well, it can also benefit whether your shop practices Agile or the traditional, non-Agile methodoligies.

  4. David and Charles,

    Thanks both for your excellent comments and i am going to blog further on ITIL and DevOps in the next few days, assuming other shiny objects don’t get my attention in the interim.

    I too, as you can assume am a real fan of the value in automation and the value that it adds in terms of not just efficiency but also effectiveness and quality of end results. Lets face it, rarely does a computer add 1 and 1 and get 3 without a logic error. The concept as correctly identified must include effective and efficient process with the correct checks and controls in place. At the moment DevOps is typically in use within Agile shops and I predict it will expand beyond that over time as the culture grows.

    Your thoughts?

    Rob

  5. Rob, I don’t have hard data to support whether DevOps is typically used in Agile shops. According to Wikipedia, DevOps owes it root mainly to the people and ideas from the Agile community, which will support your thesis. Personally I hope the concept of DevOps will be utilized and expand in many shops, Agile or not, because the idea makes so much sense.

  6. Hi Rob, good article.  DevOps is common sense and as many might suggest not a new concept – just one that reflects the times we live in.

    A focus on (business) outcomes, is of course at its core to balance agile/scrum emphasis.  If I may, I’d also like to throw in consideration for the customer/consumer experience and the ‘user story’ styled explanation of what activity is being performed and why.

    The result here is what is termed ‘outside-in’ thinking.  I think DevOps is another piece of evidence that IT organizations are shifting back towards customer centric (OI) thinking….

  7. Hi Rob – well DevOps IMHO is a cry for help from the business. I’ve long urged my fellow ITSMers to adopt a continuous improvement program (not a CSI) and overlay CAPA guidelines and optionally Agile thinking. I’ve worked with the business Agile and outside-in communities these past years to refine a common sensical approach that allows a moving conveyor belt of improvement to be enabled. Frankly, ITIL is a bit to much 1-2-3-4 or waterfall-ish as interpreted by some, and it really doesn’t imply or encourage any ‘agility’. Quite the opposite, it seems to be ‘implemented’ as a set of silos that struggle to survive a DevOps approach.

    So is ITIL dead – nope, because its just a valuable reference of guidance. Its the traditional ITSM silo/process mentality thats dead. Remember, DevOps was also ‘created’ to bridge the gap between rapid development methods focused on customer outcomes and propelled by agile thinking, with what was meant to be a similar approach from with ITSM. Its ITSM that need to adapt.

    Is ITSM dead – nope. Its real easy to adapt as long as you stop trying to implement things. The USMBOK Foundation class covers Agile and continuous improvement programs and in my next round of online lectures I’ll make sure we address how DevOps fits in – to provide a ‘next generation service management’ approach….

  8. Oh one more point – I think its a total waste of time to try and marry DevOps with ITSM as suggested by a few – and worse – under a new name. They are ‘chalk and cheese’. ITSM is easily adapted as I mentioned earlier. They easily coexist.

  9. I think that DevOps is a great approach for dealing with quite a lot of the issues that have plagued IT organizations for many years, but this doesn’t mean that every IT service should use continual deployment. The two are linked but separate.

    It is quite legitimate for an organization to embrace DevOps, and to use Agile with continuous integration and continuous deployment for some services, but to use more traditional development and release methodologies for others.

  10. Ian,

    There is no doubt the business is calling for accelerated value from IT and fundamentally IT have simply not delivered at the rate and pace of change mandated with the ever-growing adoption of technology for business. As you reference in this new world where agile allows the requirements to bend and flex with the business DevOps, or ValueOps as some are now redefining continuous release is more applicable as is customer centered design and delivery.

    I am seeing a increased movement to merge DevOps and ITSM practices especially in the ITSM world which is simply an accelerated change process… where do you see the gaps?

    Rob

  11. Stuart,

    Totally agree, I am seeing the blended model rather than one be leveraged especially where a balanced decision is taken, that said we are a people of extremes and I have seen organizations throw out an ITSM implementation wholesale and replace with DevOps only to find them having to reimplement some former ITSM investments. Balance is key as you allude.

    Rob

Leave a Reply