Nachhaltiger Erfolg durch kontinuierliche Investition

Artikel als PDF herunterladen:
Download Nachhaltiger Erfolg durch kontinuierliche Investition (2 MB)

Die Bedeutung von Software für die Abwicklung betrieblicher Geschäftsprozesse ist einem fundamentalen Wandel unterworfen. Unternehmen verschaffen sich Wettbewerbsvorteile oft nur noch durch Individualsoftware. Die Wartung und Weiterentwicklung dieser betrieblicher Anwendungssysteme wird dabei das prägende Thema der nächsten Jahre werden.

Software ist heutzutage bei der Erstellung von Produkten und Dienstleistungen im betrieblichen Kontext unentbehrlich. Bis zum Ende des letzten Jahrhunderts zog Standardsoftware in viele Unternehmen ein, übernahm dort betriebliche Funktionen und sorgte für Kostenvorteile. Dennoch befindet sich dieser Ansatz im Wandel. Begonnen hat dieser Prozess bereits vor langer Zeit mit der Erkenntnis, dass Alleinstellungsmerkmale am Markt mit Standardsoftware nicht dauerhaft zu erzielen sind. Beschleunigt wurde jener Wandel in den letzten 10 Jahren. Die Stichworte sind hier Digitalisierung, Cloud Computing, Big Data und Industrie 4.0.

Das Ergebnis dieses Strukturwandels sind Inhouse-entwickelte betriebliche Anwendungssysteme, deren Weiterentwicklung einer anderen Logik unterliegt, als der von Standardsoftware. Es ist nicht mehr Aufgabe eines Softwareherstellers, zukünftige Anforderungen zu antizipieren und eine geeignete Produktpflege zu betreiben. Diese Herausforderung ist zu einer genuinen Aufgabe des Unternehmens selbst geworden.

Einher geht die Verschiebung der Verantwortlichkeit, wer für die Zukunftsfähigkeit der eingesetzten Software zuständig ist, mit einem Wandel in der betriebswirtschaftlichen Betrachtungsweise von Anwendungssystemen. Lange Zeit galten IT-Abteilungen als reine Kostenverursacher, ohne dass sich je einer die Mühe gemacht hat, deren betriebswirtschaftlichen Beitrag zum Gesamterfolg des Unternehmens zu ermitteln. In Zeiten, in denen Unternehmen existieren, deren Wertschöpfung vollständig auf digitalen Diensten und Gütern basiert, ist diese Auffassung mehr als antiquiert.

Zunehmend setzt sich die Erkenntnis durch, dass Software – ähnlich wie Produktionshallen, Fahrzeuge und Maschinen – als ein wesentlicher Teil der Betriebsmittel aufgefasst werden muss. Sie ist nicht länger nur Anhängsel technischer Vorrichtungen. Sie unterliegt darüber hinaus ähnlichen Instandhaltungsmechanismen wie andere Investitionsgüter. Auch Software ist Erosionsprozessen ausgesetzt, die durch Ersatzinvestitionen kompensiert werden müssen. Eine Beschränkung auf den Aspekt der Immaterialität würde hier zu keinem verwertbaren Ergebnis führen.

Erosionsprozesse von betriebswirtschaftlichen Anwendungssystemen sind allerdings ungleich schwerer auszumachen. Es gibt Indikatoren, wie Time-to-Market-Strategien bezüglich neuer Features oder die Anzahl der aufgedeckten Mängel bei Innenrevisionen. Es gibt Katalysatoren, die den Erosionsprozess beschleunigen, bspw. Fachkräftemangel und Outsourcing. Ebenso spielt der moralische Verschleiß eine gewisse Bedeutung, denn nirgends sonst ist der technische Fortschritt so schnell wie in der Softwareindustrie.

Erosion als Herausforderung

Ein Anwendungssystem sollte eine ideale Balance zwischen Fachlichkeit und Architektur aufweisen. Je mehr Geschäftsregeln in einem Softwaresystem implementiert sind, umso mehr müssen diese durch architektonische Mittel von ihrem technischen Charakter befreit werden. Als Negativbeispiel sollen hier kurz die allgegenwärtigen Excel-Mappen aufgeführt werden, die Geschäftsregeln ohne jeden architektonischen Rahmen abbilden und damit ein Wartungsalbtraum für jedes Unternehmen darstellen. Eher selten existieren Inhouse-entwickelte Systeme, die stark architekturbetont sind, ohne viel Geschäftslogik zu beinhalten. Es handelt sich hierbei oft um Middleware, die kostengünstiger am Markt erhältlich ist. Beide Extreme sollen in der weiteren Betrachtung keine Rolle spielen.

Ein Erosionsprozess findet in der Weiterentwicklung betrieblicher Anwendungssysteme oftmals unbewusst und lange Zeit auch unbemerkt statt. Um diesen aufzudecken, soll Abbildung 1 und das darin enthaltene Gedankenexperiment dienen. Hier wird die Fachlichkeit und die Architektur eines Anwendungssystems abstrakt gegenüber gestellt.


Abbildung 1: Architekturverschleiß

Es zeigt sich empirisch, dass sich im Leben eines kontinuierlich gepflegten Anwendungssystems die beiden Dimensionen „Architektur“ und „Fachlichkeit“ zunächst die Waage halten. Meist beginnt die Entwicklung mit einem stärkeren Fokus auf der Architektur. Bis zum produktiven Start der ersten Version eines Systems wird dieser Vorsprung wieder ausgeglichen. Der Zyklus kann sich mehrfach wiederholen. Es setzt aber irgendwann ein Punkt ein, an dem Investitionen in Architekturverbesserungen exorbitant teuer werden und damit stoppen. Oft wird dennoch die Fachlichkeit weiter ausgebaut. Man redet dann liebevoll von Legacy-Systemen, meint damit aber eigentlich ein System mit zunehmendem Architekturverschleiß.

Es gibt mehrere Strategien, diesem Architekturverschleiß zu begegnen. Eine beliebte Strategie der Vergangenheit war das Neuschreiben des Anwendungssystems. Diese Strategie wird zunehmend obsolet. Heutige Systeme tragen derart viele Geschäftsregeln in sich, dass diese Aufgabe unter stetig wechselnden Marktbedingungen regelmäßig nicht rechtzeitig bewältigt werden kann.

Eine Alternative ist die relativ neue Disziplin des Architektur-Refactorings. Hier wird unter Beachtung und Beibehaltung der Fachlichkeit eine kontinuierliche Verbesserung der Architektur angestrebt. Die Verbesserungsmaßnahmen können sich dabei auf Stabilität, Skalierbarkeit, Modernität, Sicherheit oder Modularität des Systems beziehen. Ebenso dienen sie der Vereinheitlichung bestehender Strukturen und versuchen damit wieder eine Problemadäquanz zwischen einer gewachsenen Struktur und der darin enthaltenen Fachlichkeit herzustellen.

Architekturverbesserungen beginnen in der Regel mit einer Sichtbarmachung der bestehenden Struktur. Neben dem dokumentierenden Charakter können hierbei auch schon problematische Architektur-Hotspots der Anwendung aufgezeigt werden. Anschließend muss die bestehende Architektur hinsichtlich der beabsichtigten Verbesserungen, beispielsweise einer stärkeren Modularisierung, bewertet werden. Zum Schluss wird ein Umsetzungsplan erstellt und parallel zur fachlichen Weiterentwicklung umgesetzt.

Zum Autor

Frank Schwarz ist studierter Wirtschaftsinformatiker und arbeitet als Berater bei der buschmais GbR. Am liebsten löst er knifflige Probleme in Kundenprojekten. Als Mitinhaber der buschmais GbR versucht er aber auch, das Große und Ganze nicht aus den Augen zu verlieren.

Weitere Artikel von Frank

Kommentare sind abgeschaltet.