Ah DevOps, it feels like you hear about it everywhere you go these days. But all this talk of DevOps isn’t a bad thing. DevOps is a good thing – it’s something that can finally help to bridge the gap between app dev and IT operations, and to help make the corporate IT organization “better, faster, stronger.”
Where DevOps, done right, will help to bring the often-disparate app dev and IT operations teams closer together, and focused on the same purpose – higher quality software, better business results, and happier customers. And maybe even happier employees and reduced costs, but the former are more than enough.
But the DevOps Watercooler-Talk isn’t Enough
Instead what DevOps, and the people that are still merely talking about it, need right now is:
- Better articulation, and a common understanding, of what DevOps actually is (and isn’t)
- Greater sharing of success and failure stories such that the IT community as a whole can benefit – Isaac Newton’s “standing on the shoulders of giants”
- Greater involvement of IT operations in those organizations that are struggling with, or still to start, their DevOps initiatives
- More industry attention on the people and soft-skills aspects of DevOps, aspects that will ultimately make this “organizational and cultural change” a success
- Technology-based process support and enablement that spans the app dev and IT operations ecosystems
- More “action” from those still in the DevOps “talking” phase – even if this is simply extending the conversation outside of the app dev team to include IT operations’ colleagues
There’s no point adopting DevOps if it’s just seen as a “good thing to do” – the latest IT fad or trend. There’s also little point if there’s little or no understanding of what DevOps is or should be. But sadly this understanding is more difficult that it should be, as a standard definition of DevOps has so far eluded the IT community. Because, as with anything new and community-driven, those with a vested interest will unintentionally (or sometimes intentionally) paint a picture that suits their personal needs. Even the 26-year-old IT service management (ITSM) best practice framework, ITIL, and ITSM itself are still commonly defined differently by different people; sadly often molded to suit the needs of someone with something to sell.
Thankfully, a recent post on DevOps.com has distilled the key elements from a raft of differing DevOps definitions (but it does stop short of providing a definitive definition):
“Analysts, authors, industry, and community leaders all agree. The ideas are big and mutually supportive. In short:
- DevOps exists to help the business win
- The scope is broad, but centered on IT
- The foundations are found in Agile and Lean.
- Culture is very important
- Feedback is fuel for innovation
- Automation helps”
With the first point the real “why DevOps?” That “DevOps exists to help the business win.”
So while DevOps “thinking” often starts with application development, it also needs to be about IT service delivery and consumption – the point where IT finally makes a difference to business operations. But above all, DevOps thinking needs to recognize that it’s about contributing to better business outcomes and successes.
DevOps and the Service Desk?
Better business success requires IT teams to work in unison towards a common goal, via successful IT delivery. But this “successful IT delivery” is much more than great code creation in the shortest possible timeframe. Success is when technology consistently, and almost “invisibly,” enables business operations through effective IT operations, and ideally offers up some form of advantage over business competitors (which might be new products and services or simply the speed of adaption and change). And when the IT is “hindering” the business, through non-availability or the degradation of service, the service desk helps to “make things right” as quickly as possible. So the service desk lays an active part in both IT and business success.
However the service desk should not only be involved at the tail end of successful IT delivery, or in an isolated manner, it also has a role to play in DevOps. For example:
- The service desk often has more end-user and customer touchpoints than any other IT function. It knows what works and what doesn’t in terms of both IT systems and change. It also knows what has caused end user and business operations issues with previous systems and the lessons that can be learned.
- While DevOps will produce frequent software releases and the service desk helps to handle the successful delivery and adoption of those changes, early service desk involvement can help to prevent such issues before they occur.
- Where organizations carry out test activities with active service desk involvement, the service desk can both help to figure out the glitches and to plan ahead, creating scripts and knowledge articles for as and when the issues are encountered again once live.
So the service desk should be part of the DevOps ecosystem, and as such there are benefits to be had from using a service desk or ITSM tool that embraces rather than shies away from DevOps and its opportunities.
Freshservice – Helping Customers with DevOps
Unlike many of the legacy ITSM tools, Freshservice is designed to meet the needs of modern IT organizations. It’s cloud-based, offers consumer-world-like capabilities such as intuitive self-service, and supports both cloud management and DevOps operations by a native integration with Amazon Web Services and seamless change–release management modules that are widely used by DevOps teams from enterprises around the world.
With Freshservice, service desk teams can now not only get in on the DevOps talk, they can also get in on the DevOps action to contribute to the better business successes.
We are presenting our DevOps and ITSM capabilities at AWS Re:Invent 2015. Please come see us at booth #1333 to see how we are helping DevOps teams around the world and how you too can.