DevOps from the Front Lines: Enterprise Adoption Principles and Pitfalls
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source:- sys-con.com
So, what do I think of when I’m told a company wants to adopt DevOps? The first thing that comes to mind is the size of the organization, and how far they want to take DevOps best practices. I really want to know what DevOps adoption will mean for the company.
In my experience, it gets especially interesting for large organizations that rely on a lot of applications and teams. There are important principles that support adoption. First, adoption should include a clear directive of how people and processes will be organized to manage application lifecycles and their interdependencies. Adoption also includes selecting the optimal technologies to manage the lifecycle and pipeline.
Next, DevOps governance should specifically address:
- Cloud-based infrastructure services – both private and public options
- Development Workstation Standards and Images
- Source Control Standards
- Continuous Integration
- Continuous Delivery
- Testing methods and required coverage
- Configuration Management
- Continuous Monitoring
- Standardized Method of Delivering Information for each applications – Business Health, Operational Health, Testing Health, Development Health and Pipeline Health
Finally, leadership must carefully select the right applications in the enterprise that will truly benefit from DevOps adoption.
Now that we have an outline of how to structure adoption, let’s look at four of the biggest pitfalls that I’ve seen:
No Comprehensive Plan
This is the big one. IT executives usually have the ambition, but they often lack commitment to a clear, well-defined design for the comprehensive transitional approach that DevOps requires. Without a single top-down approach and sponsorship, DevOps initiatives face crippling disconnects across critical stakeholders such as infrastructure services, testing, project management, development and operations. Without a unified plan, everybody ends up with different—often conflicting—priorities. The DevOps team is broken into factions. Championing around one common cause for the necessary application is impossible.
Tell-tale symptoms of fragmentation include:
- Cloud Services aren’t available to the application team.
- Configuration Management isn’t used.
- Feedback loops only work for certain members of certain groups—not across teams.
- Development doesn’t prioritize necessary DevOps tasks.
- Agile is only employed by development–not throughout the entire pipeline.
- Department silos stifle innovation.
- Isolated individual groups spend too much time proving to other silos why DevOps is needed.
No Cross-Functional Training
Many companies suffer from a lack of training on technologies and processes that are a part of the DevOps initiative. In nearly all cases I’ve seen, the application team is cross-functional, but people from other areas simply fill defined, siloed roles. When organizations don’t educate everyone on cross-functional processes and technologies, DevOps can die a slow, painful death.
Missing DevOps Roles
This problem follows directly from the first two pitfalls, but it can go unnoticed until trouble strikes. A lack of planning and training means that some critical roles and responsibilities are simply left out of the org chart for the DevOps team. Without appropriate divisions of labor and chains of responsibility, DevOps is impossible. A well-defined cross-functional agile team should be formed around an application pipeline rather than multiple teams representing each of their corresponding departments.
Information Stuck in Silos
Organizations may have many valuable reports, dashboards and data that they’ve created for the application or pipeline within operations, for testing results, and/or showing development status—among other things. Along with these sources of information, groups may have improved processes within these silos, too. However, without some consistent and agreed upon standard central way to socialize and/or regularly communicate these efforts, individual team contributions remain just that–individual. This prevents useful information from making a big impact across the entire pipeline. Siloed insight means siloed innovation and improvement.
This is just a brief snapshot of a few strategies to use and pitfalls to avoid when adopting DevOps. Just remember that the best adoption initiatives start at the top. They’re backed by committed, prioritized and coordinated teams across all functional areas.