Frequently underestimated: DevOps & Configuration Management
The fact that DevOps and CALMS principles have their origins in the „agile scene“ should not obscure the fact that Continuous Delivery (CD) and DevOps have an impact on areas of IT Service Management (e.g. Configuration Management) that are least agile today.
The lifecycle of a software depends on the infrastructure and processes the software is tied to: hardware (server, clients), network administration and all supporting (ITIL®) processes – especially configuration management (CM).
The Continuous Delivery Pipeline (CD-Pipeline) implements the respective infrastructure as far as possible in the form of software and automates the processes necessary for deployment.
However, the CD pipeline does not stand for itself, but is closely interwoven with the (CM). In ITIL®, CM is covered by the Software Asset and Configuration Management (SACM) process. The entire lifecycle of an application is inextricably linked to the CM.
When mapped to the software development life cycle, one could now argue that with an agile approach, a complete CM for the system to be developed does not have to be available from the outset. Traditionally, software developers tend to focus on functionality anyway, so that software developers tend to neglect functionality, as well as commissioning and CM.
If you want to tackle this problem, the question arises as to whether and how the CD pipeline and Configuration Management should be included in application development from the outset.
In the best case, it is possible to use an already existing infrastructure (CD-pipeline) including its integration into the SACM. If this is possible with few or no adjustments of the CD pipeline at all, it should be questioned whether a project of its own is necessary for the implementation of the development activities.
If the CD pipeline and thus the SACM system has to be newly implemented, this places higher demands on the new application to be created and its integration into existing CM structures.
There are three variants for implementing the CD pipeline and Configuration Management in application development:
Variant 1: Creation of the configuration management before or during work on the initial release / prototype
Parallel to the construction of a prototype or the first release, CM is set up as part of the CD pipeline. For example, CM is naturally neglected in the context of start-up activities in order to keep the time-to-market as short as possible.
The only disadvantage of this approach is that resources are used for infrastructure automation and not for the product itself. This can be countered by the fact that even in cross-functional teams, different resources are responsible for functional and infrastructure development.
If the creation of the automated infrastructure is driven from the very beginning, all skills have to be also built up from the very beginning.
Another point is that a product/IT service cannot be operated without sufficient CM in a cost-covering way. This means that expenses for the Configuration Management integration will definitely arise. And the later they occur, the greater the risk that design decisions taken previously will increase the costs of the CM-integration.
Another argument against implementing the CD pipeline from the outset could be the lack of agile approaches. Agile, cross-functional teams make it easier to integrate DevOps engineers into the team to implement the Configuration Management and CD pipeline.
A non-agile approach for variant 1 is acceptable if the systems to be developed require a very simple CM.
For example, a micro-service architecture combined with simple version control makes a lean CM possible. However, such a scenario also makes it easy to implement agile approaches.
Variant 2: Creation of Configuration Management after the first Release
Initially, the development team concentrates on developing the first release or prototype and only afterwards on building the infrastructure for CM. As mentioned above, CM often only pops up when a team of developers is about to complete the initial release.
The advantage of this approach is that the developers can initially concentrate on the immediate goal – market introduction.
On the other hand, a lack of CM integration can have an impact on subsequent releases. Especially when the first release „before customer“ is successful and the pressure of the market demands the creation of a second release with extended features or bug fixes.
In such a case, the team could be enlarged by DevOps Engineers and CM specialists, but this would not result in an immediate acceleration of the development process.
The antipattern for a variant 2 approach is the construction of complex monolithic systems in a non-agile environment. In such situations, an accelerated market introduction without sufficient Configuration Management is a Pyrrhic victory:
The lead times for new releases would become longer and longer and the effort involved would increase until it becomes uneconomical to continue developing such a product.
The agile way
Agility is about prioritization. This focuses on the introduction of individual high-priority CM functionality before or during Release 1 and focuses on the implementation of lower-priority CM functions for a later release.
In order to reduce the project risk, it can be useful to implement important CM elements „just-in-time“. This requires an agile approach in any case.
This would mean that the challenges of variants 1 & 2 are not even met. However, the introduction of agile approaches poses challenges to any non-agile organization.
The solution to mitigate this risk is the two-stage „Unified Continuous Delivery“ development process presented in „DevOps Strategies“ (Fig. 1).
The first stage consists of a relatively short project phase in which a prototype or first release is implemented together with the CD pipeline. In this „project phase“ extensive integration into CM is already underway.
In the following phase „line organization“, the further implementation within a project or line organization can be advanced.
The interconnection of a CD pipeline with the Configuration Management is an aspect that is underestimated in many projects and should be operated from the very beginning of the project with the implementation of the CD pipeline.
Although an agile approach would be the optimal way, in connection with the UCD described in „DevOps Strategies„, a non-agile approach can lead to the goal as long as the development increments are not too large.
An organization that wants to establish DevOps and Continuous Delivery should do so using agile approaches. Even if this should lead to greater cultural distortions and resistance within the organization. In such a case, it is a promising way to develop a system by means of DevOps that is not too complex and rather not business-critical.