Follow my new blog

Dienstag, 4. Dezember 2007

OOP 2008: Planlose Softwareentwicklung!

Angeregt durch die Diskussionen rund um SOA im Blog der OOP 2008 habe ich nochmal meine Gedanken schweifen lassen... Gewöhnlich beschäftige ich mich ja nicht mit den großen Enterprise Architekturen, sondern versuche erstmal die .NET-Entwicklergemeinde vom Wert bewusster Architektur im Kleineren, "nur" für ihre Anwendungen zu überzeugen. Aber wo die Diskussion zu SOA schon so lebhaft ist, kann ich mich ihr auch nicht ganz entziehen. Allemal nicht, da sie - unausgesprochen zwar, aber dennoch - etwas mit einem Thema zu tun hat, das mich auch schon interessiert hat: die Beherrschung der Komplexität von Software. Heute nun bin ich beim Gedanken schweifen lassen über eine verwegene Idee in dieser Hinsicht gestolpert:

SOA hat ja sicherlich einiges mit Komplexität zu tun. Oder überhaupt geht es bei großen und noch größeren Softwaresystemen immer um Komplexität, egal ob sie nun etwas mit SOA zu tun haben oder nicht.

Nun scheint es mir, als versuche man diese Komplexität durch gute Planung in den Griff zu bekommen. Hört sich doch auch vernünftig an, oder? Komplizierte, ja komplexe Produkte wollen geplant sein. Vom Auto über einen Airbus bis zur Unternehmenssoftware. In meinen Publikationen und bei meinen Beratungsterminen spreche ich auch immer wieder von Planung für gute Architektur, d.h. bewusster, kontrollierter Anordnung und Verbindung von Softwareartefakten.

Jetzt die verwegene Idee: Was, wenn eben diese Planung kontraproduktiv wäre? Was, wenn Planung umso kontraproduktiver wäre, je komplexer die Software ist? Was, wenn zentrales Vordenken von komplexer Software eine Kontrollillusion wäre? Die Phantasie von "Maschienenbauern" und ein Relikt aus dem 19. Jahrhundert?

Wie bin ich auf solch eine verwegene Idee komme? Ich hatte meinen Blick mal wieder über den Rand meines Laptop in die Welt gerichtet. Eine Stunde beim Sport hatte mir den Kopf freigepustet von überkommenen Softwareentwicklungsvorstellungen. Was ich dann jenseits meines Laptops sah, war eine Welt der Komplexität. Komplexe Systeme überall: vom Ameisenhaufen bis zur globalen Wirtschaft. Und all diese Systeme... ohne Planung.

Es gibt keinen Lenker der Ameisen und Bienen. Es gibt keine zentrale Planung unserer Städte. Auch die Bundesregierung plant nicht zentral. Die heute vorherrschende Ideologie von Demokratie und darauf aufsetzender Marktwirtschaft ist geradezu die Antithese jeder zentralen Planung und Kontrolle. Es gibt vielleicht eine gewisse Lenkung... aber Planung?

Eine Uhr, ein Auto, eine Fabrik... ja, die werden noch geplant. Aber die sind im Vergleich zu (großer) Software auch noch nicht wirklich komplex. Das liegt daran, dass deren Umwelten ungleich stabiler sind, als die von Software. Wirklich komplexe Situationen und "Gebilde" jedoch, die entziehen sich Planung und zentraler Kontrolle.

Auch wenn es Städteplaner gibt, so plant niemand Städte langfristig im Voraus. Oder zumindest werden sie nicht im Detail im Voraus geplant. Städte sind wachsende Gebilde, die vor allem von unzähligen individuellen Entscheidungen geprägt werden. Dasselbe gilt für die Wirtschaft. Das ist geradezu kafkaesk, denn damit ist das große Ganze, das wahrhaft Komplexe nicht mehr in der Verantwortlichkeit Weniger. In einem Schwarm ist bei einem Missstand "der eine Schuldige" nicht mehr auszumachen; es gibt ihn einfach nicht. Dafür ist der Schwarm flexibel, anpassungsfähig.

Auf die Softwareentwicklung bezogen ergibt sich aus dieser Erkenntnis die Frage: Versuchen wir immer noch oder schon wieder zuviel zu planen? Wäre mehr Planlosigkeit, die Abwesenheit eines klaren Planes eine bessere Strategie für Erfolg? Die Agilitätsbewegung hat ja schon in gewisser Weise den Plänen den Kampf angesagt. Inkremente statt Wasserfall, kleine Schritte statt großer Sprung. Aber ist das vielleicht immer noch zuviel? Müssen wir uns vielleicht noch radikaler vom Planen verabschieden?

Probate Mittel, um Komplexität zu beherrschen sind Hierarchien, Ordnung, Entkopplung. Die ultimative Strategie ist jedoch überhaupt die Abgabe von Kontrolle. Wo Komplexität nicht mehr beherrscht werden muss, stellt sie auch kein Problem dar. Dazu bedarf es natürlich des Vertrauens. Vertrauen in diejenigen, an die die Kontrolle abgegeben wird, die unendlich vielen kleinen "Rädchen im Getriebe", die lokale Entscheidungen treffen. Und Vertrauen an die grundlegenden Gesetzmäßigkeiten, die Rahmenbedingungen.

Meine verwegene Idee zum Umgang mit komplexer Software ist also, diese Software nicht mehr zu planen, sondern sie entstehen zu lassen, sie wachsen zu lassen. Komplexe Software braucht keine Planer, die tausende Webservices so oder anders schneiden. Komplexe Software braucht keine vorgedachte Architektur.

Statt eines Masterplans braucht komplexe Software vielmehr Grundwerte und -gesetze, einfache Rahmenbedingungen, die Möglichkeit zum Experiment und maximale Kommunikationsmöglichkeiten für die real-time Kollaboration zwischen allen Beteiligten. Komplexe Software braucht ein Ökosystem, in dem sie sich entwickeln kann. Und das bezieht sowohl Entwickler wie Anwender und Kunden mit ein.

Die Funktion komplexer Software ist dann kein Ergebnis mehr von zentralem Kundenwunsch gechannelt durch Analysten und Architekten, sondern emergent. Komplexe Software ist dann das Ergebnis eines Schwarms und spiegelt die Bedürfnisse und die Intelligenz der Masse wider.

Der Gewinn? Eine maximal flexible Software, die sich ständig den Umweltanforderungen anpasst.

Die Herausforderungen? Ganz ohne alle Vordenken geht es natürlich am Ende doch nicht. Aber die Planung ist verlagert auf die Meta-Ebene. Statt konkreter Artefakte werden allgemeine Regeln für Artefakte geplant. Führung bedeutet nicht mehr Kontrolle der Planeinhaltung, sondern Hilfe zur Regeleinhaltung. Und Führung muss sicherstellen, dass der Informationsfluss ungehindert ist.

Ich weiß, das klingt alles ein wenig utopisch/theoretisch. Wie genau so ein Zeitalter der Post-Agilität, der Schwarmentwicklung aussieht, weiß ich auch noch nicht. Es gibt sicher auch gewaltige technische Hürden zu überwinden; so ist das vorherrschende Modell von Software als Text dafür zu starr, Gleiches gilt auch für die Datenbankschemata.

Aber ich bin mir nach diesem Gedankenausflug recht sicher, dass die aktuellen Antworten auf den Trend zu immer leistungsfähigerer, immer komplexerer Software ungenügend sind - zumindest solange ein wie immer gearteter Drang zu steigender Kontrolle dahinter steht. Denn Kontrolle steht im Widerspruch zu Komplexität. Wenn aber eines sicher ist, dann ist es, dass die Komplexität unserer Software bzw. des Gesamtsystems Mensch-Software oder Unternehmen-Software weiter steigt. Die Kontrolle kann also nur geringer werden - ob wir es wollen oder nicht -, wenn wir passgenaue und überlebensfähige Softwaresysteme haben wollen.

Kommentare:

Usul hat gesagt…

Aber genau das ermöglicht doch SOA? Es soll ja gerade bei Systemlandschaften helfen, wo die Evolution nicht abzusehen ist. Alles was SOA ist, ist zu sagen "die Dienste sollten als unabhängige Komponenten realisiert werden, die über eine zentrale Infrastruktur kommunizieren (und sich finden)". Da ist keine Planung vorgeschrieben. Im Gegenteil: Dieser (zugegebenermassen alte) Grundgedanke hilft doch gerade dann, wenn man eben nicht im Vorraus planen kann, da das "System" wächst.

Jedenfalls zweifel ich die grundlegende These "SOA heisst Planung" an. Darum geht es bei SOA meiner Meinung nach überhaupt nicht. Man KANN natürlich planen, aber darüber macht SOA doch gar keine Aussage.?.

Howard hat gesagt…

ICH bin entsetzt. Jetzt wo ich mich gerade an deine Ideen zum Softwarezellen Modell usw. herantaste gehen Deine Gedanken schon wieder davon weg. Hey mein Tag hat nur 48h!!!

Howard

Ralf Westphal - One Man Think Tank hat gesagt…

@Usul: Ja, du hast wohl Recht, dass "SOA in Reinform" sich gar nicht um konkrete Planung dreht, sondern eher um die Rahmenbedingungen.

Aber auf der anderen Seite nehme ich den Diskurs über SOA wahr. Und wenn ich da zuhöre, dann hört sich das nicht mehr danach an, innerhalb der Rahmenbedingungen Freiheit zu schaffen für die "Schwarmintelligenz", sondern eben konkret durchzuplanen.

SOA-Projekte scheinen eben nicht nur Rahmenbedingungen schaffen zu wollen, sondern auch Kontrolle ausüben zu wollen darüber, was wann wie wo dann eben ein Service wird. Und je mehr, desto besser.

Das ist für mich Planung bzw. Ausdruck von Willen zur Beherrschung von Komplexität. Der ist mir auch verständlich - aber wie gesagt: bei steigender Komplexität müssen wir davon mehr und mehr wegkommen. Vielleicht fasse ich meinen Gedanken am besten so zusammen: Prinzipien (wie die SOA-Tenets) statt Pläne.

Und diese Prinzipien müssen bis zum letzten Entwickler verinnerlicht werden. Und/oder Tools müssen helfen, diesen Prinzipien möglichst einfach zu folgen. Sie nicht zwangsläufig nötig, aber sie können es einfacher machen.

Hans-Jürgen Philippi hat gesagt…

Hallo Ralf, Du hast wirklich ein Talent Ideen zu formulieren, bei denen ich selbst aus dem Stand eine 50-seitige Abhandlung als Antwort schreiben möchte. :-) Hier nur ein paar elementare Punkte, mit denen ich mich selbst schon eine Weile beschäftige:

1. Komplexe Systeme können nur per Selbstorganisation funktionieren, zentrales Lenken ist zum Scheitern verurteilt. Beispiel: Diktatur als Staatsform führt in der echten Welt nicht zu dauerhaft innen und außen stabilen, produktiven Staaten. Demokratie hingegen funktioniert dauerhaft - Demokratie ist Selbstorganisation!

2. Selbstorganisation verlangt autark funktionierende Individuen und ein allgemein akzeptiertes Regelwerk für Handlungen und Kommunikation (Instinkte, Ethik, Moral, Sprache beim Menschen). Dies ist z.B. die elementare Schwäche des Kommunismus, der von der reinen Idee her tatsächlich kein totalitäres System verlangt: Das Regelwerk -z.B. die Idee der absoluten Gütergemeinschaft- wird nur von wenigen akzeptiert und praktiziert.

3. Software-Design/Entwicklung durchläuft eine vergleichbare Evolution (=Mutation und Selektion) wie die Menschheit, d.h. die auf Dauer in der Gesamtheit besser funktionierenden Systeme setzen sich durch. Also wird auch komplexe Software irgendwann zwangsläufig zu Selbstorganisation konvergieren.

4. Für Software gibt es noch kein allgemein akzeptiertes Regelwerk für Handlungen und Kommunikation sondern eine uferlose Vielfalt von Systemen und Sprachen (sic!). Interessant zu beobachten, wie sich beispielsweise mit XML eben die Suche nach einer Standardsprache formuliert, mit der alle "reden" können! SOA wiederum greift die Idee der autark funktionierenden Individuen auf.

Fazit: IMHO hast Du recht mit dem, was Du sagst. Eines Tages wird große Software nicht mehr geplant werden müssen resp. überhaupt planbar sein. Wir sind jedoch in dem Sinne noch im Mittelalter, wo unzählige Kleinstaaten von Landesfürsten, deren oberstes Interesse die Wahrung der eigenen Pfründe ist, mit schwingender Peitsche regiert werden. Es dauert noch ein Weilchen.

Haggy hat gesagt…

Sehr interessanter Gedanke,der für mein empfinden auch einiges impliziert.

Wobei ich glaube, dass hier viel von der Definition des Begriffs "Planung" abhängt.

Z.Bsp. Was bedeutet Planlos ? Bei den scheinbar planlosen Bienen würde ich sogar eher eine insgesamt doch strukturierte Arbeitsweise sehen. Wobei diese aber wie in dem Artikel auf erwähnt nicht zentral oder kollektiv strukturiert ist. Eine einzelne Biene kennt nicht den gesamten Context weiß aber wie sie ihre Botschaft an andere zu vermitteln hat.

Der Gedanke dass jedes Element in definierten Umgebungen existiert und kommunizieren kann, benötigt ja Planung

Und genau da bin ich ,so wie ich es interpretiere, der Meinung des Artikels:

Es ist denke ich entscheiden mehr in einer abstrakten Ebene zu planen als in konkreten einzelnen Elementen.

Wobei sich mir die Frage stellt ob das nicht einfach die Konsequenz daraus ist das wir Dinge mehr und mehr gekapselt betrachten und entwickeln.

Erzeugt diese abstraktere Erwartungshaltung somit nicht die Notwendigkeit Aufgaben auch weniger konkret ,dafür aber komponenten mehr "kollektiv-fähig" zu planen ?

Denn letzteres Ist meiner Erfahrung nach in vielen Projekten vernachlässigt. Da gibt werden einzelne Elemente bis in die letzte Source Code zeile geplant, sind aber dann aber auch nur für diese eine Umgebung lebensfähig.