At public corporations (especially regulated) there are confounding factors that make DevOps a farce. For example audit, a point of view that IT is a cost center, and the non technical management decision making that go along with the previous challenge the spirit and proper execution to get DevOps right. But in reality DevOps is a symptom of a larger issue - functional reporting structures and goal misalignment.
Audit - the idea that your developer doesn’t have access to production systems and data is a challenge to DevOps. The idea that one person codes and one deploys can be a challenge. Some organizations like management visibility and an audit trail to prove it - this can challenge automation and frequent deployment. This is not just a DevOps issue, audit expectations for business requirements and QA signoff can be just as bad. Admittedly some of the audit rules are relics of the past but the need to be addressed in order for DevOps practices (and really for agile teams to be agile.
In organizations where IT is a supporting function of the business there is a view point that it’s a cost center only and doesn’t produce value and should be cost controlled and managed to ultimate efficiency. I’ve reminded CIOs that the work the IT team does is not “a factory” as they sometimes insist on calling it - no one in technology that I’ve ever met (except management) really wants to think they work in a factory.
The efficiency mindset rank orders roles with QA and analysts at the bottom, devops slightly higher, developers relatively high, architects at the top of the skilled food chain and management of course at the top. To some degree these functions can be centralized so they can be optimized and made efficient. Centralizing typically means you work for management rather than a particular business mission. Your job is to make management look good and keep everything running smoothly (remember you work in a factory). Management generally looks good when quality is achieved at a lower price point. Along with that tends to be a higher level of off shoring at the lower end of the skill rank where larger numbers means more efficiency at lower cost. Here lies the problem - the premise of DevOps is that the role is integrated in the team. When DevOps is a function reporting to management then their goals aren’t aligned to the development team. They might not even sit with the team and they might have their own orders. They might be in a 12-20 hour time zone offset.
To me the larger issue is management structures aligned by function instead of business. This leads to misalignment if goals and ultimately lack of integration in functions. It’s a bigger problem than DevOps and it’s a bigger problem than IT. I think the companies that get management reporting right will win in the end. I am curious to see how Google and Amazon respond to these issues at their scale. The pizza team doesn’t work when everyone has different goals.
Audit - the idea that your developer doesn’t have access to production systems and data is a challenge to DevOps. The idea that one person codes and one deploys can be a challenge. Some organizations like management visibility and an audit trail to prove it - this can challenge automation and frequent deployment. This is not just a DevOps issue, audit expectations for business requirements and QA signoff can be just as bad. Admittedly some of the audit rules are relics of the past but the need to be addressed in order for DevOps practices (and really for agile teams to be agile.
In organizations where IT is a supporting function of the business there is a view point that it’s a cost center only and doesn’t produce value and should be cost controlled and managed to ultimate efficiency. I’ve reminded CIOs that the work the IT team does is not “a factory” as they sometimes insist on calling it - no one in technology that I’ve ever met (except management) really wants to think they work in a factory.
The efficiency mindset rank orders roles with QA and analysts at the bottom, devops slightly higher, developers relatively high, architects at the top of the skilled food chain and management of course at the top. To some degree these functions can be centralized so they can be optimized and made efficient. Centralizing typically means you work for management rather than a particular business mission. Your job is to make management look good and keep everything running smoothly (remember you work in a factory). Management generally looks good when quality is achieved at a lower price point. Along with that tends to be a higher level of off shoring at the lower end of the skill rank where larger numbers means more efficiency at lower cost. Here lies the problem - the premise of DevOps is that the role is integrated in the team. When DevOps is a function reporting to management then their goals aren’t aligned to the development team. They might not even sit with the team and they might have their own orders. They might be in a 12-20 hour time zone offset.
To me the larger issue is management structures aligned by function instead of business. This leads to misalignment if goals and ultimately lack of integration in functions. It’s a bigger problem than DevOps and it’s a bigger problem than IT. I think the companies that get management reporting right will win in the end. I am curious to see how Google and Amazon respond to these issues at their scale. The pizza team doesn’t work when everyone has different goals.