Wenn Normung den Fortschritt bremst

07.04.1978

Allein im Bereich Informationsverarbeitung arbeiten im FNI-Ausschuß des DIN Deutsches Institut für Normung e. V. rund 430 ehrenamtliche Mitarbeiter aus interessierten Kreisen der Hersteller, Anwender und der Wissenschaft. Im Normenausschuß Informationsverarbeitung gibt es 35 feste Arbeits- und Unterausschüsse sowie zahlreiche Arbeitskreise. Natürlich ist auch die Normung normiert: DIN 820 "Normungsarbeit". Der FNI-Arbeitsausschuß 5 "Programmierung" hat allein zehn Unterausschlüsse. Diese Arbeit wiederum muß International koordiniert werden. Wird hier mit deutscher Gründlichkeit des Guten zuviel getan?

Man erinnere sich an DIN 66 220 "Programmablauf für die Verarbeitung von Daten nach Satzgruppen". Im FNI-Jahresbericht 1977 heißt es zu dieser Vereinheitlichung der

"Normierten Programmierung": "Erstmalig wird damit der Ablauf von Programmen genormt, wie sie für kaufmännisch-administrative Anwendungen typisch sind." Und wer hält sich daran? Und ist heute angesichts Strukturierter Programmierung und weitverbreitetem Direktzugriff dergleichen wirklich noch typisch?

Die Vorteile der Normierung sind unumstritten und brauchen nicht diskutiert zu werden. Normung im engeren Sinne - Begriffsdefinitionen etwa, Standards für den Datenträgeraustausch etc. - wird von der Praxis dringend benötigt und ist meist auch unproblematisch.

Warnendes Beispiel

Aber bereits die Normierung von Sprachen dürfte gefährlich sein, weil eine Weiterentwicklung blockiert werden kann. So eignet sich Standard-Cobol nur mit Klimmzügen für die Strukturierte Programmierung, es könnte einfacher gehen. Und ungeachtet der ANSI-Norm kommt jetzt eine ganze Welle von "Structured Cobol Compilers" auf den Markt.

Vollends problematisch ist die Normierung von Verfahren. Das gilt bereits für relativ einfache Anwendungen, siehe DIN 66 220. Das gilt um so mehr für komplexe Systeme. Im April '71 stellte die Codasyl Data Base Task Group des American National Standard Institute (ANSI) ihren Entwurf für eine Datenbank-Norm fertig. Lauthals ist seither geklagt worden, daß der Entwurf noch kein verbindlicher Standard wurde. Dafür gibt es viele Gründe. Die vielen Datenbank-Software-Pakete des Marktes haben alle ihre jeweiligen speziellen Vorteile, die die Anwender gar nicht missen wollen. Und Tatsache ist, daß im Laufe der Zeit die großen DBMS-Standard-Pakete sich immer ähnlicher werden, weil sie ständig weiterentwickelt und verbessert werden müssen. Zwei Beispiele: IBMs IMS wurde Secondary Indexing zugefügt, um auch mit invertierten Tabellen a la Adabas arbeiten zu können. Und Adabas erhielt einen CALC-Mode a la Codasyl. Normierung in den frühen Siebzigern hätte sicherlich den Fortschritt gebremst.

Für und Wider abwägen

Dergleichen gilt es zu beachten, wenn die so verdienstvolle FNI-Normungsarbeit nicht gelegentlich in Sackgassen führen soll. Es gibt einige Projekte auf den Tagesordnungen der vielen FNI-Gremien - etwa Anpassung von Bildschirmarbeitsplätzen an den Menschen, Programmdokumentation, PEARL, Datenübertragungs-Schnittstellen und noch weitere - bei denen das Für und Wider sorgfältig abgewogen werden muß. DIN 66 220 bleibt als warnendes Beispiel.