The ITSM highway is littered with implementation efforts that failed to achieve their potential.
ITSM, done well, has proven to be great for business. Unfortunately, for many businesses, implementation efforts resulted in “bad ITSM”.
Many of these ITSM implementations were initiated by the IT operations team, and perhaps had some early successes managing incidents and service requests. But many of these implementations were too focused on tool implementations that didn’t quite hit the mark or process engineering efforts that resulted in unjustified bureaucracy.
IT Operations then tried to push ITSM onto the other parts of IT, with limited (if any) success. ITSM became the bottleneck rather than the enabler.
Can some DevOps thinking be the cure for “bad ITSM”?
What is DevOps?
First, let’s get clear on what DevOps actually is. The key objective of DevOps is getting the development and operations teams working better together. But what is “DevOps”?
The DevOps Handbook[1] defines it as “the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others”. DevOps is best thought of as “CALMS”[2] , a conceptual framework for integrating development and operations teams. CALMS is an acronym for:
- Culture – A culture of shared responsibility
- Automation – Automate as many tasks as possible
- Lean – Visualization of work in progress, limit batch sizes, eliminate waste
- Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
- Sharing – User friendly channels for facilitating ongoing communications between development and operations
If CALMS is the foundation of DevOps, can CALMS be a way forward for ITSM?
How DevOps and ITSM are often described
Many ITSM implementations fell short because ITSM was viewed only as something done only by IT operations. In many cases, this perception was deserved because no one outside of IT operations was involved in the implementation. ITSM was too focused on stability and “status quo”. As a result, ITSM became a barrier, rather than a way for the operations and development teams to better collaborate.
A recent article[3] described the relationship between development and ITSM as represented in the diagram below:
The article focuses on the relationship between software engineering and the “IT help desk” (implying that ITSM is just the “help desk”). The article suggested ways to integrate the ITSM and engineering teams, such as providing some method for the “IT help desk” to provide enhancement requests to the engineering team. Engineering should provide estimates to the help desk regarding planned releases, rather than include the help desk in those planning discussions. If a help desk representative needs to talk to an engineer about a defect, the representative should not only track such defects in the ITSM tool, but also in the engineering tool….and let engineering know which defect it is within the engineering tool.
Well, doesn’t this sound familiar?
Doesn’t this sound just like the IT operations-centric approach to ITSM, but in reverse? ITSM is seen as something being done in addition to software development. Operations must jump through some hoops to talk to the development team.
When does the security team get involved? Or the QA team?
Isn’t this just perpetuating the so-called “wall of confusion” between the parts of the IT organization?
Isn’t ITSM really this?
For whatever reason, there seems to be this irresistible tendency of looking at IT as a collection of parts:
- Security – ensures the integrity and confidentiality of data assets; protect data assets from threat or harm
- QA – provides cost justifiable quality and compliance with regulatory and other requirements
- Operations – delivers stable, reliable, and consistent IT services
- Development – encodes and delivers applications and software that solve business challenges
The fact is that it takes all parts of the IT organization – security, QA, operations, and development – working together to deliver viable and valuable services for the business. No single part of IT can deliver business solutions by itself.
We must stop looking at IT – and therefore ITSM – as a collection of parts. Shouldn’t we really think of ITSM like this?
ITSM should be a means of delivering valuable outcomes that businesses require from the use of technology. It should be Strategy-Design-Transition-Operations as a single, frictionless flow, not a series of gates. ITSM should be a way to collaboratively align the IT organization to meet shared goals and objectives. ITSM should be about continual improvement, finding ways for the business to improve how it does business, leveraging technology.
If your ITSM isn’t quite where it should be, DevOps can help.
5 ways DevOps thinking can cure “Bad ITSM”
Somehow, ITSM lost its way in many organizations. But DevOps adoption doesn’t mean that you throw out all of the ITSM work you’ve done – you’re still going to need processes, you still must define services. Having said that, DevOps can provide a means for organizations to hit the “reset” button on their “bad ITSM” implementations.
Here are five ways that DevOps thinking can cure a “Bad ITSM” implementation:
- Change the Culture – Like ITSM, success with DevOps starts with cultural change. Cultural change must start from the senior management level and permeate through the organization. What does this cultural change look like? Leaders do not allow teams to form siloes. When errors are found, the team stops work and fixes them, rather than trying to hide the issue or pass the error down the line. An attitude of collaboration and shared responsibility between development, operations, security, and quality exists from the beginning. Embed a “DevOps” culture in your ITSM implementation.
- Drive to automate – Automation first requires effective, well-designed processes. A symptom of many bad ITSM implementations are processes that are bloated, overly-engineered, and bureaucratic. Take a DevOps approach and define, simplify, then automate processes. Automation will result in ITSM that is much more effective and efficient. The more automation, the more responsive the IT organization can be to changes in business needs.
- Work iteratively – ITSM implementations often suffer from “waterfall-ish” approaches. Take a DevOps approach and work iteratively with process designs, improvements, and solution delivery. Shift from a “big bang” approach to delivering value in smaller, more manageable and predicable increments – then develop and implement those increments more frequently. This means smaller release packages or smaller changes, but in return, business realizes value from technology use more quickly.
- Standardize infrastructure configurations – Both DevOps and ITSM concepts are “technology agnostic”. Having said that, using technology in the best way makes utilizing DevOps and ITSM concepts much easier. Take a page from DevOps and standardize infrastructure configurations. Define and use a standardized approach to provisioning infrastructure[4] – servers, storage, operating systems, and networks. The same infrastructure configuration is then used across all environments – development, test, UAT, and production – simplifying testing and validation and improving reliability by removing any variation between environments. An evolutionary next step would be Infrastructure as Code – which could be codified as a “standard change”!
- Develop and document test scripts, then continually test – A key DevOps concept is automated testing. This approach allows testing to be done at any point along the development cycle. Applying this concept to ITSM, develop standardized test and validation scripts and execute those scripts as part of any change, release, or deployment. Not only will this improve service reliability and confidence in implementing changes, but it can become the foundation for automated testing, and allows for deployments to be decoupled from releases – another key DevOps concept.
DevOps can help organizations realize the promise of ITSM
If your organization is suffering from “bad ITSM”, adopting and adapting these DevOps concepts can help. But “bad ITSM” cannot be cured overnight, so “start smart”. Think evolution, not revolution – perhaps start with a service or a process that isn’t performing as needed. Implement some of these concepts, be willing to experiment and learn, and watch ITSM improve!
Is your organization suffering from “bad ITSM”? Invite Tedder Consulting to work with you to apply some “Next Generation ITSM” thinking and get back on track! Contact Tedder Consulting today!
For more pragmatic advice and service management insight, click here to subscribe to my newsletter!
Picture credit: Pexels.com
[1] Kim, Gene, et al. “The DevOps Handbook”, IT Revolution Press LLC, Portland, OR. 2016.
[2] http://whatis.techtarget.com/definition/CALMS
[3] https://devops.com/bridging-gap-itsm-software-engineering/
[4] “Infrastructure as a Service”?
Share