One mistake large enterprises often make is trying to handle DevOps the way they’ve traditionally handled any other enterprise IT project. Some simply check the box and label their infrastructure automation or ops team “DevOps.”
As it turns out, if you’ve focused efforts on things such as building software delivery pipelines or automating infrastructure, you aren’t necessarily “doing DevOps”; instead, you may be improving or building a Delivery Engineering practice. By improving Delivery Engineering capabilities, you will better enable a DevOps way of working within your organization.
DevOps vs. Delivery Engineering
DevOps is the set of working behaviors and philosophies associated with removing waste and accelerating delivery within an organization’s value stream. DevOps is the collaboration, teamwork, and innovation that enable organizations to move quickly and adapt to change. It could involve walking down the hall to talk to someone instead of sending an email. It may also involve automating a task found to be repetitive or subject to human error.
DevOps is a way of working, not a job title or a particular team that works in a silo between development and production.
Delivery Engineering, on the other hand, is a specific area of work focused on building and improving systems to accelerate the delivery of software and infrastructure. This work is often the first target of enabling DevOps practices due to its direct impact on the overall system. In these instances, it’s often labeled “DevOps” on its own. However, while Delivery Engineering can facilitate DevOps, it’s not DevOps.
To better define Delivery Engineering, we can look at it as a key piece of the physical delivery process of releasing your products. If you consider it the “build, package, and ship” phase of delivery, it’s the work associated with two efforts: Infrastructure Delivery and Software Delivery.
Infrastructure Delivery could involve automated infrastructure development and provisioning (infrastructure as a service, or IaaS), configuration management (CM), image/container management and orchestration, and monitoring and instrumentation of a toolchain to be used by Software Delivery processes.
Software Delivery is the effort around automated build and deployment. This is often continuous integration and continuous delivery (CI/CD), pipeline creation and orchestration, automated test integration, application deployment validation, artifact and software version management, and the usage of automated infrastructure provided by Infrastructure Delivery.
These two efforts work together to provide the toolchain and pipeline required to deliver digital assets to your customers.
Defining Delivery Engineer Roles
Now that we’ve defined Delivery Engineering, we can make a case for dedicating time and effort for this work. What might Delivery Engineering roles look like?
Software Delivery Engineers understand the build and deployment process for multiple application platforms/languages. They focus on improving the day-to-day experience of development teams via automation and pipeline development. Infrastructure Delivery Engineers, in turn, focus on automating the provisioning and configuration of systems used in the delivery value stream, including application environments, toolchain/pipeline tools, container orchestration systems, and cloud migrations.
Since we now have a definition of these roles, we probably shouldn’t be creating “DevOps teams” or inappropriate job titles like “DevOps Engineers.”
Need more examples of work in this area? Here are some of the things Delivery Engineers may do to improve the delivery system and accelerate delivery:
- Help decouple or “strangle” monolithic codebases.
- Migrate legacy, “non-Git” SCM code repositories to git repos.
- Help teams use a branching model not designed for rapid delivery (e.g., long-running branches, branches not tied to tickets, large change sets, not using pull requests).
- Bring CI to applications and teams without CI pipelines.
- Integrate testing frameworks into applications with limited or no automated testing.
- Bring standard versioning processes like semantic versioning to applications.
- Support container management expertise via Kubernetes, Docker, etc.
- Help organizations move away from “pet” server environments (unique/snowflake/one-of-a-kind or indispensable servers that are manually built and deployed) or other missing automated configuration.
Delivery Engineers work to understand what is needed to connect all of the tools in the delivery system, including CI Systems like Jenkins or GitLab, ticketing systems like Jira, group chat apps like Slack, internal infrastructure, and cloud providers like Amazon AWS. They orchestrate the interconnections between these tools to enable fast feedback to delivery teams to accelerate development and delivery of software or infrastructure systems while amplifying visibility of the value stream.
Delivery Engineers are often “T-Shaped” engineers. Think of the T-shaped concept like this – the vertical bar on the ‘T’ represents depth of expertise in a single field, whereas the horizontal bar represents a breadth of skills and the ability to collaborate across disciplines. Delivery Engineers can go deep on supporting their primary function but understand enough of the larger application stack to facilitate integration across several tools and functions. While they may have concentration in a single area such as software builds and deployments or infrastructure automation, Delivery Engineers become cross-functional across each area within the delivery system over time.
To summarize, Delivery Engineers are experts in improving development flow and delivery. They evangelize DevOps practices such as treating everything as code and building in automation to help deliver software to production faster.
Improving Delivery Engineering in Your Organization
A primary goal of Delivery Engineering is to build the path to production by automating and concentrating improvements around bottlenecks such as integration points and handoffs. To accomplish this goal, engineers work closely with delivery teams daily to break down silos, build more resilient pipelines, continuously improve the delivery system, and help with the adoption of better overall delivery practices.
One way to improve these areas across a large organization is to assign a dedicated group of engineers to support delivery teams or individual team members. Building an “as a service” model can accelerate adoption of Delivery Engineering capabilities where teams may not feel they have the resources to get moving quickly. For example, a centralized service team could bring improvements by organizing internal “DevOps Days,” championing the benefits of ChatOps, and hosting delivery excellence brown bags and lunch and learns.
Delivery Engineering as an organization on its own can support multiple delivery teams and the larger organization by introducing and reinforcing improved delivery standards and a company-wide focus on the value stream.
In conclusion, you shouldn’t have silos of “DevOps teams” or “DevOps Engineers” but should instead have Delivery Engineers who focus on the needs of automation and flow. By deliberately applying much-needed resources to this effort, you will be able to improve the overall system, accelerating delivery of your organization’s products and services.
