Why Enterprise APM Projects Fail

I am on a plane – on my way back from the best ever visit to a customer in the UK. One of our largest customers asked that prior to beginning his project he would like to visit another customer site to discuss “implementation.” He wanted to learn from a successful customer and improve his plan to utilize SharePath. I was so pleased from the results of the meeting that it made me realize that I know – not just why APM projects succeed – but also why they fail. That’s what this post is all about. In order to understand why APM projects fail – let’s first discuss what is so special and challenging about the APM market and especially the Enterprise APM market. Enterprise-APM-424x300This is what a successful enterprise APM project looks like

Standard APM tools focus on one isolated application built on one technology stack. That’s simply not what the enterprise APM is all about. Enterprise IT is like a spider web: many dedicated apps connected to legacy applications, linked to commercial applications, etc. The enterprise may have multiple middleware layers mixing message brokers, service busses, queues and other components. Employees and customers may access applications using browsers, rich clients, and even terminals. Enterprise IT has many layers, some are old – really old – and it can get very complicated, very fast. The major challenge in addressing enterprise application performance is simply this: Who owns APM? Think about it for a moment – most companies do not have an application performance management group. When I ask the question – “Who owns end-to-end application performance at your company?” – I get many different answers. It may be application development, application support, QA, operations, engineering, capacity planning, networking, and the most common two – “No one” or “It depends.” Even more than that – APM is treated like old-fashioned network monitoring – “When we have a problem, please let me know by sending an alert. “ This is a huge mistake; APM is not just about crisis management but also about performance analytics.

The simple question is why two different clicks that met the terms of a SLA, on the same system, at the same time, have different response times – is usually an enigma. Very few companies can answer that question, and that’s what APM is mainly about. Companies need to find these answers by closely observing performance phenomena and analyzing them. Even more importantly, they need to take actions to prevent the next occurrence. Crisis management is only one kind of performance issue, and usually a result of lack of effective analytics. Enterprise APM is not easy – that sounds like an overly simple statement, but it is true. In order to understand performance you have to understand programming, databases, networks, servers, operating systems, middleware, storage, and information security.

People who can understand the complete picture are not that easy to find and are usually very expensive. When these smart guys are not around, performance becomes the problem of everyone and many (too many) different groups “own” the problem. The challenge is that these groups look at problems differently, speak different technology dialects, and own different management tools. This situation usually forces a reactive approach to performance and not active one. Enterprise APM software can’t fix these problems by itself – buying a software tool doesn’t address the root problem – it can trigger the discussion that we are so keen to have with our customers: How does APM fit in your organization? Your answer to that question is why Enterprise APM projects succeed and fail.

Deployment vs. Implementation It is important to distinguish between the two different parts of an APM project: deployment and implementation. Good deployment involves solid R&D behind the product, extremely professional support, effective training, and a successful configuration process that supports business needs. It might sound counterintuitive, but deployment rarely fails. Deployment issues always arise and bugs will be part of the software industry forever. A good and responsive R&D organization can fix it all. Add effective and reliable customer communication and most deployments succeed.

Implementation is a totally different story. This is a different project, with a different set of owners, a different challenge, and a different goal because it involves ALL IT departments. Each of these groups has their own role in APM. Enterprise APM implementation managers should ask – how with the minimum installation and the least time can I get the maximum value? Do I need to do all the crazy things that everyone is talking about? What are the real technical requirements and where do they lead the organization? Why do I need all those installations in order to deliver a simple report and to start delivering better performance?

Troubleshooting vs. “Value-Shooting” Troubleshooting is about fixing problems. That is obviously important and it may have been the justification for an enterprise APM deployment. However, it isn’t enough. The goal is to create value for the company – more uptime, increased revenue, happier customers. How should we deal with this challenge? Again, we must distinguish between deployment and implementation. During deployment, APM providers engage in troubleshooting, a straightforward technical process that often uses templates to get things done. During implementation however, APM providers must engage in a process I call “value-shooting.” This involves asking the question, what value can we deliver to you?

The answer is what we call at Correlsense the “Target 4” : alerts, analysis, live dashboards, and reports. Any personnel at your IT can benefit from one of the four. Analysis is the hardest part, it might involve advanced installation and change in organisation processes therefor I recommend to start shooting the Value form the first day of the deployment. From the first collector in test environment we can start measure the ROI (remember – APM is for test as well as for production).  When an APM Project Focuses on Troubleshooting and Deployment – It will Probably Fail

Why is APM such an important issue in the enterprise? Take out your iPhone and use Google to search for the term “Enterprise APM” – how long does it take? Now think for a second what Google had to do to respond to your search? How many servers were involved? Think about the algorithm that prioritized the results, think about the algorithm that targeted the advertising on the side of the results page (remember – it is specific to your browser location), and now think about the performance. It’s insanely good! Do the same while rebooting your Mac and while uploading a picture to Facebook – these companies changed the the concept of performance in the technology industry forever.

Performance is not a luxury anymore. It is expected. More and more people are asking themselves why it takes eight seconds to access a single insurance policy from a LOCAL database and searching the entire web takes a few milliseconds. Everybody in your organization is using Google; expectations are changing. There is no reason your company can’t deliver the same level of performance as the leading Internet companies. There is simply no excuse for it to take more time to login to a banking system than to boot a Mac.
Good luck with your project and feel free to comment.

Elad Katav, COO