Skip to main content

APM is More Than a Software Product

Oliver Cole

I have been in the performance engineering business for about 30 years. I get involved early on during system development and move off as the systems move to maintenance. Then, I move onto the next one.

I sometimes get called in to troubleshoot a performance crisis. I have sometimes been compared to a locust moving onto the next greenfield and, at other times, compared to Kwai Chang Caine (of Kung Fu fame), wandering the earth sowing justice, peace and performance.

Whichever you choose, I have noticed some similarities between the various projects that I have worked on.

1. Speed to Meet the Need

There are two aspects to performance engineering:

- To speed up the system to meet the required response times

- To talk the customer into lowering their response time requirements

It continually amazes me how high level system people will start off with unnecessarily fast response requirements. One customer wanted sub-second browser response time, even though the user would stare at the resulting web page for many minutes. Really, it was ok if it took a couple of seconds to fetch the web page.

So don't feel afraid to talk your customers into a lower performance criteria.

2. Keep Track of Your History

Performance requirements are always patchy. Yes, they get the big ones (user response time), but it is totally typical for the subcomponents to not have requirements on them, making it unclear where and how to make the end user response times. Complicating this, generally, all of the discussions leading to the system designs are lost. There was a big debate as to how large the system should be for how many users. Someone chose that 256 CPU server monster, but what was their thinking? Half way through the project, when the response requirements have been relaxed and the number of users has been increased, it sure would be nice to look though those emails and see what people were thinking so you can estimate what system changes need to be made to accommodate the business changes.

So during the early phases, have an archive account to which people can cc "important" emails. Later, these can be reviewed and all that wonderful history and knowledge will make the system change and maintenance a lot easier.

3. Dev vs. Ops

The development people do not really address the maintenance phase of the project. The development people are in a heated rush to meet performance goals and deadlines while not over running costs. The project managers are very focused on the deadline of "going live".

Then the system goes live, everyone throws a party and then they realize that they have not planned well for this lesser period of effort: maintenance. What artifacts did the developers leave the maintainers? Did they leave a workable load test? Did they leave a well organized set of production diagnostics implemented as part of the application? Did they leave proper alert monitoring? Did they leave proper daily reporting?

Ideally, the last stage of development is to set up the system for long term, cost effective maintenance, not the first stage of maintenance. This task is properly done when the development team is still available, not after the brightest are gone to their next adventure. As much as possible the maintenance tasks (such as daily reports, regression tests and load tests) should be automated and that may require changes to the system, changes that the development team can do easily, but will be much more difficult for the whittled down maintenance team.

4. An APM Solution Itself is not the Solution

Management often feels that buying a tool will solve a problem. "We have performance problems so we will buy an APM solution." This belief often results in shelfware: management has underestimated the effort to implement the solution.

Yes, an APM solution is good. But you need to have enough labor to implement it and look at and understand the results. Plan on it up front. Don't focus on the capital cost to your organization, focus on how it will integrate into your organization and what will be done on an ongoing basis.

5. How Important is Performance?

How important is your project? Everyone feels that their project is important, but some are more so than others. Some systems really are not that performance intensive. So, you can save money by not worrying so much about performance; a high performing system is more expensive to monitor and maintain than one that requires less performance.

Make the decision early on as to how important performance is. If it is important, make sure that it is considered important by everyone. If it is not so important, embrace that too and make clear goals for performance. Even if performance is not important, clearly indicate the goals. Even easy to reach goals should be articulated.

I have seen systems where the performance goal is to wait for users to complain, then address it. Sometimes that works fine.

Oliver Cole is President of OC Systems.

Hot Topics

The Latest

Cyber threats are growing more sophisticated every day, and at their forefront are zero-day vulnerabilities. These elusive security gaps are exploited before a fix becomes available, making them among the most dangerous threats in today's digital landscape ... This guide will explore what these vulnerabilities are, how they work, why they pose such a significant threat, and how modern organizations can stay protected ...

The prevention of data center outages continues to be a strategic priority for data center owners and operators. Infrastructure equipment has improved, but the complexity of modern architectures and evolving external threats presents new risks that operators must actively manage, according to the Data Center Outage Analysis 2025 from Uptime Institute ...

As observability engineers, we navigate a sea of telemetry daily. We instrument our applications, configure collectors, and build dashboards, all in pursuit of understanding our complex distributed systems. Yet, amidst this flood of data, a critical question often remains unspoken, or at best, answered by gut feeling: "Is our telemetry actually good?" ... We're inviting you to participate in shaping a foundational element for better observability: the Instrumentation Score ...

We're inching ever closer toward a long-held goal: technology infrastructure that is so automated that it can protect itself. But as IT leaders aggressively employ automation across our enterprises, we need to continuously reassess what AI is ready to manage autonomously and what can not yet be trusted to algorithms ...

Much like a traditional factory turns raw materials into finished products, the AI factory turns vast datasets into actionable business outcomes through advanced models, inferences, and automation. From the earliest data inputs to the final token output, this process must be reliable, repeatable, and scalable. That requires industrializing the way AI is developed, deployed, and managed ...

Almost half (48%) of employees admit they resent their jobs but stay anyway, according to research from Ivanti ... This has obvious consequences across the business, but we're overlooking the massive impact of resenteeism and presenteeism on IT. For IT professionals tasked with managing the backbone of modern business operations, these numbers spell big trouble ...

For many B2B and B2C enterprise brands, technology isn't a core strength. Relying on overly complex architectures (like those that follow a pure MACH doctrine) has been flagged by industry leaders as a source of operational slowdown, creating bottlenecks that limit agility in volatile market conditions ...

FinOps champions crucial cross-departmental collaboration, uniting business, finance, technology and engineering leaders to demystify cloud expenses. Yet, too often, critical cost issues are softened into mere "recommendations" or "insights" — easy to ignore. But what if we adopted security's battle-tested strategy and reframed these as the urgent risks they truly are, demanding immediate action? ...

Two in three IT professionals now cite growing complexity as their top challenge — an urgent signal that the modernization curve may be getting too steep, according to the Rising to the Challenge survey from Checkmk ...

While IT leaders are becoming more comfortable and adept at balancing workloads across on-premises, colocation data centers and the public cloud, there's a key component missing: connectivity, according to the 2025 State of the Data Center Report from CoreSite ...

APM is More Than a Software Product

Oliver Cole

I have been in the performance engineering business for about 30 years. I get involved early on during system development and move off as the systems move to maintenance. Then, I move onto the next one.

I sometimes get called in to troubleshoot a performance crisis. I have sometimes been compared to a locust moving onto the next greenfield and, at other times, compared to Kwai Chang Caine (of Kung Fu fame), wandering the earth sowing justice, peace and performance.

Whichever you choose, I have noticed some similarities between the various projects that I have worked on.

1. Speed to Meet the Need

There are two aspects to performance engineering:

- To speed up the system to meet the required response times

- To talk the customer into lowering their response time requirements

It continually amazes me how high level system people will start off with unnecessarily fast response requirements. One customer wanted sub-second browser response time, even though the user would stare at the resulting web page for many minutes. Really, it was ok if it took a couple of seconds to fetch the web page.

So don't feel afraid to talk your customers into a lower performance criteria.

2. Keep Track of Your History

Performance requirements are always patchy. Yes, they get the big ones (user response time), but it is totally typical for the subcomponents to not have requirements on them, making it unclear where and how to make the end user response times. Complicating this, generally, all of the discussions leading to the system designs are lost. There was a big debate as to how large the system should be for how many users. Someone chose that 256 CPU server monster, but what was their thinking? Half way through the project, when the response requirements have been relaxed and the number of users has been increased, it sure would be nice to look though those emails and see what people were thinking so you can estimate what system changes need to be made to accommodate the business changes.

So during the early phases, have an archive account to which people can cc "important" emails. Later, these can be reviewed and all that wonderful history and knowledge will make the system change and maintenance a lot easier.

3. Dev vs. Ops

The development people do not really address the maintenance phase of the project. The development people are in a heated rush to meet performance goals and deadlines while not over running costs. The project managers are very focused on the deadline of "going live".

Then the system goes live, everyone throws a party and then they realize that they have not planned well for this lesser period of effort: maintenance. What artifacts did the developers leave the maintainers? Did they leave a workable load test? Did they leave a well organized set of production diagnostics implemented as part of the application? Did they leave proper alert monitoring? Did they leave proper daily reporting?

Ideally, the last stage of development is to set up the system for long term, cost effective maintenance, not the first stage of maintenance. This task is properly done when the development team is still available, not after the brightest are gone to their next adventure. As much as possible the maintenance tasks (such as daily reports, regression tests and load tests) should be automated and that may require changes to the system, changes that the development team can do easily, but will be much more difficult for the whittled down maintenance team.

4. An APM Solution Itself is not the Solution

Management often feels that buying a tool will solve a problem. "We have performance problems so we will buy an APM solution." This belief often results in shelfware: management has underestimated the effort to implement the solution.

Yes, an APM solution is good. But you need to have enough labor to implement it and look at and understand the results. Plan on it up front. Don't focus on the capital cost to your organization, focus on how it will integrate into your organization and what will be done on an ongoing basis.

5. How Important is Performance?

How important is your project? Everyone feels that their project is important, but some are more so than others. Some systems really are not that performance intensive. So, you can save money by not worrying so much about performance; a high performing system is more expensive to monitor and maintain than one that requires less performance.

Make the decision early on as to how important performance is. If it is important, make sure that it is considered important by everyone. If it is not so important, embrace that too and make clear goals for performance. Even if performance is not important, clearly indicate the goals. Even easy to reach goals should be articulated.

I have seen systems where the performance goal is to wait for users to complain, then address it. Sometimes that works fine.

Oliver Cole is President of OC Systems.

Hot Topics

The Latest

Cyber threats are growing more sophisticated every day, and at their forefront are zero-day vulnerabilities. These elusive security gaps are exploited before a fix becomes available, making them among the most dangerous threats in today's digital landscape ... This guide will explore what these vulnerabilities are, how they work, why they pose such a significant threat, and how modern organizations can stay protected ...

The prevention of data center outages continues to be a strategic priority for data center owners and operators. Infrastructure equipment has improved, but the complexity of modern architectures and evolving external threats presents new risks that operators must actively manage, according to the Data Center Outage Analysis 2025 from Uptime Institute ...

As observability engineers, we navigate a sea of telemetry daily. We instrument our applications, configure collectors, and build dashboards, all in pursuit of understanding our complex distributed systems. Yet, amidst this flood of data, a critical question often remains unspoken, or at best, answered by gut feeling: "Is our telemetry actually good?" ... We're inviting you to participate in shaping a foundational element for better observability: the Instrumentation Score ...

We're inching ever closer toward a long-held goal: technology infrastructure that is so automated that it can protect itself. But as IT leaders aggressively employ automation across our enterprises, we need to continuously reassess what AI is ready to manage autonomously and what can not yet be trusted to algorithms ...

Much like a traditional factory turns raw materials into finished products, the AI factory turns vast datasets into actionable business outcomes through advanced models, inferences, and automation. From the earliest data inputs to the final token output, this process must be reliable, repeatable, and scalable. That requires industrializing the way AI is developed, deployed, and managed ...

Almost half (48%) of employees admit they resent their jobs but stay anyway, according to research from Ivanti ... This has obvious consequences across the business, but we're overlooking the massive impact of resenteeism and presenteeism on IT. For IT professionals tasked with managing the backbone of modern business operations, these numbers spell big trouble ...

For many B2B and B2C enterprise brands, technology isn't a core strength. Relying on overly complex architectures (like those that follow a pure MACH doctrine) has been flagged by industry leaders as a source of operational slowdown, creating bottlenecks that limit agility in volatile market conditions ...

FinOps champions crucial cross-departmental collaboration, uniting business, finance, technology and engineering leaders to demystify cloud expenses. Yet, too often, critical cost issues are softened into mere "recommendations" or "insights" — easy to ignore. But what if we adopted security's battle-tested strategy and reframed these as the urgent risks they truly are, demanding immediate action? ...

Two in three IT professionals now cite growing complexity as their top challenge — an urgent signal that the modernization curve may be getting too steep, according to the Rising to the Challenge survey from Checkmk ...

While IT leaders are becoming more comfortable and adept at balancing workloads across on-premises, colocation data centers and the public cloud, there's a key component missing: connectivity, according to the 2025 State of the Data Center Report from CoreSite ...