In diesem Bereich

Links

Schwarmbildung - nicht Wald, nicht Bäume

Erfolgreiche Modularisierung darf sich nicht nur darin erschöpfen, optimale Wiederverwendbarkeit von Quellcode zu erreichen oder perfekte Kapselung von Elementardaten. Viel wichtiger ist es, das Zusammenspiel der Module untereinander und die Abhängigkeiten der Module von einander im Griff zu behalten.

Wenn es gelingt, den Fokus nicht auf einzelne Module und nicht auf komplette Funktionsbereiche zu legen, sondern auf Einheiten mit möglichst wenigen Schnittstellen, dann erhält man im Idealfall ein Softwaresystem, das sich eher verhält wie ein Schwarm als ein Organismus. Eine lokale Störung verhindert nicht das Funktionieren des ganzen Schwarms. Fällt ein Individuum aus, dann kann ein anderes seinen Platz einnehmen. Natürlich muss bei Scatterware, im Unterschied zu einem biologischen Schwarm, das Ersatzinsekt erst programmiert werden, bevor es die Aufgabe des ausgeschiedenen Tierchens zu übernehmen imstande ist.

Es ist ein Perspektivwechsel nötig, um einen Softwareschwarm zu erzeugen. Anstatt erst die Anforderungen in ein umsetzbares Schichtenmodell zu übersetzen und danach schichtweise Module zu entwickeln, sollte ein Softwaresystem angesehen und abgebildet werden als ein Maschinenpark zur Herstellung von verschiedenen Erzeugnissen oder auch abstrakten Ergebnissen.

Alles fließt auf das benötigte Ergebnis zu

Nehmen wir einen Webshop: Die Kapseln seiner Scatterware werden abgeleitet aus den Arbeitsschritten, die zur Herstellung der verschiedenen Webseiten nötig sind. Jede Kapsel erzeugt nur einen Teil des Produkts. Das unfertige Produkt, das von Kapsel zu Kapsel gereicht wird, nennt man in der Scatterware-Terminologie "Maschinom". Man programmiert quasi ein Fließband zur Herstellung dieser Webseiten. Eine Kapsel kann zum Beispiel dafür geschrieben werden, einen Eintrag in der Trefferliste einer Suchergebnisliste anzuzeigen und an die nächste Kapsel im Fließband abgeben, die das passende Produktbild darin einbindet.

Die neue Denkweise ist: Kapsel A erzeugt etwas und gibt dann an Kapsel B ab. Dadurch wird die Anzahl der Schnittstellen klein gehalten gegenüber der klassischen Denkweise: Modul A erzeugt etwas und bedient sich dazu der Untermodule B und C
...und F und H bis Q außer K, falls N durch R ersetzt wird...

Mit einer herkömmlichen Architektur würde man eher eine Blackbox erzeugen, die die ganze Suchergebnisliste erzeugt und sie so konfigurierbar schreiben, dass sie von verschiedenen Webfunktionen aus angesprochen werden kann. Einmal von der Suchseite, wo man aus der Produktbeschreibung die Textpassage mit dem Suchbegriff hervorhebt, dann von der Funktion "passendes Zubehör", obwohl man dort die Ergebnisse nur in der halben Seitenbreite darstellen möchte, dann bei der Empfehlung der Restposten auf der Bezahlseite des Webshops und so weiter.

Man kann es noch so modular aufsetzen, am Ende ist doch keines der Module leicht anpassbar, ohne viele andere Module in Mitleidenschaft zu ziehen.

Der Schlüssel zum Livesystem

Ein übliches Dilemma: das QS-System ist nicht gleich dem Livesystem. Es muss zwangsläufig Fehler geben, die auf dem einen System auftreten und auf dem anderen nicht. Es gehört zwar nicht zwingend zum Wesen von Scatterware, aber mit einer gut durchdachten Scatterware-Architektur ist es recht leicht, gegen Mock-Objekte zu testen. Von da ist es nur ein kleiner Schritt zu einem radikalen Konzeptwechsel: dem Verzicht auf eine eigene QS-Umgebung.

Der Ansatz ist, jeder Kapsel das "Bewusstsein" mitzugeben, ob sie sich in der Zielumgebung befindet und ob der Livebetrieb freigegeben ist. Es darf nur eine einzige Stelle geben, an der diese beiden Schalter definiert werden. Sie heißen in Scatterware Kupplung und genau wie eine Kuppling funktionieren sie auch: sie trennen die Kapsel von der Webseite, die die User sehen. Wenn sich eine Kapsel nicht im Modus "live" befindet oder wenn sie nicht in der Umgebung "Liveserver" läuft, dann werden beispielsweise alle Mails an eine interne Adresse verschickt, gewisse Buchungsvorgänge nicht ausgeführt oder so markiert, dass sie beim Zurückschalten auf den Livebetrieb automatisch wieder rückgängig gemacht werden und dergleichen mehr.

Dies gehört zu den architektonischen Ansätzen, die nur sehr schwer und mit hohem Risiko nachträglich implementierbar sind. Besonders, wenn man den Anspruch hat, dass sogar der Livebetrieb ungestört weiterlaufen muss während eine Kapsel isoliert auf dem Livesystem getestet wird, muss es von Anfang an eine ausgeklügelte Architektur geben, die diese Betriebsart stützt. Der Aufwand wird sich nur für zwingend ausfallsichere Anwendungen rentieren, bei denen kein Wartungsfenster existiert. Der Lohn der Mühe ist, dass A-B-Tests ermöglicht werden, bei denen ein Teil der Anwender eine neue (Beta-)Version zu sehen bekommen, während die Hauptlast mit dem etablierten System gefahren wird.

weiter mit der Umwandlung eines Systems zur Scatterware