International konkurrenzfähige Produkte sind gefragt. Im europäischen Markt gilt es daher auf die Sprachenvielfalt ebenso Rücksicht zu nehmen wie auf das Bedürfnis nach Standards. Doch obwohl die Bedeutung der Standards gerade für die übernational tätigen Unternehmen inzwischen erkannt ist, geschieht, so Pamela A. Gray, von seiten der Anwendungsentwicklung so gut wie nichts.
Programmierwerkzeuge mit Sprachen der vierten Generation, die eine einfachere und schnellere Anwendungsentwicklung ermöglichen, als es die traditionellen Methoden erlauben, sind interessanterweise ein Bereich, in dem US-Software in Europa wenig erfolgreich war. Das liegt daran, daß die VARs (Value Added Resellers) als frühe Nutzer solcher Werkzeuge sich darauf konzentrieren, Spezialprogramme für Marktnischen zu liefern, mit in deinen sie mehr Computer verkaufen konnten. Meist sind sie an einer Bibliothek von Anwendungsprogrammen, die sie an den Mann bringen wollen, mindestens so interessiert wie an den Vorzügen des Werkzeugs selbst.
Auch wenn ein amerikanisches Programmpaket zu Hause mit einer eindrucksvollen Zahl von Installationen aufwarten kann, ist es für Europa wegen unterschiedlicher Gesetze, Verfahren und Bestimmungen meist von geringem Nutzen. Oft geht es schneller, ein Programmpaket für den örtlichen Markt zu schreiben, als ein US-Produkt auf die hiesigen Bedürfnisse anzupassen.
Nur wenige europäische VARs oder andere Anwendungsentwickler unternahmen bisher ernsthafte Anstrengungen, wirklich vielsprachige Produkte zu konzipieren. In gewisser Hinsicht ist dies verwunderlich, denn gerade die leichte Anpassungsmöglichkeit an Kundenwünsche ist eine Eigenschaft erfolgreicher Software, auch wenn solche Anpassungen selten über Gliederungsstrukturen nach Kontenrahmen und einige spezielle Reports hinausgehen.
Gleichwohl kommt jetzt eine neue Generation von Entwicklungswerkzeugen auf den Markt. Sie enthalten Mechanismen, mit denen man die Sprache des Benutzerdialogs, die Währung und das Zahlenformat einer Anwendung mit Hilfe von Umgebungsvariablen wechseln kann. Sie erlauben den Benutzern, gleichzeitig in verschiedenen Sprachen mit dem gleichen System zu integrieren. Diese Flexibilität erreicht man durch zwei Schritte:
1. Das Werkzeug wird internationalisiert, indem man die Passagen, zu denen der Benutzer Änderungswünsche haben könnte, fixiert und überschreibbar macht.
2. Es wird ein Satz von Länderspezifika angelegt, um sich jedem speziellen Markt anpassen zu können.
Standards haben bisher kaum eine Rolle gespielt
Es gibt zwei Arten von Implementierungen, nämlich alte, nichtstandardisierte und neue, standardisierte. Das ist kein Wunder, denn Standards wurden erst in jüngster Vergangenheit formuliert. Für Produkte, die früh auf das internationale Karussell gelangten, wurden daher eigene Regeln geschrieben. Wenn sie Erfolg hatten, mußte man eigene Tools erst noch schaffen.
In der Unix-Welt ist Q-Office ein Beispiel für diesen Weg. Dies gilt auch für das Datenbank-System von Informix. Wenn Sie als Franzose wollen, daß beide Produkte Ihre Sprache sprechen, müssen Sie zwei Bibliotheken für Systemnachrichten und zwei Gruppen von Umgebungsvariablen einrichten und außerdem ihren Azerty-Bildschirm (A, Z, E, R, T, Y, sind die Tasten 1 bis 6 der ersten Reihe einer französischen Tastatur) auf zwei unterschiedliche Arten beschreiben.
Man könnte meinen, daß gerade europäische Hardware-Produzenten und Software-Autoren an vorderster Front für Standards kämpfen, weil sie den größten Vorteil davon hätten. Dem ist nicht so. Die meiste Arbeit wurde in Amerika geleistet. Ein wesentlicher Teil des Fundaments für die Internationalisierug von Unix (und der Sprache C) wurde im Cupertino-Werk von HP im kalifornischen Silicon Valley gelegt.
Hewlett-Packard erkannte in den frühen 80er Jahren die große Bedeutung der Internationalisierung für seinen weltweiten Kundenstamm. Diese waren an die nationale Beigaben in HPs eigenem Betriebssystemen gewöhnt und wollten auch unter Unix nicht darauf verzichten.
Als HP 1986 dem X/Open-Konsortium von Computerherstellern beitrat, bot es seine Internationalisierungswerkzeuge zur Einarbeitung in die zweite Ausgabe des X/Open Portability Guide an. Das Angebot wurde angenommen, so daß das Material heute praktisch zur freien Verfügung steht.
Gleichzeitig war HP auch an der ANSI-Arbeitsgruppe zur Standardisierung von C beteiligt. Zu dieser Zeit beteiligte sich HP außerdem an den Bemühungen von IEEE um Posix (in diesem Zusammenhang muß man auch AT&T, die Santa Cruz Operation (SCO) und Unisys erwähnen). Beide Standards wurden zwar unter Einschluß eines großen Teils von HPs Vorarbeiten entwickelt, aber dies ging nicht. ohne Diskussionen und Streit vonstatten.
In Sachen Standards gibt es zwei Argumentationslinien: Eine Richtung vertritt die Ansicht, seine Funktion bestehe darin, anerkanntermaßen funktionierenden Werkzeugen nur noch den Bestätigungsstempel aufzudrücken. Verfechter dieser Argumentation schlagen vor, daß Standards einfach in einer Weise formuliert werden sollten, die es gestattet, Neuerungen zu einem späteren Zeitpunkt einzufügen. Diese Ansicht setzte sich beim Entwurf des Standards für die IEEE-1003.1 -(Posix)Betriebssystemschnittstelle durch. Nur ein kleiner Teil des Abschlußdokuments betrifft "sprachspezifische Dienste für die Programmiersprache C".
Tatsächlich war aber gerade die Programmiersprache C Ursache für die internationale Anerkennung von Posix. ANSI wurde von der anderen Meinung bestimmt, nach der ein Standard eine umfassende Lösung für einen bekannten Problemkreis zu definieren habe.
Der C-Standard geht von der Absicht der Internationalisierung aus. Dies führt zu einer Programmiersprache für Programme, die mit jeder beliebigen Sprache arbeiten und kommunizieren kann, auch wenn dabei die Schlüsselworte nach wie vor aus dem Englischen stammen. Im Rückblick erscheint die ANSI-Lösung als die bessere. ANSI-C hat wohl eine große Chance, ohne längere Diskussionen oder Änderungen von der ISO (International Standards Organisation) bestätigt zu werden. Bei Posix 1003.1 tauchen hingegen schon unvorhergesehene Probleme auf.
Betriebssystem-Implementierungen, die Posix und den strengeren Anforderungen des X/Open Portability Guide entsprechen, kommen nur allmählich auf den Markt. Wieder hatte eine US-Gesellschaft die Nase vorn: die Santa Cruz Operation mit ihrer Mitte 1988 herausgekommenen Version der internationalen Ergänzung für das Xenix-Betriebssystem. Bald folgte auch Siemens, einer der größten europäischen Computerhersteller.
ANSI-konforme C-Compiler brauchen länger bis zur Marktreife. Die bereits vorhandenen Produkte würden jedoch ausreichen, eine gesamteuropäische Anwendung zu ermöglichen.
Inzwischen wurden so nahmhafte Produkte wie Dbase, Oracle und SAS auf C umgestellt, um deren Übertragbarkeit und Wartungsfreundlichkeit zu verbessern.
Doch bisher geschieht noch wenig. Derzeit weiß nur der etwas über die Anforderungen, der die Entwicklung der Standards intensiv verfolgt hat. Kaum ein Programmierer weiß, daß die Information, die in Englisch auf einen einzigen Help-Bildschirm paßt, am oberen Rand des Schirms wegrollen würde, wenn man sie ins Französische, Deutsche oder Italienische übersetzt. Es bleibt wohl eine abschreckende Herausforderung, Anwendungen zu schreiben, die sich jedem Markt anpassen.
Zudem reicht es nicht, eine Sprache und ein Betriebssystem zu haben, die man nationalen Besonderheiten anpassen kann, man muß natürlich auch die Unterschiede der nationalen Eigenheiten kennen. Dieses Wissen findet man normalerweise nicht bei Programmierern, sondern bei Sprachwissenschaftlern, Volkswirten und Juristen - jeweils Leute mit Spezialkenntnissen, die sie aber leider meist nicht im Zusammenhang mit Computern anwenden.
Wenn man die Hindernisse für einem Markt Offener Anwendungsentwicklung in Europa beseitigen will, muß man Wege finden, diese Kenntnisse nutzbar zu machen. Zur Zeit führen sie fast das Schattendasein von Heimarbeit. Programmautoren wissen meist nicht einmal, wo sie nach Fachleuten mit solchem Wissen suchen müßten.
Zwei Dinge sind sicher: Der europäische Softwaremarkt wird 1992 nicht wirklich offen sein, aber es werden wohl in der Computerindustrie viele neue Firmen hart für seine offene Zukunft arbeiten. Dabei werden mindestens eben soviele gleichviele US-Firmen wie europäische im Wettbewerb stehen.
Flucht nach vorne
Der gemeinsame Markt droht und mit ihm die gesamte internationale Konkurrenz. Da hilft nur die Flucht nach vorne. Software-Export heißt die Devise. Doch selbst Hersteller, die am heimischen Markt glänzen, scheitern häufig schon beim ersten Exportversuch. Im Ausland ist eben alles anders.
Die Vielfalt an nationalen Besonderheiten scheint unüberschaubar: Das fängt bei den Landessprachen an - so wird in Frankreich Computer hartnäckig als Ordinateur bezeichnet - und führt bis in das Dickicht der fantasievollsten Gesetzgebungen. Solche Passagen ließen sich jedoch austauschbar gestalten - wenn die Software dafür vorbereitet wäre. Doch ein Großteil der vermarkteten Software entstand zu einer Zeit, als 1992 ein Jahr wie jedes andere war. Modularität ist gefragt.
Doch die Zeiten ändern sich. Wachsender Konkurrenzdruck zwingt die Software-Häuser, den Binnenmarkt voll auszuschöpfen, wenn sie das Geschäft nicht gänzlich den Amerikanern überlassen wollen.
Die Chancen dafür stehen nicht schlecht, denn bei internationalen Standards haben die Europäer die Nase vorn. Und wer weiß, mit welcher Technik er es im Nachbarland zu tun hat, der hat den ersten Schritt zu einer wirklich internationalen Software bereits getan. g/h