EII: Praxisschock 3 - Insellösungen

Insellösungen werden allseits verdammt. Dennoch wird in der Praxis das Schaffen neuer Insellösungen mehr als begünstigt. Wenn man als Informatiker eine gute Arbeit macht, bestehende Anwendungen sicherer und wartbarer redesigned und sorgfältig SWPÄ-Wünsche umsetzt, verdient man sich keine Lorbeeren bei der Führung. Wenn man jedoch ein neues Programm erstellt, welches eine angebliche Lücke füllt, gibt es schnelle Anerkennung: "Die tun was!" Da ist es absolut egal, ob sich die neue Anwendung sauber in die bestehende Anwendungslandschaft einpasst, ob sie sauber designed ist, etc. Für den Nutzer zählt halt nur das Ergebnis - und die Führung ist nun einmal zumeist Nutzer.

Deshalb hilft meiner Meinung nach die gewaltvolle Einführung von SAP o.ä. allein kaum weiter. Stattdessen müsste ein Gesinnungswandel bei den Leuten herbeigeführt werden. Oft gibt es eine ebenbürtige Alternative zum Schaffen einer eigenen Applikation. Die Führung muss sich dessen insbesondere bewusst sein und tolle neue bunte Programme kritisch hinterfragen. Welchen Mehrwert bringt uns dieses Programm? Kann dieser Mehrwert auch anders erreicht werden? Wie ist es um die Wartbarkeit des Programms bestellt? Gibt es eine Entwickler- und eine Nutzerdokumentation? Wie ist der Entwicklungsprozess abgelaufen und wie passt sich das Programm in die bereits bestehende Anwendungslandschaft ein?

Bitte nicht falsch verstehen. Innovative neue Ideen sind absolut zu bestärken, es darf gern etwas ausprobiert werden, aber bevor man das Programm offiziell übernimmt, gilt es halt, die o.g. Fragen zu beantworten.
Ohne Experte zu sein, würde ich also auf die Frage, ob man etwa SAP einführen solle, mit einem "Ja, aber" antworten. Der Schritt ist sicher richtig, allerdings besteht die ernstzunehmende Gefahr, das schon kurze Zeit später neue Insellösungen wie Pilze aus dem Boden schießen, wenn sich nichts an der Einstellung insbesondere der Führungskräfte ändert. Deshalb dürfte nach der Einführung nicht Schluss sein, sondern es müsste eine kontinuierliche Überwachung der Softwarelandschaft geben.
Ist es zu schwierig, die Einstellung der Leute zu ändern, so muss nach Alternativen gesucht werden. Eine Möglichkeit wäre es beispielsweise, dass neue Programme erstellt werden dürfen, diese aber bestimmte Schnittstellen zur Verfügung stellen müssten. Das würde zu einer zwar dezentralen und heterogenen, dafür aber wenigstens gekoppelten Anwendungslandschaft führen, ein Schritt in Richtung Service-Oriented Architecture.