Peter HelfensteinPeter Helfenstein Business & IT – Change Impact will gemanaged sein

28.03.08 by Peter Helfenstein

Stetig wachsende Systemkomplexität
Bestehende IT-Systeme decken heute die Business-Prozesse praktisch vollständig ab. Mehrheitlich kommt dabei Paketsoftware strategisch zum Einsatz. Neuentwicklungen von ganzen Business-Systemen sind eigentlich eher die Ausnahme. Die moderne Anwendungsentwicklung arbeitet in solch einem Umfeld anders: Sie ist nicht mehr Build-Centric, sondern Change-Centric, siehe auch Punkt #4 im Blog-Beitrag von Niel Roberston, CTO von ALM Anbieter Newmerix.

War früher bei Projekten das Bauen von neuen Systemen in erster Linie kreative, innovative Herausforderung, geht es heute vielmehr darum eine mehr oder weniger grosse Zahl von kleinen und grossen Changes an bestehenden Systemen und Customizings vorzunehmen. Die Systeme selbst sind gebaut, im Einsatz, zum Teil mit mehreren technischen und produktiven Instanzen und oft komplex miteinander verknüpft und lokal angepasst. Dies auf jeder Ebene, von der kleinsten Programmkomponente oder einzelnen Customizing-Einstellungen, über einzelne Business-Funktionen bis hin zu ganzen Geschäftsprozessen.

Kommt hinzu, dass heutige Systeme aus immer mehr aus mehrfach benutzten Komponenten bestehen. Serviceorientierte Architekturen erlauben Business Prozesse und funktionale Komponenten sauber zu trennen. Ein „guter Design“ erlaubt, Services relativ gut vor negativen Auswirkungen von Änderungen in Teilbereichen schützen. Doch neue Abhängigkeiten werden mit einer solchen Wiederverwendung auf jeden Fall geschaffen. Funktionale Komponenten werden von verschiedensten Business-Prozessen genutzt. Änderungen an einem einzelne Geschäftsprozess oder einer Geschäftsfunktion können an verschiedensten Stellen im System Konsequenzen haben.

Auch Systemkonsolidierungen tragen das ihre bei. Um Hardware und Softwarekosten einzusparen, werden Business Prozesse und funktionale Komponenten regional oder global auf einem System zusammengefasst. Änderungen aufgrund lokaler Bedürfnisse müssen somit immer im Kontext des gesamten konsolidierten Systems betrachtet werden.

Impact für das System und die Änderung
Dies hat zur Folge, dass diese Komplexität für Änderungen verstanden werden muss, will man nicht böse Überraschungen erleben. Die Erfahrung zeigt, dass es im wesentlichen gilt, drei plus zwei Arten von Folgen am System zu verstehen und zu kontrollieren.

Welche Komponenten gehören insgesamt über alle Ebenen hinweg zum betroffenen System und müssen verändert werden? Welche anderen, von aussen gesehen eigentlich unabhängigen Systemteile werden beeinflusst? Was bedeutet die Änderung für in Planung oder in Arbeit befindliche parallele Projekte?

Ebenfalls sollte betrachtet werden, wieviel neue Komplexität im System mit der Änderung geschaffen wird. Ein nicht mehr wartbares System ist leider allzu schnell geschaffen.

Letztendlich sollte auch noch der Impact der Komplexität des Systems für die vorzunehmenden Änderungen beurteilt werden. Möglicherweise zeigt die Analyse des Systems, dass eine an sich einfache Änderung wegen zu hoher Systemkomplexität gar nicht in Angriff genommen werden sollte. Mit diesen Analysen kann die System-„Umweltverträglichkeit“ von Änderungen erst wirklich beurteilt werden.

Im übrigen kann mittels geeigneter Massnahmen und Projekte, beispielsweise einem entsprechenden Systemdesign oder mit Schutzmassnahmen für Komponenten wie Firmentemplates präventiv ein Systemumfeld geschaffen werden, das Auswirkungen von Änderungen reduziert oder ungewollte Änderungen erkennt und nicht einfach zulässt.

IT Impact Management heisst IT Impact Analyse & IT Environment Protection
IT Impact Analyse und IT Environment Protection werden so zu Schlüsseldisziplinen der Systementwicklung. Für Paketsoftwarelösungen gibt es erste gute Ansätze, diese Aufgabenstellungen richtig anzugehen. Informatikorganisationen, bei welchen Impact Analyse und Environment Protection konsequent in die IT Change Prozesse integriert sind, findet man jedoch noch selten. Stattdessen treiben die Firmen über den gesamten Application Lifecycle hinweg noch viel unnötigen Aufwand und bezahlen einen hohen Preis: Projekte werden zu komplex und geraten ausser Kontrolle, Abhängigkeiten werden nicht erkannt, Tests somit nicht durchgeführt und Fehler erst im Betrieb gefunden.

Es kann anders sein: Projekte können von Anfang an aufgrund Ihrer Auswirkungen korrekt beurteilt werden. Sogar die Konkurrenzsituation, die entsteht, wenn von Änderungen durch parallele Projekte an denselben Systemkomponenten vorgenommen werden, kann verstanden und kontrolliert werden. Solche Änderungen können für verschiedene Projekte gar gezielt miteinander vorgenommen werden. Die anzupassende Komponente muss nur einmal verstanden und angefasst werden. Da es dank Impact Analyse klar ist, was am System alles von einer Änderung betroffen ist, kann auch das Richtige getestet und so die Qualität der Systeme vor dem Roll-out in die Produktion massiv erhöht werden. Grosse Paketsoftwareinstallationen werden dank Impact Management-Massnahmen für das Geschäft flexibler anpassbar und über eine längere Zeit einsetz- und wartbar.

Fazit
Konsequentes Impact Management, also Business & IT Change Impact Analyse und Environment Protection erlangen zentrale Bedeutung. Der Einsatz von umfassenden, eingekauften oder selbst entwickelten Softwaresystemen verändert die Optik beim Bau von Systemen – jeder neue Bedarf wird in erster Linie zu einer Änderung des bestehenden Systems!

Service Architekturen und Business Process Management erlauben Wiederverwendung, gleichzeitig steigen damit potentiell die Auswirkungen von Änderungen.

Change Impact Management bestehend aus Impact Analyse und Environment Protection konsequent in die Systementwicklungs-Methodik integriert und werkzeugunterstützt erlaubt, dass Systeme trotz hoher Komplexität über die Lebenszeit hinweg mit adäquatem Aufwand verändern lassen und sich die Komplexität nicht mit jeder Veränderung unnötig erhöht.

Der Nutzen von wirkungsvoller Impact Analyse und Environment Protection kann sehr gross sein. Paketsoftwareinstallationen und Systeme mit Service Architektur können mit vernünftigem Aufwand bei hoher Qualität weiterentwickelt werden. Die Systeme bleiben für Business und IT flexibler und mit kürzerer Reaktionszeit anpassbar. Sie können so viel länger im Einsatz stehen, ohne wegen zu hoher Komplexität frühzeitig wieder abgelöst werden zu müssen.

Sphere: Related Content

5 Kommentare

Kommentar schreiben

XHTML: Sie können diese Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>