Wie Energieversorger mit der App-Revolution auf transparente Datenwirtschaft umstellt

Der Weg der Digitalisierung, so erstrebenswert das Ziel auch sein mag, erweist sich bei vielen Unternehmen doch als ein steiniger Weg. Sicher ist aber, dass Transparenz bei der Anwendungsleistung nicht nur entscheidend für eine effektive Technologiestrategie ist, sondern auch für den geschäftlichen Erfolg.

Die folgende Fallstudie schildert eine Reihe von Umständen und Ereignissen, wie sie viele Unternehmen schon erlebt haben und gibt euch außerdem einige Tipps dazu, wie ihr dafür sorgen könnt, dass ihr genau wisst, wie die digitalen Services aussehen, die eure Kundschaft bekommt. Und wie ihr schnell reagieren könnt, wenn es zu Ausfällen oder Spannungsschwankungen kommt – sodass ihr im Endeffekt die negativen Auswirkungen auf Umsätze und Markenwert minimieren könnt.

Monolithische Anwendungen und kaum Änderungen

Ein europäischer Energieversorger hatte 2015 eine APM-Lösung (Application Performance Monitoring) der zweiten Generation eingeführt und sich für einen Anbieter entschieden, der seinerzeit als Leader im Magic Quadrant™ von Gartner® geführt wurde. Anfangs passte die Lösung gut. Die eigenen Unternehmensanwendungen wurden zunehmend in Java programmiert (als dreischichtige Architekturen, was damals Standard war), und es war absehbar, dass der größte Teil des Anwendungsportfolios am Ende Java-basiert sein würde. Eine weitere zentrale Anforderung war diese: Die APM-Lösung sollte einzelne Business-Transaktionen vollständig und durchgängig auf die Abfolge der Zustandsänderungen der zugrundeliegenden Softwarekomponenten abbilden können. Der betreffende Anbieter hatte genau diese Funktion angeboten und sie prominent als Differenzierungsmerkmal beworben.

Revolution in der Anwendungsentwicklung

In den ersten Jahren nach der Einführung dieses APM-Systems lief alles gut. Doch unterdessen wandelte sich die Vorstellung, wie Best Practices für Anwendungsarchitekturen auszusehen hätten. Und weil die Digitalisierung den Energiemarkt veränderte, erlebten auch die Prozesse der Anwendungsentwicklung selbst eine Revolution. Anwendungen sollten nun so aufgebaut sein, dass immer wieder und in Sekundenschnelle Funktionen hinzugefügt, geändert oder entfernt werden konnten, und zwar ohne sonderliche Auswirkungen auf die Umgebung. Mit Blick auf diese Anforderungen wurden die Architekturen modularer und die Komponenten flüchtiger. Zugleich wurde der Prozess der Anwendungsentwicklung sehr viel schneller und zu einem kontinuierlichen Fluss von Änderungen, der in die Produktion strömte. Ein Nebeneffekt dieser Revolution war, dass die Teams der Anwendungsentwicklung – denen bis dahin egal sein konnte, was mit ihrem Code weiter geschah, sobald er einmal in der Produktion war – nun auch operative Verantwortung für diesen Code übernehmen mussten, zumindest in den ersten Tagen nach dem Release.

Apps auf einmal unsichtbar

Mit veränderten Anwendungsarchitekturen und sehr viel kürzeren Änderungstakten zeigte sich, dass die eingesetzte APM-Technologie ihre Aufgabe nicht mehr ganz erfüllen konnte. Es war wie gesagt eine Plattform der zweiten Generation; deren Technologie arbeitete mit Stichproben, vordefinierten Anwendungstopologiemodellen und einer Bytecode-Instrumentierung für Tiefenanalysen von Verhaltensanomalien. Leider waren die Samples aber nicht fein genug und konnten daher nicht alle änderungsbedingten Events in der Umgebung erfassen. Die vordefinierten Modelle waren fast schon im Moment der Erstellung überholt, und die in erster Linie Bytecode-basierten Analysen ergaben ein verzerrtes Bild der Transaktionsflüsse, weil der größte Teil der Transaktionsverarbeitung in der Weiterleitung von Nachrichten zwischen containerisierten Java-Code-Komponenten bestand. Aufgrund der Unzulänglichkeiten bei der Beobachtung und der Analyse der Zustandsänderungen im Softwaresystem hatte die End-to-End-Ansicht der geschäftlichen Transaktionen letztlich nicht mehr viel praktischen Wert. Kurz gesagt: Bei den neueren Anwendungen war der Energiekonzern nicht in der Lage, die Auswirkungen der Änderungen, die pro Monat zu Tausenden vorgenommen wurden, wirklich zu überschauen.

Zu viel Aufwand, zu wenig Information

Weil sich die Lage zusehends verschlechterte, wurde die APM-Lösung um eine wachsende Anzahl von Zusatztools ergänzt. Die Anwendungslogs, die das Log-Management-System vom Splunk lieferte, erwiesen sich in dieser Phase als eine besonders ergiebige Informationsquelle – damit konnten die Resultate der Technologie zweiter Generation bestätigt und verbessert werden. 

Die Gesamtkosten stiegen allerdings, ebenso wie der Aufwand, der erforderlich ist, wenn ein Portfolio nicht integrierter Technologien gewartet und choreografiert werden muss. Das größte Problem war aber, dass das Unternehmen keine Möglichkeit mehr hatte, ein durchgängiges End-to-End-Bild vom Verhalten seiner digitalen Systeme zu zeichnen, und zwar eines, das für die Entscheidungsverantwortlichen der Business-Seite (im Gegensatz zur technologischen Seite) unmittelbar relevant wäre.

Und abermals auf Einkaufstour

Es wurde daher beschlossen, das Angebot auf dem Markt zu prüfen. Das Ziel war jedoch nicht, die bestehende APM-Technologie komplett zu ersetzen, sondern vielmehr eine Art Arbeitsteilung: Eine neue Plattform sollte sich um die neuere Generation modularer, flüchtiger Anwendungen kümmern, während für die älteren Teile des Portfolios (immer noch > 50 %) der bisherige Anbieter zuständig bliebe. Zwar würde sich mit der Zeit die Entwicklung vermutlich immer weiter von der älteren Lösung entfernen, doch bestand zu dieser Zeit keine Notwendigkeit einer radikalen und umfassenden Ersetzung.

Warum sich das Unternehmen für Splunk entschied

Die Observability-Plattform von Splunk setzte sich schnell an die Spitze der infrage kommenden Anbieter. Das hatte vier Hauptgründe:

1. Der Funktionsumfang der Splunk-Plattform ließ erwarten, dass sie in integrierter Weise die breite Palette von Anforderungen bewältigen könnte, die bis dahin von vielen unterschiedlichen Einzeltools abgedeckt wurde.
2. Es war klar, dass die Observability-Plattform von Splunk im Gegensatz zu den meisten anderen Technologien im Wettbewerb von Anfang an für die Welt der modularen, flüchtigen Anwendungen konzipiert ist und kein Retrofit einer APM der zweiten Generation ist, die einfach auf die schöne neue Welt der Clouds, Microservices und Funktionen umgerüstet wird.
3. Das Energieunternehmen hatte erkannt, dass der Umgang mit Telemetriedaten in praktisch unbegrenztem Umfang ein entscheidendes Kriterium ist, wenn es darum geht, die Auswirkungen von Änderungen zu verstehen. Und Splunk hatte mit makellosen Leistungen im Log-Management bereits bewiesen, dass die Technologie mit dieser Art von Daten bestens umzugehen weiß.
4. Dass die Plattform außerdem die DEM-Funktionalität (Digital Experience Monitoring) von Splunk integriert, versprach eine Sicht auf das Anwendungsverhalten, die nicht nur zur Erfassung der „letzten Meile“ des Transaktionsverlaufs unerlässlich ist, sondern auch den Business-Verantwortlichen relevante Monitoring-Informationen dazu geben kann, wie sich die Services der Anwendung für die User darstellen.

Regionale Cloud mit ganz neuen Möglichkeiten

Die Implementierung war erfolgreich, die Observability-Plattform von Splunk ist nun zu einem wichtigen Enabler für die Teams von IT Operations und Entwicklung des Energieversorgers geworden. Für die Zukunft ist zu erwarten, dass der Einsatz von Splunk zunehmen wird, je mehr Anwendungen der „neuen Generation“ entstehen. Abgesehen davon dürften die KI-Funktionen von Splunk ITSI (IT Service Intelligence) in den Mittelpunkt des Interesses rücken, weil sich damit aufzeigen und sogar vorhersagen lässt, welche Folgen Änderungen auf Systemebene in Bezug auf die Ausführung von Geschäftsprozessen haben.

Die Erfolge, die das europäische Energieversorgungsunternehmen erzielt hat, sind keineswegs das Resultat besonderer Umstände. Jedes Unternehmen, das die Digitalisierung als vordringliche Aufgabe begreift und einen datenstrategischen Ansatz verfolgt, kann mit dem Technologieportfolio von Splunk so weit kommen. 

Neuer Bereich (Realm) in Deutschland 

Bislang konnten sich die Observability-Funktionen von Splunk auf dem deutschen und britischen Markt leider nur in gewissen Grenzen durchsetzen. Der Grund: Es gab bisher noch keinen eigenen Bereich (Realm), keine dedizierte regionale Instanz der Splunk Observability Cloud, die den regulatorischen Anforderungen der Region genügte. Daher konnte Splunk die vielen deutschen und britischen Unternehmen nicht in vollem Umfang unterstützen, die einen immer schnelleren digitalen Wandel zu bewältigen haben – selbst dann, wenn Splunk bereits on premises die strategische Wahl für das Log-Management im IT-Betrieb und für SIEM (Security Information and Event Management) ist. Jetzt aber, mit den neuen Realms, ist unsere Kundschaft in Deutschland und im Vereinigten Königreich optimal aufgestellt und kann mit einem einheitlichen, KI-gestützten Datenansatz für Entwicklung, IT-Betrieb und Security für durchgängige Observability sorgen und digitale Resilienz aufbauen.

Mit den neuen Realms sind unsere deutschen und britischen Kunden nun jedoch in der Lage, einen einheitlichen, KI-gestützten Ansatz für das Management von Entwicklungs-, Betriebs- und Sicherheitsdaten zu entwickeln.

👉 Hier erhaltet ihr mehr Informationen zu Splunk Realms und unserem Lösungsportfolio 👈