{"id":41,"date":"2016-08-03T14:06:24","date_gmt":"2016-08-03T12:06:24","guid":{"rendered":"http:\/\/blog.iese.fraunhofer.de\/?p=41"},"modified":"2025-10-02T11:10:08","modified_gmt":"2025-10-02T09:10:08","slug":"historisch-gewachsen","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/historisch-gewachsen\/","title":{"rendered":"Historisch gewachsen \u2013 Systemmodernisierung richtig machen"},"content":{"rendered":"

Erfolgreiche Software lebt h\u00e4ufig viel l\u00e4nger als urspr\u00fcnglich gedacht. Kontinuierliche Erweiterungen f\u00fchren zu einem Zustand, den Praktiker gerne als \u00bbhistorisch gewachsen\u00ab bezeichnen. Das \u00e4u\u00dfert sich in inkonsistenter User Experience, leidender Qualit\u00e4t, steigenden Wartungskosten und mangelnder Innovationsf\u00e4higkeit. Aber wie die Systemmodernisierung angehen?<\/p>\n

Irgendwann stellt sich fast jeder Firma die Frage, wie die eigene Software erfolgreich renoviert werden kann und wie tiefgreifend der Eingriff werden muss oder darf, um auch in Zukunft die Gesch\u00e4ftsziele zu erreichen. Um die Weichen der Renovierung richtig zu stellen ist es notwendig, den tats\u00e4chlichen Zustand der Software genau zu analysieren, vor allem weil dieser erfahrungsgem\u00e4\u00df deutlich von fr\u00fcheren Pl\u00e4nen und Dokumenten abweicht.<\/p>\n

Innovation statt Wartung<\/h2>\n

Software ist DAS Mittel, mit dem heute Innovation geschaffen wird. Leider wird es \u00fcber die Lebenszeit eines Softwaresystems immer schwieriger, innovativ zu bleiben und auf neue Anforderungen und Gegebenheiten zu reagieren. Software wird immer weiterentwickelt und neue Features werden hinzugef\u00fcgt, auch wenn sie nicht in das urspr\u00fcngliche Konzept passen. So altert Software sp\u00fcrbar und bringt vielf\u00e4ltige Probleme mit sich.<\/p>\n

F\u00fcr die Nutzer ist die User Experience einerseits nicht mehr einheitlich und andererseits nicht mehr zeitgem\u00e4\u00df. F\u00fcr die Entwicklung wird die Software immer schwerer zu verstehen und \u00c4nderungen werden fehleranf\u00e4lliger, wodurch mehr und mehr Zeit f\u00fcr Wartungsaktivit\u00e4ten aufgebracht werden muss.<\/p>\n

In der Konsequenz bleibt immer weniger Zeit f\u00fcr die Entwicklung von innovativen Features und gerade bahnbrechende Innovation ist nahezu unm\u00f6glich.<\/p>\n

\n

\u00bbSOFTWARE ALTERT DOCH!\u00ab<\/p>\n

Hartn\u00e4ckig h\u00e4lt sich das Ger\u00fccht, Software k\u00f6nne nicht altern. Das gilt h\u00f6chstens f\u00fcr den Code als solchen. Sp\u00e4testens die Weiterentwicklung von Technologien und Erwartungen im Umfeld eines Softwaresystems f\u00fchren dazu, dass die Software gef\u00fchlt altert. Vor allem kontinuierliche Weiterentwicklung mit vielen Kompromissen f\u00fchrt im Lebenszyklus einer Software meist zu einer Situation, in der mehr und mehr Aufwand f\u00fcr Wartung statt f\u00fcr Innovation aufgewendet werden muss.<\/p>\n<\/div>\n

\"Systemmodernisierung
\u00a9iStock.com<\/figcaption><\/figure>\n

Neubau, Umbau oder nur neu streichen?<\/h2>\n

Die Renovierung eines Softwaresystems kann je nach Ausgangszustand und Zielsetzung sehr unterschiedlich ausfallen. Viele Firmen denken zun\u00e4chst \u00fcber ein Refactoring nach, was relativ kosteng\u00fcnstig und lokal durchzuf\u00fchren ist. Leider sind auch die Verbesserungseffekte \u00fcberschaubar, weil globale Herausforderungen so nicht gel\u00f6st werden k\u00f6nnen. Deshalb stellt sich dann h\u00e4ufig die Frage, ob ein System mit einer Neuausrichtung der Architektur umgebaut werden soll oder ob es sich sogar lohnt, ein komplett neues System zu entwickeln. Die komplette Neuentwicklung ist in der Praxis oft auch keine Option, weil dieEntwicklungsmannschaft nicht gleichzeitig das alte System warten und das neue entwickeln kann.<\/p>\n

Renovierung ist keine Einmal-Aktion sondern sollte kontinuierlich fortgef\u00fchrt werden.<\/p>\n