Cloud-Based DevOps at the Crossroads : Process Maturity vs. Capability

The early stages of the adoption of any new IT technology are filled with countless detours, dead-ends, and pitfalls. As the technology innovators and early-adopters give way to the mainstream users and latecomers, the once frenetic activity of this fertile first phase calms down followed by an often painful series of trial and error, and concerted efforts of the community's thought leaders, patterns of best practice begin to emerge, become recognized, gain endorsement, and ultimately and become recognized cornerstones.

DevOps may now be at the threshold of this next adoption phase; and the signs that it has, like its software engineering predecessors such as OOP, Waterfall, Spiral, Agile, Scum, Extreme Programming, already begun its journey along the same path to become a standardized documented practice. One unmistakable hallmark signifying DevOps has "crossed the chasm" is the ongoing and somewhat confusing debate over how to define a maturity and capability model for DevOps

We're Not In Kansas Anymore

Doug Kerwin, Lead DevOps Engineer at Billtrust, posted an insightful article here on LinkedIn almost two years ago answering the classic first question: "What problem does DevOps solve?"

Doug's answer:

The problem( DevOps solves) is we need to run and continually update our software in a scalable, reliable, and affordable manner. 

Leaving how to accurately measure the "affordability" of running and updating software for a follow-up discussion, there can be almost no counter-argument that DevOps attempts to solve problems of scaling and improving the reliability of software development's 'build-test-deploy' cycles and accelerating the speed of both new software feature releases, enhancements, and fixes. While two years is not a very long period in wall-clock time, technology measures time in dog years - 2 years = 24 technology years. And with such accelerated 'aging' the next obvious question becomes how has DevOps "matured"

The follow-on "problem" question to be asked now of DevOps practitioners is: "What problem does a DevOps Maturity model solve?" Perhaps an even better question would be: "What is a DevOps maturity?"

Rolling In The Years

How has DevOps come of age since 2016 (date of Doug's post)? For one thing, the cloud has made DevOps a place where the tangible dissolves into the intangible at literally the flip of a switch; were "hardware" is actually "software" and the applications running on these also no longer a stable, long-lasting (long running) entity with lifespans measured in seconds, if not milliseconds.

But even in this brief period, DevOps has advanced even further to the almost complete 'virtualization' of IT infrastructure: Containerization and Serverless now reign and DevOp practitioners speak of VMs or cloud-servers they way naturalists do of extinct dinosaurs. Docker, Kubernetes, and CoreOS clusters have taken their place and DevOps can meaningfully describe that what it does in the cloud is build IT architectures of "code."  

DevOps As Code: Send in the Programmers

Doug speaks of cloud application deployments as being much like launching a satellite into space. Few of today's DevOp practitioners had even been born as NASA struggled and stumbled, almost comically, again and again, before successfully launching Explorer 1 into near-earth orbit on January 31, 1958. And was another long three years before the Russians succeeded in orbiting a man in Vostok 1.

While the journey into space was an arduous step forward, DevOps practitioners have apparently decided to take a backward step to become programmers. Judging by DevOps embrace of the terms "Infrastructure as Code" (IasC) and "Pipelines as Code" (PasC), could there be reasonable disagreement against placing DevOps in the software engineering domain and therefore subject to its many lessons learned, disciplines, and practices, including capability and maturity process models.

DevOps Capability and Maturity Models

To say IasC and PasC coding is a backward step may be premature. There's a good deal of visible difference between writing programs in a procedural language like Python, C, or even a scripting language like JavaScript and IasC and PasC programs. Hopefully, DevOps "programming" can be supported by software development's current crop of sophisticated IDEs, code linting tools, source code libraries, version control systems, and other code wrangling tools that dramatically increase coding productivity and efficiency. DevOp practitioners have the legions of programmers who came before them to thank for blazing a trail and creating these tools which reduce if not eliminate all to the coding drudgery, pitfalls, and tarpits their predecessors suffered through.

However, despite those code language differences and productivity enhancements, DevOps code is still code and therefore DevOps practitioners cannot ignore earlier seminal programming works such as Code Complete by Steve McConnell now in its second edition, Kent Beck, Martin Fowler,  or Brian W. Kernighan. Literally hundreds of thousands of man-years, and almost countless books about programming are an important legacy for DevOps coders.

But it's the luminary Watts Humphrey (1927-2010) of the Software Engineering Institute, John H. Baumert, and Mark S. McWhinney who defined the process by which software development activity gains maturity and capability.

Again, measuring in technology "dog years", Humphrey's "Introduction to Software Process Improvement, published in 1992, seems as ancient as the Dead Sea Scrolls. Yet along with Baumert and McWhinney, Watts built the foundation for software maturity

and explained how specific coding activities had to be formalized into processes which then had to be documented, organized, implemented and maintained to create a hierarchy of measured, discrete stages delineating ascending levels of maturity. The diagram shown on the left should be recognizable to most DevOps practitioners and is taken from Watts Humphreys published work on software development. Humphrey, followed by others, created a series of maturity models which was eventually adopted and

Humphrey explained the defined stages in his software process maturity model:

Note, the word, "improvement" is mentioned in each of Humphrey's bulleted points to explain what his maturity model represents and how it relates to software development activities. Humphrey's concept of improvement as a measurable quality of software engineering practice and performance was a significant insight into software development and how it could improve and evolve.

DevOps and Continuous Improvement

Humphrey explained how software development processes could be matured and the basic ideas driving ongoing software process improvement efforts to achieve maturity,

The DevOp maturity model, according to Humphrey, can be used either within an organization to pinpoint activities that need change or redesign or by DevOps external stakeholders who want to judge the qualifications of DevOp service providers. Without delving into the external uses of maturity model, the key takeaway is maturity should prioritize DevOps process improvement using an assessment or evaluation operation.

Yet seldom is the idea of assessing and evaluating DevOps practices been described in the commentary or literature about it. The "Holy Grail" of DevOps maturity seems to be the discovery and endorsement of an assessment and evaluation methodology. Each of those assessments and evaluations should reveal the continued efforts by the DevOps practitioners to increase the maturity of their practice beginning at the lowest maturity level.

Continous improvement is the overarching software process principle that allows meaningful distinctions between progressive stages in code development activities regardless of the programming language being used or the specific techniques in managing those code development activities.

Cloud-Based DevOps at the Crossroads

Cloud-based DevOps is at a crossroads at which its' practitioners should decide either to understand the historical maturity model concept and its process improvement based foundation or to redefine the term "maturity" and explain how it applies to the code they write. Taking such a step would require a consensus among DevOps practitioners on how to apply the work of Humphrey and others on software engineering discipline to IasC and PasC. Achieving such a consensus will be difficult unless DevOp practitioners recognize the value and benefits of creating software engineering process for DevOps code and then share what they create in an operational, "best-practices" way with other practitioners.

DevOps Maturity: What Problem Does It Solve?

Borrowing once more from Doug's post, although there still a great deal more to how maturity, software engineering, and capability-based continual improvement apply to IasC and PasC in DevOps, I can attempt to answer a similar question: What Problem Does DevOps Maturity Solve?

The problem( DevOps Maturity solves) is we need to assess, evaluate and continually improve our DevOps code in a scalable, reliable, and affordable manner.

At this point in cloud-based DevOps, this answer may not suffice in explaining how Watts Humphrey's software process maturity model can be applied to IasC and PasC but it hopefully will inspire productive insights, comments, and discovery of his important and valuable contributions to software engineering practice in cloud-based CI/CD systems.

Perhaps the most incentive to encourage more exploration of how to adopt Humphrey's maturity model and continuous improvement concept to DevOps can be best summarized in the quote:

'Those who do not learn history are doomed to repeat it.'