Cost of Performance

Cost of Performance Dr. Carsten Bange (Business Application Research Center - BARC GmbH) Die Frage der Performance von entscheidungsunterstützenden Informationssystemen kann zum Grabenkampf zwischen Fachanwendern und IT-Betreuern führen. Performance ist ein wesentliches Qualitätsmerkmal in entscheidungsunterstützenden Informationssystemen. In technischer Hinsicht relevant sind die Ladeperformance, also die Zeitspanne bis relevante Daten im entscheidungsunterstützenden System zur Verfügung stehen, und die Abfrageperformance, also die Zeitspanne zwischen dem Aufruf von Daten durch einen Anwender bis zur Lieferung und Darstellung der Daten in der Anwendung. Performance ist immer relativ Performance ist immer relativ: Zehn Sekunden Antwortzeit können für einen Analytiker oder eine Echtzeit-Applikation so unerträglich langsam sein, dass das System als nicht einsetzbar beurteilt wird, während 10 Minuten Antwortzeit für einen statischen Bericht, der im Hintergrund automatisch vorberechnet wird, völlig ausreichend sein kann. Performance- Anforderungen sind daher genau und differenziert im Projekt zu definieren. Dass Perfomance „nie“ ausreicht, wäre eine rein fatalistische Reaktion. Das richtige Maß zu finden, ist eine Herausforderung, die häufig zu einem Grabenkampf zwischen fordernden Fachanwender und vermeintlich verhindernden IT-Betreuern führt. Zur Versachlichung der Diskussion sollten zwei Aspekte in Betracht gezogen werden: die technische Realisierung und die Kosten für (Nicht-)Performance. Für die technische Realisierung ist es wichtig, dass die Sicherstellung der Performance von Anfang an ein wesentlicher Bestandteil von Systemdesign und -auswahl ist. Obwohl Performance sich immer wieder als das größte Problem für Anwender herausstellt, wird in der Auswahl häufig zu wenig Gewicht auf dieses Kriterium gelegt – dies zeigt auch der OLAP Survey 6. Wartezeit kostet Arbeitszeit Kosten, die aus Mangel an Performance entstehen, werden selten erhoben. Dabei können zwei Kostenarten leicht identifiziert werden. Erstens: Direkte Wartezeit kostet Arbeitszeit. Dazu ein Beispiel aus einem BARC-Beratungsprojekt. Die Data- Warehouse-Applikation eines namhaften Herstellers brauchte im Zusammenspiel mit eingeschränkter Leistungsfähigkeit der Anwenderrechner circa zehn Minuten Abfragezeit für Berichte. Die 100 Vertriebsmitarbeiter benötigten morgens drei Berichte, die nur sequentiell ausgeführt werden konnten – ihre Rechner waren derweil lahm gelegt. Dem Unternehmen gingen somit 30 Minuten täglich wegen mangelnder Performance verloren. Dies ist sicherlich ein extremes Beispiel, aber auch kleine Wartezeiten addieren sich zu stattlichen Produktivitätsverlusten. Zweitens: Wartezeiten verursachen mittelbar Produktivitätsverluste. Gedankengänge bei der Datenanalyse können nicht zügig durch Informationen belegt werden, sondern müssen immer wieder aufgenommen werden. Arbeitsprozesse werden schlicht unterbrochen und es kann fünf bis zehn Minuten dauern, bis der Mitarbeiter wieder seine volle Produktivität erreicht hat. Dieser versteckte Produktivitätsverlust wird von vielen Unternehmen als noch gravierender bewertet, als der durch die direkt messbare Antwortzeit einer Applikation. Neue technische Möglichkeiten Information Lifecycle Management zeigt, dass nur ein kleiner Teil der Daten eines Data Warehouse tatsächlich aktiv genutzt wird. Auf diese sollte man sich konzentrieren – für selten genutzte Daten akzeptieren Anwender häufig auch eine schlechtere Performance. Auch hilft eine Sensibilisierung gegenüber Performance und deren Berücksichtigung im Systemdesign (Datenmodell, Schichtenarchitektur, Einsatz geeigneter technischer Komponenten). Außerdem wurde bei relationalen Datenbanken in den letzten Jahren viel für die Unterstützung von Vorberechnung und Parallelisierung getan – zwei wichtige Faktoren zur Gewährleistung von Performance. Des Weiteren sind multidimensionale Datenbanken eine seit langem verfügbare und etablierte Technologie mit besonders guten Eigenschaften in entscheidungsunterstützenden Systemen. In-Memory-Datenbanken liefern alle Abfragen sehr schnell aus dem Hauptspeicher und sind mit der Verfügbarkeit von 64-Bit-Umgebungen in breitem Umfang einsatzbereit. Zahlreiche neue und alte Anbieter machen hier inzwischen Angebote. Anwender wollen das Missverhältnis zwischen der Dauer bei der Suche nach unstrukturierten Daten (Milliarden von Dokumenten im Millisekundenbereich) und der Abfrage von strukturierten Daten nicht mehr hinnehmen – ein Effekt der auch „Googleization of BI“ – auf deutsch etwa „Google“-isierung von Business Intelligence – genannt wird.