We’ve been hearing the terms “APM” and “DevOps” thrown around by a number of vendors and analysts these days. Two recent interviews can clarify what this all means for developers.

First, let me start by saying there is not even agreement as to what APM stands for. It comes down to which side of the street you work. For some, such as AppDynamics, HP and OpNet—and according to analysis firm Gartner—APM means Application Performance Monitoring. That’s usually associated with the IT or operations department, as they use APM software to make sure calls are being received and responded to in the time frame established, that Web pages load in the prescribed time, and the like. Rarely do these issues find their way back to the development arena, as the tools are not designed for that task.

Others, such as the folks at Compuware’s dynaTrace business unit, define APM as Application Performance Management. The company sells software that captures events as they come across the network and can drill down to the line of code to find the problem, an extension of what we used to call “root-cause analysis.”

John Van Siclen, general manager of the APM business unit at Compuware (and formerly CEO of dynaTrace), said he wanted to use the term “performance life cycle” to describe how organizations need to bring development, testing and production together throughout the application process. But he said he was told by Gartner not to use it because it was something HP, IBM and others had promised but could not deliver.

“Application monitoring was being sold to operations as a way to triage to a fault domain,” he said. “A data center is a fault domain. It was really coarse-grained” and did not support the applications people, he continued. “Application specialists—the architects, testers, development managers—were underserved.”

dynaTrace 4, which came out in early October, enhances Compuware’s PurePath technology by extending it to mainframe MQ and CICS, the leading enterprise service buses, C/C++, and Tomcat, Van Siclen said, without the need to instrument the software to read across methods and componentry within an application. “We did a lot of work in intelligence and analytics so humans can manage more complex environments,” he said.

About David Rubinstein

David Rubinstein is editor-in-chief of SD Times.