Technical challenges push IT administrators and development and operations personnel to the limit of what they...
can do, but few things really slow them down, except one: ITSM.
As IT becomes central to business strategies and operations and as technology turns over rapidly, outages occur with devastating effects. While equipment failure and software bugs do occur, a more common theme is human error from change. Whenever you change anything, it has a degree of unknown effects, even to supposedly unrelated processes or workloads. These outcomes spur multiple changes simply to keep up, which creates potential for more problems.
IT service management frameworks address both outages and change management. But ITSM -- most notably associated with the IT Infrastructure Library (ITIL) methodology -- is a roadblock to many. To see how service management actually benefits IT and DevOps organizations, you must understand why ITIL and the other ITSM frameworks exist and what each is designed to do.
ITSM is more than procedures: It is a method of process improvement for what many people see as a broken or nonexistent system. With a change methodology in place, IT teams can create a flow with documentation and take-action plans in the event of an issue. It helps eliminate the unexpected. Process improvements don't correct every issue, but they go a long way to mitigate them. Change control is management's dream come true.
Where well-intentioned ITSM implementations go wrong
Change management easily becomes a nightmare for all of IT. While most workers agree that some level of control and documentation is necessary, the implementation of ITSM involves much more than most IT organizations expect. These process improvements put reviews, documents and safety guards in place at multiple levels in the entire development and operations app lifecycle process, as well as for other IT groups. While management envisions the benefits of these new processes, the staff sees barriers to getting the job done.
Imagine exactly how many new processes could be put in place: The core of the ITIL process is divided up into three categories with multiple steps and checkpoints in each one. Development, planning, audits, control, quality assurance (QA), testing -- the list goes on -- require unique stops along the process chain. Ideally, different staff members should complete each of the steps -- for example, to prevent a software developer from QA-ing her own code.
Even if you can ignore the prohibitory expense of hiring an army of IT pros to complete these unique steps, there's the prohibitory expense of time. What will they do when there are no changes to approve? A large staff with a breadth of singular focuses becomes a drain on resources. Upfront staffing costs are an issue, but the time it takes to complete all of the new processes is more pressing. Every break point, document or sign-off increases the length of the change process. Something that could be done in hours can now take days or even weeks.
Management -- the likely source of this ITSM implementation -- will be the first to complain that it takes too long to get anything done in IT. This common scenario leaves developers, operations and the rest of IT between a hard place and a brick wall as they complete more and more forms and work continues not to get done.
Mix and match together an ITSM strategy
Indisputably, change control and ITSM are necessary, but success comes down to shrewd implementation. In a pure form, ITIL, COBIT and the other ITSM frameworks simply are not practical for most businesses. These methodologies can't be a rigid set of rules to follow with no deviation. They are a collection of processes from which an organization can select and combine pieces.
It's OK to not completely align with one ITSM framework or to use pieces from multiple schools of thought to create an ideal ITSM implementation for the business. ITIL, Agile and DevOps, Six Sigma and other approaches all bring something to an organization. For example, if the software release process from ITIL seems ideal in concept, adjust as needed to make it work for your business size. If Six Sigma's project methodology suits your core businesses, tailor it with some input from ISO standards on quality.
Most businesses don't fit into one mold, so be flexible with processes. Create the checks and balances where they make the most sense for your workflows and staff. Have that additional step to QA a software release by someone other than the code author if bugs are a concern; it doesn't have to be his full-time job. That second set of eyes keeps both sides sharp. Even if there aren't sufficient resources for a person at each step in a process improvement plan, good checklists and other document types mitigate possible issues by forcing people to review and track work.
The key is to make these processes organic in nature, not obstructions, so that enough processes exist to reduce the number of issues in development and operations, without restricting the ability of workers to get jobs done in a timely fashion.
Infrastructure-as-code work benefits from a fluid deployment pipeline
Automation features polish application release tools for DevOps success
ServiceNow upgrades ITSM offerings with machine learning, artificial intelligence