The improvement of understanding is for two ends: first, our own increase of knowledge; secondly, to enable us to deliver that knowledge to others.
John Locke
I often say “If you ask five different DevOps/SRE engineers what the term means, you will get five different answers”. For myself, I define it as:
“Role of enabling developers to author, deliver, deploy, maintain, monitor and diagnose software systems whilst maintaining high velocity, quality and uptime“
The word “enable” appears frequently in documentation around DevOps, but finding out what that really means is harder. In this sequence of byte-sized posts, I will attempt to delve more deeply into some of the implications of that word. IMHO, DevOps is not a team or an activity but more a philosophy. The mantra of DevOps is to help other people rather than to own a silo.
To enable developers, we need to empower them to take responsibility of the entire software lifecycle, and understand an increasingly complex ecosystem of tooling, languages, libraries and infrastructure.
Enablement allows us to :
- Reduce costs by increasing efficiency and quality and reducing waste
- Increase velocity by shorting OODA loops, increasing self reliance and the speed of iterations
- Increase customer value and product alignment by faster feedback both internal and external
- Improve visibility and communication
- Improve security with better education, processes and tooling
- Reduce developer churn by improving satisfaction and culture and reducing burnout
This empowerment process breaks down into:
- Culture: A good working environment and a culture which supports and rewards the developers for their efforts is essential
- Investment: We should strive to provide the appropriate resources and investment to support the developers with tools and services they need, whilst ensuring that costs are not permitted to spiral out of control
- Education: We must ensure that we have appropriate educational support for our developers, and make the time for them to use those resources
- Process: Delivering software is a deeply complex amalgamation of many processes. Solid processes with good tooling support and excellent documentation are a requirement to achieve velocity without sacrificing quality
- Reviews: Code reviews are a contentious subject in the software industry and often result in time sunk in pointless arguments or addressing concerns modern tooling can alleviate. Improving reviews, including code, process and performance is a key enabler
- Reduce or Remove barriers: Developers should not have to fight against the system in order to deliver their software with high confidence
- Metrics: Improvement should always be driven by measuring what matters and focusing on improving the Return on Investment (RoI)
- Security: Security is hard to retrofit so encouraging a culture of security awareness and implementing secure processes from the get go is essential. Developers should have the appropriate tooling, guidance and processes to ensure security is built in
Also, in order to achieve the above, a wise DevOps/SRE engineer will leverage development to help themselves via feedback, authoring internal tools, automation, skills transfer and peer reviews.
Over the next few posts I shall elaborate on these areas.