Schon die Hinweise auf Produktivitätssteigerungen durch wiederverwendbare Komponenten klingen wie die Werbung von Anlageberatern. Eine Verdoppelung der Produktivität sei drin. Und ganz en passant würde durch immer wieder erprobte Komponenten auch die Qualität der Software steigen. Auf Anhieb verwendbar - und pünktlich beim Anwender, was ja auch eher selten ist.
Jedoch wäre auch ein Szenario denkbar, das dem Alltag in den Rechenzentren eher entspricht. Dort besteht nämlich allzu häufig kaum mehr ein umfassendes Wissen, welche Software in welchem Ausmaß wozu genutzt wird. Erste Voraussetzung für die Verwendung von Komponenten wäre also ein präziser Überblick über die Bestände - unter dem Begriff Repository seit Jahren bekannt, aber nie perfekt entwickelt. Zuviel Chaos?
Auch die Modelle wiederverwenden
Ein noch wichtigerer Punkt aber ist die Organisation der Wiederverwendung. Je früher diese einsetzt, desto mehr nützt sie. Diesen Aspekt bringt Martin Bertram, Senior-Berater bei der Debis- Tochter Diebold, auf den Punkt: "Die Hebelwirkung der Wiederverwendung ist um so höher, je früher die Komponente im Entwicklungsprozeß genutzt werden kann. Die Wiederverwendung von Modellen ist effektiver als die Wiederverwendung spezifischer Programmcodes."
Ergo kann es durchaus ökonomischer sein, noch eine Komponente zusätzlich von Grund auf neu zu schreiben, wenn sich wegen schlechter Organisation der benötigte Softwarebaustein nur mit erheblichem Aufwand finden läßt. Eine gute Bestandsverwaltung ist die Grundvoraussetzung. Wenn diese erfüllt ist, muß eine an Wiederverwendbarkeit orientierte Entwicklungsweise firmenoffiziell vorgeschrieben werden.
Doch werden Verordnungen nichts nützen, wenn sie zu eng gefaßt sind. Das Optimum aus vielfacher Verwendbarkeit und Nutzen ist nicht auf Anhieb auszubalancieren. Bertram erläutert dies so: "Hohe Spezialisierung bedeutet hohen Nutzen je Anwendung, aber niedrigen Wiederverwendungsfaktor, hohe Allgemeingültigkeit dagegen niedrigen Nutzen je Anwendung, aber höheren Wiederverwendungsfaktor."
Eine penible Dokumentation ist von elementarer Bedeutung. Schriftliche Festlegungen sind schon bei den ersten Schritten zur Componentware unerläßlich. Wer sich Unaufmerksamkeiten oder vage Festlegungen hinsichtlich der Kompatibilität der Methoden, Schnittstellen oder Protokolle erlaubt, hat schon verloren. Eine Architektur so zu konzipieren, daß sie Probleme der Umsetzung überlebt, ist nicht einfach
Dafür ist es laut Bertram nötig, einen Imperativ aufzustellen: "Wir erfinden das Rad nur einmal!" Dieses Leitmotto müsse als "Firmenphilosophie" durchgesetzt und gegen alle Widerstände aufrechterhalten werden. Und die sind ziemlich wahrscheinlich. Viele DV-Spezialisten befürchten nämlich, im Unternehmen überflüssig zu werden und ihre Jobs zu verlieren, wenn einmal geschriebene Komponenten immer wieder genutzt werden können. Gravierend werden solche Ängste dann, wenn es um den Einsatz von Fremdkomponenten geht.
*Luque Flaco-Korte ist freier Journalist in München.