Die Scope Story: Die Zeiten ändern sich

Taucht ein in die Entstehungsgeschichte von Scope. In unserer mehrteiligen Blogpost-Serie erfahrt ihr, wie der digitale Standard für die Logistik ins Leben gerufen wurde. Alle Kapitel im Überblick: 

1. Aufbruch in eine neue Zeit 
2. Eine Idee setzt sich durch
3. Die Zeiten ändern sich 
4. Es bleibt alles anders 
5. Noch nicht gut, aber schon schön
6. Einmal vor und wieder zurück
7. Und sie bewegt sich doch 

Die Zeiten ändern sich

Das war schon immer so. Aber ab Mitte der 1990er Jahre ging alles plötzlich sehr viel schneller. Vor allem im IT-Bereich. Denn in diesen Jahren kamen zwei Entwicklungen auf, die ProCarS das Leben schwer machen sollten. Und nein, keine dieser Entwicklungen war das Internet. Das Internet war zu diesem Zeitpunkt eher ein Vorteil für ProCarS, da man nun Clients kostengünstig auch weltumspannend auf zentrale UNIX-Rechner aufschalten konnte. Der mehrfach erwähnte Großkunde brauchte gerade einmal fünf Server, um alle Anwender:innen weltweit anzubinden. 

Die wirklich einschneidenden Entwicklungen für ProCarS waren ganz anderer Natur. Zum einen etablierte Windows 95 das Konzept der grafischen Oberfläche auch im Business-Umfeld. Wirklich stabil war es nicht, aber die Welt am Bildschirm wurde bunter. Zum anderen wurden SQL Datenbanken modern. Beide Konzepte waren in ProCarS nicht vorhanden. ProCarS basierte auf einer Technologie, die SQL nicht verstand. Zwar beherrschte auch PL/B recht schnell die Konzepte „Grafische Oberfläche“ und „SQL Datenbank“. ProCarS hätte nur an diese neuen Konzepte anpasst werden müssen und beide Probleme wären auf einen Schlag gelöst worden.

Aber es kam anders. Und das hatte verschiedene Gründe.

ProCarS bestand mittlerweile aus Tausenden (ja: Tausenden!) verschiedenen Programmen, die sich untereinander aufriefen. Allerdings hatte ProCarS auch gefühlt Tausende von Vorteilen. Alle Masken konnten mehr oder minder frei gestaltet werden, die Reihenfolge der Felder war konfigurierbar, es gab Tausende kleiner Stellschrauben, mit denen man das System individualisieren konnte. Und: ProCarS war extrem schnell und unschlagbar günstig. Was also sprach gegen eine Anpassung an die neuen Konzepte?

Das Problem mit der Umstellung der Datenbank auf SQL hätte man – wenn auch mit sehr hohem Aufwand –  in den Griff bekommen. Aber es gab mehr als eine SQL Datenbank und diese waren miteinander nicht wirklich kompatibel. Allein das warf eine Reihe von Fragen auf: Welche Datenbank hätte man wählen sollen? Wer betreut diese Datenbank beim Kunden? Passt das überhaupt in deren IT Landschaft? Ein anderer Großkunde aus dieser Zeit setzte damals ausschließlich auf IBM und hätte deshalb auf einer DB/2 bestanden, aber Oracle war viel populärer – wenn auch deutlich teurer – und Microsoft SQL Server waren noch weit davon entfernt, überhaupt in Betracht gezogen zu werden. Mit sehr viel Optimismus erfüllte die Vorstellung einer Datenbank-Sammlung niemanden. Eine babylonische Namensvielfalt und keine Entscheidungsgrundlage.

Das weitaus größere Problem aber war die grafische Oberfläche. Damals durfte ein Program maximal 16 Kilobyte groß sein und konnte maximal 16 Kilobyte an Daten verwalten. Diese Grenzen waren im Laufe der Zeit größer geworden, doch große Teile von ProCarS basierten genau auf diesem Aufbau. Und genau so funktionieren Programme mit einer grafischen Oberfläche nicht. Dort hat man normalerweise ein einziges Programm und nicht Hunderte oder gar Tausende, die sich untereinander aufrufen. Da die Eingabemasken in ProCarS sehr eng mit der Business-Logik verwoben sind, hätten diese entwirrt werden müssen, um überhaupt eine grafische Oberfläche zu realisieren. Das bedeutete: ProCarS hätte komplett neu geschrieben werden müssen. Und das kam für Christian Riege, der bereits als Student im Unternehmen hospitiert hatte und mittlerweile für die Entwicklung zuständig war, dann doch nicht in Frage. Dann ProCarS lieber gleich neu entwickeln.

Fortsetzung folgt...