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.

16.08.1991

Auch die Menschen werden -falls möglich - re-engineered

Harry M. Sneed Geschäftsführer der SES Software-Engineering Service GmbH, München

Im Gegensatz zum allgemeinen Wunsch vieler Org./DV-Leiter, daß endlich einmal Ruhe einkehre, dreht sich das Innovationsrad der Softwaretechnologie immer schneller. Kaum ist etwas "in" - installiert, ist es schon wieder "out" - hat es ausgedient. Nichts deutet darauf hin, daß die Innovationszyklen länger werden, im Gegenteil, sie werden immer kürzer. Daraus folgt, daß der Bedarf an Migrationsstrategien - Konversion, Downsizing, Reverse- und Re-Engineering - immer größer wird.

In diesem kurzen Aufsatz werden die Ins und Outs der gegenwärtigen Softwareszene aufgelistet und auf die Bedeutung von Re-Engineering als Migrationstechnik hingewiesen.

- Out sind hierarchische und netzartige Datenbanksysteme.

- In sind zur Zeit relationale verteilte Datenbanksysteme. Am Horizont wartet schon die nächste Datenbankgeneration - objektorientierte Datenbanken.

- Out sind starre, festformatierte Bildschirmmasken.

- In sind Windows, X-Windows, MS-Windows etc.

Grafische Benutzeroberflächen setzen sich immer mehr durch. Am Horizont sind Customized User Interfaces schon erkennbar.

- Out sind Sprachen der vierten Generation.

- In sind CASE-Werkzeuge, aus denen Standard-C- beziehungsweise Cobol-Code generiert wird. Am Horizont zu sehen - formale, grafisch formulierbare Spezifikationssprachen.

- Out sind Precompiler-Werkzeuge.

- In sind Code-Generatoren. Im Kommen sind Generatoren, die sich Reusable-Module-Libraries bedienen.

- Out sind Dictionaries, die nur Datenbeschreibungen verwalten.

- In sind Repositories, die sämtliche Softwarekomponenten verwalten.

- Out sind große Mainframe-Applikationen .

- In sind kleine verteilte Anwendungen, in offenen Systemen vernetzt.

- Out sind Structured-Analysis-&-Design-Methoden.

- In sind objektorientierte Analyse- und Entwurfsmethoden.

- Out sind starre, bürokratische Phasenkonzepte.

- In sind dynamische, verteilte ergebnisorientierte Vorgehensmodelle.

- Out sind eigene Entwicklungsmannschaften, die letzten Endes viel zu hohe Kosten verursachen.

- In ist dagegen das sogenannte Outsourcing beziehungsweise die Vergabe der Software-Entwicklung und -wartung an externe Firmen.

- Out ist schließlich die ganze Generation von Software-Entwicklern aus den 70er Jahren, die sich nur mit Mainframes auskennen.

- In ist die neue "Turnschuh-Generation" von Informatikern, die in der PC- und Unix-Welt zu Hause ist.

Bei all diesen Ins und Outs darf man sich nicht wundern, daß sich die regierenden Org./DV-Leiter überfordert fühlen. Denn hierin liegt das Haupthindernis zum Fortschritt überhaupt. Die DV-Führungsschicht bei den meisten Anwenderbetrieben ist selbst out, nur sie erkennt dies nicht. Die älteren Führungskräfte stehen sich selbst im Wege. Ihre Zeit ist abgelaufen, sie haben ihren Dienst geleistet; jetzt wäre es angebracht, wenn sie zurücktreten würden. Das Gebot der Stunde ist ein genereller Generationswechsel. Generationswechsel bedeutet einen Übergang von einem Paradigma zum anderen beziehungsweise eine Migration. Die Daten müssen aus der hierarchischen in die relationale Datenbank überführt werden. Der Inhalt der Benutzeroberflächen muß anders aufbereitet werden. Sprachen der vierten Generation sind in CASE-Spezifikationssprachen zu transformieren. Precompiler-Sprachen sind durch Code-Generatoren abzulösen.

Der Inhalt der Dictionary-Systeme muß in die Repository-Systeme versetzt werden. Große Mainframe-Applikationen sind durch "Downsizing" auf mehrere kleine Systeme zu verteilen. Funktions- beziehungsweise prozeduralorientierte Software-Architekturen müssen objektorientierten Architekturen weichen. Phasenkonzepthandbücher sind rauszuschmeißen und durch neue flexible Richtlinienhefte zu ersetzen. Schließlich muß eine neue Generation von Software-Entwicklern die alte ablösen. Am besten, man schickt die Altentwickler zurück in die Fachabteilungen, woher viele ursprünglich gekommen sind. Dort kennen Sie sich bestens aus.

Bei all diesen Änderungen handelt es sich um Re-Engineering. Im einen Fall werden die Daten, im anderen Fall die Benutzerschnittstellen, im dritten Fall die Programme, im vierten Fall die Systemarchitektur reengineered. Auch die Menschen werden - falls möglich - reengineered, um anders zu denken. Re-Engineering ist deshalb zweifelsohne eine Schlüsseltechnologie unserer schnellebigen Zeit und verdient viel mehr Aufmerksamkeit, als sie bisher genossen hat. Nur eines kann sie nicht - und das ist, die Zielumgebung eines Unternehmens bestimmen.

Die DV-Führungskräfte müssen selbst erkennen, wo es lang geht und dementsprechende Entscheidungen fällen. Denn ohne klar definierte Zielumgebung ist jede Transition eine Fahrt ins Blaue. Wer den Bestimmungsort nicht kennt, wird dort niemals ankommen.