Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Verlag ersetzt Mainframes durch Unix-Rechner (Teil 1)


25.10.1991 - 

Downsizing-Projekt: "Die Vorteile überwiegen deutlich"

Ein Großprojekt, in dessen Rahmen Großrechner durch Unix-Systeme mit Multiprozessoren abgelöst wurden, beschreibt Raymond Treß* im ersten Teil seines Beitrags berichtet der Autor über die Kriterien, nach denen Hardware und Software ausgewählt wurden. Überdies werden Planung und Zielsetzung des Projektes beschrieben.

Die konsequente Ablösung vorhandener Mainframe-Systeme durch Unix-Rechner war das Ziel, das sich der Hannoveraner Verlag Heinz Heise GmbH & Co. KG gesteckt hatte. In diesem Beitrag sollen Planung, Ziele und Durchführung des CATSS-Projekts (Catalogues-, Addressbooks-, Telephonebooks, System & Services) geschildert werden. Wir wollen Einblick in die von uns gemachten Erfahrungen bei der Realisierung eines von der Größe und Komplexität her anspruchsvollen Unix-DV-Projektes geben.

Einer der beiden wesentlichen Wertschöpfungsbereiche beim Heise-Verlag ist die Produktion und Herausgabe von amtlichen und örtlichen Telefonbüchern. Dabei ist es wichtig, klarzustellen, daß es sich hierbei um die normalen Telefonbuchausgaben und nicht um Branchenbücher handelt. Die Telefonbücher geben wir als Lizenznehmer der Deutschen Postreklame GmbH, einer Tochter der Deutschen Bundespost, heraus. Geografisch ist der Verlag auf den nordwestdeutschen Raum konzentriert.

Nun ist die Produktion von Telefonbüchern allein natürlich nicht gewinnbringend. Lukrativ ist der Verkauf von Anzeigen und von grafisch gestalteten Einträgen, zum Beispiel, Fettschriften und Ergänzungen. Der Ablauf der Telefonbuchproduktion läßt sich folgendermaßen schematisieren:

- Laufende Einarbeitung der amtlichen Veränderungen in den Datenbestand,

- Bewerbung durch den Außendienst,

- Einarbeitung von Aufträgen:

- Auftragsdaten für die Fakturierung;

- Angaben über Art und Größe der grafischen Gestaltung;

- Scannen, Setzen und Belichten von Anzeigen;

- Redaktionsschluß,

- Umbruch- und Satzrechnung des Telefonbuches,

- Belichtung des Fließsatzes,

- Zusammenführung des Fließsatzes mit den Anzeigen,

- Druck und Auslieferung.

Die Gestaltung eines Telefonbuchs unterliegt ausgeteilten Regeln der Deutschen Bundespost Telekom (DBP). Weil Umbruch und Satzrechnungen sehr kompliziert sind, stößt die herkömmliche DV hier schnell an ihre Grenze.

Neben der Telefonbuchproduktion hat der Verlag schon vor längerer Zeit damit begonnen, Redaktionen für die technisch interessierte Leserschaft aufzubauen. "cÆt - Magazin für Computer und Technik", die Unix-Zeitschrift "ix" sowie die Publikationen "elrad" und "HIFI Vision" sind Publikationen, die bei uns erscheinen.

Bis 1988 hatte die Existenz der Redaktionen keine direkte Relevanz für die zentrale DV, verwendet wurden unterschiedliche PCs wie C64, Atari, MS-DOS-Rechner. Zu Beginn des Jahres 1989 haben wir dann das verfügbare Hard- und Softwarespektrum der Apple-Macintosh-Szene eingesetzt.

Mit diesem fortschrittlichen Material haben wir unsere Redaktionen an die Desktop-Publishing-Produktion (DTP) herangeführt. Das Ergebnis war eine erhebliche Kostenreduzierung, wesentlich verbesserte organisatorische Abläufe und eine Bemerkenswerte Motivationssteigerung der Redakteure.

Wir verwenden Quark Express, Freehand und Adobe Illustrator auf vernetzten Macintosh-Rechnern (Apple Talk) mit Ethernet-Gateways zu unseren Unix-Rechnern. Auf dieses Projekt soll nicht weiter eingegangen werden, da es genügend Stoff für einen eigenen Beitrag hergeben würde. Nur soviel sei gesagt: Der mit den Unix-Systemen erreichte Integrationsgrad wäre mit unseren Mainframes nur äußerst schwierig zu erzielen gewesen.

Im Zuge der wachsenden Bedeutung elektronischer Kommunikationstechniken (X.25, Btx, ISDN) ist in den 90er Jahren mit Veränderungen der Auskunftsmechanismen für Telefondaten zu rechnen. Bestes Beispiel dafür ist Frankreich mit dem sehr erfolgreichen Einsatz von Minitel (Btx) als schon eingesetzter, fast vollständiger elektronischer Ersatz für das Papiermedium Telefonbuch.

Um für den bevorstehenden Strukturwandel gewappnet zu sein, haben wir auch die Voraussetzungen für den Erwerb des notwendigen Know-hows im Bereich der elektronischen Kommunikation geschaffen. Mit der von uns entwickelten Mailboxsoftware haben wir Zugang zu allen wesentlichen weltweiten Verbundsystemen wie Internet, Dialcom, UUCP etc. Selbstverständlich sind die dafür eingesetzten Rechner ebenfalls Unix-Systeme.

Unserer bisherige Arbeitsweise läßt sich wie folgt beschreiben:

- Einsatz traditioneller Mainframe-DV,

- Anwendungen sind Insellösungen mit aktivem "Ruderbootverkehr",

- keine sinnvolle Integration der Anwendungen,

- Schwierigkeiten bei der Pflege der Anwendungssoftware,

- keine sinnvollen Erweiterungsmöglichkeiten der Software.

Nach der Einführung der DV im Jahre 1975 arbeiteten wir wie die meisten mittleren Unternehmen mit einem "Mainframe". Solange dieser Begriff auf die Firmengröße der DV-Hersteller bezogen wird, mag er noch gelten. In bezug auf die Leistungsfähigkeit der DV-Systeme ist der Terminus heute nicht mehr gerechtfertigt.

Wir setzten zwei Siemens-Systeme C40 ein mit BS2000 als Betriebssystem, 50 Terminals, 5 GB Plattenspeicher und 32 MB Hauptspeicher. Datenbanksysteme waren Sesam (bedingt relational) und Leasy (hierarchisch). Um diesem Teilnehmersystem eine komfortable Teilhaber-Benutzeroberfläche zu geben, kam UTM als Transaktionsmonitor zum Einsatz.

Die Anforderungen unserer zeitkritischen Dialogverarbeitung (Antwortzeit nach DIN kleiner/gleich einer Sekunde) bei der Telefonbuch-Bestandspflege konnten wir jedoch nur mit eigens dafür entwickelten Assembler-Programmen abbilden.

Den Kern unserer Anwendung bildet der Telefonbuchbereich mit der typischen Problematik einer Datenbestandspflege von etwa fünf Millionen Telefonbuch-Haupteinträgen, mit entsprechend vielen Neben- und Untereinträgen sowie der daraus resultierenden Umbruch- und Satzsoftware. Dafür verwendeten wir eine Software deren Entstehung in die Pionierzeiten der DV fällt: Sie wurde Ende der 60er Jahre entwickelt.

Sämtliche Programme waren in Cobol und Assembler geschrieben und im Laufe der Jahre um zahlreiche Module erweitert worden. Die Datenhaltung wurde - mit bescheidenem Erfolg - in Teilbereichen mit einer Datenbank (Sesam) durchgeführt aber da, wo es schnell gehen mußte, waren wir gezwungen ISAM zu verwenden. Unschwer vorzustellen, daß die Pflege, geschweige denn die Weiterentwicklung, dieser Software kaum sinnvoll zu realisieren war.

Nicht nur die Programmierer litten unter der Situation, auch die Anwender in den Fachabteilungen waren betroffen. Wer kennt den Zustand nicht: Um eine notwendige Auswertung von Daten zu bekommen, muß der Anwender warten, da erst ein entsprechendes Programm geschrieben werden muß.

Oder ein kleines aber typisches Problem: Bei der Einarbeitung eines Teilnehmernamens am Terminal wird die Laufweite der Schrift (Dicte) abhängig von Schrifttyp und Größe berechnet, um Satzkonflikte zu vermeiden.

Konflikte werden durch Blinken der Position angezeigt. Dabei entsteht nicht selten das Kuriosum eines blinkenden Blanks, das "zur Freude der Benutzer" außerordentlich gut sichtbar ist.

Ein trauriges Kapitel stellt wegen der Geschwätzigkeit des Mainframe-Betriebssystems auch das Operating dar. Kurz und gut: Die Summe der Hard- und Softwarerestriktionen erschwerte oder verhinderte in allen Bereichen eine sinnvolle integrative Arbeitsweise.

Der entscheidende Gesichtspunkt für uns war die durchgängige elektronische Verarbeitung der Telefonbuchdaten von der Datenhaltung bis zur Verfilmung. Das bedeutet: keine Medienbrüche, so wenig wie möglich manuelle Eingriffe und die konsistente Verifikation von Daten und Abläufen. Unsere Ziele für die 90er Jahre:

- Steigerung der Wettbewerbsfähigkeit,

- zeitgemäße und funktionsgerechte Benutzeroberflächen für die Anwender,

- hoher Integrationsgrad mit geeigneten Benutzeroberflächen,

- Reduzierung der DV-Kosten für Hardware, Software und Personal,

- gleichmäßige Know-how-Verteilung innerhalb des DV-Potentials,

- zukunftssichere Dokumentations- und Wartungsfähigkeit der Software,

- Erweiterungsmöglichkeiten in jeder Hinsicht,

- Unabhängigkeit von DV-Herstellern,

- langfristige Absicherung der Investitionen.

Die Situationsschilderung zeigt, daß wir aufgrund der festgefahrenen Anwendersoftwaresituation kaum Möglichkeiten hatten, Flexibilität und Wettbewerbsfähigkeit durch Veränderungen zu verbessern. Ende 1987 haben wir deshalb folgende Alternativen geprüft:

1. Wechsel der Hardware. Unsere einzige Möglichkeit war der Wechsel von Siemens zu IBM. Das aber würde bedeuten: "alter Wein in anderen Schläuchen".

2. Die zweite Alternative, andere am Markt verfügbare Anwendersoftware einzusetzen, erledigte sich schnell, weil keine entsprechende Software verfügbar war.

3. Software für unseren Mainframe neu zu schreiben, erschien uns wenig sinnvoll, denn wir wollten keinen "neuen Wein in alten Schläuchen".

4. Am sinnvollsten schien uns, die Software unter Verwendung von "State-of-the-art-Werkzeugen" zu schreiben und sowohl Hardware als auch Betriebssystem zu wechseln.

Bei der genauen Analyse kamen wir zu dem Ergebnis, daß der Einsatz von Unix als Betriebssystem unter Verwendung geeigneter relationaler Datenbankmanagement-Systeme (RDBMS) mit den dazugehöriger, Entwicklungswerkzeugen unter den Aspekten Zeit, Aufwand und Qualität die einzig sinnvolle Alternative darstellte. Bedenken hatten wir allerdings, was die Leistungsfähigkeit der seinerzeit (1987/88) am Markt verfügbaren Hardware anging, und zwar hinsichtlich der Geschwindigkeit und des Anschlusses ausreichend großer Platten-Peripherie.

Neuentwicklung für Unix ist deutlich billiger

Unabhängig von der hardwaremäßigen Machbarkeit haben wir jedoch klar herausgearbeitet, daß sich mit diesem Schritt für uns folgende Vorteile ergeben würden:

- Die Neuentwicklung der Software ist wesentlich weniger aufwendig als eine Neuentwicklung für den Mainframe.

- Durch den hohen Portabilitätsgrad vermeiden wir Herstellerbindung und schützen unsere Software-Investitionen.

- Hardware- und Softwaremöglichkeiten unter Unix befreien uns von bekannten Restriktionen und sichern die Schaffung angemessener komfortabler Benutzeroberflächen. - Der Einsatz von Entwicklungswerkzeugen garantiert die Wartbarkeit und Flexibilität der Software sowie einen gleichmäßigen Know-how-Stand aller Beteiligten.

- Da der Markt für Anwendungssoftware für Telefon- und Adreßbuchverlage kaum existierte sahen wir die realistische Chance, unsere neu entwickelte Software vermerkten zu können und damit den Zeitpunkt für den Return of investment zu verkürzen.

Wir waren zu diesem Zeitpunkt ziemlich sicher, daß unsere Bedenken in bezug auf die Leistungsfähigkeit der Hardware durch die rasanten Entwicklungsfortschritte der Hersteller ausgeräumt werden können. Unter diesen Gesichtspunkten haben wir dann die Unix-Möglichkeiten noch weitgehender analysiert.

Soll Unix zum Einsatz kommen, so ist die Grundvoraussetzung, daß die vorhandenen Schnittstellen, Standards und Richtlinien konsequent angewendet beziehungsweise eingehalten werden. Diese zunächst nach weiteren Restriktionen und Starrheiten klingende Formulierung wird verständlicher und Positiver, wenn man die historische Entwicklung aufzeigt.

Alle Bestrebungen internationaler Normierungs- und Fachausschüsse, wie Codasyl, ECMA etc., herstellerübergreifende Standards für die Mainframe-Welt zu schaffen, sind durch die Hersteller selbst zur Farce geworden. Jeder war verständlicherweise darum bemüht, seinen Kunden durch Schaffung eigener Software- und Hardwareschnittstellen Anreize zur Umgebung dieser Standards zu geben.

Im Gegensatz dazu sind die Unix-Standardisierungen durch die weltweite Kooperation von Benutzervereinigungen geprägt von einer außerordentlichen Sachlichkeit bestimmt. Ursache hierfür ist sicherlich die aus den Unix-Anfangszeiten herrührende liberale universitäre Praxis. Der entscheidende Unterschied ist also, daß hier Standards von Anwendern für Anwender entstanden sind und noch immer entstehen.

Für uns ergab sich daraus die eindeutige Festlegung auf Unix System V gemäß der System V Interface Definition (SVID) und den X/Open-Guidelines. Als Programmiersprache wurde ausschließlich C akzeptiert. Außerdem entschieden wir uns für den Einsatz SQL-orientierter relationaler Datenbanksysteme (RDBMS). Von dieser Linie versprachen wir uns folgende Vorteile:

1. Einfachere Entwicklung der Software unter Verwendung geeigneter Tools;

2. Entkopplung der Datenhaltung von der Anwendungslogik durch SQL/RDBMS;

3. Geräteunabhängigkeit durch genuine Kommunikationsfreudigkeit des Betriebssystems;

4. Übertragung von Aufgaben an die Fachabteilungen und damit Beseitigung starrer zentraler Strukturen, wie Batch-Betrieb und Closed shop;

5. Reduzierung des Operating-Bedarfs und Erhöhung der Sicherheit durch intelligentere Abwicklungsmechanismen;

6. Erhöhte Motivation der Mitarbeiter durch vereinfachte Lösung von Aufgaben innerhalb der DV und wesentlich komfortablere Benutzung in den Fachabteilungen.

Zur Umsetzung unserer Erkenntnisse fehlte uns jetzt "nur noch" die Entscheidung für die richtige Hardware. Vor der Systemauswahl war es zwingend erforderlich, die Entscheidung für das einzusetzende Datenbanksystem zu treffen. Hierbei waren vier Aspekte von Wichtigkeit:

1. Deckt das RDBMS die funktionalen Anforderungen ab?

2. Sind die Entwicklungsmechanismen sinnvoll, praktikabel und durchgängig?

3. Reicht die Performance in Verbindung mit der zum Einsatz kommenden Zielhardware?

4. Sind geeignete Backup- und Restore-Mechanismen verfügbar?

Wir stellten folgende Anforderungen an das Datenbanksystem:

1. Abbildbarkeit komplexester Datenstrukturen:

- Sechs Datenbanken mit insgesamt etwa 600 Tabellen,

- zirka fünf Millionen Primärdatensätze mit durchschnittlich 30 Detailsätzen,

- bis zu sechs Verkettungsebenen,

- Abspeicherung der Datenfelder in tatsächlicher Länge, also variabel,

2. Optimale Performance für ein Gesamtdatenvolumen von ungefähr elf Gigabyte Netto-Daten. Bei mindestens 50 gleichzeitigen Dialogen durften die Response-Zeiten bei maximal einer Sekunde liegen.

3. Unterstützung von Online-Backup-Mechanismen und geeigneten Möglichkeiten, Wiederanlaufzeiten von weniger als 30 Minuten zu gewährleisten.

4. Durchgängige Verfügbarkeit von Design-Werkzeugen bis zu Programmierer-Tools:

- Data Dictionary, Prüfung von Normalisierungsbedingungen und referentieller Integrität,

- objektorientierte Mechanismen bei Format und Reporterstellung,

- Datenbankdesign mit grafikunterstützter Oberfläche.

Oracle meisterte unsere Anforderungen

In Betracht kamen die Datenbanksysteme Informix, Ingres, Unify und Oracle. Alle Anforderungen wurden nur durch Oracle gemeistert. Hinzu kam der nicht unwesentliche Gesichtspunkt der Marktverbreitung und der durchgängigen, Verfügbarkeit auf allen relevanten Rechnersystemen vom PC bis zu Hochleistungsrechnern. Wesentlichen Ausschlag für unsere Entscheidung gaben die besonderen Fähigkeiten bei der Abbildung verteilter Datenbanken, die vorhandenen Backup-Mechanismen und die Performance.

Bei der Rechnerleistung wollten wir nicht vorbehaltlos den Aussagen der Anbieter folgen. Daher entschieden wir uns für eine Verifikation der Herstellerangaben durch einen Benchmark. Natürlich ist die Aussagekraft verfügbarer Standard-Benchmarks über die getesteten Systeme nur begrenzt gültig. Deshalb lohnt sich die Mühe, einen konkret auf die funktionalen und volumenmäßigen Belange der Zielanwendung zugeschnittenen Benchmark durchzuführen. Nur so lassen sich Ergebnisse mit einer hinreichenden Aussagekraft erzielen.

Die relativ einfachen Benchmarks der ersten Phase und die Einschätzung der funktionalen Kriterien führten uns zu der Entscheidung für Oracle. Bis zu diesem Zeitpunkt hatten wir jedoch noch keine Gewißheit, ob das gesamte Projekt performant genug auf der seinerzeit verfügbaren Hardware abbildbar war. Mit unserem Anwendungs-Benchmark haben wir dann folgende Systeme getestet:

- Siemens MX 500/85, 8 Prozessoren, 32 MB RAM, 1,5 GB Platten;

- UNISYS 6000/70, 6 Prozessoren, 32 MB RAM, 1,5 GB Platten;

- Hewlett-Packard HP 9000/850, 1 Prozessor, 32 MB RAM, 1,5 GB Platten.

Bei der ersten Betrachtung war besonders erstaunlich, daß der Durchsatz rechen- und I/O-intensiver (Batch-) Anwendungen extrem gute Ergebnisse auf der HP-Maschine erzielte. Die Erklärung hierfür ist beim hochleistungsfähigen RISC-Monoprozessor und den schnellen Plattenzugriffen durch Fiber Optic Link (Glasfaser) zu suchen. Bei der Betrachtung der Ergebnisse für unsere zeitkritischen und datenbankintensiven Dialoge wurden jedoch die Vorteile der Multiprozessor-Maschinen deutlich.

An dieser Stelle sei noch einmal deutlich betont, daß diese Aussagen ausschließlich auf unsere Anforderungen zu beziehen sind. Es ist durchaus möglich, daß weniger komplexe voluminöse RDBMS-Anwendungen ausreichend schnell auf Monoprozessoren abbildbar sind. An dieser Stelle des Projektes waren wir zum erstmal sicher, daß unsere Aufgabenstellung grundsätzlich mit verfügbarer Hardware plus Datenbank performant genug durchführbar ist. Entscheidend hierfür war ebenfalls die Tatsache, daß zum damaligen Zeitpunkt Oracle mit der Version 6.xx als einziger Hersteller die Vorteile von Multiprozessor-Maschinen sinnvoll unterstützte. Nun mußten wir uns zwischen den Rechnern von Siemens und Unisys entscheiden. Besonders delikat wurde die Auswahl deswegen, weil die verwendeten Systeme beide von Sequent (USA) kommen und damit bauähnlich sind.

In der ersten Annäherung zeigte sich, daß die Siemens-Systeme geringfügig leistungsstärker sind, bezogen auf die reine Hardwareleistung. Bei der Auswertung des gesamten Anwendungs-Benchmarks fiel jedoch auf, daß dieser Vorteil vollständig durch System-Overhead geschluckt wurde und damit im Gesamtergebnis die Unisys-Maschinen performanter waren.

Hinzu kommt, daß das Siemens-Unix (Sinix) ein aus unserer Sicht "unreines" Unix ist, durch die heterogene Implementierung verschiedener Unix-Universen (AT&T, Berkeley und Siemens). Dadurch ergeben sich erhebliche Nachteile für eine Straight-forward-Software-Entwicklung im Sinne eines reinen Unix System V. Das beginnt mit unterschiedlichen Device-Treibern in den verschiedenen Universen und endet bei fehlender oder inkonsequenter Implementierung von NFS (Network File System) oder

Sockets.

Der ausschlaggebende Punkt für die Unisys-Systeme lag jedoch in der wesentlich größeren Ausbaufähigkeit und Rekonfigurierbarkeit der Plattenperipherie.

Damit war es uns möglich, die Aufgabenstellung mit zwei statt mit vier Systemen zu bewältigen, wobei das zweite System ausschließlich als Batch- und Backup-System dient.

Die Zielsetzungen für das Projekt lassen sich wie folgt beschreiben:

1. konsequente Anwendung der definierten Standards, 2. durchgängige und projektbegleitende Dokumentation,

3. Ersatz der Insellösungen durch konsequente Integration,

4. stringente Ausnutzung der technischen Möglichkeiten zur Gestaltung optimaler Benutzeroberflächen,

5. Erstellung einer wartungsfreundlichen pflegeleichten und erweiterbaren Software,

6. Egalisierung des Know-how-Standes aller Beteiligten.

Geprägt durch die schlechten Erfahrungen aus der Mainframe-Vergangenheit achteten wir darauf, daß nicht nur Standards und Richtlinien konsequent eingehalten werden, sondern jeder einzelne in der Lage ist, auf möglichst der gesamten Projektbasis einen umfassenden Know-how-Stand zu haben. Im Klartext bedeutete das eine Kampfansage gegen Entwickler-Spezialistentum, das im Zweifelsfalle dazu führt, daß der erfolgreiche Ablauf einer Anwendung nur dann gewährleistet ist, wenn der betreffende Mitarbeiter auch verfügbar ist.

Um es noch einmal klar herauszustellen: Die Zielsetzung war, ein integriertes, benutzerfreundliches, durchgängig dokumentiertes und damit pflegbares Gesamtpaket zu erstellen, das als Basis für das Geschäft der 90er Jahre dienen kann.

Die gesamte Planung des Projektes wurde methodisch unter konsequenter Anwendung der Netzplantechnik aufgesetzt. Hierzu bedienten wir uns des Produktes Mac Projekt II. Der erste Schritt der Projektdurchführung war eine schonungslose Analyse der betriebsorganisatorischen und -funktionalen Abläufe. Die Ergebnisse dieser Mischung aus einer Ist- und einer Schwachstellenanalyse wurden in einem umfassenden Grobkonzept niedergeschrieben.

Im permanenten Dialog mit den Fachabteilungen wurden die Möglichkeiten der Verbesserung von Benutzeroberflächen und Abläufen ermittelt, so daß sich ein konzeptioneller Entwurf erarbeiten ließ. Dieser Entwurf wurde zusammen mit den DV-technischen Details und der Programmvorgabe, einschließlich der Layout von Datenbankstrukturen, Bildschirmformaten und Listen, in einem verbindlichen Pflichtenheft verabschiedet. Erst danach begann die eigentliche DV-technische Realisierung.

Bei Betrachtung des Gesamtumfangs von knapp 40 Mannjahren und einem vorhandenen Personalbestand von ungefähr 20 Personen ergab sich das Problem, das Projekt der Belegschaft schmackhaft zu machen. Immerhin hatte der größte Teil der DV-Stammannschaft weder Unix-, noch C-, noch Oracle-Kenntnisse, sondern das übliche Profil eines Cobol- beziehungsweise Assembler-Programmierers.

Zwei Unix-Cracks bildeten Mitarbeiter aus

Da wir natürlich unsere Mannschaft nicht komplett austauschen wollten, entschlossen wir uns dazu, das Stammpersonal zu qualifizieren. Wir begutachteten die damals verfügbaren externen Schulungsmöglichkeiten, kamen aber zu dem Entschluß, die entsprechenden Maßnahmen selbst durchzuführen. Zwei neu eingestellte Unix-Cracks, die Projektmanager Daniel Grass und Markus Hess, übernahmen diese Aufgabe.

Die Ausbildung erfolgte auf einem eigens dafür angeschafften Entwicklungsrechner, einer MX500 von Siemens, anhand eines praxisorientierten Datenbank-Fallbeispiels aus unserer Anwendung unter Verwendung der Informix-Datenbank. Nach anfänglichem Murren und Zähneknirschen der Cobol- und Assembler-orientierten Kollegen, waren die Mitarbeiter schnell überrascht und fasziniert über die Effizienz der Programmiermöglichkeiten. Die Erkenntnis, daß auch komplizierte Aufgaben wesentlich schneller und einfacher gelöst werden können als zuvor, wirkte motivierend.

Bemerkenswert ist die Tatsache, daß die Übernahme von Teilen der Fallstudie von dem Siemens-System MX500 auf die Unisys 6000/80 mit wenigen Handgriffen erledigt war - das überzeugte sämtliche Kritiker.

Positiv ausgewirkt hat sich zudem der Zeitpunkt der Ausbildungsmaßnahmen, der zwischen Abschluß der Ist-Analyse und vor Beginn der weiteren konzeptionellen Schritte lag. "Denkrillen" wurden aufgebrochen, die Mitarbeiter konnten ihre frisch erworbenen Kenntnisse direkt einbringen.