APM for Vendor Provided Business Critical Enterprise Applications

Sri Chaganty

Traditionally, Application Performance Management (APM) is usually associated with solutions that instrument application code. There are two fundamental limitations with such associations. If instrumenting the code is what APM is all about, then APM is applicable only to homegrown applications for which access to code is available.

However, the majority of business critical applications are not homegrown. As the chart below shows, the $320B enterprise software market is driven by vendors who provide solutions for which there is no access to the source code. The enterprise software market in the chart covers a full assortment of commercially off-the-shelf products ranging from corporate databases to Enterprise Resource Planning (ERP) solutions and from Cloud-enabled productivity tools to mission-critical vertical applications. However, there are technical challenges with code instrumentation that are overlooked with this traditional association.


Source: Apps Run the World, 2016

Vendor Provided Software

Traditional APM vendors focus on application software that is developed in house, mainly based on Web Services. These solutions employ Byte Code Instrumentation (BCI), a technique for adding bytecode during "run time." These solutions are developer focused. If developers want to debug or profile the code during run time, BCI is an effective solution.

In reality, enterprises depend on both in-house developed software as well as vendor provided software. Applications that businesses use can be dived into two categories: 1) Business Critical Applications and 2) Productivity Applications. While business critical applications are the foundation on which the business success is dependent upon, productivity applications like email are also equally important for enterprises.

Generally, about 80% of the applications that enterprises use in either category are packaged applications supplied by vendors like Microsoft, SAP, Oracle, PeopleSoft and others. Only 20% of the applications are developed in-house. In the majority of cases, the in-house developed applications generally wrap around vendor provided software.



A common example is an application developed based on web services customized for a business that are supported on SAP in the background. Instrumenting vendor provided software is not possible as the source code is not provided by the vendor, therefore, code instrumentation techniques are not feasible for vendor provided software.

Instrumenting in-house developed application software at different points gives a rich view to optimize the application throughout development. However, there are several types of problems that such instrumentation just can't see. It does not, and cannot, always deliver the complete visibility that users think they're getting. In addition, code instrumentation is not "free", even with the expensive tools commercially available, it takes considerable coding skills (not widely available) to achieve effective code instrumentation without degrading the performance of the production code execution.

Technical Challenges

Code instrumentation can report on the performance of your application software stack, but the service offered to customers depends on far more than just the software – it depends on all of the networks, load balancers, servers, databases, external services like Active Directory, DNS etc., service providers and third parties you use to provide the service. 

Traditional APM products do only BCI. They claim to be transaction management solutions, though there are limitations to what they can do in Java environments, and they have zero visibility of non-Java topologies.

A real transaction management product needs to follow the transaction between different types of application-related components such as proxies, Web servers, app servers (Java and non-Java), message brokers, queues, databases and so forth. In order to do that, visibility into different types of transaction-related data is required, some of which only exists at the actual payload of each request. Java is an interpreter and therefore hides parts of the actual code implementation from the Java layer. The Java Virtual Machine (JVM) itself is written in C, therefore there are operating system-specific pieces that are not accessible from Java and thus not accessible through BCI techniques.

If you want to use features of TCP/IP packets for tracing a transaction between two servers, the actual structure of packets is not accessible from the Java layer. There is information that is crucial to trace transactions across more than just Java hops. Such information is available only at a lower layer than the Java code, thus not accessible by BCI, which limits the ability to trace transactions in the real world.

Conclusion

For vendor provided software, BCI is an ineffective technique. For in-house built software, BCI allows programmers to enhance the code they are developing. It is a necessary tool for development teams but insufficient as it does not offer the visibility that IT Operations require in order to understand the application service delivery chain performance. If your business depends on mission-critical web or legacy applications, then monitoring how your end users interact with your applications is more important than how well the code is written. The responsiveness of the application determines the end user's experience. The true measurement of end-user experience is availability and response time of the application, end-to-end and hop-by-hop – covering the entire application service delivery chain.

Sri Chaganty is COO and CTO/Founder at AppEnsure.

Hot Topics

Related Vendors

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...

APM for Vendor Provided Business Critical Enterprise Applications

Sri Chaganty

Traditionally, Application Performance Management (APM) is usually associated with solutions that instrument application code. There are two fundamental limitations with such associations. If instrumenting the code is what APM is all about, then APM is applicable only to homegrown applications for which access to code is available.

However, the majority of business critical applications are not homegrown. As the chart below shows, the $320B enterprise software market is driven by vendors who provide solutions for which there is no access to the source code. The enterprise software market in the chart covers a full assortment of commercially off-the-shelf products ranging from corporate databases to Enterprise Resource Planning (ERP) solutions and from Cloud-enabled productivity tools to mission-critical vertical applications. However, there are technical challenges with code instrumentation that are overlooked with this traditional association.


Source: Apps Run the World, 2016

Vendor Provided Software

Traditional APM vendors focus on application software that is developed in house, mainly based on Web Services. These solutions employ Byte Code Instrumentation (BCI), a technique for adding bytecode during "run time." These solutions are developer focused. If developers want to debug or profile the code during run time, BCI is an effective solution.

In reality, enterprises depend on both in-house developed software as well as vendor provided software. Applications that businesses use can be dived into two categories: 1) Business Critical Applications and 2) Productivity Applications. While business critical applications are the foundation on which the business success is dependent upon, productivity applications like email are also equally important for enterprises.

Generally, about 80% of the applications that enterprises use in either category are packaged applications supplied by vendors like Microsoft, SAP, Oracle, PeopleSoft and others. Only 20% of the applications are developed in-house. In the majority of cases, the in-house developed applications generally wrap around vendor provided software.



A common example is an application developed based on web services customized for a business that are supported on SAP in the background. Instrumenting vendor provided software is not possible as the source code is not provided by the vendor, therefore, code instrumentation techniques are not feasible for vendor provided software.

Instrumenting in-house developed application software at different points gives a rich view to optimize the application throughout development. However, there are several types of problems that such instrumentation just can't see. It does not, and cannot, always deliver the complete visibility that users think they're getting. In addition, code instrumentation is not "free", even with the expensive tools commercially available, it takes considerable coding skills (not widely available) to achieve effective code instrumentation without degrading the performance of the production code execution.

Technical Challenges

Code instrumentation can report on the performance of your application software stack, but the service offered to customers depends on far more than just the software – it depends on all of the networks, load balancers, servers, databases, external services like Active Directory, DNS etc., service providers and third parties you use to provide the service. 

Traditional APM products do only BCI. They claim to be transaction management solutions, though there are limitations to what they can do in Java environments, and they have zero visibility of non-Java topologies.

A real transaction management product needs to follow the transaction between different types of application-related components such as proxies, Web servers, app servers (Java and non-Java), message brokers, queues, databases and so forth. In order to do that, visibility into different types of transaction-related data is required, some of which only exists at the actual payload of each request. Java is an interpreter and therefore hides parts of the actual code implementation from the Java layer. The Java Virtual Machine (JVM) itself is written in C, therefore there are operating system-specific pieces that are not accessible from Java and thus not accessible through BCI techniques.

If you want to use features of TCP/IP packets for tracing a transaction between two servers, the actual structure of packets is not accessible from the Java layer. There is information that is crucial to trace transactions across more than just Java hops. Such information is available only at a lower layer than the Java code, thus not accessible by BCI, which limits the ability to trace transactions in the real world.

Conclusion

For vendor provided software, BCI is an ineffective technique. For in-house built software, BCI allows programmers to enhance the code they are developing. It is a necessary tool for development teams but insufficient as it does not offer the visibility that IT Operations require in order to understand the application service delivery chain performance. If your business depends on mission-critical web or legacy applications, then monitoring how your end users interact with your applications is more important than how well the code is written. The responsiveness of the application determines the end user's experience. The true measurement of end-user experience is availability and response time of the application, end-to-end and hop-by-hop – covering the entire application service delivery chain.

Sri Chaganty is COO and CTO/Founder at AppEnsure.

Hot Topics

Related Vendors

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...