Enterprise DevOps: Context is King
Enterprise DevOps: Context is King
This blog about enterprise DevOps talks about how to discuss DevOps adoption, and making sure to keep it separate from the adoption of tools and automation.
Join the DZone community and get the full member experience.Join For Free
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.
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 the 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 are 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.
Published at DZone with permission of Sacha Labourey . See the original article here.
Opinions expressed by DZone contributors are their own.