DevOps was established as a way to share best practices and codify some of the collaborative processes that should be undertaken between development and IT operations teams. This approach is starting to get taken up by more teams as according to a recent Gartner report, “By 2016, DevOps will evolve from a niche strategy employed by large cloud providers to a mainstream strategy employed by 25% of Global 2000 organisations.” However, some approaches around DevOps seem to be based on a couple of assumptions that can undermine its potential.

The first is around how development projects within organisations are prioritised and then put together. Traditional “waterfall” application development was based on getting all the necessary requirements together and then pushing this through the overall process. If any changes to business requirements occurred in the meantime, the whole process had to be completed before new development could be envisaged. Agile approaches reacted against this, setting up much shorter time-scales so that projects would fit much better against business requirements over time.

The important point here is that app dev projects can be self-contained, i.e. each development project focuses on a particular set of business requirements, and then code is developed to meet that set. That project is then put into production and the whole process starts off again. Even if an application gets updated on a regular basis, the emphasis is on meeting particular sets of requirements at any point in time, rather than being an ongoing “service” that evolves continuously.

The second is that the flow of work always goes from development to operations. The aim for collaboration is to improve the whole process with work between teams taking place, but the overall emphasis is on development creating code, and operations taking that application and supporting it in the most efficient way.

Per the same Gartner report mentioned above:

There is not a single, sequential DevOps track that progresses from development to test to operations. Instead, each of the critical stakeholders has its own sequence of scheduled tasks performed in a workflow that, from a time series perspective, often overlaps with those from other groups.

For example, IT operations needs to be developing (or at least buying and testing) its own management tools and technology long before the technology that it is intended to support is ready for production. The same is true for the testing organisation,which should be developing or implementing the necessary tests well before the development organization’s code is ready for testing. This is an absolute requirement for any DevOps organisation that intends to achieve maximum velocity for the IT service delivery process.

Contrary to these two points, the IT support role within operations can be characterised as an ongoing process, rather than one with a fixed end-goal: support staff are called on when things go wrong, and then they have to fix the problems. Each event may be self-contained, but the process of providing support is an ongoing one. The ability to do this relies on visibility of application development projects and deployment schedules as support teams need to prepare to support new applications in parallel with development. Helping users if something does go wrong is simpler if the support team has a full picture of changes implemented well-ahead of time.

Building up collaboration between the Dev, Ops and Support teams is aimed at improving the overall speed of delivery for applications or services. This is then supported by an ongoing service layer that calls upon Support, Ops and then Dev team members if and when things go wrong. At any time, each of these teams will have work going through processes in parallel so that the business requirements can be delivered on-time and on-budget.

For example, let’s say a company is rolling out tablets to their staff in the field and the development team is working on a set of new mobile apps. Supporting mobile devices for remote workers can be a challenge for IT support teams as some vendors, including Apple and many Android manufacturers, don’t allow you to remotely view and control their devices. But there are options to enable remote viewing and actions within the individual iOS or Android application by inserting specific code within the application itself. This allows the support team to help field workers with the new apps even if they can’t access and control the full device.

But getting this code inserted requires the IT support and operations teams to be part of the development process from the beginning. This involves discussion and understanding about what the value would be for the support team, and how this will also benefit the developers themselves down the line.

From a developer perspective, involving support early on may be difficult as it involves ‘owning up’ to the fact that potential problems may come out after a new release is finalised. However, the emphasis should be that allowing support to get involved early will make it easier for them to identify and resolve problems affecting users, whether these are due to specific application issues or more general problems.

In general, ITSM and service desk teams should be brought into the overall DevOps world, and included in the collaboration process around how the results of DevOps are delivered to the organisation and then supported in future. This burgeoning community should work both ways, rather than being from ‘development onwards’. By continuing to bridge these gaps, DevOps and support can offer greater opportunities for business users to see the value that IT is creating as part of wider activities.