Welcome back to the blog series in which we summarize the findings of our Autonomous Cloud Management Survey. In part 1 we examined the
Dev-to-Ops ratios that organizations have for their most critical application projects. In this post, we’ll look at
organizational silos, and how far organizations have come in breaking them down. To explore this issue, we asked
participants the following question:
Which of your teams have access to production monitoring data?
Three quick conclusions:
1) More than 80% of the respondents claim that their Development teams have access to production monitoring data. This
is good news.
2) The fact that only 43% of QA teams have access to production monitoring data leads us to conclude that many QA teams
still operate in silos. Ideally, QA teams use production data for better test definitions (based on real use cases) and
better workload modeling for load testing (based on real-world load behavior). Organizations that don’t look at
production data may test the wrong things and simulate the wrong performance tests.
3) Only 41% of business stakeholders have access to production monitoring data. This leads us to conclude that many
business teams are still relying on tools that only provide insight into certain types of organizational data (for
example, marketing tools), or they are not at all involved in the software development lifecycle.
The case against silos
Digital transformation and organizational agility can only take place when organizations break down silos across
departments (i.e., software development, IT operations, support, and business teams). Interestingly, only about 20% of
this challenge can be attributed to technological limitations. The remainder of the challenge requires changes in
organizational structure and culture.
Here’s how silos are organized at a typical company:
With such an arrangement, each department operates independently, focusing on its own silo-oriented KPIs, with little
attention paid to business and customer concerns. This creates a range of problems:
- Misaligned goals across teams
- Slow collaborative processes
- Slow releases
- Disconnects between users, services, and products
Define agile teams with a mix of skills pulled from former silos
A better approach is to define agile teams that have a skill mix derived from former silos and ownership of the specific
business goals and outcomes for each microservice or application. In this way, an organization can break through silos
and create stronger business outcomes overall. Eventually, a previously siloed company can be reorganized as follows:
In such a setup, shared high-level metrics drive individual team members to focus on improving customer outcomes,
creating more value, and improving the bottom line. Team members can:
- Be more agile
- Automate processes
- Release faster
- Focus on business outcomes
So, instead of a Support representative focusing on the number of closed support tickets—which has little direct
correlation to business success and customer happiness—the cross-talented team is collectively focused on business
outcomes, like customer retention and revenue growth.
Such cross-talented teams work together on the same service/application and, when something goes wrong, rely on the same
data to diagnose and resolve issues. This can only work, however, when data monitoring and reporting are standardized
and accessible on a common platform that all team members can access.
Production monitoring data: The lifeblood of cross-talented teams
All team members of cross-talented teams need to have the same understanding of the company’s business-critical
applications—from code-level visibility to insights into end-user experience. With shared access to the same monitoring
data on a common platform, team members can quickly find answers to their most burning questions:
- Developers: “Do people use the recently deployed feature at all? If so, how are they using it?”
- IT Ops: “Does the new mobile app meet the company’s SLA?”
- Support: “Why were so many new support tickets opened last weekend?”
- Business stakeholders: “How much revenue is generated by each of our applications?”
When business stakeholders notice that the revenue generated by an application has dropped since the last deployment,
they can easily correlate this information with the usage metrics of any recently deployed (or removed) features. In
this way, business stakeholders and developers share a common understanding of what’s going on and can decide together
on plans for addressing the drop in application usage.
Thus, production monitoring data becomes the lifeblood of your enterprise, letting cross-talented teams make informed
decisions. This level of understanding is essential in rapidly changing market landscapes, where businesses live and die
based on their reputations.
How to get started
Are there silos at your organization? After identifying them, you may want to create a strategy for bringing all team
members onto the same page. Help everyone understand the common vision and goals, and how they can contribute to the big
picture.
Then assemble small, cross-talented teams that have “cooperation, communication, and collaboration” as their mantra.
Lastly, work toward common goals by giving your teams access to the same monitoring data on a common
performance-monitoring platform that facilitates and supports team collaboration.
When our customers deploy Dynatrace, they quickly see that it’s much more than just an APM solution. It’s an all-in-one
software intelligence platform that provides insights into the full application stack with
automation and simplicity. It won’t take long before your team members recognize that they can achieve much more with
Dynatrace. That’s when they’ll realize that they’ve found an effective real-world alternative to working in siloed
teams.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum