Es zeigte sich, daß derzeit keine der vorgestellten Klassen den gestellten Anforderungen vollständig gerecht werden kann. Die Überwachung des Netzverkehrs bzw. von Systemparametern ermöglicht nicht die erforderliche Überwachung nutzerorientierter Parameter. Die Client-seitige Überwachung liefert zwar nutzerorientierte Parameter, kann aber den Detaillierungsgrad, der für eine zügige und erfolgreiche Fehlerdiagnose unabdingbar ist, nicht zur Verfügung stellen. Einzig durch Überwachung der Gesamtanwendung ist es möglich, die geforderten Parameter zu ermitteln. Im Bereich der Überwachung der Gesamtanwendung zeigt sich, daß eine Anwendungsbeschreibung meist ebenfalls keine ausreichende Information liefern kann und auf Anwendungsinstrumentierung zurückgegriffen werden muß. Dies ist allerdings bereits zum Zeitpunkt der Anwendungserstellung mit erheblichem Mehraufwand für den Anwendungsentwickler verbunden und ist zu einem späteren Zeitpunkt nahezu unmöglich.
Die Untersuchung erstreckte sich über die unterschiedlichen Standardisierungsgremien, Ansätze aus dem Bereich der Forschung sowie am Markt verfügbare Produkte unterschiedlicher Hersteller. Existierende Standards beschäftigen sich vorwiegend mit der Definition der erforderlichen Information, machen aber keinerlei Aussage darüber, wie diese Information zu ermitteln ist. Auch die Standards im Bereich der Instrumentierungstechniken sind hier wenig hilfreich: Sie definieren zwar Schnittstellen, mit denen die benötigte Information von der zu überwachenden Anwendung zur Verfügung gestellt werden kann, geben aber keine Hilfestellung bezüglich einer Methodik für die Instrumentierung oder gar hinsichtlich einer Automatisierung. Dies stellt heute den wesentlichen Einflußfaktor für die geringe Verbreitung von Instrumentierungstechniken dar.
Auch im Bereich der Forschung finden sich nur wenige Arbeiten, die sich mit der Automation des Anwendungsmanagements beschäftigen. Im Bereich der Automation der Instrumentierung von Anwendungen konnten keine Arbeiten gefunden werden.
Die Hersteller von Managementwerkzeugen haben die Problematik der Anwendungsüberwachung erkannt und versuchen, geeignet darauf zu reagieren. Die meisten bieten mittlerweile kombinierte Managementlösungen an, die unterschiedliche Konzepte integrieren und versuchen somit, die Nachteile der einzelnen Konzepte auszugleichen. Die Abkehr von Methoden der Netz- und Systemüberwachung ist deutlich zu erkennen. Diese kommen in modernen Werkzeugen zur Überwachung von Anwendungsdiensten bestenfalls zur Unterstützung nutzerorientierter Verfahren zum Einsatz.
Es läßt sich also feststellen, daß das einzige der vorgestellten Konzepte, das in der Lage ist, alle geforderten Informationen zu liefern, die Anwendungsinstrumentierung ist; diese wird aber aufgrund des mit ihr verbundenen hohen Aufwands derzeit nur in geringem Umfang eingesetzt. Die meisten der aktuellen Arbeiten fokussieren auf eine Verbesserung der Alternativen zur Anwendungsinstrumentierung, z.B. durch Kombination unterschiedlicher Konzepte, um somit ähnlich aussagekräftige und detaillierte Informationen erbringen zu können. Arbeiten, die versuchen, den mit der Managementinstrumentierung einer Anwendung einhergehenden Aufwand zu verringern, sind zum heutigen Zeitpunkt nicht bekannt. Die speziellen Bedürfnisse bausteinbasierter Anwendungen werden nur von wenigen Arbeiten betrachtet: Das CAMI der DMTF beschreibt Managementanforderungen einzelner Bausteine, ohne dabei aber auf die Verknüpfung mehrerer Bausteine zu einer Anwendung einzugehen; Baggiolini und Harms stellen eine Lösung vor, die die Bausteinstruktur von Anwendungen berücksichtigt, geben dabei allerdings keinerlei Hilfestellung bezüglich der erforderlichen Instrumentierung der einzelnen Bausteine.
Der im nachfolgenden Kapitel vorgeschlagene Ansatz basiert auf der Instrumentierung von Anwendungen und ist insbesondere an die ARM API angelehnt. Darüber hinaus werden aber auch Aspekte des Produktes ETEWatch der Firma Candle mit in die Architektur aufgenommen, um die Identifikation der eigentlichen Benutzertransaktionen mit geringem Aufwand durchführen zu können. Die wesentlichen Punkte der im Folgenden vorgeschlagenen Architektur, das automatische Einfügen von Meßpunkten in die Anwendung aufgrund der Bausteinstruktur sowie die Zuordnung der einzelnen Meßwerte zu übergeordneten Transaktionen aufgrund von Kontrollflüssen, sind in keinem der aktuell existierenden Ansätze in ähnlicher Form bereits vorhanden.