IT-Systeme befassen sich mit der Verarbeitung von Informationen, um dem Anwender einen strategischen Vorteil zu verschaffen. Hierfür muss das System eine wichtige Kernaufgabe erfüllen:
Die richtige Information in der richtigen Darstellung zur rechten Zeit am rechten Ort bereitstellen zu können.
Jedoch enthält diese Forderung einen Aspekt, der oftmals zu spät und/oder zu wenig Berücksichtigung findet. Der Aspekt der Bereitstellung "zur rechten Zeit". Dieser stellt in vielen Systemen eine sehr wichtige und kritische nicht-funktionale Anforderung dar. Informationen, welche zu spät bereitgestellt werden, können wertlos sein und in Folge dessen zu strategischen Nachteilen oder finanziellen Verlusten führen. Als Beispiel können Nachrichten im Börsenhandel gesehen werden. Zu spät bereitgestellte Börsendaten können - in Folge von dadurch verspätet getroffenen Entscheidungen - zu hohen Kursverlusten führen.
Daher ist die Performance ein kritischer Faktor für den Erfolg von IT-Systemen und Unternehmen und sollte frühzeitig untersucht und einbezogen werden. Dies erfordert zunächst im Requirements Engineering eine Aufnahme der Performanceanforderungen an das System. Die daraus resultierenden Messkriterien finden später in der Testphase und den entsprechenden Performancetests Verwendung.
Weit wichtiger ist jedoch, diese Performanceanforderungen im Requirements Engineering zu erfassen und bereits bei der Architektur und dem Design des Systems zu berücksichtigen. Nachträgliche Performanceoptimierungen in bestehenden Systemen sind in der Regel nur schwer durchführbar und teuer. Nicht zuletzt da dies in vielen Fällen zu einer Neuausrichtung der Architektur sowie dem Design führt. Dies resultiert oftmals in einer Neuimplementierung des Systems.
Als Entscheidungsbasis für Performanceoptimierungen ist jedoch eine Performanceanalyse basierend auf den Ergebnissen der Performancetests unerlässlich. Nur wenn Performanceleaks und deren Ursachen richtig erkannt und priorisiert werden, können Optimierungsmaßnahmen gezielt, nutzenstiftend und kosteneffizient umgesetzt werden.
Andernfalls bestehen diverse Risiken, welche bei Performanceoptimierungen berücksichtigt werden sollten. Es besteht z.B. zunächst die Gefahr knappe und teure Ressourcen ineffizient für Mikrooptimierungen im Millisekundenbereich einzusetzen. Hierdurch wären diese Ressourcen gebunden und könnten nicht für Weiterentwicklungen oder Fehlerbehebung eingesetzt werden. Somit wäre weder ein wirtschaftliches Kosten-Nutzen-Verhältnis gewahrt, noch die Opportunitätskosten entsprechend berücksichtigt. Weiter besteht unter anderem das Risiko, anstatt eine spürbare Performancesteigerung zu erzielen, schwer erkennbare Fehler in das System zu bringen. Als Beispiel können Raceconditions aufgrund falsch eingesetzter bzw. falsch umgesetzter Parallelverarbeitung angeführt werden. Ein weiteres und nicht zu unterschätzendes Risiko ist die entstehende Systemerosion, welche mit Mikrooptimierungen oft einhergeht. Diese führt, aufgrund der zunehmenden Vermengung von technischem und fachlichem Code, im weiteren Verlauf meist zu unverständlichen und somit unwartbaren Komponenten. Dadurch können die späteren Wartungs- und Weiterentwicklungskosten auf unwirtschaftliche Größenordnungen ansteigen und eine vorzeitige Systemablösung bedingen.
Negativ Beispiel : Nachträgliche Parallelisierung eines Produktes
Ein Softwarehersteller versuchte seine Performanceprobleme dadurch zu lösen, indem er sein Produkt nachträglich auf Parallelverarbeitung umstellte. Jedoch erwies sich dies schnell als Fehleinschätzung. Anstatt die gewünschte Performancesteigerung zu erzielen, lieferte das System nun falsche Daten. Dies resultierte zunächst in einem hohen finanziellen und personellem Aufwand des Herstellers, um die Fehlerursache zu analysieren und zu beheben. Weit schlimmer war allerdings der Vertrauensverlust des Kunden in das Produkt. Derartige Imageschäden sind im hart umkämpften Markt kaum bezifferbar.
Positiv Beispiel : Umstellung der Verarbeitung von Massendaten
In einem BI-Umfeld wurden täglich mehrere Gigabyte an Daten in eine historisierte Datenbank übertragen. Die eingesetzten Algorithmen bedienten sich dabei auch der mehreren Terrabyte umfassenden, historisierten Daten. Aufgrund einer ungenügenden Analyse, wurde zunächst eine einfache, sequentielle Batcharchitektur umgesetzt. Diese resultierte in Verarbeitungszeiten von zum Teil mehreren Stunden pro Algorithmus. Nach einer Untersuchung der Datenstrukturen sowie der Anforderungen, konnte eine mehrfachparallele Architektur mit Datensegmentierung als Lösung präsentiert werden. Diese Umstellung der Algorithmen führte im ersten Schritt zu einer sauberen Trennung der technischen und fachlichen Logik. Somit konnte - als Nebenprodukt - die Anpassungsgeschwindigkeit der Algorithmen signifikant erhöht und die Fehleranfälligkeit reduziert werden. Im zweiten Schritt war es durch gezielte Performanceoptimierungen möglich, die Laufzeit der Algorithmen auf jeweils ca. 10 bis 15 Minuten zu senken.