Halls H. Matthies ist Berater bei James Martin Associates

Um die Einführung sogenannter Software-Entwicklungsumgebungen kommt heute kaum ein innovatives Unternehmen herum. Allerdings, so zeigt Hans H. Matthies* in seinem Beitrag, gibt es unterschiedliche Wege: Den einen reichen organisatorische Veränderungen, andere setzen auf die Teilautomatisierung ihrer Entwicklungsaktivitäten und bedient sich dabei verschiedener CASE-Werkzeuge. Der dritte Weg ist die Installation vollintegrierter Entwicklungsumgebungen.

Für Unternehmen, die aufgrund vorhandener Investitionen in eine SEU die Strategie eines "evolutionären" Auf- und Umbaus ihrer Anwendungsentwicklungs-Umgebung verfolgen, besteht das Problem, daß sie sich dadurch von den durch Technologiesprünge erzielbaren Effekten ausschließen.

Ein Weg aus diesem Dilemma kann durch eine zeitweise Parallelität zweier Ansätze gegeben sein: Zum einen wird die vorhandene SEU, so weit möglich, schrittweise mit einem offenen Rahmenkonzept verbunden und weiterentwickelt, zum anderen wird für die Entwicklung von Neusystemen eine zunächst eigenständige hochintegrierte SEU "von der Stange" gekauft und sofort produktiv eingesetzt.

Neusysteme werden künftig zunehmend auf relationalen Datenbanksystemen basiert sein. Im Bereich der IBM-Welt bedeutet dies vielfach die Ausrichtung auf DB2 oder Oracle. Eine die Entwicklung neuer Systeme unterstützende SEU sollte auf entsprechende relationale Datenbanksysteme spezialisiert sein.

"Einmal entwickeln, überall anwenden"

Als Zusatzeffekt wird durch die temporäre Einführung zweier SEU-Ansätze in einem Unternehmen eine erhebliche Sicherheit gegenüber einseitigen Abhängigkeiten von einem Anbieter erzielt. Dies gilt sowohl hinsichtlich der Entwicklungslinien- und -Geschwindigkeiten als auch bezüglich der Leistungsfähigkeit der Produkte.

Gegen die Verzögerung angekündigter Produkte und deren

etwaige Unzulänglichkeiten werden Sicherheiten erworben. Durch die bewußte Förderung einer teilweisen Konkurrenz der SEU-Ansätze läßt sich zudem sicherstellen, daß stets die dem jeweiligen Stand entsprechende beste SEU verfügbar ist.

Im Verlaufe fortschreitender Entwicklung könnte sich herausstellen, daß eines der verfolgten SEU-Konzepte aufzugeben ist. Dies könnte beispielsweise dann der Fall sein, wenn ein Konzept vom anderen infolge einer fortschreitenden Redundanz "aufgesogen" wird. Die Möglichkeit eines gleitenden Übergangs zu der dominierenden SEU ist jederzeit gegeben, wenn für die entscheidenden Komponenten beider Software-Entwicklungsumgebungen Kompatibilität vorgesehen ist.

Schließlich ist davon auszugehen, daß die Leistungsfähigkeit einer schlüsselfertigen SEU erheblich schneller wächst als diejenige einer unternehmensintern aufzubauenden. Insofern könnte hier möglicherweise ein ungleiches Rennen vorliegen.

Ein gewisser Chancenausgleich wäre dadurch zu erwirken, daß Erkenntnisse aus der weitentwickelten SEU zur hausinternen Eigenentwicklung transferiert werden würden. Ein umgekehrtes Vorgehen ist relativ unwahrscheinlich.

Die Portabilität von Anwendungen erlaubt, einmal entwickelte Anwendungen in verschiedene Zielumgebungen transferieten zu können. Einmal entwickeln, überall anwenden - so lautet das Schlagwort. Investitionen in Anwendungssysteme werden durch deren Portabilität abgesichert. Software- wie Hardware-Anbieter erhalten durch portable Anwendungen eine größere Marktbasis.

Anwendungssysteme sollten portabel sein

Die Portabilität von Anwendungen kann auf einer sehr niedrigen Ebene durch standardisierte Codierung in portablen Programmiersprachen sichergestellt werden. Ferner ist Portabilität heute punktuell innerhalb von Betriebssystem-Familien wie zum Beispiel Unix und innerhalb aufwärtskompatibler Rechnerfamilien wie der DEC, VAX-Welt gegeben.

Die zuvor genannten Portabilitätstypen haben Nachteile. Der Aufwand zur Erstellung und Wartung Programmier-sprachen-basierter Anwendungen ist gegenüber der vergleichsweise geringen Mächtigkeit solcher Programme sehr hoch. Innerhalb von Systemfamilien sind portable Programme stets nur in den dort vorgegebenen Grenzen verschiebbar.

Wünschenswert ist eine Portabilität, die über die Grenzen von Systemfamilien hinausgeht und die auf einem Spezifikationsmechanismus von hoher Mächtigkeit basiert. Solche portablen Anwendungsysteme werden einen Meilenstein in der Geschichte der automatisierten Informationsverarbeitung darstellen.

Portable Anwendungen, die als Modelle auf der Basis eines CASE-Systems erfaßt sind, können diese Anforderungen erfüllen. Die Eigenschaft der Portabilität kann damit als wichtiges Merkmal einer offenen, CASE-basierten SEU gelten. Die Offenheit besteht darin, daß die Produkte einer solchen SEU nicht auf eine dedizierte Zielumgebung festgelegt sind.

Offenheit bedeutet hier Unabhängigkeit hinsichtlich der Auswahl von Zielumgebungen. Dazu ein triviales Beispiel: Einmal erfaßte und formatierte Texte können heute unter Verwendung unterschiedlicher Druckertreiber auf verschiedensten Druckern identisch ausgegeben werden. Analog hierzu werden portable, CASE-basierte Modelle von Anwendungen nach dem Durchlaufen unterschiedlicher "Zielumgebungs-Treiber" in identischer, wenn gewünscht auch in angepaßter Weise in diesen Zielumgebungen ablauffähig sein.

Als Zielvorstellung werden hier - im Gegensatz zu vielen gegenwärtigen Branchenmodellen - vollständige Anwendungssystem-Modelle einschließlich aller Komponenten gesehen. Sollen solche Modelle unmodifiziert als Standardmodelle zur Anwendung kommen, so können sie vollautomatisch in komplette, lauffähige Applikationen umgesetzt werden.

Innerhalb der Systemarchitektur eines Unternehmens könnten beispielsweise Transfers von Anwendungs-Modellen aus IBM- in DEC-Zielumgebungen oder umgekehrt von Interesse sein. Koexistenzen dieser beiden Zielumgebungen finden sich in vielen Produktionsunternehmen.

Weitere Ansätze wären im Falle einer zukünftigen Restrukturierung der Unternehmens-Systemarchitektur dadurch gegeben, daß portable Anwendungen mit wirtschaftlich vertretbarem Aufwand zwischen unterschiedlichen Zielumgebungen verlagert werden könnten. Technisch bedingte Abschreibungen von Anwendungen können künftig fortfallen.

Durch die Portabilität von Anwendungen wird eine wesentliche Voraussetzung für das "Change Management", das heißt für die permanente Anpassung informationstechnischer Systemkomponenten an den Stand der Technik, gewährleistet. Umstellungen bei einem Wechsel des Rechnermodells werden viel von ihrem heutigen Schrecken verlieren.

Wenige CASE-Tools tragen heute der strategischen Bedeutung der Portabilität von Anwendungssystemen in unterschiedlichste Zielumgebungen Rechnung. Portabilität sollte sich jedoch nicht nur auf Anwendungen, sondern auch auf solche Software-Entwicklungsumgebungen und angebundene CASE-Tools erstrecken, die den Anwendungen als Entwicklungsplattformen zugrunde liegen. Ein Idealzustand wird aus Anwendersicht dann gegeben sein wenn ein CASE-Hersteller seine Entwicklungsplattform für unterschiedliche Trägersysteme bereitstellt.

Ein wesentlicher Aspekt bei der Definition einer neuen Systementwicklungs-Strategie besteht darin, daß heute kein Unternehmen mehr Systeme "auf die grüne Wiese" stellt. Berücksichtigt man, daß Investitionen in bestehende Software-Entwicklungssysteme und in die damit erzeugten Produkte zu schützen sind, so sollte eine Systementwicklungs-Strategie nach Möglichkeit auch auf den Bestandsschutz ausgerichtet sein.

Neuanschaffung ist besser als Nachrüstung

Einschnitte, das heißt eine generelle Abschreibung bestehender Entwicklungssystem-Komponenten oder deren Nichtanwendung für die Entwicklung bestimmter neuer Systeme, können unter Umständen dennoch sinnvoll sein - beispielsweise bei Überalterung einer Entwicklungsumgebung. Präferenzen für Abschreibungen sind auch dann gegeben, wenn ein Unternehmen Anwendungen - also Softwareprodukte - für neue Zielumgebungen produziert. Wie in industriellen Bereichen ist es dabei oft sinnvoll, zur Herstellung neuer Produkte auch neue, effizientere Produktionsanlagen zu verwenden.

Entsprechend sind Investitionen in neue "Software-Produktionsanlagen" erheblich sicherer als in die Nachrüstung von alten - sofern die richtigen Anlagen beschafft werden. Wer ein technologisch fahrendes entwicklungsfähiges CASE-Tool einsetzt, kann sicher sein, für die unternehmensinterne Software-Entwicklung eine langfristig tragfähige Basis gelegt zu haben.

Investitionssicherungs-Aspekte sind ferner durch die Macht des SEU/CASE-Anbieters, die Stellung seiner Produkte innerhalb der zu erwartenden Entwicklungslinie der CASE-Technologie sowie in aktuellen wie künftig zu erwartenden Marktanteilen gegeben.

Die Einführung einer CASE-basierten SEU unterliegt den gleichen Gesetzmäßigkeiten, die auch für andere Fälle der "Einführung neuer Technologien" gegeben sind. Viele Unternehmen haben innerhalb der letzten zehn Jahre Erfahrungen bei der Einführung neuer Technologien sammeln können. Dabei mußte nicht selten viel Lehrgeld gezahlt werden. Als ein weithin bekanntes Beispiel sei die Einführung von CAD-Systemen in Produktionsunternehmen genannt.

Know-how-Transfer Ist relativ selten

Zur CASE-Einführung müßten im Idealfall vorhandene Erfahrungen einfach transferiert werden. In der Praxis wird dies meistens daran scheitern, daß die betreffenden Technologieprojekte in den unterschiedlichsten Unternehmensbereichen angesiedelt waren. Die Erfahrungen wurden weder aufgezeichnet noch auf ihre allgemeingültigen Regeln und Faktoren reduziert. Ein innerbetrieblicher Know-how-Transfer zur CASE-Einführung wird daher nur selten realisierbar sein.

Möglicherweise wird die Wiederverwendung von Know-how aus früheren Technologieprojekten an der Erkenntnis scheitern, daß die Einführung neuer Technologien ohne erfahrene, professionelle Begleitung unwirtschaftlich ist.

Ein professioneller Begleiter sollte mehrjährige Erfahrungen in der entsprechenden Disziplin vorweisen können. Idealerweise sind diese Erfahrungen mit einem erprobten Vorgehensmodell verbunden, welches die Technologieeinführung als Leitlinie unterstützt und flexibel auf die internen Gegebenheiten anpaßbar ist. Kritische Faktoren werden dadurch bereits im Planungsstadium erkannt und eliminiert. Im Ergebnis wird eine maßgeschneiderte CASE-Einführung hoher Effizienz erreicht. Ausbildungsleistungen runden das Gesamtpaket ab.

Ein weitgehend automatisiertes, "durchgängiges" CASE-Tool wird die Notwendigkeit um fangreicher Zielumgebungs-Kenntnisse (Betriebssysteme, Datenbanken und so weiter) der Entwickler reduzieren, indem es zielumgebungsspezifische Elemente generiert. Zu denken ist hier zum Beispiel an Job-Control-Anweisungen zur Ausführung notwendiger Funktionen oder an die Generierung von DDL-Anweisungen. Unter diesem Aspekt kann ein CASE-Tool als "Katalysator" wirken, indem es Anwendern zum Beispiel den Übergang von heutigen auf relationale Datenbanksysteme erleichtert.

CASE-basierte Software-Entwicklungsumgebungen sind in der Regel sehr komplexe Systeme. Zu ihrer effizienten Handhabung ist hochwertiges Know-how in einer möglichst effektiven Form aufzubauen und verfügbar zu halten. Entsprechende produktergänzende Leistungen eines CASE-Anbieters unterstützen die Anwendungseffizienz von Anfang an nachhaltig. Sie stellen daher eine absolute Muß-Forderung beziehungsweise ein KO-Kriterium dar.

- Wie eingangs ausgeführt, sollte die CASE-Vision, also die SEU der Zukunft, als Meßlatte zur Evaluation von CASE und den damit verbundenen Entwicklungsumgebungen zur Anwendung kommen. Eine ausführliche Betrachtung wäre hier zu umfangreich, sie beschränkt sich daher auf einige wesentliche Punkte.

Eine zukunftsorientierte SEU wird nach heutigen Erkenntnissen hinsichtlich Architektur und Komponenten etwa folgende Eigenschaften aufweisen:

- Unterstützung des vollständigen Software-Lebenszyklus,

- Unterstützung und Koordination arbeitsteiliger Entwicklungen,

- Projektmanagement-Funktionen,

- Datenmodellierung nach dem Entity-Relationship-Modell,

- Zentraler Speicher für alle Informationen,

- Aufgabenverteilung auf Workstation (dezentral) und Mainframe (zentral),

- Workstation-basierte Tool-sets.

Bereits ein Abgleich dieser sehr groben und unvollständigen Anforderungsliste mit den Merkmalen heute verfügbarer CASE-Tools reduziert das Spektrum der zu evaluierenden Werkzeuge erheblich. Es gibt heute wenige umfassendere SEU/CASE-Realisierungen mit den vorstehenden Merkmalen, die als praxisanwendbare, erprobte Produkte verfügbar sind.

Produkte, die nachgewiesenermaßen über eine solche tragfähige Basiskonzeption verfügen, werden ihren heutigen technologischen Vorsprung nicht nur halten, sondern sehr schnell weiter ausgebauen können - sie sind eben "state-of-the-art". Entspricht eine Entwicklungsumgebung diesen Merkmalen auch nur im Ansatz, so lassen sich mit ihr Know-how und Organisationsstrukturen aufbauen, bevor allumfassende Rahmenkonzepte und deren Realisierungen in adäquater Form verfügbar sind.

Ein entsprechend dem absehbaren Stand der Technik aufgebautes Know-how und nicht zuletzt die abzuleitenden Organisationsstrukturen werden dort, wo dies gewünscht wird, in großen Teilen direkt auf entsprechende zukünftige Software-Entwicklungsumgebungen übertragbar sein. Dem Ziel "Zeitwettbewerb gewinnen" wird dadurch nachhaltig entsprochen.

CASE-basierte Modelle werden häufiger angeboten

Ein kritischer Punkt bei der Betrachtung von Software-Entwicklungsumgebungen ist häufig deren offene beziehungsweise geschlossene Konzeption. Dieses Architektur-Merkmal korrespondiert direkt mit dem Merkmal "Integrationsgrad". Hochintegrierte, CASE-basierte Entwicklungsumgebungen erscheinen heute aufgrund ihrer umfassenden Funktionalität in ihrer Gesamtheit zunächst als relativ geschlossene Systeme. Das ist auch gut so, denn nur so kommt es nicht zu Brüchen, die infolge von Schnittstellen zwischen einzelnen Toolsets entstehen könnten.

Nicht vorhandene Schnittstellen können auch nicht produktivitätsmindernd wirken, was wiederum eine Voraussetzung für die mit dem CASE-Tool angestrebte Produktivitätssteigerung ist. Davon unabhängig muß eine Entwicklungsumgebung selbstverständlich Imund Exportschnittstellen zum Informationsaustausch mit anderen Systemen aufweisen.

Relativ "geschlossen" im gegenwärtigen Zustand sind ferner die Schnittstellen zwischen einzelnen Toolsets und zentralen Datenspeichern von CASE-Tools. Offenheit an dieser Stelle wäre für die Anwender heute praktisch wertlos, denn welches "normierte" Repository sollte im gegenwärtigen Stand der Technik diese Offenheit nutzen und an die Stelle eines gegenwärtig einsetzbaren, spezifischen treten?

Eine derartige Anforderung ist erst dann sinnvoll beziehungsweise praktisch nutzbar, wenn die Funktion eines Repository infolge der technischen Entwicklung und der Konstituierung eines Industriestandards marktbreit durch entsprechende Produkte abgedeckt werden würde. Sollte zum Beispiel das Repository des AD/Cycle einen solchen Industriestandard etablieren wie zum Beispiel der IBM PC, so wird kaum ein überlebenswilliger SEU/CASE-Hersteller auf die Kompatibilitätseigenschaften seiner Produkte verzichten können.

Denkbar wäre auch, daß marktgängige Repositories aufgrund der Vollständigkeit ihrer Metamodell-Definitionen zukünftig zum industriestandard avancieren oder einen solchen Standard mitgestalten. Insbesondere sind hier solche Repositories zu sehen, die auch den Bereich der (Programm-) Logikdefinition abdecken, dieses Merkmal weisen gegenwärtig nur wenige Repositories auf.

Eine Voraussetzung für die Integration der Funktionalität wird durch die künftige Austauschbarkeit von zentralen Datenspeichern gegen die entsprechenden Komponenten eines künftigen "Standard"-Speichers gegeben sein. Als ideal erscheint nach heutigem Stand der Technik eine SEU, deren Funktionalität bezüglich ihres Verwendungszweckes vollständig ist, mit deren Hilfe postulierte Produktivitätsziele erreichbar sind und deren Datenspeicher zu künftigen Standards absehbar kompatibel sein wird.

Begleitet werden sollte dies durch ausgefeilte Anwendungskonzepte. Integraler Bestandteil solcher Konzeptionen könnte die Nutzbarmachung sinnvoller Synergie-Effekte sein. Dies kann beispielsweise durch die Vermarktung werkzeugbasierter "Standard"-Anwendungssystem. Modelle geschehen. Erste Aktivitäten dieser Art sind bereits zu beobachten. Im Zuge einer sich verbreitenden CASE-Anwendung wird die Verfügbarkeit CASE-basierter Modelle explosionsartig zunehmen.

Im Verbund aller komplementären Leistungskomponenten wird eine CASE-basierte SEU hinsichtlich ihrer Gesamteffizienz optimiert. Dies bezieht sich auf alle Einsatzphasen. Die "Effizienz-Ziellinie" sollte durch die permanente, systematische Weiterentwicklung aller Komponenten zügig nach vorne verlegt werden.

Infolge sorgfältig organisierter Rückkopplungs-Effekte der über mehrere Jahre hinweg gewonnenen Praxiserfahrungen kann eine einzigartige Wissensbasis zur Automatisierung der Anwendungsentwicklung entstehen. Die Organisation solcher Rückkopplungs-Effekte kann zweistufig durch den CASE-Anbieter und durch anwendende Unternehmen vorgenommen werden.

Das hier dargelegte Gedankenmodell, so läßt sich zusammenfassend sagen, muß selbstverständlich durch eine Reihe von Detail-Betrachtungen zu den konkreten Anforderungen eines Unternehmens in Beziehung gesetzt und bestätigt werden. Jede noch so detaillierte Betrachtung beruht, selbst wenn sie sinnvollerweise durch Wirtschaftlichkeitsberechnungen gestützt wird, auf einer großen Zahl nicht quantifizierbarer Annahmen.

Die Entscheidung für eine CASE-basierte SEU fällt klar in die Kategorie des Einsatzes neuer Technologien. Die Mehrheit heute noch existierender Unternehmen haben "Prozesse des Einsatzes neuer Technologien" in ihrer Vergangenheit erfolgreich durchgeführt. Sie sollten sich ihrer dort gemachten Erfahrungen erinnern. Jede Entscheidung zu CASE kann angesichts ihrer Bedeutung und Tragweite nur eine unternehmerische sein. Sie sollte sich nicht ausschließlich auf technische Erwägungen stützen. Eine Gesamtsicht ist notwendig.