This presentation was delivered by Julie Craig, Research Director of Enterprise Management Associates (EMA) and Kalyan Ramanathan, VP, Product Marketing AppDynamics in a webinar. Julie reveals the results of a recently conducted EMA survey of 300+ IT professionals highlighting the real-world impact of Franken-monitoring.
On-demand webinar is available at: bit.ly/Franken-Monitoring
We’re hearing a lot these days Application Performance Management, AKA APM
We’re going to take some time today to figure out what’s real, what’s hype, and what it means to you and your company.
To answer these questions, EMA and AppDynamics recently partnered to conduct a survey of the APM marketplace. The objective was to develop a neutral, third-party view of the current state of application delivery– and application management-- within enterprise IT and service provider data centers
During today’s event, I’ll share the results, based on the input of more than 300 IT professionals worldwide
Before I start, I wanted to talk about the title of this event.
AppDynamics actually proposed the title. However I find the Frankenstein analogy particularly apropos when applied to modern applications
As far back as 2012, I named Frank N. App as my APM man of the year. That blog post can still be accessed at the link I’ve included above.
It’s true that, at the time, I was referring to the applications themselves. They were in the process of becoming increasingly component-based and complex. Developers were not only reusing code, they were cobbling together applications from bits and pieces of code running on a wide variety of platforms. Operations teams were finding that, once in production, these FrankenApps were very difficult to monitor and manage. To complicate matters, they often did not perform particularly well.
In today’s event, we’re extending this concept to tooling as well. We conducted the survey, in part, to identify the types of tools being used to perform the APM function– and to see if they were as diversified and disconnected as the applications they were managing.
Shifting back to the survey, let’s start by looking at the demographics of survey participants.
We intentionally surveyed an approximate 1/3 2/3 mix between EMEA and North America. We chose this mix because we wanted to make sure we had a good understanding of the differences and similarities in APM challenges across geographies.
To make sure those we surveyed were knowledgeable on the topic of APM, we selected only those respondents actively involved in application delivery via a series of qualification questions.
They also needed to be familiar with managing large scale, enterprise applications, versus desktop applications only. Finally, since some of our questions were budget-related, they also needed at least a high level understanding of IT budgets within their own organizations.
Of the 300 plus who responded to the survey, a little less than half were executives, defined as Directors and above.
Middle managers self identified as managing technical teams or being involved in activities such as application architecture, while line staff were those on the front lines, hands- on specialists tasked with actually MANAGING the applications.
In a few cases during this presentation, I’ll talk about the differences we saw in the responses across the three groupings.
Often, line staff have a far different perspective on the the day to day, nuts and bolts aspects of application delivery than their management peers, and its very revealing to examine the differences.
In examining data from any survey, company size is important. This is particularly true in IT’-focused surveys, since typically, the larger the company, the larger and more complex its IT environment.
This isn’t always true– for example public cloud providers may have very complex environments and relatively few employees to manage them. However in general, company size does provide a context for judging answers related to scale and complexity-related challenges
It provides a general idea of the scale and breadth of IT ecosystems being managed, and sub analyses based on company size can be very useful as well.
One of the most interesting statistics revealed by the survey is the fact that only about 30% of companies had application-specific tools in place. Both Application Management platforms and consolidated application and infrastructure focused tools are counted in this percentage.
Interestingly enough, these numbers are very similar to those from research I did in late 2014, so they haven’t changed significantly in the past 6 months.
And while the vast majority of companies have silo tools in place, those who have invested in application-focused platforms or solutions are still in the minority.
That being said, you have to ask yourself whether companies are investing in tools at all.
When you look at the numbers, you can see that companies ARE spending money on enterprise management products, however they are primarily silo-focused in nature.
The numbers vary, of course, depending on company size.
Most appear to have between 6 and 25 tools, with about 45% reporting more than that.
This slide is an attempt to quantify the true value proposition of tools investments.
By focusing on percentages versus numbers alone, this view of the survey data eliminates the element of company size we see when measuring only # of tools.
This analysis reveals the percentage of overall tools investments which are basically wasted on shelfware.
It reveals that nearly 45% of companies are using 50% or fewer of the tools they have purchased
This is a very interesting statistic, particularly in view of the flat budgets we were seeing 3 or 4 years ago.
It would be interesting to know what went wrong, but the point here is that simply buying a tool doesn’t mean it will turn out to be an organizational asset.
My conclusion from the last three slides is that the low adoption rate of application-focused versus silo-focused tools is not necessarily due to budgetary constraints. Companies ARE buying tools.
So we have to dig deeper to figure out why such a small percentage of companies have invested in application-specific tool sets.
We’re hearing a lot these days Application Performance Management, AKA APM
We’re going to take some time today to figure out what’s real, what’s hype, and what it means to you and your company.
To answer these questions, EMA and AppDynamics recently partnered to conduct a survey of the APM marketplace. The objective was to develop a neutral, third-party view of the current state of application delivery– and application management-- within enterprise IT and service provider data centers
During today’s event, I’ll share the results, based on the input of more than 300 IT professionals worldwide
One problem is that only 27% of application-related issues are detected by monitoring centers.
And IT becomes aware of application-related issues by calls from users 25% of the time. Now you’ll see that this number is debatable, depending on role. For the moment, however, let’s take a look at why this number is relatively low.
I believe there are two primary reasons for this. One is that IT teams are trying to manage applications as they do silos– by watching the network, the servers, and the databases. This doesn’t work when a technology is horizontally versus vertically focused, as applications are.
The second reason is that what happens in the gaps between silos is as important as what’s happening in the silos themselves.
Silo-focused tools cannot monitor through these gaps. They can’t see interactions between silo elements or the handoffs that occur across the execution chain– things like calls to data bases, message queues, and even external services.
It’s within these gaps and interactions that the most difficult to solve application-related issues occur.
And it is these gaps that are the sweet spot of Application Management-focused tools, since they see beyond silos and ACROSS the execution ecosystem.
Another interesting data point is the last one– basically what IT is NOT seeing. External users almost never report application problems, although they do occasionally vent on Social Media platforms such as Twitter.
With customer-facing applications, it’s often the case that IT never knows about problems impacting external users.
You have to wonder how much revenue is lost from these types of issues, and this is one thing this survey can’t tell us.
It’s also interesting to break down the “calls from users” response based on role.
You may recall that, on the prior slide, this number was calculated as 25% of respondents.
However when you break down this aggregated number, you see that the higher you go in the organization, the smaller this number becomes.
Line staff, who are presumably the most familiar with the nuts and bolts of exactly how IT finds about application issues, reports this number at 34%.
Executives report it at 20%, a delta of almost 15%.
Taking the real number as 34%, one third of application-related problems are reported by users. For many companies, this would be an unacceptably high number.
This slide and the following 2 (tech 4, 5, and 7) look at the administrative “cost” of application performance and availability issues in a variety of ways.
This one quantifies the amount of time it typically takes for an application problem to be solved, in terms of elapsed hours.
Most frequently, elapsed time ranges between 3+ and 6 hours.
What this slide does not show, however, is the fact that many application-related problems are never solved at all.
These intermittent problems become the gift that keeps on giving, returning at intervals, until Application-specific tools are put in place to automate analysis of root cause.
Building on this theme, this slide shows the average number of people involved in solving a problem.
While the most common number is 3-4, almost 15% of companies report that 11 or more people, on average, are involved.
The annual manpower costs of such efforts can be staggering; I’ve talked with healthcare organizations reporting 36 hour conference calls, just to get at the root of an application problem.
Clearly, troubleshooting exercises of this magnitude are unsustainable long term, which is another reason why companies are becoming increasingly interested in application-focused management tools.
The numbers on this slide report the tally in “people hours”.
This is basically the total number of aggregated hours associated with solving a single application-related problem; labor costs can be inferred by multiplying these numbers by average hourly rates.
Most companies range in the 5 hour to 7 hour range; however almost 25% of companies report 13 hours or more.
For companies on the fence in terms of application monitoring/management investments, this slide provides a snapshot of what your application problems are actually costing in terms of administrative costs.
We’re hearing a lot these days Application Performance Management, AKA APM
We’re going to take some time today to figure out what’s real, what’s hype, and what it means to you and your company.
To answer these questions, EMA and AppDynamics recently partnered to conduct a survey of the APM marketplace. The objective was to develop a neutral, third-party view of the current state of application delivery– and application management-- within enterprise IT and service provider data centers
During today’s event, I’ll share the results, based on the input of more than 300 IT professionals worldwide
Flexible deployment options are important to today’s IT Professionals. Traditionally, virtually all APM tools were hosted on premise, and this option is still the right one for many companies.
However others are seeking options such as SaaS where most functionality is hosted for them—or options which they can host in the cloud.
In selecting a form factor, it’s important to find a solution that fits not only today’s requirements, but which can grow and change along with a company’s evolution and priorities
Ability to monitor cloud services is critical or important to an almost identical percentage.
Again, this might be more a future direction than a current need for your company, however it’s nice to know that an APM product can grow along with you
One element that is often overlooked in making product choices is the need to support cross-functional problem solving.
Just as they say it takes a village to raise a child, it likewise takes a village to support applications.
Composed as they are of services running across numerous infrastructure elements, it’s virtually impossible for a single person to have expertise in each application language, network type, device type, etc.
So people often end up collaborating to diagnose and solve application-related problems.
Application-focused tools support collaborative problem solving, particularly those products delivering multiple perspectives on an application– such as from the database, from the network, or from the server.
These products span silos by enabling IT professionals skilled in specific areas to see the application in the context of the area they support.
This common view provides a common language which makes it easier for personnel with diverse skills to collaborate more efficiently.
This in turn means that problems that do occur can be solved far more quickly than would otherwise be possible.
So if you’re in the market for an APM solution, what type of product should you buy?
On this survey, respondents felt that a unified platform– one which consolidates application and infrastructure monitoring in one product– is their top feature choice.
In products of this type, a common data store enables diverse IT stakeholders to see the application in the context of their own area of support and expertise.
A unified platform is also simpler to deploy than multi-component solutions, answering the need of many companies to simplify deployment and maintenance.
This approach is far simpler than installing network, server, and database monitoring tools, then trying to integrate them.
So from this perspective, this finding isn’t really surprising.
Franken apps seem to be the norm, and Franken monitoring– buying multiple silo tools and attempting to integrate them– isn’t a good answer.
While silo tools are still important for silo management, an unified platform can be an excellent option for optimizing both applications and the support costs associated with managing them.