APM for Vendor Provided Business Critical Enterprise Applications

Sri Chaganty
Learn more about AppEnsure

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

Crisis Communications: When the Outage Hits, Your Communications Can't Be "Investigating"

Outages aren't new. What's new is how quickly they spread across systems, vendors, regions and customer workflows. The moment that performance degrades, expectations escalate fast. In today's always-on environment, an outage isn't just a technical event. It's a trust event ...

OpenTelemetry: A Complete Telemetry Framework that Grows with You

Most organizations approach OpenTelemetry as a collection of individual tools they need to assemble from scratch. This view misses the bigger picture. OpenTelemetry is a complete telemetry framework with composable components that address specific problems at different stages of organizational maturity. You start with what you need today and adopt additional pieces as your observability practices evolve ...

The Quiet Power of Milliseconds in High Traffic Systems

One of the earliest lessons I learned from architecting throughput-heavy services is that simplicity wins repeatedly: fewer moving parts, loosely coupled execution (fewer synchronous calls), and precise timing metering. You want data and decisions to travel the shortest possible path. The goal is to build a system where every strategy and each line of code (contention is the key metric) complements the decision trees ...

Are AI "Autonomous Coworkers" Ready for Payroll?

As discussions around AI "autonomous coworkers" accelerate, many industry projections assume that agents will soon operate alongside human staff in making decisions, taking actions, and managing tasks with minimal oversight. But a growing number of critics (including some of the developers building these systems) argue that the industry still has a long way to go to be able to treat AI agents like fully trusted teammates ...

Enterprise AI Reaches Pivotal Inflection Point: From Automation to Agentic Intelligence

Enterprise AI has entered a transformational phase where, according to Digitate's recently released survey, Agentic AI and the Future of Enterprise IT, companies are moving beyond traditional automation toward Agentic AI systems designed to reason, adapt, and collaborate alongside human teams ...

The Real Reason Enterprise AI Stalls: It Doesn't Fit in the Box

The numbers back this urgency up. A recent Zapier survey shows that 92% of enterprises now treat AI as a top priority. Leaders want it, and teams are clamoring for it. But if you look closer at the operations of these companies, you see a different picture. The rollout is slow. The results are often delayed. There's a disconnect between what leaders want and what their technical infrastructure can handle ...

AI's Inflection Point Will Redefine Enterprise Readiness in 2026

Kyndryl's 2025 Readiness Report revealed that 61% of global business and technology leaders report increasing pressure from boards and regulators to prove AI's ROI. As the technology evolves and expectations continue to rise, leaders are compelled to generate and prove impact before scaling further. This will lead to a decisive turning point in 2026 ...

Turning Foresight into Resilience: Reclaiming Prevention in the Age of Exposure

Cloudflare's disruption illustrates how quickly a single provider's issue cascades into widespread exposure. Many organizations don't fully realize how tightly their systems are coupled to thirdparty services, or how quickly availability and security concerns align when those services falter ... You can't avoid these dependencies, but you can understand them ...

MLOps Meets DataOps: Creating Unified Backbone for AI

If you work with AI, you know this story. A model performs during testing, looks great in early reviews, works perfectly in production and then slowly loses relevance after operating for a while. Everything on the surface looks perfect — pipelines are running, predictions or recommendations are error-free, data quality checks show green; yet outcomes don't meet the ground reality. This pattern often repeats across enterprise AI programs. Take for example, a mid-sized retail banking and wealth-management firm with heavy investments in AI-powered risk analytics, fraud detection and personalized credit-decisioning systems. The model worked well for a while, but transactions increased, so did false positives by 18% ...

2026 Network Monitoring Trends

Basic uptime is no longer the gold standard. By 2026, network monitoring must do more than report status, it must explain performance in a hybrid-first world. Networks are no longer just static support systems; they are agile, distributed architectures that sit at the very heart of the customer experience and the business outcomes ... The following five trends represent the new standard for network health, providing a blueprint for teams to move from reactive troubleshooting to a proactive, integrated future ...

APM for Vendor Provided Business Critical Enterprise Applications

Sri Chaganty
Learn more about AppEnsure

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

Crisis Communications: When the Outage Hits, Your Communications Can't Be "Investigating"

Outages aren't new. What's new is how quickly they spread across systems, vendors, regions and customer workflows. The moment that performance degrades, expectations escalate fast. In today's always-on environment, an outage isn't just a technical event. It's a trust event ...

OpenTelemetry: A Complete Telemetry Framework that Grows with You

Most organizations approach OpenTelemetry as a collection of individual tools they need to assemble from scratch. This view misses the bigger picture. OpenTelemetry is a complete telemetry framework with composable components that address specific problems at different stages of organizational maturity. You start with what you need today and adopt additional pieces as your observability practices evolve ...

The Quiet Power of Milliseconds in High Traffic Systems

One of the earliest lessons I learned from architecting throughput-heavy services is that simplicity wins repeatedly: fewer moving parts, loosely coupled execution (fewer synchronous calls), and precise timing metering. You want data and decisions to travel the shortest possible path. The goal is to build a system where every strategy and each line of code (contention is the key metric) complements the decision trees ...

Are AI "Autonomous Coworkers" Ready for Payroll?

As discussions around AI "autonomous coworkers" accelerate, many industry projections assume that agents will soon operate alongside human staff in making decisions, taking actions, and managing tasks with minimal oversight. But a growing number of critics (including some of the developers building these systems) argue that the industry still has a long way to go to be able to treat AI agents like fully trusted teammates ...

Enterprise AI Reaches Pivotal Inflection Point: From Automation to Agentic Intelligence

Enterprise AI has entered a transformational phase where, according to Digitate's recently released survey, Agentic AI and the Future of Enterprise IT, companies are moving beyond traditional automation toward Agentic AI systems designed to reason, adapt, and collaborate alongside human teams ...

The Real Reason Enterprise AI Stalls: It Doesn't Fit in the Box

The numbers back this urgency up. A recent Zapier survey shows that 92% of enterprises now treat AI as a top priority. Leaders want it, and teams are clamoring for it. But if you look closer at the operations of these companies, you see a different picture. The rollout is slow. The results are often delayed. There's a disconnect between what leaders want and what their technical infrastructure can handle ...

AI's Inflection Point Will Redefine Enterprise Readiness in 2026

Kyndryl's 2025 Readiness Report revealed that 61% of global business and technology leaders report increasing pressure from boards and regulators to prove AI's ROI. As the technology evolves and expectations continue to rise, leaders are compelled to generate and prove impact before scaling further. This will lead to a decisive turning point in 2026 ...

Turning Foresight into Resilience: Reclaiming Prevention in the Age of Exposure

Cloudflare's disruption illustrates how quickly a single provider's issue cascades into widespread exposure. Many organizations don't fully realize how tightly their systems are coupled to thirdparty services, or how quickly availability and security concerns align when those services falter ... You can't avoid these dependencies, but you can understand them ...

MLOps Meets DataOps: Creating Unified Backbone for AI

If you work with AI, you know this story. A model performs during testing, looks great in early reviews, works perfectly in production and then slowly loses relevance after operating for a while. Everything on the surface looks perfect — pipelines are running, predictions or recommendations are error-free, data quality checks show green; yet outcomes don't meet the ground reality. This pattern often repeats across enterprise AI programs. Take for example, a mid-sized retail banking and wealth-management firm with heavy investments in AI-powered risk analytics, fraud detection and personalized credit-decisioning systems. The model worked well for a while, but transactions increased, so did false positives by 18% ...

2026 Network Monitoring Trends

Basic uptime is no longer the gold standard. By 2026, network monitoring must do more than report status, it must explain performance in a hybrid-first world. Networks are no longer just static support systems; they are agile, distributed architectures that sit at the very heart of the customer experience and the business outcomes ... The following five trends represent the new standard for network health, providing a blueprint for teams to move from reactive troubleshooting to a proactive, integrated future ...