This is the third in a series of blogs about enterprise DevOps. The series is co-authored by Nigel Willie, DevOps practitioner and Sacha Labourey, CEO, CloudBees.
“So, how can I help you?” Nigel asked.
“I need all the DevOps tools.”
Nigel was manning a booth at an internal DevOps conference, and the start of this conversation made him fear he had a communication issue.
Whenever targeting a mass market, your message should be simple. It is also critical that momentum for change is rapidly built up. We had obviously succeeded in this aspect but we had an issue of nuance.
“Why do you need all the tools?”
“My manager has put it in our objectives to adopt all the DevOps tools by the end of this quarter.”
We now have two issues that need to be addressed. Today, we are going to concentrate on the criticality of contextual knowledge.
In a technology company it is very easy, and dangerous, for DevOps adoption to become synonymous with the rollout of automation via a set of tools. Automation is key, but it’s certainly not the sole task and a monomaniacal focus on tool adoption introduces many risks.
One of the key aims of DevOps is the delivery of consumable content to the business more rapidly. As such, the product backlog will be more dynamic and the need to be in communication with the business is increased. It is critical that the technologist understands their product from a business perspective as that will drive value from your investment.
One of the key concepts that can be used when talking to technicians is the Gartner Pace Layer principle. This is not new or radical, but we believe it is very useful as a means of introducing context into discussions.
Figure 1: Gartner Pace Layer Diagram for DevOps1
In our experience, technologists often understand the technical landscape they work within (and often are very keen to innovate) but are less confident about the business value of the product they own. At the trade fair, Nigel talked through the three systems the Gartner Pace Layer diagram highlights, after seeing previous versions of the diagram (above) several years back. He then asked the individual where they saw their product (or aspects of their product) as sitting within the three system types defined. From this, he then moved to a discussion of the areas of automation that would drive most value for their business.
For example, nobody in the business is going to be delighted if we start innovating around a regulatory reporting product. These are hygiene systems that require accuracy and resilience. There are still capabilities in the DevOps tooling chain such as automated testing, a focus on regression validation, etc. that increase confidence and add value. If you understand the context you are working in, you can make more informed decisions on your priorities.
It is a given that there are interdependencies between different products within the enterprise portfolio. A technologist also needs to understand which other products have a dependence on their product and then use good architectural practices (API’s, microservices) to ensure that their product does not become an impediment to the cadence of change of others.
In short, within a large organization we see the role of any central function as being an enabler. You provide capabilities and make it as easy as possible for these to be adopted. DevOps and Agile is all about personal empowerment and with that comes accountability. One of the key accountabilities of the technologists is to understand the business context within which they work. It is critical that this is communicated clearly with appropriate guidance to ensure that investment value is maximized.
1. Gartner, DevOps — Eight Simple Steps to Get It Right , George Spafford, Ian Head, October 9, 2017.
Follow the Enterprise DevOps blog series from Sacha and Nigel
Enterprise DevOps: I Wouldn't Start from Here: Understand Your DevOps Starting Point
Enterprise DevOps: Context is King (this post)
Enterprise DevOps: The Peoples' Front of Judea, or Don't Sweat the Small Stuff
Enterprise DevOps: 13 Principles of Meaningful Metrics Measurement, Part 1
Enterprise DevOps: 4 Further Considerations for Metrics Measurement, Part 2
About the Authors
Nigel Willie
With over 20 years’ experience working in IT for one of the world’s largest financial institutions, Nigel has experience managing and delivering global transformation programs. Starting his career as a developer, Nigel’s most recent role was to deliver cross-platform DevOps automation capabilities to the enterprise. From his experience, he understands many of the challenges and mistakes involved in a DevOps transformation; indeed, he claims to have made most of the mistakes himself.
Nigel has also had the good fortune to work with a lot of highly skilled individuals, both as colleagues and across the industry. He is attempting to share some of his personal observations and thoughts in the hope they will be of value to others. Nigel is a great believer that every initiative is individual and any observations he makes are intended as principles or guidelines, not rules.
Sacha Labourey
Sacha is a native of Switzerland and graduated in 1999 from EPFL. While at EPFL, he started his first consulting business - Cogito Informatique. In 2001, he joined Marc Fleury’s JBoss project as a core contributor and implemented JBoss’ original clustering features. Sacha went on to become GM for JBoss Europe, leading the strategy and helping to recruit the partners that fueled the company’s growth in the region. In 2005, he was appointed CTO, overseeing all of JBoss engineering.
In June 2006, JBoss was acquired by Red Hat (NYSE :RHT ). As CTO, Sacha played a crucial role in integrating and productizing the JBoss software with Red Hat offerings. In 2007, Sacha became co-General Manager of Red Hat’s middleware division. He left Red Hat in 2009 and founded CloudBees in March 2010. Follow Sacha on Twitter .