Aside from kicking off our first of many CIO blogs, I also have a lot more tactical content I’d like to share with the APM community. After speaking to thousands of APM users over my time with Gartner, and several in the last few weeks at AppDynamics there are some key issues that cause APM failures:
1. Organizational immaturity
The first cause of failure is the silos in many of today’s organizations. There are often too many stakeholders involved in APM decision-making ranging from application support, server teams, network teams, database teams (DBAs), application developers, and various architects across the organization. We’re also seeing more non-technical users, such as the business owner of an application interested in seeing usage and performance data on critical Business Transactions within the application. These business users will become a more central user of APM in the future. It’s critical to identify the primary user of the product, and determine requirements focused on those primary users. Secondary users can have input but should not be the ones driving the key decision points. As products mature, they can sell into multiple areas or even cross sell through teams, but it shouldn’t be the focus of the initial implementation.
2. Ownership
Typically the excitement of an APM solution, the added visibility, and capabilities presented with an implementation provide immense value to operations, application support, and development. The implementation if you select an easy to implement the product normally proceeds without many issues, and there is a clear owner or stakeholders of the product. Over time as roles and business direction changes often APM loses its key owner. The result of this is that the product isn’t maintained or used day to day. The way to avoid this is to make the executives key stakeholders. As APM and Application Intelligence will become critical to business decision-making, changing what’s often been to fate of older APM products.
3. Application Complexity
APM tools are installed for two reasons, if APM is strategic it’s implemented during development or implementation of a project. The second driver for APM implementation is when the pain threshold gets too high, and something is needed to see the production environment to remediate issues. The lack of understanding or visibility in applications, both old and new is normally the first benefit. You’ll often hear “I didn’t know this was connecting to that?”.
Issues occur within changing applications for two primary reasons, firstly demands of business model changes driven by greater customer demand or higher volumes of data. The second for change is feature requests, requiring application changes. These two reasons for change can be distilled down to scale and complexity making it harder to identify and correct issues (or passing this data to development to make corrective changes to the software).
4. Engineering Skills Required
With yesterday’s APM tools the implementations were incredibly complex and time consuming. This was due to the amount of tuning and customization enterprises required. Companies which have failed in APM were normally due to having too heavy a services engagement. This has caused the likes of Optier to completely go out of business, Correlsense to rethink its strategy, and ITOM giants such as IBM, HP, and CA to rethink how they approach the market. Many of these companies, including Dynatrace even have staff members who would work full time at customer sites to keep the products up and running. These are often seen as benefits to the buyer, but eventually they become burdens.
Applications both in the enterprise and customer worlds have become easy to buy, implement, and show the value of the technology. This has permeated IT products as well, buyers expect things to be easy and show value quickly. The APM winners today, and for the future (AppDynamics, New Relic, and Ruxit) build easy to implement products, and refuse to customize them or push a heavy services engagement.
There is still consulting (or what we call enablement services) to get customers fully up and running, trained, and getting full value from the product. This is one of the key reasons our net promoter score is as high as it is, we also keep these engagements short lived. The key is enabling customers, and not offloading the work of using the product or providing staff augmentation. If you are looking at managed services, select the right technology first, and then the managed services provider.
Many legacy APM tools are far too complex, with countless config files and GUI features to tune in order to get value out of the investment, you shouldn’t need to be a senior technologist to get results. Today’s modern tools are easy to understand, and often present information in a way that level-1 operations engineers get value from them.
5. Focus on the wrong thing
Selecting APM technology isn’t just about meeting the needs of your application today, but thinking about the future state of the applications and infrastructures. What is considered experimental and bleeding edge eventually become standard components of traditional enterprise applications. We’ve already seen this happen with PHP, and we’re beginning to see this with other languages. Today you may be a Java shop on VMware, and possibly even a PHP user on LAMP, but in the future you will likely be a node.js shop, possibly running on a public PaaS like IBM BlueMix.
Most organizational leaders have a strategy for both private and public cloud, where areas of business innovation and differentiation tend to be built on public clouds. This is the reason Gartner states that “IT spending on public cloud services is growing more than five times faster than growth in IT spending across all categories”. Similarly, your organization may not have a large mobile investment today, but I can assure you will in the future. In order to handle these shifts many applications are moving from a single programming language to being composed of multiple languages. These technology shifts are requiring people with new broader skills, or people who can learn new skills quickly. The path towards the full stack developer, or IT operations generalist show many are evolving to meet these new challenges to meet business agility requirements.
Summary
Regardless of if these proof points or discussions match your organization, the ability to support past investments, existing investments, but most importantly future investments is critical when selecting APM technologies. Areas of growth and innovation are critical to senior management, hence will provide the most value to the business. These challenges are being addressed by the APM innovators, keep that in mind when selecting application management technology keeping in mind the depth and context of the application performance monitoring and analytics.
