IT has been practicing omphaloskepsis – that’s navel gazing – since long before IT service management (ITSM) and DevOps were born. And now in “the age of many frameworks” we hear COBIT-ans jostle with ITIL-istas, and ITIL-istas disputing the ways of DevOps with developers.
Sadly, the emphasis can be too much on the doctrine of one winner, with many losers, rather than picking the best of the bunch to suit the situation at hand. With the situation at hand for many enterprises being that they need both DevOps and ITSM at the same time.
“How is this possible with so much uncommon ground between the two?” you ask. This blog explores why both ITSM and DevOps are needed, and how to get them to “play nice” while acknowledging their differences.
What Makes ITSM and DevOps Different?
Putting religion and emotion aside, there are fundamental differences between DevOps and ITSM. A difference does not mean that one is right and the other is wrong, or that one is better and the other is worse. While there are many problems to solve within the business there are at least as many different paths of getting to the solutions.
So it’s OK to have differences and it’s advisable to debate, accept, and understand them before finding out where the compatibilities are. To help with this, the following table describes different qualities that differentiate DevOps from ITSM.
|ITSM Quality||DevOps Quality|
|1||Resource oriented - efficiency focused||Flow oriented - effectiveness focused|
|2||Functional teams||Product teams|
|3||Process focus||Value stream focus|
|4||Hierarchy of functions, silos, and towers||Matrix of tribes, squads, guilds, and chapters|
|5||Pathological an bureaucratic||Generative|
|6||Process managers||Software developers|
|7||Outsourcing, running services||Product companies, delivering services|
|8||Quality assurance||Quality built in|
|9||Originated in the UK||Originated in Japan and the US|
A Little Empathy Goes a Long Way
When hundreds of IT professionals gathered at the Operability.IO conference in London in 2015, one of the most surprising takeaways for most attendees was the emphasis on empathy. That’s:
- Empathy between developers and operations
- Empathy between technologists and their customers
- Empathy between ITSM and DevOps professionals
The attendees recognized that one of the main sources of issues in the IT industry is the constant “war” between ideological factions. One suspected cause of this is the Theory of the Monkeysphere, which uses Dunbar’s Number to suggest that the size of our brain – well, the limit to the number of people with whom one can maintain stable social relationships – reflects the size of our “tribe.”
Beyond Mission to High Performing Organization
Research over the past decade has shown that high performing organizations deliver more customer value, greater shareholder value, and increased employee happiness. The 2015 State of DevOps from Puppet Labs looked into what a high-performing organization is, and the outcomes they have. And, while this is a DevOps “state of the nation” report, there’s no reason why these attributes can’t be a shared goal between ITSM and DevOps:
- High-performing IT organizations experience 60x fewer failures and recover from failure 168x faster than their lower-performing peers. They also deploy 30x more frequently with 200x shorter lead times.
- High performance is achievable no matter if your apps are greenfield, brownfield, or legacy.
- DevOps initiatives launched solely by C-level executives, or solely from the grassroots, are less likely to succeed.
- IT managers play a critical role in promoting diversity and limiting burnout.
Creating Physical Common Ground
When groups of people work in different teams and in different locations then there’s a human behavioural tendency to “not get on.” One way to get ITSM and DevOps to better work together is to position the teams physically together.
Good practice suggestions from those companies “winning” with DevOps include:
- Use the same online systems. No hidden areas.
- Use the same physical location.
- Same perks for everyone. If one team gets cool stuff, everyone gets cool stuff.
- Mix up the teams using a matrix of squads and guilds.
- That leadership distribute themselves among the teams.
It’s also worth noting that the DevOps movement has created an alternative to the hierarchical structure common in many enterprises and that is best explained using this document from Spotify. It isn’t a million miles away from what enterprise are used to, apart from the Game of Thrones language, and should be considered as a way to physically connect ITSM and DevOps.
So Interconnect The Work
DevOps and ITSM have one big thing in common: a plethora of toolsets. And the good news is that this is an era of emerging APIs which make disparate toolsets easy to interconnect. For instance, DevOps flow engines can be connected to ITSM tools, such that all parties can see and control work in the realm of continuous integration (CI). Where the CI system will automate the build, integration, and deployment of software including releasing to any target environment such as developer laptop, staging area, or production. This is a robust process, rich with tools and metrics that help to make DevOps work.
Other example integrations include that:
- Approvals are maintained in the ITSM tool. When a user triggers a release, for example a developer releasing to their own desktop, the CI server consults the ITSM tool over the API to confirm authorization. It might be that only the Fintech team can deploy a release of the Banking application, say.
- When a release is triggered it steps through a number of iterations to build quality into the product during release. All of these metrics are tracked by the CI server which can feed the summary into the ITSM tool for historical tracking. It can also raise tickets as appropriate depending on events.
- The ITSM tool could present users with forms and approvals which ultimately call the CI server to deploy an environment and a product into it. This would be common for a production release.
So ITSM and DevOps can and must co-exist but we need to avoid prematurely advancing into a weird convergence that creates another framework – such premature optimization is the root of all evil. Instead find the common ground, starting with the people, with a shared goal, some empathy, add a bit of physical locality, and eventually just getting on with it.