By: Jim Leichtenschlag – Practice Leader – GlobalNow IT
There’s little doubt that if you are part of an organization that delivers software, you are aware of the DevOps movement, which is all about increasing the velocity and frequency of software delivery to production with the highest level of quality. If you think that following Agile Methodology means you are doing DevOps because you are building software fast, think again. Building software fast is one thing, delivering it to production is where DevOps comes in, and its quite another problem to solve. The question any IT leader should be asking is: Is my organization capable and ready to embrace DevOps?
Like Agile Development impacted the processes, tools and talent necessary to manage defining and delivering software product requirements through the build cycle, DevOps offers a similar set of challenges to the second half of the software delivery processes. DevOps is meant to streamline the processes from software construction to test to deployment. Like Agile Development, for DevOps to be most effective, the processes need to be improved earlier in the cycle, which for DevOps really starts with Continuous Integration.
The best part of DevOps is that it essentially applies all the principles of software development to the end to end delivery process. The delivery process should be looked at as an automation programming challenge. Like any other programming challenge, this means:
- Define the problem
- Break it down into achievable steps
- Identify the useful process metrics
- Identify the available tools you can leverage
- Fill in the gaps with programming
- Minimize the human dependence
- Enable configuration and exception
- Iterate through it until you achieve solving the problem
In bigger organizations, the problem is large and complex. You can and should look at the DevOps based delivery process as a product and thus apply product life cycle management techniques. If you are starting out, this means define a set of MVP processes and then develop a series of additions/changes/improvements that move you along the development of a more comprehensive and complete DevOps maturity. This helps you avoid boiling the ocean….small steps lead to promised land.
The organizational talent needed to deliver effective software delivery processes using a DevOps orientation means having resources that are less bound by traditional roles. You may have people on staff with the interest and desire that you can simply unleash, but you may realize not everyone on staff has the ability or desire to play in different sandboxes. The bottom line is you need people that are open to understanding details outside their immediate role so they can contribute in a way that allows their output to enable the next steps in the process. Example: the application architect should learn and/or work with IT Ops to understand the characteristics and limitations of your production environment; ensuring the architecture is actually workable and code is not sent back or worse, causes a compromise in the production environment.
Just like a sales engineer can be a conduit to manage and ease the translation of business desires to technical development reality, DevOps engineers can ease the translation of the development environment to a stricter IT Operations environment. The closer those two layers are aligned, the faster everything goes and the higher the resulting quality.
Successful DevOps alignment means looking at the organization and making sure that mid-level leaders have both the decision-making authority that enables barriers to be broken down and their peer-level success measurements are reliant on one another.
With this level of capability and thinking is in place, you are ready to unleash the power of DevOps in your organization.