Since the concept of applications management was first articulated in late 1995, there has been considerable divergence in attempts to define it. The natural tendency of vendors has been to define applications management as a set of requirements best met by the strengths of the vendors' own products. But, although the concept has seemed like a battlefield of competing definitions, applications management really is a hybrid of all the criteria that the vendors are promoting. The problem is that each vendor only offers a partial solution.
Applications management includes the broad set of management actions required to keep an application available and functioning: event monitoring, performance tuning, storage management, security management, software distribution, configuration management, and operations management. Furthermore, each of these management disciplines must be applied to all the underlying components upon which an application depends, including databases, operating systems, and networks. This in turn means that it is paramount for an application manager to understand and be able to visualize all application dependencies.
The interrelationship between an application and its underlying components is called the application dependency stack. This concept was introduced in early 1996 in a Hurwitz Group report titled "Application Management Defined: The Application Dependency Stack," and further described in Judith Hurwitz's column in the December 1996 issue of DBMS. See Figure 1 for an illustration.
To give you an example of the importance of the application dependency stack, most brokerage houses on Wall Street estimate that application downtime costs approximately $200,000 per minute in lost stock transactions. Spending even five minutes hunting through networks, operating systems, and databases attempting to identify where a performance bottleneck exists can accumulate excessive downtime costs. Therefore, it is imperative to be able to identify quickly all the distributed components upon which the applications depend and isolate where faults or bottlenecks have occurred.
Users have refined the original definition of applications management to include an application services layer that represents the growing use of middleware in support of distributed application transactions. Additionally, a hardware layer, separate from the operating system layer, has also been introduced to represent the latest developments in intelligent hardware components, which can be monitored without requiring the operating system to be available.
However, despite the growing need for management tools for applications and their underlying components, no one solution has emerged. Vendors are still pushing their particular products, and users must fend for themselves.
In the absence of a comprehensive offering for applications management, IT organizations must piece together best-of-breed products that deliver some level of applications management in one or more of the seven management areas.
The first area of applications management that must be addressed is storage management. If the data is not backed up, end users will not use the application. Throughout 1996 (although not labeled as applications management) a broad number of storage-management vendors introduced backup and recovery products that feature the ability to back up SAP AG, PeopleSoft Inc., and Oracle Corp.'s Financials applications while users are accessing their data. Customers should continue to pick and choose among the best-of-breed point products to address the storage management requirements for their applications because none of the management frameworks provides strong storage management capabilities.
Another key requirement is application security management. Among the more than 600 companies that offer security products, several have announced products that are targeted directly at securing mission-critical business applications. Application security --in particular, auditing -- is quickly becoming a trend in the security market. Customers are just now becoming aware of application security holes that exist above the system and database layers. For example, application clients send account names and passwords in clear text across the network to the application server, which presents the possibility of the passwords being disclosed and subsequently misused. SAP recognized this potential threat early in 1996 and has announced plans to insert an industry-standard security API to provide integration with leading authentication and encryption products that eliminate this security concern. As with the storage-management solutions, consumers must turn to best-of-breed point product solutions to resolve their security-management needs.
Still, management areas in strongest demand are application event/fault monitoring and application performance management. In order to build a complete picture of the state of an application, managers are faced with the daunting task of collecting all the events that get produced by each component upon which their application depends as well as all the events produced by the application itself. The increasing number of data points and frequency of occurrence of events, known as "alarm showers," has generated the need for better event/fault filtering and correlation in application-monitoring tools. In many situations, these events are performance related, indicating a performance bottleneck buried somewhere in the application dependency stack that will eventually manifest itself as an increase in the overall end-user response times. While traditional management frameworks provide a solid foundation for event/fault monitoring, customers will have to turn to best-of-breed performance products to provide complete top-to-bottom views of their application dependency stack.
Application state changes (known as events) and application performance measurements, such as transaction response times, make up the fundamental information required for monitoring service-level agreements (SLAs) between IT and end users. Without a doubt, the concept of establishing SLAs and managing them is the very essence of applications management. For over a decade, IT organizations have had well-established metrics for service levels of applications in the mainframe environment. Now, end users of distributed applications need to establish realistic expectations for the availability of their application and the response time in accessing it. As such, SLAs have become a critical component of any applications-management strategy.
There are three distinct approaches to establishing and monitoring service levels in a distributed environment: inspecting network traffic for application transactions, monitoring every component in the application dependency stack, and embedding application monitoring APIs directly into the application source code.
Several small companies have sprung up offering tools that inspect all the network traffic packets looking for, measuring, and reporting on application transactions. This method of application monitoring yields the desired application-level information in a fairly reliable fashion and eliminates the need for intelligent, autonomous agents to be distributed and maintained on every system under the application. However, there is no mechanism for drilling down into the subcomponents of an application to determine where performance bottlenecks or availability problems are in the underlying networks, systems, or databases. And without the presence of intelligent agents, there is no possibility for automating corrective responses to problems. So, while this method yields effective monitoring, it does not provide any management capability.
A more common technique is to equip every level of the application dependency stack with intelligent, autonomous agents and then consolidate the information into a single view of all the state changes and performance statistics for a given application. This strategy, often referred to as "monitoring by footprint," does provide a more comprehensive view of the application and proactive management of problems. However, without the ability to interrogate an application directly for the necessary management information, an application manager can only draw conclusions regarding what the actual application response times are by summing up statistics from each layer in the dependency stack. The challenge with this technique is identifying-- and maintaining-- all the components upon which an application depends, and then visualizing this information in a form that your applications-management staff can comprehend.
A third method for measuring and managing applications-- based upon the insertion of a set of monitoring and management APIs directly into the application-- is evolving. API calls provide a means by which applications-management tools can effectively query end-to-end response times as well as invoke management actions against the application, such as starting a backup or archiving historical data. This design depends upon the widespread adoption of a standard set of API calls that all the application vendors could adopt. Additionally, it will take several more releases of most of the major business applications before such an API could be fully implemented and available.
When managing home-grown business applications, you may want to implement a management API during the development phase in order to provide maximum manageability. Conversely, when managing packaged applications where it is not possible to embed a management API in the vendor's application code, the non-intrusive method of inspecting network traffic is a cheap and efficient approach. But it falls short of providing enough detailed information to troubleshoot serious problems effectively. For this reason, the predominant choice in most IT shops is to deploy intelligent agents that are capable of gathering extensive information about each application without requiring source-code changes to the application itself.
With the widespread recognition of the need for applications management in the market, along with the related significance of SLAs, most vendors are now marketing the service-level aspects of their management tools. Vendors are expanding their monitoring coverage up and down the application dependency stack. For example, IBM and Tivoli Systems Inc. (a subsidiary of IBM) are combining the Tivoli applications-management tools and the IBM NetView network-management product to produce a complete view of all the components upon which applications depend.
Rather than remain limited to just monitoring, some vendors are forming partnerships or executing acquisitions across the spectrum of the applications-management areas. IBM's acquisition of Tivoli started the ball rolling in this area in 1996; and Computer Associates International Inc.'s (CA) acquisition of Cheyenne in 1996 considerably strengthened the storage-management component in the family of Unicenter products.
Vendors need to package their products with improved "out-of-the-box" monitoring to facilitate implementation of their products. Both BMC Software Inc., with its Knowledge Modules, and Tivoli, with its 10+ modules, have considerable campaigns underway to produce application-ready management modules containing preset event definitions and performance thresholds that are appropriate for specific applications. In the meantime, several of the smaller vendors are independently working on alternative monitoring approaches that include automated discovery and actively learning about an environment over time.
Users are also demanding that vendors improve the visualization of the application environment and the related management information and service levels. The three-dimensional, virtual-reality interface available in CA's TNG product, along with its ability to define business views, is a prime example of an attempt to improve visualization of the distributed environment. Similarly, IBM's Global Enterprise Management (GEM) initiative is sporting the capacity for application-oriented views of the distributed computing environment. And BMC has recently announced improved visualization and navigation capabilities by leveraging the Microsoft Explorer paradigm.
And so the applications-management war has begun. As is the case with most any market as it matures, the field of competition will eventually erode to a two-horse race. This market has yet to reach that point, however. There are still no clear leaders, and a growing number of companies are continuing to enter the arena. Major accumulations of power are developing around CA (with its Unicenter TNG offering) as well as IBM (with its Tivoli/TME framework under its GEM initiative) and BMC (with its line of Patrol products). This clash of the titans in the market has attracted quite a bit of attention, and their business strategies for dominating this market couldn't be more different.
CA's strategy is to provide a complete in-house offering across the major areas of applications management. This strategy is made evident by CA's acquisition of Cheyenne in 1996, which was designed to strengthen its storage management offering and its security product launches throughout the early part of 1997. CA's plan is to deliver a more synthesized applications management environment by tightly integrating all its management tools while publishing CA's internal APIs to allow other vendors to integrate with Unicenter and TNG.
The IBM/Tivoli strategy is to deliver most of the required applications management functionality themselves, but also to build strategic partnerships with other vendors that either have dominant positions in one of the major areas of applications management, or have cutting-edge technology that IBM could exploit more effectively with its distribution channels. The Tivoli 10+ partnership program embodies IBM's partnership intentions and has been very successful at attracting integration partners.
Interestingly enough, BMC is today's mindshare leader when consumers are asked to name which vendors currently provide applications management solutions. BMC's approach is to dominate a number of the management segments, including monitoring and performance management, by offering a best-of-breed solution in those areas and relying on strong partnerships to cover the remaining areas.
Other large players in the applications management market that offer best-of-breed, point product solutions include, but are not limited to, the following: Boole & Babbage Inc., Candle Corp., Compuware Corp., Hewlett-Packard Co., Platinum Technology Inc., and Seagate Software. Boole & Babbage recently acquired MAXM to strengthen its event/fault monitoring capabilities. Candle is fortifying its stronghold in the performance market by expanding its coverage into the middleware market. Compuware is aggressively maturing its EcoTOOLS and EcoSCOPE products to provide better coverage up and down the application dependency stack. HP has partnered with Tivoli on an API for application-performance monitoring. Platinum, through a series of acquisitions, has built a comprehensive set of management products, the star of which is its software distribution product Xfer. Seagate, like Platinum, has accomplished a number of acquisitions over the past year, including that of NetLabs, whose NerveCenter offers product superior event correlation and filtering.
As a greater number of smaller companies start to offer revolutionary approaches to meeting the end-user requirements, the larger players will begin to take notice of them and begin to acquire vendors that attain respectable revenue streams, in excess of $10 million, for credible product offerings. Once a dominant player is established, the number of small, new companies entering this market will quickly drop to zero.
Several management vendors have been courting and partnering with development tool vendors in an effort to get either their management agents, or their own management APIs, embedded in those development tools so that any applications developed with those tools will be inherently more manageable. The consummate example of this tactic is Tivoli's Application Response Measurement (ARM) API that, although very well thought out and designed, has been slow to be adopted as the de facto standard in the manner that IBM, Tivoli, and HP had planned.
IBM/Tivoli, Hewlett-Packard, and BMC, among others, have been working diligently with development tools vendors (including Dynasty Technologies Inc., Fortý Software Inc., PeopleSoft, and Unify Corp.) as well as some of the largest application vendors (including Oracle, PeopleSoft, and SAP) on numerous strategic initiatives to couple the application development and applications management worlds. Perhaps the deal with the most substance to date has been the BMC and Unify agreement to integrate, bundle, and codistribute their technologies. On a related note, given that Oracle runs under most of the popular distributed applications on the market, Oracle's collective knowledge of the Oracle Financials, SAP, and PeopleSoft installed bases makes it a considerably strategic partner to have on one's side.
All this hype, jockeying for position, and conflicting definitions of the market needs on the part of vendors has caused the IT community to turn to the churches of technology-- the standards bodies-- for some clear direction, insight, and religion. Unfortunately, these standards bodies are often funded and/or staffed by the technology vendors themselves.
The Internet Engineering Task Force (IETF), an organization with considerable representation from the actual technology consumer space, has several working groups attempting to bring some convergence to the way in which applications are monitored. The working group focused on the Simple Network Management Protocol is planning to include, among other features, stronger security so that IT managers can rely on secured Management Information Bases (MIBs) to monitor their environment. In order to capture information above the network layer, another of the IETF working groups is working on a system/application MIB (SysAppl MIB) and an application MIB (Appl MIB). The SysAppl MIB draft, which does not require any direct application instrumentation, is now under review and quite possibly could be adopted later on this year. Unfortunately, the Appl MIB draft is not scheduled for completion and review until late 1998, so it is not likely that it will be supported by any production applications management tools until well into 1999.
The Desktop Management Task Force (DMTF) is working on both the Desktop Management Interface (DMI) and a Management Information Format (MIF) standard that would allow management tools to detect and manage applications that are installed on desktops. The DMI has matured considerably with version 2.0 recently released, but few vendors provide full support for the standard. Its focus is limited to the application on the desktop and does not include any of the underlying dependent layers. The MIF is largely based upon a donation from Tivoli of its Applications-Management Specification (AMS), which relies on MIF files to exist in order to discover and manage them. Tivoli continues to evolve and promote its AMS specification independently as well, but it has yet to be widely adopted outside of the IBM family of software products.
In addition to supporting the standards bodies, many vendors are making direct attempts to create religious followings. The most recent example is that of the Web-Based Enterprise Management initiative (WBEM). A considerable number of vendors (Cisco Systems Inc., BMC, Compaq Computer Corp., Intel Corp., Microsoft, CA, IBM/Tivoli, and about 40 others) have gathered together to form WBEM, whose goal is to establish an architecture for supporting the management of enterprise applications across the network.
The fundamental premise is simple enough: All monitoring and management activities will be accessible via any Web browser, thereby making it easy to manage the environment from any spot on the network, versus from just the systems that have the management interfaces installed on them. While WBEM has received considerable attention from the marketplace, it does little, if anything, to meet the actual management needs of IT other than promising to make it easier to manage from anywhere. And it will be another six to 12 months before any management tools provide production support for the WBEM specifications and standards. It is interesting, perhaps even concerning, to note that most of the email traffic on the WBEM mail lists is currently coming from Microsoft, which indicates who may be the most interested in seeing the WBEM initiative succeed.
As Java matures, more application vendors are considering future releases of their applications written in this new programming paradigm. Given that it is impractical to download an entire application each time an end user accesses it via a Web browser interface, the application vendors are redesigning their applications and breaking them down granularly into "application primitives," which are implemented as Java applets. An example of an application primitive might simply be the code required to process an order-entry transaction. The intent is to facilitate the downloading of only those portions of an application that end users need to access at that time to perform their job functions.
The design and implementation of application primitives does facilitate access to applications, and it may reduce the need for the distribution of the client-side application software; however, it produces a wide spectrum of new management problems that were not present in traditional applications management. How will access control and security be implemented on these various application primitives? What demands will arise in managing the version dependencies between various releases of application primitives that must interact? How will these primitives be licensed? The answers to these questions --and the full effect of Java on applications management --will not become fully apparent until well into 1999. It is premature for applications-management vendors to speculate on how their management tools will evolve to meet these demands because there are no commercially available applications on the market today that are implemented in this fashion. One thing is certain, though: The task of managing these distributed applications is only going to become more complex, so consumers should be wary of applications that have been decomposed into Java applets until the management requirements are more fully understood and addressed.
Applications management continues to evolve, and IT management should use the application dependency stack and the seven management areas as tools to focus and converge vendors' development initiatives. When implementing an applications-management strategy, key areas to seek coverage for include: storage management, security management, event/fault monitoring, and performance management. Management must establish realistic service-level agreements for their distributed applications. Be cautious in deploying applications built in Java applets because the management requirements are not yet fully understood. Watch for partnerships to form both vertically through the various layers in the application dependency stack as well as horizontally across the different management segments. Additionally, many smaller vendors may be quickly absorbed by larger players in attempts to establish critical mass through the end of 1998. So, the applications management arena is likely to be a battlefield for at least another two years.
What did you think of this article? Send a letter to the editor.