DevOps isn’t the answer to every business demand, but it might be the best way to keep up with the accelerating rate of change.
Travelling in Norway following a chapter conference there, I was undertaking some research for this article. As I searched the relevant web page, which was delivered to me in Norwegian, I was immediately asked if I wanted it translated. Shortly afterwards as I was looking for a hotel, I was immediately shown hotels close to my position. Location services and related technologies – determining from the available information who and precisely where the user is – are now becoming prevalent in all aspects of the online user experience. Indeed, they are at the centre of business solution design in a customer-centric era. It’s an era of disruptive technologies and rapidly evolving business models, and what continues to surprise me is the rate of acceleration in technological solutions to deliver business outcomes in ways that IT could not have imagined a couple of years ago.
This acceleration is creating significant issues for many CIOs and senior IT managers. Many have not yet realised their return on investment in existing solutions and are being pressured to accelerate their pace of change faster than ever before. The outcome in many cases is business management who claim that IT cannot react and deliver in a timely manner and then choose to source the technology via another route!
This has led to the rapid adoption of agile development methodologies to meet quickening business change requirements, and many IT organisations are looking to DevOps as the answer to their problems.
DevOps as the name suggests is a merging of Development and Operations. DevOps asserts a philosophy that removes barriers between the development and operations functions, allowing the rate and pace of change to accelerate across the business. The question that I am often asked by ‘disbelievers’ is whether DevOps is simply a strategy to give development and the business the right to skip the proven change processes and avoid the rigour of operations and its investment in current service and project management best practice.
This could not be further from the truth: DevOps is a business-centric philosophy to deliver business outcomes.
Tweet: #DevOps is a business-centric philosophy to deliver business outcomes - @RobertEStroud #ITSM
Speaking to the CIO of a large manufacturing organisation at an industry conference, he mentioned to me that their DevOps initiative is being led by the operations function, who are looking to accelerate the pace of change through pre-production testing to production, even to the point of automation of change reversal where change doesn’t quite deliver the desired results (this depends on processes being implemented to automatically validate change once in production).
The point is that IT needs to react and challenge current philosophies and framework implementations. DevOps is a philosophy that supports rapid innovation and IT-powered business change but it is not a panacea.
So how do we work with DevOps to accelerate our rate of change and overcome the resistance of the existing culture, and what techniques do we use? I thought that I would share some practical steps leveraged by other organisations to commence the journey:
Create a leadership DevOps advocate
Let’s face it, most organisational structures are overly complex, and red tape is often the primary obstacle to success. The first stage in the cultural change is to create a role for a senior executive who has power across the full IT domain to evangelise and sell the organisational benefits of DevOps.
Create the team
DevOps by its very nature is a combination of development and operations. Therefore, DevOps requires a cross-functional team with skillsets reflecting both areas; and to be successful the business must be represented as well.
These individuals should understand DevOps itself, but also be familiar with the processes and technologies that are needed to make the DevOps implementation successful. They must be completely dedicated to the cause and not distracted by other business. As the team progresses, process experts and tool specialists might also be required. The key thing to remember, particularly if you are using consultants, is not to forget the training or skills transfer.
One of the major outcomes must be the automation of processes across the business. The starting position should logically be demand intake of all levels. More often, the initial focus is within the development organisation, through to QA/test and operations, including back-out in the case of failure. Before rolling out technology, DevOps teams must work on business and IT process improvements to ensure they have identified the challenges that their work could encounter and plan how to eliminate gremlins. Knowledge of existing business processes is a key skill, as is the ability not just to plan and test for success but also to prepare for process failure both for education and triage.
Budget for talent and technology
Although additional headcount, training programmes and technology will be needed to drive DevOps through the organization, over time the value and automation will change the way teams work and should release headcount back into the pool.
Processes including application delivery, service virtualisation, IT automation and release management integrated directly with your change and management systems with will only be successful with knowledgeable team members taking the reins and leveraging their intellectual knowledge. As a first step you should conduct an internal inventory of tools, identifying the gaps and filling the holes needed to support the DevOps methodology.
Get started with your troublesome applications and services
Rather that starting with a ‘big bang’ approach I recommend that organisations consider piloting or testing DevOps before committing completely. The best way to prove the value of DevOps is to start with an application and/or business service that has been causing problems across production and creating headaches for developers and operations alike as they attempt to remove defects. This sample service/application should demonstrate the value that DevOps can deliver. Once you have the recipe correct, repeat and repeat and this approach will soon attract attention across the organisation.
DevOps is a philosophy to focus the organisation on outcomes needed to support the velocity of change in an innovative world. It is not an answer to every business demand but when used effectively and correctly it can deliver real business innovation.
This article was first published in the Spring 2014 issue of Service Talk which is a benefit of ITSMF UK membership
To find out more about our range of workshops and masterclasses including DevOps visit our events calendar