This is the sixth in a series of blogs about enterprise DevOps. The series is co-authored by Sacha Labourey, CEO, CloudBees, and Nigel Willie, DevOps practitioner.
In previous articles, we discussed creating a standard taxonomy of capabilities and, from here, identifying solutions for them.
While all capabilities are critical to delivering a complete solution, it is essential that you don’t focus on delivering individual solutions to your enterprise. It is not an accident that the core DevOps capabilities are prefixed continuous (integration, delivery, deployment, monitoring). To misquote George Orwell in Animal Farm: in a DevOps context “all tools are equal, but some tools are more equal than others.”
From experience, it is common for most of the early requests to be for individual capabilities. For example, “We need automated test tooling,” or “We need improvements to the requirements tooling solution,” etc. We recommend that you avoid delivering single capability solutions without ensuring you deliver something that can be easily integrated into your pipeline, or spine.
An early visual representation of your pipeline is an extremely useful way to force this discipline on yourself. It also stresses the place of individual solutions within the larger ecosystem when discussing requirements with your stakeholders across the enterprise. The concept of a pipeline is so fundamental to DevOps that it often is taken for granted by technicians. In a larger enterprise, it is critical that assumptions are avoided and the critical dependency on integrated capabilities is made clear to all your stakeholders.
We would also like to issue a caution about falling prey to the opposite problem. While you cannot deliver continuous automation using point solutions, you should also avoid delivering a tightly integrated, automated pipeline. Your technologists should be regularly hearing the message that the solutions they deliver need to move from monoliths to microservices, that they need to decouple, remove dependencies and abstract via API’s. The same fundamentals apply to the delivery pipeline. Do not create a monolithic, tightly coupled pipeline but rather use APIs and configuration within the enterprise automation solution. A key question when investigating potential solutions (whether homegrown, open source or vendor delivered) should be, “Does this tie me into a specific ecosystem or solution going forward or can we continue to take advantage of a variety of solutions?”
The spine of your toolchain is critical to the success of any automation initiative. Without early delivery of a robust, consistent and configurable spine, you will create significant issues for you and your customers going forward. It is always easier to architect integration into the solution than to retrofit it to extant point solutions.
Follow the series from Sacha and Nigel:
- Enterprise DevOps: An Introduction
- Enterprise DevOps: I Wouldn’t Start from Here: Understand Your DevOps Starting Point
- Enterprise DevOps: Context is King
- Enterprise DevOps: Creating a Service Line
- Enterprise DevOps: On Governance
- Enterprise DevOps: The Spine is Critical (this post)