Weak link in the devops value chain

DevOps – the prequel and sequel

Next Story

DevOps as part of the IT value cycle

Extending the DevOps philosophy to benefit the whole IT value chain

Many people who have taken more than a brief look at DevOps will be familiar with the 3 Ways, as described in the ‘must read’ book, The Phoenix Project. These are the underpinning principles from which all DevOps patterns can be derived. They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps. The principles are:

  1. Systems thinking
  2. Amplified feedback loops
  3. Culture of continuous learning and experimentation


The first Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g. a developer or system administrator).

Amplified feedback loops are about creating information that allows corrections to be made continually. It includes understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where needed.

The final Way is about creating a culture that fosters continual experimentation. This requires taking safe-to-fail risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery. Experimentation and risk-taking provide the drive to improve, and mastery of skills enables the dampening of unwanted effects of a experiments that have gone off at an undesirable tangent.

This is all good stuff, and it’s even better when you apply it in a broader context. Let’s take a look at what happens before Dev, and after Ops.


So what happens before any development activities commence? Somebody in the business has a business issue and suspects that it could be addressed by better, quicker or cheaper (access to) information. Or somebody sees an opportunity to use IT to influence business benefits, costs and risks. Whether it is pull or push, when this has been validated, we can safely say that there is demand. People involved in demand collaborate with those involved in development of the solution. Although pre-Dev, the same DevOps principles apply to this interaction. Let’s duplicate the 3 Ways and apply them within this new context.

  1. When formulating demand it is useful to be aware of the capabilities and limitations of the IT function.
  2. It is equally useful for the business to get feedback for instance on the quality of the requirements and specification that they provide to development.
  3. And of course it is always beneficial to continuously refine the way of working between business and IT so that the business takes well-informed decisions about their investments.

In addition to the original the 3 Ways within DevOps, we have now duplicated them within the pre-Dev domain. So now we have 6 Ways.


After deployment, the pivotal DevOps activity, the solution is available for the users. When the users use the solution effectively and efficiently, interpreting the information and taking appropriate action, value is realized. There is surprisingly little research in this crucial area but anecdotal evidence suggests that this might be the weakest link in the IT value chain. Consider for a moment your personal experience. How well (or not) information systems are used and how much (or little) support is available to guide the users in the right direction? Once again, let’s take a look at the 3 Ways.

  1. It is crucial for Ops to be aware of why and how the users use information systems and services. Only then can they appropriately pre-empt and respond to disruption of the users’ work.
  2. Users are notoriously creative in using systems in a different way than intended. Either as an easy workaround so that they don’t have the hassle of engaging with the IT department (the service desk is often regarded as the final resort). Or because the intended way wasn’t well-thought through. In both cases, unless there is feedback from the users, Ops is blissfully ignorant of reality and therefore not able play their part in co-creating value from the investments.
  3. Finally, the same comments apply to continuous improvement of collaboration between business and IT at an operational level.

These two new applications of the 3 Ways have now given us 9 Ways: 3 for DevOps, 3 for pre-Dev, and 3 for post-Ops. The prequel and sequel provide a better context to DevOps, starting with business demand and ending with business use.



  • DevOps: The top 11 things you need to know about DevOps, Gene Kim, http://itrevolution.com/11devops/
  • Kill DevOps, Mark Smalley, http://allthingsitsm.com/kill-devops/
The following two tabs change content below.
Mark Smalley, also known as The IT Paradigmologist, thinks, writes and speaks extensively about IT 'paradigms' – in other words our changing perspectives on IT. His current interests are the digital enterprise, IT operating models, value of IT, business-IT relationships, co-creation of value, multidisciplinary collaboration, working with complexity, and as the overarching theme, management of information systems in general. Mark is an IT Management Consultant at Smalley.IT and Ambassador at the ASL BiSL Foundation. Mark has spoken at 100+ events in 20+ countries.