Assess DevOps. Thinking of Quantitative Techniques.

Throughout my stint in DevOps implementations across organizations, along with my friend and colleague who is an Enterprise Architect, we have seen that a consulting-led approach prior to any such implementation works best because of the following reasons:

1. Aligning with the organization on our and their understanding of what is meant by DevOps; we have seen organizations with quite a skewed or a narrow view of DevOps, with the people aspect considered nowhere
2. To understand where to start the journey; this depends a lot on factors such as the interested groups, the inherent people dynamics, technology landscape and readiness, et al

Now coming to the actual work of consulting itself, we have seen lot many boutique DevOps firms coming up with elaborate assessment reports and recommendations that are primarily qualitative in nature. Such reports start typically with an overall As-Is IT landscape of the organization in context (presented as PowerPoint slides or Word document), followed by gap analysis sections that detail out aspects on people, process and technology dimensions in qualitative terms. Recommendations typically are on To-Be changes to the aforesaid dimensions, again in qualitative terms, and in some cases possibly followed by To-Be technical architecture with tentative tool recommendations (of course, subject to tools' evaluation as a post-consulting activity downstream).

Now, what we found out as a fallout of such consulting activity and results is that, once the organization in context gets such a report in their hands, they do not have a clue on where to start, or how the current projects that they running as DevOps pilot implementations align to this overall consulting output. To solve such problems, some the DevOps consulting firms do go to the extent of classifying a set of projects and selecting a few out of them to try out implementations based on the assessment report. This definitely shows the organization a certain path to kick-start, however still lacks the rigor of quantitative approach in terms of discrete benefits expected.

Hence, the question is how do quantitative techniques fit in for something like DevOps where people dimension - which inherently poses the problem of unpredictability in how activities can be done - is of paramount importance? Even if we say that the end state of DevOps should ideally be a No-Dev, No-Ops world with 100% automation, whether an organization actually wants to reach that state (with accompanying job irrelevance) or how it will reach a given state of maturity on this journey, still comes as constraint to applying quantitative techniques first hand.

So while we may think of applying such techniques to come up with a consulting model or framework, we may first start keeping the following in mind:

1. A number of techniques, either incorporating specific algorithms or not, may need to be used; a single technique may not suffice
2. The solution to a given problem statement for DevOps may be heuristic instead on unique and optimal, given that we have a high degree of variability in terms of people dynamics, technology maturity, et al
3. There may be a set of qualitative techniques used in conjunction, which may be applied manually as part of consultant's experience and judgement (unless of course we start talking about a robotic consulting agent and AI)

Given the above, let us see a few quantitative techniques, and try to find out if any fits our bill for assessing and doing DevOps:

1. Linear programming - This is the most common and relatively simplistic method that comes to our mind. To evaluate if this technique is useful, we may find out if we can represent any one of the DevOps dimensions (people, process, technology) as a set of variables, and apply constraints with respect to the other two. An alternative is to consider each of resource, cost and time as dimensions, and treat the other two as constraints. Hence, though this technique can be highly deterministic and prescriptive due to use of such algorithms, the large number of equations (and inequations for the constraints) would be too complex to analyze. Further, there may not be a good solution; leave alone an optimistic one.
2. Game theory, may be in conjunction with Markov process - This method may be apparently evaluated in terms of viewing adoption of DevOps as a philosophy that needs competing attention on how/ when each of the IT functions of Dev, QA, Ops would work along with the other two, and utilize resources optimally. However, given that DevOps is more to do with collaboration with respect to people, process and technology dimensions cutting across, such a mathematical analysis again becomes overtly complicated.
3. Gantt chart (not the typical MS Project diagram, but as a proper quantitative technique) - This is an age old and proven technique in operations research whereby DevOps is viewed as a practice to reduce overall cycle times in IT. The cost and resource dimensions can also be brought in for the analysis. Though this method can be explored to optimize cycle times, this may be more suited to the technology based automation (since operations research uses this for optimal usage of machines), whereby cost and people become the constraints.
4. Critical Path Method (CPM) - This can be thought of as an alternative to Gantt chart, however the focus is on defining overall cycle times based on IT processes, and then factor in the other dimensions as constraints.
5. Dynamic programming - This is yet another time-based optimization technique. The beauty of this technique is that, it incorporates a shift-left approach (given that the analysis starts with the end state, and then working backwards) and also may handle non-deterministic final states quite well, given that it does not follow rigorous algorithms as say, linear programming.

Whereby I am not an expert in quantitative techniques, and there may be consulting companies who are already using the aforesaid (or additional) techniques which we have not come across, this is definitely an area to explore. The other aspect of this thought process is to see if such techniques, once applied, can be automated as a model or framework along with incorporating concepts such as genetic algorithm, neural networks and AI. In that case, the IT process and its implementation itself can become self-actuating (oh, too far-fetched ?!)

All content in this article is completely the personal opinion of the author, and is no way related to or owned by any organization, company, trade, agency, person or legal entity where the author has worked in, been affiliated to, or associated with. Hence, the author does not assume any liability to usage or consequences to usage of the above content by any third party whatsoever.