2.5 The Enterprise-Wide Context
2.5.2 DevOps
A ‘spin-off’ or an extension to agile software development is the strategy referred to as DevOps. Aligned to the agile strategy of ensuring quick software release, and implementation, DevOps is a strategy that attempts to reduce the
‘disconnect’ between the developers (Dev) and the operators (Ops) of a system (Limoncelli & Hughes, 2011). It should be noted that although the DevOps concept has been conceived around 2009 (Kim, 2013), it is currently at a stage of infancy
with regards to the rate of adoption (Zhu et al., 2016). DevOps is a concept that attempts to dismantle the ‘silo-based’ or fragmented approach to application development and the delivery and operation of the application from an enterprise perspective (Ravichandran et al., 2016). Traditionally, the development of an application proceeds linearly from development/coding to quality assurance to integration of the application with an organisation’s IT infrastructure. This path entails the involvement of software developers, quality assurance (QA) personnel and IT management who are entrusted with the task of providing a smooth operational environment (Ops16) for the successful implementation of the application. The DevOps philosophy comprises of a strategy where the specialists who are involved in each of these individual activities are brought together to work in a collaborative environment (Ravichandran et al., 2016). It mitigates a situation where developers write the code and entrust the responsibility of deployment of the application onto the operations staff. DevOps is an initiative to embrace an approach to software development and deployment that integrates the different silos of the IT department that typically are involved in the software development, deployment and maintenance of an application in an organisation. A closer working relationship between developers and operations staff will enable the ongoing management of the application to be conducted in a manner that enhances the prospect of a quick and efficient deployment of the application to a ‘live environment’ as well as a quick turnaround time when it comes to issues of perfective and adaptive maintenance. Hence, DevOps embodies a working environment that prioritises collaboration, cross-functional teams and enables early and continuous delivery of working software. The preceding statement reflects the resonance of the DevOps concept to the principles of ASDM.
If one had to adopt a restricted view of the DevOps concept, then there could be a claim made that the linkage between DevOps and ASDM is a tenuous one.
This assertion is based on the perception that much of the deliberations regarding
16 The operators (Ops) of a system include organisational personnel who have any form of contact with the system after it has been released by the development team as a finished product or a finished version of a product. The list includes network administrators, database administrators, system administrators,
ASDM has been conducted from a coding/purely software development perspective while the operational environment in which the application delivers its expected functionality is not the domain of the development team. However, Mueller (2016) does make the claim that if the development team did not take cognisance of the operational side of the system, which becomes the main focus during the deployment phase, then the benefits of having adopted an agile approach will not be realised. The speed and agility used to facilitate competitive advantage via the
‘quick-release’ of software may become counter-productive if the development team did not consider issues pertaining to systems integration as well as compatibility with the technological infrastructure. According to Mueller, cognisance of these issues need to take place at high level systems development planning meetings as well as during the deployment phase once an initial version of the system has been released. This close collaboration between the development team and the operational staff embodies the DevOps framework. Sharma (2017) provides an overview of this close collaboration intrinsic to the DevOps approach by suggesting that:
developers have to work with operations staff so that they can understand the environment in which the systems work;
operations staff need to be close observers of the development process so that they have an intimate understanding of the requirements as well as the coding logic used.
Whilst these characteristics of the DevOps approach are suggestive that the DevOps strategy is easily understood, many authors (e.g. Bass et al., 2015; Roche, 2013; Sharma, 2017) allude to the difficulty of providing a precise definition of the DevOps strategy. In many cases authors are willing to propose a rather informal description of the DevOps strategy such as Limoncelli and Hughes (2011) who provide an uncomplicated interpretation by advocating that DevOps represents a strategy that brings developers and operators closer together. Mueller (2016) adds to this interpretation by suggesting that the developers and operations staff collaborate on a project throughout the development and service lifecycle. This
collaboration comprises of an integration of Dev and Ops functions from design through to the development process up until production and support for the system. This collaborative strategy blurs the traditional distinction between development, quality assurance and operations. It also has implication from an organisational culture perspective because it requires the various stakeholders to work in an interactive manner to facilitate the building, testing and release of software in a quick and reliable manner.
The DevOps strategy as outlined in Mueller (2016) requires that once a development team declares that a specific version of a system is ready to be deployed, the assumption is made that any further development will be suspended while the application is deployed into production. At this juncture, the application is subjected to ‘live’ testing and intensive scrutiny whilst in the ‘live’ environment.
The DevOps practice requires that developers are allocated the task of observing the progress and analysing systems errors so that remedial action can be taken. In this way an iterative relationship is maintained between the developers of the system and the operators of the system. This iterative arrangement enables quicker releases and the implementation of quicker changes that may be required by the operators who enjoy the benefit of having immediate access to the developers.