Was Ursula Schrader-Gaddum vom Bundesministerium des Innern, kurz BMI, als "De-facto-Zwänge" bezeichnet, "die sich aus einmal getroffenen technologischen Entscheidungen ergeben könnten" (vgl: Interview der Woche, Seite 3), nennen DV-Profis drastisch "Herstellerabhängigkeit" - korrekt müßte es heißen "Systemabhängigkeit". Folgt man der Argumentation von Frau Schrader-Gaddum, dann wächst - zumindest in der öffentlichen Verwaltung - das Problembewußtsein, Systemabhängigkeit unter allen Umständen zu vermeiden. "Ausschreibungen werden grundsätzlich nicht auf bestimmte Maschinen zugeschnitten", führt die Normenhüterin des BMI als Beweis an.
Daß Inkompatibilität und wirtschaftliche Datenverarbeitung gerade bei Bund, Ländern und Gemeinden unvereinbar sind (Stichwort "Programmaustausch"), ist indessen seit langem bekannt. Um programmieren zu können, ohne Rücksicht auf die Hardware nehmen zu müssen, wurden 1975/76 sogenannte "kompatible Schnittstellen" entwickelt, Software-Versatzstücke, die gewissermaßen zwischen Anwendung und Datenbank geschoben werden.
Ergebnis: Die kompatible Schnittstelle zur Bearbeitung von Datein "KSDS", die kompatible Schnittstelle zur Bearbeitung von Datenbanken "KDBS" sowie die kompatible Schnittstelle zur Bearbeitung der Datenkommunikation "KDCS".
Mit dem Unabhängigkeitswillen der DV-Anwender im Bohördenbereich dürfte es freilich nicht sehr weit her sein - die vorhandenen KDBS/KDCS-Umsetzer werden kaum genutzt. Woran liegt das? Der "Vater" der kompatiblen Schnittstellen, Dr. Herbert Klimesch von der Bayerischen Staatskanzlei, vermutet "Widerstand gegen Gleichmacherei", und zwar dort, "wo man sich so sehr an einen Hersteller gebunden hat und verhindern möchte, . . . diesen Hersteller zu verlieren". Diesen Satz sollte man dreimal lesen und sich auf der Zunge zergehen lassen.
Im Klartext heißt das doch, das ganze Kompatibilitäts-Lamento ist pure Heuchelei - auf Seiten der Hersteller sowieso, aber auch bei den Anwendern. Aber kann diese Erkenntnis eigentlich irgend jemand überraschen?
Auf die Hardware, auf die Betriebssoftware, auf die Programmiersprachen und auf das Datenbanksystem eines bestimmten Herstellers fixiert zu sein, das macht schließlich den Marktwert des DV-Spezialisten aus. Beispiel IMS: Die Schwierigkeit bei IBMs "großer" Datenbanksoftware liegt bekanntlich nicht in der Programmierung, sondern darin, daß eine Unmenge gelernt werden muß, um das System überhaupt anwenden zu können. Dieses systembezogene Know-how entbehrlich zu machen, hieße den Spezialisten in Frage zu stellen- und damit ginge es an's "Eingemachte". Nun ist offensichtlich, daß sich die dank bestehender Unverträglichkeiten entstandene Ausnahmestellung der "Verschlimmbesserer" nicht mehr lange wird halten können - auch wenn diese Konsequenz schmerzlich ist. Die Möglichkeit, kompatibel, das heißt "systemneutral" zu programmieren, ist ja mit den KDBS/KDCS-Schnittstellen gegeben - jetzt geht es darum, daß sich auch alle Datenverarbeiter gegen Inkompatibilität impfen lassen.
Zugegeben, es gibt "eine objektive Unmöglichkeit", wie es Klimesch ausdrückt, "die Schnittstellen sofort einzusetzen", dann nämlich, wenn das Kind bereits in den Brunnen gefallen ist - mit anderen Worten: wenn mit einem Datenbank-Projekt begonnen wurde, bevor die Schnittstellen definiert waren.
Und ein Schönheitsfehler der Schnittstellen-Operation ist auch, daß exotische Funktionen einzelner Datenbanksysteme quasi als "Streichnoten" unter den Tisch fallen.
Nur muß nochmals daran erinnert werden, daß sich Schnittstellen-Benutzer den Vorteil einhandeln, ihre Anwendungen ohne Intimkenntnisse der Datenbank-lnnereien programmieren zu können. Oder sollte dies (siehe "Eingemachtes") vielleicht gar kein Vorteil sein?