My son plays tennis on his high school’s varsity team. While he doesn’t play at a professional level, he’s had every opportunity to learn the skills and techniques of world-class athletes, using the same equipment that they use today. Over the years, tennis rackets have evolved from large, heavy pieces of solid wood to ultra-light and flexible man-made materials like graphite. It’s readily available to anyone, including my son—not just the pros, like Roger Federer and Naomi Osaka.
The democratisation of technology has given everyday people greater access to use and purchase new technologies, dramatically changing the way consumers view and demand such access. This is also true in the IT world. From agile to DevOps, these are movements that are in pursuit of democratising application development, a domain sought after by hard-core technologists. Today, a self-service platform and automation are key to accelerating and enabling effortless app deployment on demand.
Goodbye request tickets
Back when I was working as an engineer on a large software development project (and many Linux versions ago), there were specialised roles. While I wrote, checked, and unit tested my code, I wasn’t able to integrate or deploy it. Forget provisioning a dev server (yes server, not an environment).
For each of the tasks outside my immediate responsibilities, I had to open a ticket and wait for someone else—typically a specialist in that area—to perform my request. One individual provisioned a test environment while another integrated the code and built the WAR files. It was only six working days later (if things went smoothly, and no one was on vacation) that I learned there was a bug in the last code updates I wrote.
In today’s world, the adoption of continuous integration and continuous delivery (CI/CD) has changed how developers and testers ship software. In a fully automated CI/CD pipeline, a developer can do so much more—write code, commit it, integrate it, deploy it, provision and configure a test environment, provision test data, run the tests, and get the results back in hours (if not minutes) for any changes.
But the specialists have not gone away. They have democratised the services they deliver, and as a result, it’s elevated their roles to a higher level. They are delivering the capabilities they used to perform themselves, but now as a service available to other practitioners via self-service. For example, the developer is empowered to focus on writing the best code while the database administrator manages the performance, integrity and security of the database. This is true DevOps adoption—fostering a culture of collaboration and trust.
The ‘core four’ tenets of modern DevOps tech
In order to work at scale across an enterprise, there are four key tenets for adoption: self-service capabilities, permission, guardrails, and trust. Let's look at each one of these in detail.
1. Self-service driven empowerment
The shift left concept is a core tenet of DevOps. It requires capabilities to be made available to practitioners earlier (shifting left) in the application delivery lifecycle. Specialists, to the right, make their capabilities available to all practitioners to their left, via self-service. The goal is to empower the practitioner who needs the capability, as and when he or she needs it. This requires the service to be ideally accessible via API and/or a command-line interface (CLI), integrating into the practitioner’s toolset and workflow of choice.
2. Permission to act and experiment
Democratisation needs to come with permission to act. What good is providing a practitioner with a capability if he or she still has to ask for permission before every step? The individual needs to be able to act and experiment with the capabilities provided. At the same time, these need to be done within well-defined boundaries, which is where the guardrails come in.
3. Guardrails to protect
The age of 'move fast and break things' is passé. Role- and policy-based access controls and governance need to be built into every capability being democratised. The developer needs to be notified when he or she has hit a guardrail and kept from crossing its bounds. The individual should not need to query, for example, whether or not he or she has permission to deploy a new version of the code to a server in an offshore data center. The service should prevent that person from doing so if it is not a permitted action via role-based policies embedded in the automation of the service itself. If the individual is allowed by the service to execute the deployment, it should not break any security or compliance requirements. The automated guardrails must protect both the individual and the organisation.
4. Environment of trust
Democratisation needs trust and builds trust. A developer, as a consumer of a service, needs to trust that the results he or she gets from a number of actions are real and accurate. The individual also needs to trust that the guardrails of the service will keep the person within the bounds of what is allowed and kosher. In turn, specialists need to trust that the developer is not misusing the access he or she has. Management should also trust that the organisation will learn and develop a new culture of communication and collaboration with the new freedom they are all afforded. They should not look at this solely from a cost reduction perspective, but as a path to make the practitioners more productive. Do more with what you have.
Adopting democratised services
The democratisation of technology is the essence of DevOps. The adoption of a 'democratised' model of services for application development or the delivery of AI and machine learning models require both a top-down and bottom-up approach.
From the bottom up, practitioners should see this as a way to elevate their skills to the next level, to become more productive and creative while honing their craft as they no longer need to do rote, repetitive tasks. From the top down, senior executives and business leaders need to invest in the transformation—to allow silos to break down and for roles to become both more fluid and specialised. Above all, they must allow for organisational fiefdoms to end. For many large enterprises that have grown up with command-and-control organisational structures, this is the toughest part of the transformation exercise. The executive leadership must be fully supportive of the work in order for it to scale. It's all or nothing.
Looking at DevOps adoption from a lens of 'democratisation' of the CI/CD pipeline is a perspective that brings the entire organisation on the same page. This gives everyone a glimpse into how they need to change their jobs and roles to enable democratisation. It also eliminates the need for the mythical full-stack engineers—the so-called superheroes in Silicon Valley who can do it all. In large enterprises, we need practitioners who specialise in their craft while understanding and appreciating the craft of others by working in a trustworthy manner. Only then does everyone win.
Sanjeev Sharma, VP and Global Practice Director of Digital Transformation, Delphix