ITSM vs. DevOps - Agility vs. Control - is this really battle royale? - Matthew Hooper VigilantGuy Digital Transformentalist - Create High Performing IT
ITSM vs. DevOps – Agility vs. Control – is this really battle royale?
Agility vs. Control
poster227x227
© 2000 Battle Royale Production Committee. All rights reserved.

ITSM has been getting a bad wrap lately.It seems it’s hot sibling DevOps is getting all the attention these days.

DevOps is Lean, Fast, and all the Cool kids love hanging with it.
I get it.  With ITSM it’s kind of like you want to get to 2nd base, but you have to fill out 3 request forms and appear in front of a committee.
But before you go thinking DevOps is cheap and easy… there are more commonalities in values and principles with these two philosophies than you think.
ITSM Focus:
DevOps Focus:
Incident Management
Optimizing layers of human interaction and escalation.
Self-aware code and infrastructure that can self-heal.
Problem Management
Analyzing trends between disparate systems and eliminating systemic issues.
Outputting known current state for external correlation and point of failure determination.
Configuration Management
Building traceability into assets through logging and mapping dependancies with service relationships.
Utilizing common definitions for self-discovery and leveraging software defined configurations for self-mapping.
Change Management
Orchestrating operational changes to reduce risks and conflicts, and to provide traceability and accountability.
Leverage trusted configuration models to determine risk and automate changes with built in recovery for risk reduction.
Knowledge Management
Capture information and make it available in context through systems and process.
Stream information to all through real-time collaboration and let individuals self-filter based on accountability.
You can see why DevOps sounds so attractive.  The complexity and technical debt of legacy systems forces most organizations to focus on ITSM controls.  It’s a natural response and will, if done properly, establish some much needed control within the organization.
Where most ITSM sponsors make a grave mistake though, is in selling ITSM as way to increase IT’s agility.  It won’t, it can’t.  IT will make IT more predictable, accountable, and effective, but not more agile.  However, ITSM provides a great foundation for DevOps ability to increase speed through automation.  I’ve heard of few, if any, organizations using DevOps for legacy systems, it’s always been for new systems.
If an organization can embrace the shift to allowing systems manage systems, then they can capitalize on this foundation of stability that ITSM practices has established.  Enabling the values fostered by DevOps to create a fluid release stream that is scalable will thus position the business value streams to test new market opportunities faster and with less risk.
DevOps take us to a Business Service Management focus, a customer centric focus where the recognition of technology services are creating value for end-customers.  ITSM establishes this foundation for the end-users in the enterprise.  BSM is built on ITSM and thus a poorly implemented ITSM capability will lead to a instability that will make DevOps and BSM initiatives a nightmare to manage.
So let’s get off the Kill ITSM, ITIL is dead, blah blah blah soapbox and start acting with a sense of reasonableness.  Operational Excellence + Speed of Innovation = Business Agility….
In my next Blog I’m going to tackle the reasons why ITSM “fails”… hint it has nothing to do with ITSM!
Written by

Digital Transformentalist Twitter: @VigilantGuy http://twitter.com/vigilantguy Linkedin: http://www.linkedin.com/in/matthewbhooper Web: http://www.vigilantguy.com Matt Hooper is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimization. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on Social Media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology. HackBizTech.com

9 Comments
  • My Homepage says:

    … [Trackback]

    […] Read More here: vigilantguy.com/itsm-vs-devops-agility-vs-control-is-this-really-battle-royale/ […]

  • Karsten says:

    Thank you for sharing this post, Matt. I have been looking into DevOps (more from a security standpoint) recently, and would agree that both ITSM and DevOps can coexist.
    Eventually, the BSM would be great to achieve, but this could be quite an effort. Security, for example, might sometimes be seen more as hindering the business, instead of supporting it. Yet, positive developments can be seen. I am looking forward to the next post, you made me curious.

  • Erez Nir says:

    I like the way you think. The need for speed is not at odds with the need to have audit-able systems/processes which is what ITIL, ITSm etc. are trying to deliver. After all, to deploy consistently bad code is no help to the business in achieving its goals. Many of the ITSM processes can be totally or almost completely automated and still benefit from the power of workflows, audit trails and the ability to trace back a problem when you are awoken at 2AM. I loved the Google or Netflix approach of ‘Dev carry the pager’ but the reality is (and I’ve yet to be proven otherwise) that developers don’t really like to carry the pager. They are Devs because they like to write code. Rushing it out without some guardrails is not such a great idea. At least not until an organization can fully trust its automated processes.

  • Google says:

    … [Trackback]

    […] There you will find 27862 more Infos: vigilantguy.com/itsm-vs-devops-agility-vs-control-is-this-really-battle-royale/ […]

  • Julio Vieira says:

    I fully agree with your article, I have started to think on the same way when too many conflicts are happening at the Change Mgmt process and Release Mgtm at a DevOps enabled team…so I had to change the process with less assessments on known risks to gain speed Ness, but this is not even close to what is needed. I’m still researching and I’m more tending that we need to build something in between both ITSM and DevOps. I’m studying but thinking that we could have different type of management by cloud layers or stacks, I still think we can not manage everything such as DevOps, but a composition in between Infra vs. Application might works…very nice article..if you need help let me know. I can definitely help. Take care

  • Wolfram Schnur says:

    I would say take the best of both worlds. If we are talking about stability and quality of the production systems you simply have to stick to ITIL. Without any doubt automation is also a good approach but you have to take into account that automation is getting harder the more you go up in the ISO/OSI layer. However automation -if feasible- will also support stability and quality.

    • matt_hooper_2000@yahoo.com says:

      Thanks for your comment Wolfram. Statistics and practice are showing that a rigors ITIL implementation is actually not increasing quality or stability. The increased layers of governance are only removing the the insight to change impact. The delays in release require larger more complex releases, which are too difficult to isolate faults. With smaller more frequent releases as prescribed by DevOps, it has shown to increase quality and stability. The challenge is in audit and controls. Frequent changes are harder to track, thus automation is the only way, which requires an investment in tools, methods and team commitment.

  • Bas says:

    Do you have any solution / best practices to manage the challenge of compliance (e.g. FDA documentation) and security in these more frequent releases? Beside the disciplines of Compliance and Security I also notice that other disciplines e.g. Legal, Architecture, Purchasing, Operations have a hard time to keep up with this new way of working.

Leave a Reply

Matthew Hooper

Digital Transformentalist