TEKnically Speaking – Automation, Part 2
Normally I’d be reticent to use two terms that have multiple definitions in an interactive conversation, much less a blog post. However, since this post is part of a larger series, we’ve already covered the various ways automation is used as a term, so let’s define how we are using DevOps in this post. While DevOps is normally associated with more culture and people related aspects, for visualization purposes we are also going to include the CI/CD pipeline elements into our DevOps automation reference.
The people and cultural motivations around DevOps Automation should be at the forefront of strategic planning conversations, as well as in daily engineering standups, for many of the same reasons. Engineers are striving to automate processes to improve delivery time, consistency and quality, and sometimes, because there is a tedious process that they are simply tired of doing. Managers and directors discuss those same goals, but are also looking to do more with what they have, or in some scenarios, do the same with less. In all of those scenarios, meeting automation goals lowers operating costs, improving time to value, and improves quality and security. Automation also ultimately allows for one of the other major cultural goals of DevOps—shared ownership throughout the lifecycle, breaking down silos, and improving collaboration.
The Process and Technology Benefits of DevOps
In addition to people-related considerations and benefits, DevOps delivers an advantage in terms of process and technology. Process automation is at the core of DevOps automation. This can happen across any and all of the key consideration areas, such as the software development lifecycle (SDLC), operational visibility, continuous integration, and continuous delivery. There are typically, and predictably, three effective ways to use automation:
- The engineer driven decision to automate a complicated, frequent, or time-consuming process (most common use of automation).
- To eliminate human error after some sort of issue or incident has occurred due to a manual process.
- Through proactive design as an output of analysis from a business architect on existing manual processes, or the rollout with automation in place for a new business process (least common use of automation).
There are obvious benefits to all three scenarios, but I can’t stress enough that the third proactive way of rolling out automation, should become part of any healthy DevOps culture. Enterprise architecture, both business and technical, can significantly uplift the overall benefits an organization yields from its DevOps practices.
Automation is an aged topic in information technology, but it’s definitely received a new and deserved level of focus in organizations, thanks to DevOps culture and practices. Even if you don’t prescribe to DevOps in your organization, I highly encourage you to explore its core concepts and practices to see where you can standardize, optimize, and automate.
