Application Service Deployment Plans Influenced by Team Structure

Developers really are different. From their roles and responsibilities to their placement in the organizational structure, developers are often the "odd group out". You can't even necessarily include them in the term "IT" because development teams swing on pendulums between being a part of IT and being a part of the business.

Even while DevOps as a cultural shift begins to take root, most organizations remain functionally organized into what are not so fondly referred to as IT silos. In our State of Application Services 2019 research, we found that nearly half of all respondents (46%) were still organized in "single function teams" a la "Network", "Server", "Storage", and "Security". More than one-third (37%) were working on combined operations teams better suited to embracing and applying DevOps principles and approaches to application delivery and deployment. Just 15% were working on small, cross functional teams based on business units or company products.

Structure matters, because it in part defines your purpose and priorities. That, in turn, determines the metrics by which success is measured. Siloed organizations mean siloed metrics. We can see that in our NetOps and DevOps survey from last summer. We saw significant differences in how teams were measured based on structure. For example, the most common metrics across all team types and roles were:

1. Network uptime (60%)
2. Application uptime (56%)
3. Process optimization (40%)
4. Mean time to resolution (39%)

But when we break that down and look at metrics based on team types, we see that the more collaborative - a.k.a. DevOps-like - a team structure is, priorities shift. 

Now, how does the metrics by which you're measured relate to application services? Quite a bit, actually.

If your primary focus is network uptime, you're going to work toward that and deploy services that serve that goal. The same for application uptime. If that's your priority, you're going to take availability services a lot more seriously than the folks being measured on deployment frequency.

We can see the impact of a largely "single function team" respondent base in the deployment plans for application services in our research. It is more evident when we categorize the application services by what they provide for applications - security, performance, identity/access, availability, and mobility. 

These results reflect the impact of single function team metrics. Developers are concerned primarily with availability - which often includes specific performance goals - and plan to deploy those application services that support both availability and performance. Likewise, NetOps are focused on those application services that support network uptime by optimizing, scaling, and protecting the network protocols applications rely on. 

Team structure matters. Not just because of the need to encourage a more collaborative culture, but because of the way it impacts decisions - including technology choices. Diverse goals lead to friction and frustration. It's one of the reasons we see application services like load balancing that are traditionally deployed and operated by NetOps being arrogated by DevOps and deployed as part of the application. Because in organizations with single function team structures, application uptime is a priority for developers but not for NetOps.

To really capitalize on DevOps, team structures - and the metrics by which they are measured - must shift toward more collaborative models and away from traditional, single-function teams.

Because silos belong on farms, not in IT.