For most organisations Application Performance Monitoring (APM) is a journey, not a destination. Here are some of the typical steps along that journey. See where you are in your organisation.

AP are working on an APM maturity self-assessment tool which you an use to track where you are on the maturity curve. If you would like to be notified when it is available, click the button below and we will let you know once it is released.

Level 0: we don’t have it, we don’t need it, what is it?

In an ideal world you wouldn’t need Application Performance Management (APM) solutions. Your applications would always perform as you expected, for all users, wherever they were in the world. There wouldn’t be any errors, spikes in traffic, resource constraints or unhappy users.

But you have this nagging doubt that this is not the situation. The first you hear about problems is when users complain. The problems take a long time to fix. This is sometimes known as flying blind. Just as you might in an aeroplane without an airspeed indicator, altimeter, compass or fuel gauge…

On the other hand, some organisations have smart individual syndrome: one or two key personnel who do understand the application and how it behaves. But what happens when they leave?

Perhaps you have gone down the Software as a Service (SaaS) route and think you do not need APM. Certainly you have traded the convenience of having someone else look after the servers for the control that comes from doing it yourself. But it would be embarrassing to complain to your vendor about slow performance in their application only to find that the problem was not with them but was in your part of the network or on your users’ devices. How would you even know?

Another thing to consider is the complexity and dynamism of modern applications. It is hard to keep up. There doesn’t seem to be a single answer to how the application is behaving. As an example of this, you might like to read the blog article on “The Cache Effect”.

Level 1: we need help, we have problems, we are being reactive

Once upon a time most organisations were at level 0 but now probably most are at level 1. Organisations recognise that they need some form of APM. You have created your brand-new application that has (finally) passed all functional tests but now that it is in production there are performance problems. In the wild, people don’t use the application as you expected. They don’t follow a linear path through the screens, which you tested. Batch jobs overrun. Users (or bots) enter bad data. The application doesn’t scale. The list goes on.

At this point, companies go into troubleshooting or fire-fighting mode and retrofit APM. There are many good APM tools out there and in most cases they will do a reasonable job out of the box to monitor your application. Typically, once the immediate crisis is over you go back to your day job and forget about the APM tool until next time it is needed. This is not a bad way to exist but there are better ways.

Level 2: we are getting alerts, we are beginning to think about this, we are being active

At this level, you are trying to use your APM tool to maintain business as usual, as well as tackle the various crises that occur. You receive real-time alerts on availability and deviations from normal behaviour (before your users tell you). You no longer have to stare at the screen in order to glean information; the tool tells you something has changed. You can quickly respond to common problems - standard things such as resource exhaustion. You will still have to use the tool in fire-fighting mode for the unanticipated events. But when they occur you can add an alert to detect it next time.

You may be starting to customise your chosen tool so that you can see the data in a form that is convenient for you, perhaps in custom dashboards and reports. To start with these will mostly be technical metrics but in time you will add business metrics such as the number of widgets you are processing per hour (substitute your own business metric here). You can also keep an eye on the performance of your third-party suppliers that you interface with. You now have enough information to know if you are meeting your Service Level Agreements (SLAs).

You are also using APM earlier in the application lifecycle. You are able to discover errors and bottlenecks in the testing phases before the application makes it into production. You still need monitoring in production because of all the unexpected things that can occur there but at least you have increased confidence that the application will perform as expected.

Level 3: we are mature, APM is part of the furniture, APM is automated

At this level, everybody buys into APM.

Support automatically get trouble tickets opened when there is an alert i.e. APM is integrated with your favourite trouble-ticketing system. The business can see the relationship between performance and how much money they are making, via custom business dashboards. Analysts, designers and marketeers can see the most popular user journeys through the system and common patterns of behaviour, which aids future requirements capture.

At this level, the decision as to which APM tooling to use on the next project is considered as part of the architecture design along with all the functional requirements. The application is designed to perform and you will have the evidence to back it up as the implementation progresses. The trade-offs that you inevitably have to make will include performance considerations. For further reading in this area, you may be interested in another blog article - “Stepping back from the bleeding edge”.

Going beyond merely raising alerts, APM tools are beginning to make recommendations, increasingly through the use of Machine Learning and Artificial Intelligence (AI). Automation, possibly in concert with orchestration tools, allows them to spin up extra virtual machines in response to increased load, for example. Taken to its logical conclusion, APM will become part of the application, self-diagnosing and self-healing. At this point we humans may feel like we are back at level 0!

Final thoughts

Some of the boundaries between the different levels can become blurred. Don’t take them as exact definitions but use them as a guide and decide for yourselves if you want to go to the next level. If you would like to have a guide on your journey then Application Performance would be happy to help. It’s what we do.