Snake-lines of Software Production & DevOps

DevOps paradigm is all the rage these days. And I think it is a necessity rather than just a hype. Speed and Scale are two primary factors demanding a paradigm shift such as DevOps. Speed refers to the rate at which software can be delivered to address production customer needs. Whether it is a new product, new feature, or simply bug fix roll out, if you are slow then sooner or later you will lose business. Speed and agility is a necessity in the mobile-cloud era where pace of change has been tremendously accelerated. Scale refers to the need to address drastic demand jump experienced by current applications. The current mobile-cloud apps, for eg, need 24x7 global availability, can be accessed by exponentially more mobile devices and are also heavily used by machine-machines interactions.

So we need to move fast and scale while maintaining acceptable levels of quality, security, compliance... i.e "necessary controls". And you are looking at something like "DevOps" paradigm to address the above demands. But question is how would you measure whether DevOps or any other effort is helping or hurting you? To answer this question I have created a simple model to plot efforts of speed vs quality/control elements (see chart below). I am calling these "Snake-lines of Software Production (TM)"

So what is Snake-lines of Software Production? In the chart below, Y-axis defines your daily rate of software change as experienced by your production customers. This can be measured by "number of code-changes that are being rolled out daily and being adopted/experience by customers". So if you made 1000 changes in your software in a day but only 10% customers experienced it, then your daily rate of change is in "100s".
On the X-axis, I define the production incidences. Following same logic as above if there were 100 outages in 500days, impacting 1000 customers then  100/500 * 1000 = 200 incidences per day.
You don't need to be dogmatic about these numbers. Your engineering can give you the Y-axis and your Global Support can give you the X numbers.

In this chart, a Snake-line is a plot of your software "condition" over a period of time. For eg: in the Red Snake-line, below, the software started at the bottom right corner, with low daily incidences and low rate of change. As the adoption picked up and as the rate of change increased, you see the red line drifting towards "worsening quality" and at the same time slowing the "ability to release the changes". I call this a "Negative Snake-line"
In contrast the Green Snake-line, shows that software has maintained pretty fast pace in terms of rolling out changes. But at the same time has also maintained quality and control of the incidence rates. This is a positive Snake-line.




Over period of time you want your software efforts to evolve and establish a "positive" Snake-line. I believe this is a simple quantifiable approach to define whether your DevOps, or micro-services re-architecture or public cloud adoption ... etc is steering your software production in a positive direction.

要查看或添加评论,请登录

Arvind Soni的更多文章

社区洞察

其他会员也浏览了