Modularisierung auf den zweiten Blick

Eschborn, 07.03.2016

Modularisierung gilt – völlig zurecht – als ein wichtiges Prinzip beim Erstellen hochwertiger Software. Wie fast immer im Leben haben die erhofften Vorteile jedoch ihren Preis. Dieser Preis kann sehr unterschiedlich ausfallen, abhängig davon wie geschickt und angemessen das Prinzip Modularisierung eingesetzt wird. Daher sollte es eigentlich selbstverständlich sein, dass Projekte auch in dieser Hinsicht einer regelmäßigen Kosten-Nutzen-Analyse unterworfen werden. Überraschenderweise finden sich jedoch kaum Quellen und Belege  für derartige Untersuchungen. Das steht im krassen Gegensatz zu der Fülle an Beiträgen, die die Vorteile der Modularisierung in fast jeder Hinsicht zu belegen versuchen.

Eine Gruppe von Forschern des Fraunhofer-Instituts für Experimentelles Software Engineering (IESE) in Kaiserslautern hat in einer teilweise durch das Bundesforschungsministerium geförderten Studie versucht, diesem Missstand abzuhelfen. Dazu wurden verschiedene Modularisierungsprojekte aus industriellen Partnerunternehmen systematisch analysiert. Die Ergebnisse finden sich kurz und prägnant zusammengefasst in [1]. Obwohl die präsentierten Erkenntnisse nicht sehr überraschend sind, sollen die wichtigsten Punkte im Folgenden zitiert werden. Dass das nicht überflüssig ist, beweist die Studie, laut der Modularisierung häufig als „Silver bullet" gesehen wird, wenn es darum geht, unwartbar gewordene Systeme zu rekonstruieren. Die zusammenfassende Schlussfolgerung lautet dann auch: Examples …  support a truism too often ignored by architects: everything has its price, and more often than not, the price for modularity is a lot higher than initially estimated.

Das sollte jedoch nicht missverstanden werden. Damit wird nichts über Modularisierung als solche gesagt, sondern ist vielmehr eine Aussage über falsche, schlecht vorbereitete oder leichtfertige Anwendung. Wie bei jeder mächtigen Methode ist es sehr viel leichter, etwas falsch zu machen, als sie optimal anzuwenden.

Da die positiven Potentiale hinreichend bekannt sind, sollen hier vor allem die häufig beobachteten Fehler dargestellt werden. Wenn man will, lässt sich daraus eine Checkliste der zu vermeidenden Fallen zusammenstellen.

Häufig gefundene Fehler

Eine überambitionierte Zielstellung

Nicht alle Probleme lassen sich durch Modularisierung lösen oder vermeiden. Man sollte sich vor unrealistischen Versprechungen hüten, weil sonst leicht der Eindruck entstehen kann, dass die Modularisierung gescheitert ist, wenn tatsächlich nur einige der untergeschobenen zusätzlichen Ziele (man kann sagen: erwartungsgemäß) nicht erreicht wurden.

Alles modularisieren

Modularisierung als globales Projektziel vorzugeben reicht nicht aus. Interaktionen zwischen den Modulen erfordern die Definition und Pflege (!) von Schnittstellen. Die Abgrenzung von Systemteilen, die von möglichen Änderungen der Anforderungen betroffen sein können, ist deshalb die hohe Kunst der Modularisierung. Daher muss das richtige Maß an Modularität für jedes Systemteil individuell gefunden werden, wobei die Kosten für das Erreichen und Erhalten der Modularität gegen den tatsächlichen Nutzen abzuwägen sind. Wie bei allen Entscheidungen, die von zukünftigen Ereignissen abhängen, ist das Risiko, etwas falsch eingeschätzt zu haben, nicht vermeidbar. Deshalb sollte Modularisierung nicht als einmaliges Projekt gesehen werden, sondern als immanenter Prozess der Systempflege. Damit wird die Gefahr beseitigt, dass man „vorsichtshalber" in unnötig viele kleine Module zerlegt.

Modularität als Selbstzweck

Wie bereits erwähnt, hat Modularität ihren Preis. Der Nutzen erweist sich erst in besonderen Situationen, in der Regel bei Änderungen. Deshalb ist es unerlässlich, die angestrebte Zielarchitektur gegen die zu erwartenden Änderungsszenarien zu bewerten. Der Unterschied zum vorherigen Punkt besteht darin, dass es hier nicht um die Größe und Anzahl der Module geht, sondern um deren funktionale Abgrenzung. Ein typisches Beispiel für eine zu hinterfragende Modularisierung ist die Isolierung des Datenbankzugriffs in einer Weise, die den einfachen Austausch der DBMS-Software erlauben soll. Während das für ein Produkt, das bei verschiedenen Kunden zum Einsatz kommt, quasi ein Muss darstellt, ist das in anderen Fällen völlig unrealistisch, weil beispielsweise langfristige Vertragsbindung besteht oder allein die Datenmigration unakzeptable Kosten verursachen würde.

Vereinfachungen von funktionalen Abhängigkeiten

Für den Entwurf der Modulstruktur reicht eine grobe Anforderungsanalyse in der Regel nicht aus, weil die Gefahr besteht, dass unverzichtbare Abhängigkeiten übersehen werden. Dieser Punkt ist deshalb extrem kritisch, weil solche Abhängigkeiten oft rein semantisch und deshalb erst bei vollständiger Analyse erkennbar sind. Ein häufig anzutreffendes Beispiel für derart versteckte Abhängigkeiten ist die Verwendung von festgelegten Namen, Kontonummern usw. zur Kennzeichnung von Spezialfällen.

Missachtung bzw. Unterbewertung des „Altsystems"

In der Euphorie des Neu- und Bessermachens sollte man nicht vergessen, dass auch das zu ersetzende oder zu rekonstruierende System seine unbefriedigende Struktur nicht nur unerwarteten nachträglichen Änderungen oder überforderten Entwicklern verdankt. Mancher Design-Entscheidung lag womöglich eine der gerade erwähnten verborgenen Abhängigkeiten zugrunde. Eine gewissenhafte Analyse der bestehenden Architektur kann helfen, später unliebsame Überraschungen zu vermeiden.

Verlust der Übersicht

Gewissenhaftes Vermeiden der beiden letztgenannten Fehler birgt seinerseits die Gefahr, in einer Unmenge von Details zu ertrinken. Das Finden des jeweils richtigen Detaillierungsgrades bei der Analyse und Bewertung von Abhängigkeiten erfordert Erfahrung und sollte möglichst werkzeuggestützt erfolgen.

Ignorieren vorhandenen Wissens

Selbst bei vorbildlicher Dokumentation bleibt immer ein Rest von wichtigen Kenntnissen (u. a. bspw. das Verständnis), der nur in den Köpfen der Entwickler existiert, das betrifft insbesondere Beweggründe für Design-Entscheidungen. Es ist deshalb leichtfertig und risikoerhöhend, auf solches Wissen zu verzichten, so lange es noch verfügbar ist.

Ungeprüfte Annahmen

Manche Annahmen werden so oft wiederholt, dass sie schließlich als Fakten akzeptiert werden. Sehr oft stellt sich dann später heraus, dass sie nur teilweise oder gar nicht wahr sind. Deshalb müssen alle Aussagen, die wichtigen Design-Entscheidungen als Begründung dienen, auf ihre Stichhaltigkeit überprüft werden.

Übersehen der iterativen Natur jedes Redesigns

Redesign ist selten als große Ein-Schritt-Lösung erfolgreich. Im Allgemeinen sind mehrere Zyklen notwendig, um ein wirklich befriedigendes Ergebnis zu erreichen. Wenn das unbedacht bleibt, läuft man Gefahr, unnützen Aufwand in Dokumentation u. Ä. von Systemständen zu stecken, die sich dann als rein temporäre Zwischenprodukte erweisen.

Übertriebener Glaube an neue Technologien

Die Nachteile bekannter Technologien sind weithin bekannt - ihre Vorteile geraten leicht aus dem Auge. Demgegenüber werden bei neuen Technologien vor allem die Vorzüge gesehen, auch weil mögliche Probleme im vorliegenden Anwendungsbereich noch gar nicht bekannt sind. Die Bewertung erfordert deshalb nicht nur den Beweis der effektiv vorteilhaften Anwendbarkeit durch einen überzeugenden Prototypen, sondern auch eine Kostenbewertung unter Einbeziehung des notwendigen Umstellungsaufwands.

Zwischenzeitliche Änderung grundlegender Architekturentscheidungen

Wenn im Laufe der Arbeit festgestellt wird, dass fundamentale Entscheidungen ungünstig oder sogar falsch waren, ist die Versuchung groß, diese nachträglich zu revidieren. Die ausgewerteten Erfahrungen zeigen aber, dass die Konsequenzen solcher späten Modifikationen fast immer stark unterschätzt werden. Weniger riskant ist es, zunächst eine Zwischenlösung in Angriff zu nehmen.

Unzulängliche Projektsteuerung

Wenn die Zielarchitektur definiert ist, muss sie konsequent umgesetzt werden. Das erfordert die ständige Überwachung des Entwicklungsprozesses an Hand nachvollziehbarer Kriterien. Das sollte eigentlich eine Selbstverständlichkeit in jedem Projekt sein, aber gerade bei einer Zielstellung wie Modularisierung, die jeder verstanden zu haben glaubt, ist offenbar die Gefahr besonders groß, dass notwendige Überwachungen vernachlässigt werden.

Kein klares Projektziel

Ein klares Projektziel, das eine solide Fortschrittbewertung gestattet, sollte stets außer Frage stehen. Aber gerade in Modularisierungsprojekten, wo vermeintlich jedem klar ist, was erreicht werden soll, wird diese elementare Regel überraschend oft verletzt. Ohne klares Ziel kann es keine angemessene Projektsteuerung geben. (s. o.)

Verschleiernde Berichterstattung

Einzugestehen, dass bestimmte Ziele realistischerweise nicht erreichbar sind, ist schwer. Dieses Eingeständnis unnötig lange hinauszuzögern untergräbt die Glaubwürdigkeit.

Modularisierung als Tarnmantel

Modularisierung ist ein Projektziel, das dem Management leichter zu vermitteln ist als andere, möglicherweise aktuell sogar wichtigere Rekonstruktionsziele. Es kommt vor, dass deshalb versucht wird, notwendige Überarbeitungen unter dem Deckmantel der Modularisierung durchzuführen. Ebenso wie bei verschleiernder Berichterstattung beeinträchtigt das bei Bekanntwerden die Reputation der Projektverantwortlichen. Außerdem kann man nicht erwarten, dass mehrere Ziele gleichgut ohne Mehraufwand erreicht werden können. Entweder wird das sogenannte Modularisierungsprojekt unangemessen teuer, oder – was wahrscheinlicher ist – das Ergebnis leidet in der Qualität.

Perfektionismus

Alle Reengineering-Projekte benötigen in gewissen Abständen Phasen des Neuordnens und Aufräumens. Aber für diese Arbeiten müssen messbare Abbruchbedingungen definiert sein. Anderweitig besteht die Gefahr, dass bereits guter Code weiter verbessert wird, während anstehende Arbeiten mit größerem Effekt auf das Endergebnis liegen bleiben oder verzögert werden.

 

Schlussfolgerungen

Wie bei jedem Projekt gibt es auch bei Modularisierungsprojekten Fallen. Die hier referierten waren in den untersuchten Praxisbeispielen die häufigsten. Für erfahrene Projektleiter dürften die meisten nicht völlig neu sein. Für jede der genannten Fallen gibt es erprobte Mittel der Vermeidung. Deshalb ist es wichtig, sich der Risiken bewusst zu sein und diese Mittel entsprechend einzusetzen.

Quelle

[1]  J. Knodel, M. Naab, B. Weitzel: Modularity - Often Desired, but Rarely Achieved; Softwaretechnik-Trends; Bd. 35, H. 2, S. 37f.; 2015

Auto: Dr. Jürgen Lampe

Fragen Sie unseren Experten

Nicole Heyne
Marketing/Vertrieb
vertrieb@agon-solutions.de