Follow my new blog

Samstag, 1. Mai 2010

Sollte Architektur wirklich emergieren? [OOP 2010]

In Objektspektrum 3/2010 steht ein Artikel auf der Höhe der Zeit: “Emergente Architektur: Der machtlose Architekt”. Denn davon spricht man auch hier oder hier. Und woanders mag es auch Emergent Design heißen.

“Emergenz” scheint ein neues Zauberwort zu sein. Es bedeutet soviel wie Entstehung von etwas Ganzem, ohne dass dieses Ganze so geplant worden wäre. Eine Termitenbau entsteht auf diese Weise oder geordnete Menschenströme in einer Einkaufsstraße oder sogar die erfolgreiche Jagd eines Löwenrudels.

Klingt gut, oder? Wäre doch toll, wenn Softwareentwicklung nicht länger krampfhaft und bewusst versuchen müsste, der ewig nörgelnden Forderung nach einer sauberen Architektur nachzukommen, sondern sie irgendwie “wie von selbst” entstehen lassen, sie emergieren lassen könnte.

Zugegeben, eine schöne Vorstellung. Aber glauben tue ich an sie genauso wenig wie an die Rettung der Welt durch CASE, SOA oder O/R Mapper. Trotz aller Erkenntnisse der Komplexitätsforschung sehe ich weiterhin die Notwendigkeit zur Planung von Architektur. Denn:

  • Emergenz ist trivial: Wenn Systeme genügend unbekannt oder genügend groß in Bezug auf den Kenntnishorizont eines Teams sind, dann kann ihre Architektur nicht “auf einmal” geplant werden. Sie entwickelt sich vielmehr über die Zeit in Reaktion auf neue Erkenntnisse und Anforderungen. Jeder Entwicklungsschritt folgt dabei (hoffentlich) den lange bekannten Prinzipien “guter Architektur”. Jeder einzelne Architekt hat dann über die Zeit nur einen Teil zum großen Ganzen beigetragen.
    Emergenz ist letztlich also kein neues Phänomen, sondern nur ein modischer Begriff für Evolution. Weniger Rede von Emergenz und mehr von Evolution könnte helfen, nicht schon wieder nach einer neuen Silberkugel zu suchen.
  • Emergenz ist unvermeidbar: Auch wenn die Kenntnis über das zu realisierende System groß ist, endet die Verantwortung eines Architekten irgendwo. Er ist ja Architekt und nicht Entwickler. Und Planungspapiere sind kein Code. Bei der Umsetzung der Architekturplanung kann daher immer noch einiges passieren und passiert auch. Architekturvorstellungen werden selten 1:1 umgesetzt. Die Architektur eines Systems ist damit immer mehr oder weniger ungeplant und Resultat vieler kleiner Entscheidungen vor Ort während der Implementation.
  • Emergenz ist schwer planbar: Soll ein makroskopisches Ergebnis (z.B. Architektur) emergent entstehen, sind passende microskopische, einfache Regeln zu definieren. Solche Regeln a posteriori durch Analyse von Ergebnissen zu finden, ist eine Sache. Sie jedoch a priori zu postulieren, eine andere. Das makroskopische, am Ende recht simple Verhalten von Schwärmen hat schon Forscherjahre in der Analyse gekostet, auch wenn nur 3 Kernregeln dabei gerausgekommen sind. Was ist dann für so etwas komplexes wie Softwarearchitektur zu erwarten? Ich bin sehr im Zweifel, ob die Softwarekunst darauf schon eine Antwort hat. Entwickler mit TDD vor sich hinwerkeln zu lassen, mit S.O.L.I.D kräftig voran zu schreiten und darauf zu vertrauen, dass Featureteams es schon richten werden, halte ich für zuwenig. Damit sind zwar Richtschnüre auf der Microebene gespannt – doch die führen nicht so unausweichlich wie die Regeln eines Sardinenschwarms zu einem evolvierbaren großen Ganzen.

Architektur braucht, so glaube ich, auf unabsehbare Zeit immer noch ein gerüttelt Maß an expliziter Planung “in der Mitte”. BDUF ist out, soviel ist klar. Gesamtplanungen sind womöglich nicht mal machbar. Microplanung ist ebenfalls kontraproduktiv; sie zerstört Motivation und Effizienz. Doch “in der Mitte” gibt es Raum und Notwendigkeit für explizite Architekturplanung. Denken und Planen hilft, da bin ich mir sicher. Immer noch. Ameisen oder Sardinen mögen nicht planen müssen. Aber “große Maschinen”, die sich auch noch ständig ändern sollen, die deshalb auf der Metaebene konstant änderbar/evolvierbar sein müssen, solche “Maschinene” “sich ergeben zu lassen” durch lokale Anwendung überschaubarer Regeln… das halte ich für zumindest eine verfrühte Vorstellung.

Denn wahre Emergenz" bedeutet eben keine Planung des großen Ganzen. Niemand malt ein Architekturdiagramm. Niemand hat eine Vorstellung von der Form des Ganzen – sondern immer nur von seinem Verhältnis zur Umwelt. Viele kleinste Entscheidungen auf Microebene ergeben – oh, Wunder! – ein wahrhaft elegantes und zweckmäßiges Ganzes. (Wobei Zweckmäßigkeit von Software immer einschließt, dass die nicht nur heute vorhanden ist, sondern auch für morgige Anforderungen leicht hergestellt werden kann.)

Damit komme ich sozusagen zum philosophischen Teil meiner Position:

Keine Ameise versteht das Ganze ihres Staates. Kein Mensch versteht mehr das Ganze einer Volkswirtschaft. Dasselbe mag für ein genügend großes Softwaresystem gelten. Das Internet könnte dafür ein Beispiel sein. So ist das halt, wenn etwas sehr komplex wird.

Das bedeutet im Umkehrschluss jedoch, dass das, was da so groß und komplex ist, was über die Köpfe der Individuen hinaus gewachsen ist, keine (oder nur wenige) von den Individuen planbare Eigenschaften hat. Wir das an der Finanzkrise, wir sehen das an den Entwicklungen im und um das Internet und die neuen Medien.

Wie können womöglich noch etwas Emergiertes erkennen. Wir können das Ganze beobachten. Aber wir können ihm als “Rädchen im Getriebe” keine spezifischen Eigenschaften mehr verordnen. Klar, wir schrauben am Ganzen herum. Jede unserer Handlungen verändert das Ganze. Aber es in eine funktionale Richtung zu bewegen oder auf der Metaebene es Flexibel zu machen… das sind geradezu titanische Aufgaben, deren Lösung unabsehbar ist.

Was bedeutet das für Software, wenn wir uns für sie wünschen, dass ihre Architektur emergieren möge? Mir scheint es, dass Emergenz nur um den Preis eines Kontrollverlustes zu haben ist. Aber wer möchte den schon erleiden? Software soll sehr konkrete Zwecke erfüllen, Architektur ist dafür die Basis. Wenn Architektur dann jedoch “nur” emergiert, wenn Architekten machtlos sind und das Ganze “sich ergibt” aus regelhaften Einzelaktionen… wie stellt ein Team dann sicher, dass der durch den Kunden vorgegebene Zweck zeitig wie nachhaltig erfüllt wird?

image Ergo: Solange wir noch Ziele ansteuern, können wir uns nicht auf Emergenz verlassen. Softwareentwicklung ist kein Selbstzweck. Also kann ihr Ergebnis nicht komplett einer Emergenz anheim gestellt werden.

Das bedeutet nicht, dass wir nicht immer wieder prüfen sollten, wieviel Planung/Kontrolle wann angemessen ist. Wir sollen nach Microregeln suchen, die helfen, Makroeigenschaften “einfach so” herzustellen. Doch um explizite Architekturentscheidungen kommen wir nicht herum. Architekten werden nicht überflüssig und degenerieren auch nicht zu reinen Prozessmoderatoren.

Ein wenig Bescheidenheit mag allerdings angezeigt sein. Eine Haltung der Akzeptanz der Vorläufigkeit hilft. Etwas weniger Kontrolle haben wollen, schadet nicht. Kollektive Intelligenz fördern, ist sicherlich ein guter Ansatz. Aber Planen und Denken bleiben Kernaufgaben von Architekten.

Kommentare:

Uwe Friedrichsen hat gesagt…

Hallo Ralf,

sehr schöner Post!

Ich glaube manchmal, dass es sich der ein oder andere ein wenig zu einfach macht, wenn er Architektur einfach als "emergent" erklärt bzw. dass er (oder sie) schlicht etwas anderes meint. Neal Ford hatte das für meinen Geschmack einmal sehr schön auf den Punkt gebracht, indem er von "Evolutionärer Architektur und emergente Design" sprach.

Architektur kann für die meisten Systeme nicht wirklich optimal upfront gestaltet werden, ein evolutionärer Ansatz ist da auf jeden Fall angebracht. Dennoch ist es ein expliziter Akt zu versuchen, einen für die Aufgabenstellung geeigneten Lösungsrahmen zu finden. Das geschieht nicht "zufällig".

Bzw. es könnte schon zufällig geschehen, wenn wir nur genügend Zeit und Geld zur Verfügung hätten. Emergente Architktur hätte dann nämlich viel mit genetischen Algorithmen zu tun: Wir fangen mit einer willkürlichen Basisstruktur an, modifizieren diese zufällig gemäß unserer Refactoring-Regeln und wenden eine Bewertungsfunktion darauf an (Kundenzufriedenheit, Entwicklerzufriedenheit, Kosten für Anpassungen, etc.), um die nächste Generation auszuwählen, usw. Das wäre dann irgendwie wirklich emergent, weil wir so ohne Kenntnis der eigentlichen Zielstruktur diese entwickeln könnten.

Oder aber im Sinne von Schwarmintelligenz: Das Ergebnis einiger einfacher Regeln löst in Summe eine um eine Größenordnung komplexere Aufgabe, z.B. die Lösung eines komplizierten Klassifikationsproblems unter Verwendung dreier absolut trivialer Regeln für die einzelnen Schwarmmitglieder. (Das ist nämlich eine zweite, häufig übersehene Definition von Emergenz: Dieses "1+1>2" oder das Ergebnis ist mehr als die Summe seiner Teile.)

Das ist jetzt nicht ironisch gemeint; ich fände es klasse, wenn wir auf die eine oder andere Art Architekturen emergent entstehen lassen könnten. Nur sind wir m.E. (noch?) nicht so weit. Für die genetische Variante werden wir wahrscheinlich nicht die Zeit und das Geld vom Kunden bekommen und für die Schwarmvarainte haben wir (noch?) nicht das Wissen: Wir haben keine Ahnung bzgl. irgendwelcher Architekturmechanismen, wie wir eine komplizierte Architekturanforderung auf einige triviale Regeln heruntertransformieren können. Umgekehrt haben wir auch keine Ahnung, welche komplizierten Aufgaben die uns bekannten Regeln lösen.

Wir stecken also weiter in unserem komplexen Umfeld, und dafür wissen wir mittlerweile wenigstens, dass iterative Ansätze mit häufigen Feedbackzyklen, sogenannte empirische oder auch evolutionäre Vorgehensweisen das Mittel der Wahl sind ... etwas besseres haben wir bislang nicht zur Hand.

Etwas anders sieht das m.E. bei dem Design aus, bei dem Ausgestalten und Verfeinern der initialen Lösungsidee. Hier können wir tatsächlich versuchen, uns einfach von einer Reihe einfacher Gestaltungsprinzipien (wie z.B. SOLID) leiten zu lassen und die finale Struktur emergent (natürlich zusammen mit den notwendigen Refactorings auf dem Weg) entstehen zu lassen. Etwas schwierig ist das noch mit der Bewertungsfunktion im Sinne der genetischen Algorithmen, aber bis wir da weitere Hilfsmittel an der Hand haben, fahren wir da mit der Erfahrung der "Senior-Entwickler" gepaart mit einer Portion gesundem Menschenverstand als Bewertungsfunktion ganz gut. Vielleicht brauchen wir da auch gar nicht mehr ...

Zusammenfassend: Ich glaube, dass das mit der "Emergenz" von Architekturen bei den meisten eine unachtsame Fehlverwendung des Begriffs ist: Entweder sie reden über Design (was den Aspekt der Findung einer Lösungsklasse, die zur Aufgabenstellung passt, auslässt, eben den - häufig vernachlässigten - Kern von Architektur) oder sie reden über Evolution.

Und das deckt sich dann m.E. wieder sehr gut mit den - aus meiner Sicht absolut zutreffenden - Gedanken, die Du in Deinem Blog formuliert hast.

Gruß, Uwe

Ralf Westphal - One Man Think Tank hat gesagt…

@Uwe: Ich freue mich, dass wir so übereinstimmen.

Dennoch zur "generischen Architektur": Daran glaube ich nicht, weil diese Verfahren eben mit einer "blinden" Evolution arbeiten, ja arbeiten müssen. Das ist der Trick an der Sache. Am Ende stehen dann immer Lösungen, die niemand versteht - die aber funktionieren ;-) Ein schönes Beispiel findet sich dazu in diesem Buch: http://www.amazon.de/Complexity-Guided-Tour-Melanie-Mitchell/dp/0195124413 Schon bei dem dortigen kleinen Beispiel ist es schwer herauszufinden, warum die eine Lösung der anderen überlegen ist.

Wir wollen und müssen bei der Architektur vielmehr das Gegenteil erreichen: Eine Architektur für ein konkretes System muss verlässlich "gut" werden. Ohne viele Versuche und Irrtümer. Dafür brauchen wir Regeln - auf Makro- und/oder Mikro-Ebene.

Einige kennen wir schon, denke ich. Aber andere müssen noch dazu kommen. Am Ende jedoch - wie von mir postuliert - wird trotz allem aber eben Planung bleiben. Architekturen werden auf einer gewissen Ebene immer entworfen werden müssen, um sie effektiv zu machen im Sinne eines Auftraggebers.

-Ralf

Carsten hat gesagt…

Schon wieder richtig:

Konrad Lorenz erklärt unser Ich-Bewusstsein mit einer plötzlichen Verbindung der biologischen Fähigkeit zu sprechen und der Sprachanlage im Gehirn. Irgendwann ist der Hals und sind die Stimmbänder so ausgeformt, dass sie Laute bilden können. Zudem ist unsere Hand besonders geformt: wir sind die einzige Spezies, die mit dem Daumen den kleine Finger erreichen kann. All diese Sub-Systeme verbinden sich nun schlagartig.
Die Evolution „blitzt“. Er nennt dies Fulgaration.

Die speziellen Eigenschaften des niedrigeren Systems, so Lorenz, sind dabei im höheren enthalten, nie sei es aber umgekehrt.

Wenn man dann Softwareentwicklung und Evolution vergleicht, dann sollen Sub-Systeme klein und beherrschbar sein. Und nun wird gespielt: es werden neue Eigenschaften hinzugefügt, bestehende verändert, einfach nur so, ganz zum Spass. Das neue Sub-System wird mit verkoppelt und muss sich nun beweisen: Ist es sinnvoll, für eine Hand, sechs Finger zu haben? Nein – weg damit.

Leben ist lernen (auch von Lorenz) und spielen (ich glaube, auch von Lorenz). Nun frage ich mal: wie wird den in unsrer Branche gespielt? Rennen wir doch mal zu unserem Chef und sagen: die nächsten drei Wochen daddeln wir mal so rum und danach fragen wir die Leute, ob sie das toll finden und dann schmeißen wir es ggf. wieder weg.

Ralf Westphal - One Man Think Tank hat gesagt…

@Carsten: Wir "spielen" zuwenig in der Branche. Allerdings ändert sich da grad was: Code Katas, Coding Dojos... Wir können hoffen.

Bis wir allerdings da sind, wo andere Höchstleister "spielen", d.h. üben, üben, üben, das dauert noch lange.

Aber jeder einzelne kann etwas daran tun. Wenn wir es als zu unserer Profession gehörig ansehen, dann müssen wir darum auch niemanden bitten. Wenn wir kollektiv sagen: "Der Morgen beginnt für jeden Programmierer mit 'Aufwärmübungen' von 90min.", dann ist das eben so. Punkt.

Kein Tennismanager wird seinem Schützlich verbieten, sich aufzuwärmen oder statt am Tennisnetz im Fitnessstudio zu sein, um gezielt Muskeln aufzubauen. Warum sollten wir uns bei Analogem von einem Projektmanager reinreden lassen?

-Ralf