OOP 2008: Wider die Wiederverwendbarkeit

Im OBJEKTspektrum 1/2008 hat Nicolai Josuttis einen Artikel zum Thema SOA geschrieben, der mir recht das Herz aufgehen ließ. Besonders hervorheben möchte ich hier von den vielen seiner Aussagen, denen ich beipflichte, allerdings zunächst nur diese:

"Beides zusammen führt dazu, dass sich Wiederverwendbarkeit nicht unbedingt als primärer Business-Case für SOA eignet."

Fast möchte ich darauf nur sagen: Amen.

Denn Wiederverwendbarkeit - oder Neudeutsch: Reuse - halte auch ich für stark überbewertet. Nicht nur in Bezug auf SOA, sondern allgemein in der Softwareentwicklung. Seit die Objektorientierung ihren Siegeszug angetreten hat, lautet die Botschaft "Wiederverwendung ist gut, Wiederverwendung ist ein wichtiges Ziel!".

Irgendwie klingt das ja auch ganz plausibel, nein, geradezu zwingend! Besonders für alle, die ein Auge auf´s Geld haben wollen oder müssen. Wenn etwas wiederverwendet werden kann, dann amortisieren sich die darin getätigten Investitionen umso schneller. Wer wollte das nicht?

Nun, alle die etwas mehr Weitblick haben, wollen das nicht "einfach so". Die Welt ist nicht so simpel schwarz/weiß, wie Wiederverwendungsapostel es gern hätten. Wiederverwendbarkeit steht nicht einfach unökonomische Mehrfachentwicklung gegenüber. Wiederverwendbarkeit und Wiederverwendung haben ihren Preis - und müssen daher wie jede andere Investition abgewogen werden.

Kosten der Wiederwendbarkeit und Wiederverwendung

1. Wiederverwendbares zu entwickeln, kostet deutlich mehr Aufwand, als nur für einen konkreten Zweck zu entwickeln. Es ist Zeit aufzuwenden, um die vielen möglichen Wiederverwendungsszenarien zu sammeln und zu analysieren. Es ist dabei auch mehr Personal involviert. Und die Qualität des Wiederverwendbaren muss höher sein, d.h. mehr Planungs- und Entwicklsaufwand fließt hinein, weil mehr Parteien davon abhängen. Wann sich nun aber ein solcher Mehraufwand amortisiert haben wird, ist ungewiss. Hoffnungen und Wünsche sind oft die Triebfedern, nicht glasklare Kalkulationen.

2. Wiederverwendung ist nicht kostenlos. Sobald ein Zusammenhang entsteht, in dem etwas wiederverwendet werden könnte, der zum Zeitpunkt der Herstellung der Wiederverwendbarkeit noch nicht bekannt war bzw. nicht berücksichtigt wurde, entsteht Anpassungsaufwand. Per definitionem ist die Schnittstelle von etwas Wiederverwendbarem nicht optimal für den einzelnen Wiederverwendungsfall. Wer wiederverwendet, muss sich mehr oder weniger anpassen. Und im schlimmeren Fall muss sogar das Wiederzuverwendende ebenfalls nachgeführt werden.

3. Wiederverwendbares zu finden, kostet Aufwand. Sobald Wiederverwendung nicht in überschaubarem Rahmen abläuft, man also quasi im Hinterkopf haben kann, was denn potenziell wiederverwendet werden könnte, fallen Recherchekosten an. Bei allen Entscheidungen muss explizit geprüft werden, ob "Spezialentwicklung" oder Wiederverwendung angezeigt ist. Ist der Pool des als grundsätzlich wiederverwendbar Klassifizierten groß genug, kann der Rechercheaufwand sogar womöglich den Aufwand einer Spezialentwicklung erreichen. Nicht zu vernachlässigen sind auch negative Effekte auf die Motivation der Projektmitglieder, die ihren Sinn aus dem Entwickeln ziehen und nicht aus der Suche nach Wiederverwendbarem (s. "Implementing component reuse strategy in complex products environments", Ilan Oshri et al. in CACM 12/2007).

4. Wiederverwendung erhöht die Komplexität, denn Änderungen an etwas Wiederverwendbarem haben Auswirkungen auf eine große Anzahl von Verwendern.

Wenn sich eine Spezialentwicklung ändert, hat das potenziell nur Auswirkung auf wenige Nutzer. Wiederverwenbares jedoch muss immer im Blick behalten, dass eine große, womöglich sogar unbekannt große Zahl Nutzer zu Anpassungsaufwand gezwungen werden könnte. Das führt über kurz oder lang zur Versteifung von Wiederverwendbarem, weil die Konsequenzen von Änderungen immer schwerer zu überschauen sind. Dem Versprechen von Änderungen, die nur noch an einem Ort vorgenommen werden müssen, steht also eine Drohung des Kompatibilitätszwangs gegenüber.

5. Wiederverwendbarkeit entwickeln, ist nicht agil. Wer etwas auf Agilität gibt, kann eigentlich kein Freund der Entwicklung von Wiederverwendbarkeit sein. Denn Wiederverwendbarkeit lässt sich nur mit einem Blick in die Glaskugel erreichen. Es muss vom aktuell Nötigen extrapoliert werden. Gefragt ist dann nicht mehr, was jetzt, hier und heute ausreichend wäre, sondern was auch noch morgige potenzielle Fälle abdecken helfen könnte. Das läuft dem Gedanken zuwider, immer nur den aktuell angemessenen Aufwand zu treiben und alle weitere Aufwände bzw. Entscheidungen auf den spätest möglichen Zeitpunkt zu vertagen - weil sich ja bis dahin wieder Anforderungen oder schlicht Erkenntnisse (über Anforderungen oder Technologien) geändert haben könnten.

Wiederverwendbarkeit ist kein Ziel, sondern ein Mittel

Und nun? Wiederverwendbarkeit ist nicht schlecht. Ich mag sie auch - wo sie sich leicht herstellen lässt oder einfach ergibt. Wiederverwendbarkeit halte ich nur einfach für kein taugliches Ziel. Kräfte sollten nicht auf Wiederverwendbarkeit ausgerichtet sein nach dem Motto "Lasst uns erst schauen, was wir wiederverwendbar machen können!" Das mag sich für Controller zwar gut anhören oder Entwicklerpersönlichkeiten entsprechen, die sich gern mit Grundsätzlichem und vor allem Infrastruktur beschäftigen. (Wer würde nicht gern seinen eigenen Persistenzframework basteln und das Thema einfürallemal lösen, statt sich mit ewig wetterwendischen Kundenwünschen herumzuplagen?)

Stattdessen sollten alle Kräfte zu jeder Zeit darauf gerichtet sein, Komplexität zu meistern - und natürlich Kundenwünsche zu erfüllen. Wiederverwendbarkeit ist aber kein Kundenwunsch. Gemeisterte Komplexität jedoch, weil sie Langlebigkeit fördert. Und wenn sich dann an einem Punkt ergibt, dass die Komplexität durch Wiederverwendung sinken würde, dann ist das wunderbar. Dann ist Wiederverwendbarkeit lediglich ein Mittel. Dann ist es Zeit, durch Refaktorisierung Wiederverwendbarkeit herzustellen - falls dem nicht zu hohe Folgekosten entgegenstehen. Aber nicht früher.

Wiederverwendbarkeit und SOA?

Wiederverwendbarkeit und SOA haben deshalb soviel miteinander zu tun wie Wiederverwendbarkeit und Objektorientierung oder Wiederverwendbarkeit und Komponentenorientierung. SOA-Dienste können Einheiten der Wiederverwendung sein wie Objekte oder Komponenten. Mehr nicht. Es gibt keinen SOA-Grundsatz, der da lautet "Services should be as reusable as possible" oder dergleichen. SOA-Services können wiederverwendbar sein - aber ob das angemessen ist, steht auf einem ganz anderen Blatt.

SOA wie Komponentenorientierung - die Objektorientierung lasse ich einmal bewusst außen vor - haben vor allem ein Ziel: die Beherrschung von Komplexität. Große Systeme sollen verstehbar und evolvierbar sein und bleiben. Darum geht es. Und deshalb halte ich eine "System Oriented Attitude" für den wichtigsten Ausgangspunkt aller Softwareentwicklung.

 

PS: In der Entwicklungsgeschichte eines Systems kann es übrigens zu gegenläufigen Bewegungen kommen: Ähnliche Funktionalität kann zu Wiederverwendbarer zusammengefasst werden (Integration) - Wiederverwendbares kann aber ebenso wieder aufgespalten werden, wenn es versucht, zuvielen Herren zu dienen (Desintegration). Auch diese Möglichkeit gilt es im Blick zu behalten. Wahrhafte Agilität versteift sich nicht auf einen Zustand.