Configuration management – the DevOps victim

Configuration management

The quest for corporate agility

This article is written from the perspective of discussing the main obstacles to business agility.  More specifically, business that pursue competitive advantage objectives by means of responsiveness to customer demand, find themselves facing an interesting dilemma. The issue is twofold.  On the one hand there is a strong motive for rapid response to customer demand.  On the other hand, there is the equally strong requirement for reliability of new systems and stability of existing systems and functions.  The prize is to achieve high rates of delivery without adversely affecting the stability of existing systems.  This is the juicy bit.

Industry talks of Agile, DevOps and Continuous Delivery.  These are great topics and fantastic attempts at reducing time to value, in principle.  But they all suffer the same obstacle.  The obstacle is maintaining the stability of the existing systems, processes and platforms within the business.  The continuous pressure of rapid release cycles and delivery of new functionality leads to increased pressure on areas in the business that were less stressed in the past.  Testing and configuration management are the two departments most likely to buckle under the sustained pressure of high frequency release cycles.

The businesses ability to scale in terms of development is considerably better than it is to scale test processes and configuration management disciplines.  Outsourcing of development effort, and even citizen developers allow for new functionality to be made available very quickly.  Need more features quicker?  Simple, add another development team by means of contract developers, outsource companies or even off shore development, and your development bottleneck is addressed.  However, it is not that simple to scale integration testing and configuration management.  The reason for this is that typically these functions are best performed internally using resources familiar with the business, its systems, processes and interfaces.  Furthermore, it is unlikely the same assets will be recreated externally for purposes of comprehensive testing and escalation processes to the same degree as in the live environment of the operating business.  Professional configuration management practitioners will tell you that it is critical to have functionality move through real environments with real complexity, real loads and real capacity constraints if such testing is to mean anything.  There is simply very little value in going through the motions when the real-world environment is not reflected in the staging environments.

Bimodal practices attempt to combine the agile, rapid response environment with the more mature, predictable practices found in the business.  Bimodal practices separate the two approaches in terms of their execution, but combine the results of the two streams somewhere along the line.  Given the complexity of functionality promotion through the organization, even Bimodal IT suffers the same pains.

Automated configuration, automated tests and continuous configuration are common terms heard, but the reality of the matter is that very little of these actually exist in practice today other than a handful of public domain systems which are far from production strength, even by their own admission.  Until these are addressed in a scalable and low cost, both in terms of effort as well as financial manner, these are going to be key weaknesses in the business pursuing agility as well as minimum degrees of stability.  Stability is going to have to be delivered one way or another.

It is the configuration management function that needs the focus of attention to realistically sustain the agile enterprise.  The goal of frequent (continuous) delivery requires an incredible amount of confidence in the release management cycle.  Functionality already in the pipeline undergoing integration testing may require withdrawal from the pipeline due to issues being discovered.  The pipeline needs to be robust enough accommodate those exits while simultaneously accommodating functionality in earlier stages of testing against a new set of test criteria, and agile enough to not delay the subsequent release cycles.

Much is said about the role of the CIO in establishing buy-in and support for such development efforts in the business and the associated need for maintaining stakeholder confidence and the establishment of shared goals and wins, but all this goodwill is at risk when it comes to the final stages of product delivery.  When expected functionality is withdrawn or delayed, corresponding functionality with dependencies on the withdrawn functionality is often rendered ineffective or useless until the issues with the dependencies are resolved. Such issues may not be resolved for some time, resulting in loss of confidence in the methodology, systems and strategy.

Download a PDF version of this document here.

Mornay Durant March 2017