Betriebswirtschaftliche Anwendungsfelder Zunächst sollen die betriebswirtschaftlichen Anwendungsfelder betrachtet werden: Die beiden bekannten Autoren Hammer und Champy dokumentieren in ihrem Buch „Reengineering the Corporation“ den Zusammenhang zwischen Entwicklungen der Informationstechnologie und wirtschaftlichen Veränderungen Anfang der neunziger Jahre (des zwanzigsten Jahrhunderts). Sie stellen dazu zahlreiche Beispiele vor, wie Neuerungen der Informationstechnologie zu organisatorischen Veränderungen in Unternehmen führen. Als konzeptionelle Basis für diese organisatorischen Veränderungen entwickelten sie das Konzept des „Business Reengineering“. An dieser Stelle sind nicht die Details dieses Konzepts von Interesse. Gegenstand der nachfolgenden Betrachtungen ist vielmehr die Frage nach den Schlußfolgerungen, die sich für die Gestaltung von Softwaresysteme unmittelbar aus diesem Konzept ableiten lassen. Von diesen Schlußfolgerungen wird wiederum nur der Teil betrachtet, der einen Bezug zur komponentenbasierten Reorganisation hat. Die erste zentrale Schlußfolgerung des „Business Reengineering“ betrifft die Tatsache, daß sich organisatorische Strukturen des Unternehmens häufig auch in den Softwaresystemen widerspiegeln. Wie sich beobachten läßt, orientieren sich die Bedürfnisse der Kunden nicht immer an den Organisationsstrukturen der Unternehmen. Vielmehr müssen die Organisationsstrukturen den Kundenanforderungen gemäß optimiert werden. Dieser Wandel muß sich dann auch in den Strukturen der Informationssysteme vollziehen.[4] Beispielsweise findet sich im Bereich der Finanzdienstleister (Banken, Versicherungen) häufig eine Unterteilung in Organisationseinheiten gemäß der Struktur der angebotenen Produkte. In Versicherungsunternehmen können die Sparten Lebensversicherung, Gebäudeversicherung und Kraftfahrzeugversicherung existieren. Dann gibt es bestimmte Programme (oder Unterprogramme), mit denen jeweils die Produkte einer dieser Sparten definiert und vertrieben werden können. Ein Programm A dient dann beispielsweise zur Beratung und zum Vertrieb von Lebensversicherungen, Programm B realisiert diese Funktionalität für Gebäudeversicherungen und für Kraftfahrzeugversicherungen existiert ein drittes Programm C. Die Spartenorientierung des Unternehmens spiegelt sich in den Softwaresystemen wider. Natürlich ist es schwierig, aufgrund der organisatorischen und technischen Gegebenheiten neue Produkte anzubieten, die aus vorhandenen Produkten mehrerer Sparten zusammengefügt sind. Insbesondere gibt es keine Möglichkeit, die Trennung der Programme A, B und C aufzuheben, um spartenübergreifende Produkte anbieten zu können. Da die Anforderungen von Kunden nicht starr sind, sondern sich mit der Zeit weiterentwickeln, wird eine Struktur der Softwaresysteme benötigt, die gegenüber Veränderungen in der Organisationsstruktur eines Unternehmens und gegenüber veränderten Kundenwünschen tolerant ist. An dieser Stelle wird deutlich, daß eine vollständige Neuentwicklung der Softwaresysteme kein realistischer Weg zur Lösung dieses Problems ist. Da die Kundenanforderungen einer stetigen Weiterentwicklung unterliegen, würde eine wiederholte Neuentwicklung notwendig werden. Die damit verbundenen Kosten und das Projektrisiko lassen die Neuentwicklung als Alternative ausscheiden. Daher sind weitaus flexiblere Strukturen gefordert, die es ermöglichen, auf veränderte Organisationsstrukturen und Kundenanforderungen nachträglich noch flexibel reagieren zu können. Die zweite wesentliche Schlußfolgerung, die sich aus dem Konzept des Business Reengineering ergibt, ist die Forderung nach einer schnellen, kostengünstigen an den Bedürfnissen der Anwender orientierten Entwicklung von Informationssystemen für die (sich ständig verändernden) Organisationsstrukturen. Diese Anforderung ist jedoch nicht neu – im Gegenteil: Der Begriff der Softwarekrise, der in den sechziger Jahren des vergangenen Jahrhunderts geprägt wurde, thematisiert ebenfalls diese Problemstellung. Die Entwicklung von Softwaresystemen hat nach Ansicht von Hammer und Champy nun eine neue Qualität erreicht. Beispielsweise ist die Möglichkeit, eine neue Technologie zu nutzen, bevor es ein anderer tut, heute entscheidend für den wirtschaftlichen Erfolg des Unternehmens. Es wurde bereits darauf hingewiesen, daß eine Neuentwicklung von Softwaresystemen mit einem Risiko verbunden ist. Das Risiko resultiert aus der Unsicherheit, ob das System zum benötigten Zeitpunkt und zu den vorhergesagten Kosten fertiggestellt werden kann. Außerdem unterliegen auch die Benutzeranforderungen einer Unschärfe, was sich ebenfalls auf das Risiko auswirkt. Insgesamt ist die (wiederholte) Neuentwicklung von Softwaresystemen, um damit die Möglichkeiten einer neuen Technologie voll ausnutzen zu können, keine optimale Lösung. Sowohl die erste Anforderung, daß eine Struktur benötigt wird, die flexibel genug ist, um ständigen organisatorischen Veränderungen angepaßt zu werden, als auch die zweite Forderung nach einer neuen Form der Entwicklung von Softwaresystemen, sind zwei Seiten eines Problems, dessen Lösung aktuell in der komponentenbasierten Softwareentwicklung gesehen wird. Ziel bei dieser Form der Softwareentwicklung ist es, Softwarebausteine – sogenannte Komponenten – zu erstellen. Diese Komponenten können gemeinsam mit anderen Komponenten zu einem Softwaresystem zusammengefügt werden. Das Zusammenfügen gestaltet sich beispielsweise so, daß eine bestimmte Komponente ausgewählt und per Drag&Drop mit anderen Komponenten verbunden wird. Damit handelt es sich weniger um ein Programmieren im eigentlichen Sinne, als vielmehr um ein „Komponieren“.[5] Allerdings muß bei der komponentenbasierten Softwareentwicklung der folgende Zusammenhang beachtet werden: Um die komponentenbasierte Entwicklung einführen zu können, müssen bereits ausreichend Komponenten vorhanden sein (z.B. durch Eigenentwicklung oder Zukauf), aus denen die neuen Anwendungen erstellt werden. Jedoch ist diese Situation, insbesondere zu Beginn der Einführung der komponentenbasierten Entwicklung in einem Unternehmen, nicht unbedingt gegeben. Häufiger ist es der Fall, daß Komponenten nicht in ausreichender Anzahl existieren. Dann muß zunächst mit ihrer Entwicklung begonnen werden. Dazu können diese vollständig neu entwickelt werden. Häufig wird dabei auch Anwendungsfunktionalität in Form von Komponenten neu entwickelt, die bereits in existierenden Anwendungssystemen realisiert wurde. Dies käme jedoch einer (zumindest teilweisen) Neuentwicklung bestehender Anwendungen gleich. Damit gelten auch für dieses Vorgehen die Aussagen, die oben in Bezug auf die Neuentwicklung getroffen wurden.  Folglich scheidet es als sinnvolle Alternative aus. Zur Lösung dieses Problems bedarf es einer Strategie, die aufzeigt, wie die Abhängigkeit zwischen dem Vorhandensein einer ausreichenden Anzahl an Komponenten und der komponentenbasierten Entwicklung aufgelöst werden kann. Die Lösung liegt darin, daß bereits existierende Anwendungen nachträglich in Komponenten zerlegt werden. So entsteht eine hinreichende Auswahl an Komponenten, so daß mit der komponentenbasierten Entwicklung begonnen werden kann, ohne daß die Risiken einer vollständigen oder teilweisen Neuentwicklung in Kauf genommen werden müssen. Die komponentenbasierte Reorganisation bietet eine Lösung des Problems an, indem vorhandene Softwaresysteme nachträglich in Softwarebausteine (und Teildatenbanken) zerlegt werden, die als Komponenten in anderen Anwendungen wiederverwendet werden können. Um die für den Übergang zur komponentenbasierten Entwicklung benötigte Auswahl an Komponenten zu erhalten, ist (fast) kein Aufwand für Neuentwicklung notwendig. Dadurch können vorhandene Investitionen gesichert und das Projektrisiko minimiert werden. [4] vgl. [Noak, 1998], S. 1602 [5] vgl. [Griffel, 1998], S. 23 [6] vgl. [Hammer&Champy, 1994]