If we look back to consider how we arrived at the era of DevOps, it quickly dawns on us that it was a reaction to the frustrations brought about by elements of IT service management (ITSM) best practice that businesses realized were not conducive to certain aspects of modern business operations. There were issues such as complex steps that had to be followed to get things done, and the inevitable amount of bureaucracy that would stack up as a result.
DevOps has changed the face of IT meeting the needs of business operations – from product design to the delivery stage. But the elephant in the room remains, in many cases, how to avoid a collision between DevOps and ITSM approaches.
Finding the middle ground
For some, it would be tempting to jettison the idea of ITSM completely, but then what about the elements of ITSM that DevOps doesn’t pick up? Instead, for DevOps to operate efficiently you need the collaboration of all teams, including ITSM teams.
Of course, this wouldn’t be the first time that competing philosophies have clashed in a business environment. In fact, at the speed things now change, philosophies are forever being supplanted with a new approach, but it’s how you move on, and in most cases, integrate approaches, that really establishes a successful organization.
So here, balance is key, and this would mean DevOps approaches and speeds but performed within the context of an ITSM framework. Done right, this creates a harmonious approach which utilizes the benefits of both philosophies without creating a culture clash. However, the following three mistakes need to be guarded against.
1. Letting perceptions and philosophies stunt progress
As with any philosophical mindset, be it in business, governance, or lifestyle approach, there are bound to be elements which are slightly incompatible with others. Problems arise when people become too dogmatic regarding their preferred philosophy, and lose the capacity for empathy in terms of another’s philosophy.
This may all sound slightly too, well, philosophical for an article on IT management but, in essence, the same problem arises within an organization when you have competing factions who believe their approach is best. It happens with management styles, and it happens here too in relation to your business’ IT approach. The key is to aim to create an open and harmonious approach which takes the best from both DevOps and ITSM.
Compromise is a key word here, and we’re talking about the business culture that you foster. The younger generation, groomed in Agile processes, sometimes have a problem even accepting that there is, or was, another way.
“Much will depend on your hiring policies in terms of being able to mold individuals into an approach that benefits the company and can forge the best IT teams consisting of workers from multiple generations and viewpoints (that is good for your business),” says Mandy Figueroa, a technical writer at Big Assignments.
As a great starting point, DevOps disciples should be encouraged to see that certain practices within ITSM, such as the use of service requests and the logging of incidents are actually great ways to help deliver business software solutions. Close monitoring actually promotes speed and quality, and certainly in terms of measurement and consistency, ITSM is a great approach.
2. Not dealing with the change management differences
Change management is often THE area in which DevOps and ITSM approaches cannot agree, simply because the latter is slightly more resistant to change due to its more methodical approach, while DevOps can facilitate change at breakneck speed which can make non-disciples nervous.
“From an ITSM perspective, although it’s unrealistic to continue working in the same old way, it must also be considered that change may be resisted. Things are moving along, though, and within ITSM circles the need to adapt has been recognized, and practices are evolving to fit into a DevOps framework, which can only be good news for the road ahead,” enthuses Robert Schneider, a developer at Academized.
3. Operating separate toolchains
Aside from the practitioners working in ITSM and DevOps, have you considered that the issue at hand may actually be that your business is utilizing separate toolchains to carry out the various tasks. It’s possible that your ITSM system is completely separate to everything else that you use within the organization, and this is bound to create issues.
But while DevOps disciples may view ITSM tools as antiquated, ticket-heavy systems, the reality is different. Automation is changing the landscape, and integration is now easily attainable, so stop making the mistake of using non-complementary tools.
What other mistakes would you add to my list? Please let me know in the comments.