What's in a Name?

With my focus on Application Performance Management (APM), I have a keen interest in getting to the "devil in the details." I always like to get the vendor to explain to me just what an application is and what they do to manage its performance.

When you look at and actually analyze what an application is, for many vendors of APM solutions, there are similar stories but not much consistency. Depending upon whom you talk to and the specific nature of their solutions, it could break down into different structures, ranging from Web to client/server and thin client to different product types such as Oracle Corp. (Nasdaq: ORCL) and IBM Corp.s (NYSE: IBM) WebSphere. Then there are the many different application types to be considered, ranging from Enterprise Resource Planning to Customer Relationship Management. Finally, the application could cover any number of protocols, ranging from HTTP to FTP, and ports, such as 80, 443, 1,214.

However, within an organization, an application is rarely, if ever, broken down into a single specific category. Therefore, a whole lot of work has to go into building associations between the business context of an application and its technical foundations. When you ask the vendors about this, they all say, “Well it’s real easy to fill it in,” or ”We have a wizard for that”… And so forth and so on.

This gets especially interesting for an organization that is attempting to orchestrate various performance management products – either from an information or control perspective. The information obtained from one system and the information from another might be describing the same thing, but you’d never know it when you look at the screen or report.

As I discussed in my last column, Knobs & Gauges, the introduction of a technique called Application Infrastructure Management is helping IT organizations understand the links among their disparate technology resources. With that in place, there is a clear need to develop a more business-oriented view of how those resources relate to each other, as well as to understand them at the transaction level.Over the past few weeks I’ve run into some very interesting approaches and technologies that I think will help achieve this. This is all about moving from understanding bits on a wire to developing information that builds a clear association between those bits and the business applications they represent.

With common links between the owner of the application and the IT groups that support it, we can begin to structure methods for obtaining application-specific information and then sharing it, so as you move from one solution to another, there will be a common context. Business names for applications, vendor platforms, protocols, ports, etc., would then have continuity among the various systems that can leverage it.

Now the scary part: This development and dissemination of information will require us as an industry to support a "policy" system. With the bad taste left in everyone’s mouth about policy by the COPS (Common Open Policy Service) and DEN (Directory Enabled Networking) initiatives, it’s understandable why no one wants to say the word. But the bottom line is that today, most, if not all, vendors of application performance management solutions are implementing a policy engine built "in their own image."

So vendors are going to have to muster up the courage to say, “OK – we screwed up, but it’s time to swallow our pride and do the right thing.” We can do it in small support groups to get started, but we need to get started. Having a common structure for defining an application will resolve small problems we have now that will only get bigger. Most importantly, it will build the foundation for delivering APM value throughout an entire organization.

— R. Lynn Nye Jr is president of analyst firm APM Advisors0