Eine wachsende Anzahl von Anwendern setzt sich gegenwärtig mit der Frage auseinander, was Im Fall eines Systemwechsels mit seinen meist eigenentwickelten Programmen geschehen wird. Das Bestreben vieler DV-Verantwortlicher wird sein, die über viele Jahre selbst programmierten Systeme nicht zuletzt aus Kostenerwägungen am Leben zu erhalten. Doch wie gut oder schlecht Ist derjenige beraten, der sich mit veralteten, wenig flexiblen und damit wartungsanfälligen Softwaresystemen weiterhin auseinandersetzen will? Holger Madsen, Marketing-Mitarbeiter der ADV/Orga aus Wilhelmshaven nimmt zu dieser Frage Stellung.
Das Kernproblem ist die Portabilität von Software. Sie besagt, daß eine Anwendung derart beschaffen und konzipiert ist, daß sie ohne großen Aufwand von einer gegebenen Konfiguration auf eine bestimmte andere oder potentielle andere Hardware-/ Software-Konfiguration übertragen werden kann.
Die mangelnde Portabilität von Anwendungsprogrammen ist eine Ursache der sogenannten "Softwarekrise". Die Misere liegt darin, daß DV-Anwendungssysteme in der Regel eine Mischung aus Hardware, Systemsoftware und Anwendungsfunktionen sind. Diese drei Komponenten sind so fest miteinander verbunden, daß bei Änderung einer dieser Komponenten, zum Beispiel Aufrüstung einer batchorientierten Hardware auf Dialogbetrieb oder Austauschs eines Datenbanksystems für bestehende DV-Anwendungen (gleich ob Standard oder individuell) ein Umstellungsaufwand entsteht, der häufig dem Aufwand für eine Neuentwicklung gleichkommt.
Um dieser Misere wirkungsvoll zu begegnen, muß die Entwicklung der Softwaretechnologie dahin gehen, Anwendungssysteme so zu konzipieren, daß sie weitgehend unabhängig von Hardware und Systemkomponenten sind. Eine Lösungsmöglichkeit ist, die Anwendung frei zu machen von der jeweiligen DV-Umwelt. Dies kann zum Beispiel durch die Anwendung der sogenannten kompatiblen Datenbank- und Datenkommunikationsschnittstellen (KDBS/KDCS) erreicht werden. Diese Schnittstellen wurden von einigen Bundesländern mit Unterstützung des Bundesministerium des Inneren und des BMFT definiert und stehen zur Normung an. Ein derartiger Schnittstellenumsetzer sorgt dann jeweils dafür, daß zum Beispiel aus einem KDBS-Befehl der entsprechende Datenbankbefehl erzeugt wird.
Für einen Wechsel bei der Hardware und/oder den Softwarekomponenten muß sichergestellt werden, daß alle relevanten Schnittstellen eindeutig definiert werden.
Mit dieser ausgesprochen wartungsfreundlichen Technologie können gleiche Verarbeitungsprozeduren ohne Doppelprogrammierung sowohl im Dialog als auch im Batch-Betrieb eingesetzt werden, Einige Softwarehäuser wenden diese neue Softwaretechnologie bereits konsequent an, so daß dort ein "Lager" an Anwendungsmoduln und Bausteinen entsteht, die für eine Vielzahl von Anwendern langfristig nutzbar sind und vielleicht manchen Hardware und/oder Systemsoftwarewechsel überdauern wird.
Programmwartung als "Blocking point"
Parallel dazu nehmen diese Softwarehäuser ihren Anwendern die zeitaufwendigen Dokumentationsund Wartungsverpflichtungen ab. Im Rahmen eines Systemwechsels sollte gerade diesem Tatbestand Beachtung geschenkt werden. Denn vielerorts trifft man ebenso einen wahren undurchdringbaren Dschungel von Dokumentationsmaterialien an wie ganze Stäbe von Mitarbeitern, die fast ausschließlich mit Wartungsaufgaben blockiert sind. Die hierfür verschwendeten wertvollen Kapazitäten stehen für die notwendige unternehmensindiviuelle Softwareentwicklung dann nicht mehr zur Verfügung.
Die Hauptursache der noch immer zu geringen Akzeptanz von universeller Anwendungssoftware - ein Systemwechsel muß dabei gar nicht immer die zwingende Voraussetzung sein - liegt offensichtlich darin, daß in vielen Unternehmen immer noch eine "kunsthandwerkliche" Einstellung in den Mitteln und Methoden vorherrscht, mit deren Hilfe das Produkt "Information" hergestellt werden soll.
Trotzdem zeigt sich eindeutig, daß sowohl das Angebot von Programmsystemen als auch die Installationszahlen in den letzten Jahren sprunghaft zugenommen haben. Damit gewinnt auch die Auseinandersetzung mit dem Einsatz universeller Software - womöglich erst recht im Zuge eines anstehenden Systemwechsels sowohl auf der Hardwarewie auch der Systemsoftwareseiteständig an Relevanz und Aktualität.
Zum anderen haben Eigenentwicklungen die unangenehmen Begleiterscheinungen, daß monate- oft sogar jahrelange Verzögerungen des endgültigen Fertigstellungstermins nicht nur zu Unzufriedenheit und Komplikationen in den Fachabteilungen führen. Darüber hinaus erfolgt auch kein zeitgerechter Rückfluß der Investitionen.
Spätestens in der Diskussion zur Produktivität und
Wirtschaftlichkeit von universellen Anwendungsprogrammen sollte der Anwender erkennen, daß er sich bei weiterer Nutzung seiner veralteten Programme der Chance beraubt, auf dem Markt befindliche, qualitativ bessere Lösungen einzusetzen.
Das jahrtausende alte Prinzip der Arbeitsteilung muß und findet auch Eingang in die Datenverarbeitung. "Do it yourself " lohnt sich nur in den Fällen, in denen kein qualitativ hochwertiges Angebot an fertiger, universeller Software vorhanden ist.
Know-how von draußen
Nur der Einsatz vorgefertigter Softwarelösungen führt zu einer Steigerung der Produktivität in der Informationsverarbeitung. Anders ausgedrückt, bedeutet eine Softwarekrise auch in aller Regel eine Produktivitätskrise, Jedes Unternehmen, das ein bestimmtes Werkzeug oder eine Maschine zur Herstellung seiner dukte benötigt, wird den Eigenbau dieser Produktionsmittel als letzte Notlösung ansehen.
Unter dem Gesichtspunkt einer wirtschaftlichen Arbeitsteilung kann es auch nur sinnvoll für den Anwender sein, eigene Kapazitäten für individuelle Problemlösungen einzusetzen und sich spezielles Know-how für universelle Anwendungslösungen am externen Markt zu beschaffen.